Experienced Testing Interview Questions & Answers
Have you written Test Plan? What is a Test Plan? What does it include?
Ans: Yes, I have written/contributed to the test plan. A test plan is a document describing the scope, approach, objectives, resources, and schedule of a software testing effort. It identifies the items to be tested, items not be tested, Who will do the testing, the test approach followed, what will be the pass/fail criteria, training needs for the team, the testing schedule, etc.
- Typical Test Plan for as per IEEE-829 contains following)
- Test plan identifier
- Test items
- Features to be tested
- Features not to be tested
- Item pass/fail criteria
- Suspension criteria and resumption requirements
- Test deliverable
- Testing tasks
- Environmental needs
- Staffing and training needs
- Risks and contingencies
What is a TestCase? What does it include?
Ans: Test case is a document, which has a set of test data, preconditions, expected results developed for a particular test scenario to verify compliance against a specific requirement.- Typical Test Case Parameters consists of:
- Test Case ID
- Test Scenario
- Test Case Description
- Test Steps
- Test Data
- Expected Result
- Actual Result
- Test Status
How many Test Cases did you write in your last project?
Ans: wrote about 1000 Test Cases in my last project. (The reasonable number of Test Cases varies from 500 to thousands. The number 1100 test cases can be completed in an 8-month project duration).
What document did you refer to write the Test Cases?
Ans: Requirement document. (NOTE: It can also be Use Cases, or Design Document and purely depends on the company)
Did you have a situation where you did not have any documents (no requirement document, no Use Cases, or no Design Document) and you had to write the Test Cases? How did you write the Test Cases?
Ans: Yes. I have been to that kind of scenario in some companies. There were companies where they had no documents at all (As requirement doc becomes obsolete sometimes for new or maintenance projects)In that case, and I had to discuss the application scenario and functionality with the Business Analysts or developer. Sometimes I prepared a document indicating the main work-flow of the application.
Can you tell me what a Use Case is?
Ans: A use case is a document that describes the user action and system response for a particular functionality.
For example, a Use Case for Banking System can have the following user interactions:
What is Software Development Life Cycle?
Ans: The systems (or software) development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. It includes the following different stages:
- Requirement phase
- Design phase
- Coding (programming)
- Release (Production)
- Maintenance (Support)
What is Build? What is mean by Patch?
Ans: Build: When each of the different modules of software is prepared, they are put in a single folder by the Configuration Management Team, and it is called the ‘Build’.In other words, the developers put their code in the shared location (folder), and all those codes (modules) are combined so that it is a complete application that works.
Patch: A patch (sometimes called a “fix”) is a quick repair job for a piece of programming. During a software product’s beta test distribution or try-out period and later after the product is formally released, problems/bugs will almost be found. A patch is an immediate solution that is provided to users. E.g. Check that for HP UFT they release patches to provide support for new browser versions or to fix any bugs that are found after release.
What is meant by the Build Deployment?
Ans: When the Build so prepared by the Configuration Management Team is sent to different Test Environments, it is called the Build Deployment.
What is the Requirement Traceability Matrix?
Ans: The Tractability matrix is used to cross-check the test cases as per the requirement of the test cases. In other words, it checks whether each functionality is covered in the Test Cases as per requirement document.
What is Exploratory Testing, and when should it be performed?
Ans: The definition of Exploratory Testing is “simultaneous test design and execution” against an application. This means that the tester uses his domain knowledge and testing experience to predict where and under what conditions the system might behave unexpectedly. As the tester starts exploring the system, new test design ideas are thought of on the fly and executed against the software under test.
In an exploratory testing session, the tester executes a chain of actions against the system, and each action depends on the result of the previous action. Hence the outcome of the result of the actions could influence what the tester does next. Therefore the test sessions are not identical.
This is in contrast to Scripted Testing where tests are designed beforehand using the requirements or design documents, usually before the system is ready and execute those same steps against the system in another time.
Exploratory Testing is usually performed as the product is evolving (agile) or as a final check before the software is released. It is a complementary activity to automated regression testing.
What Test Techniques are there, and what is their purpose?
Ans: Test Techniques are primarily used for two purposes:
- To help identify defects,
- To reduce the number of test cases.
- Equivalence partitioning is used to reduce the number of test cases by identifying different sets of data that are not the same and only executing one test from each set of data
- Boundary Value Analysis is used to check the behavior of the system at the boundaries of allowed data.
State Transition Testing is used to validate allowed and disallowed states and transitions from one state to another by various input data
- Pair-wise or All-Pairs Testing is a very powerful test technique and is mainly used to reduce the number of test cases while increasing the coverage of feature combinations.
How do you test the login feature of a web application?
Ans: the Possible answer to these questions :
- Sign in with valid login, Close browser and reopen and see whether you are still logged in or not.
- Session management is important – how do we keep track of logged-in users, is it via cookies or web sessions?
- Sign in, then log out and then go back to the login page to see if you are truly logged out.
- Log in, then go back to the same page, do you see the login screen again?
- Sign in from one browser, then open another browser to see if you need to sign in again?
- Log in, change the password, and then log out, then see if you can log in again with the old password.
How do You Verify the Results of Your Search on Search Results Page?
Ans: In the first instance, we need to know where the data is coming from. Are they coming from a database? Or some XML files from 3rd party websites?
Once we have this information, we can start comparing the results we see on the result page with the results from the source, e.g. database.
Another option is to use mocks to generate the data that we need so we can fully control the data that we see on the search results page.
How is Web Application Testing different from Desktop Application Testing?
Ans: Web Applications are typically hosted on a server that we can access via a web browser, whereas desktop applications are installed on the client’s machine.
This setup opens a whole new testing challenge: Performance and Security testing become important as the application is open to a wide audience. Good design and usability are also important.
Other important factors that come to play are testing on multiple browsers, multiple devices, redirection, and responsiveness.
What are the HTTP response code blocks, and what do they mean?
Ans: After a request is sent to a server, there are different possible response codes which can be returned by the server:
The blocks are:
- 2xx for Success, the most common one is 200, which means “OK”.
- 3xx for Redirection, the most common ones are 301 and 303 which means “Permanent Redirect” and “Redirect for Undefined Reason”, respectively.
- 4xx for Application Error, the most common ones are 403 and 404 which means “Forbidden” and “Not Found”, respectively.
- 5xx for Server Error, the most common one is 500 which means “Server Error”.
How would you Test a Service Oriented Architecture (SOA) Web Application?
Ans: The testing of web applications that communicate with a web service can be broken down into two parts:
Testing of the Web Service in isolation. Each web service has one or more functions that can be tested by sending appropriate requests and analyzing the response and verifying correct data is returned in the response. We can use tools such as SoapUI to test a Soap Service or Rest Client to test a RESTful web service.
Integration Testing of Web Service with the Front End. The integration testing is also important as it can highlight issues with data in the request and display of the response. The reason for this separation is to be able to identify issues in the web service much quicker and easier to debug.
Suppose you have a Login form that is connected to an Authentication Web Service. What tests would you perform at which layer?
Ans: All the input/output validation should be tested at the API layer calling the Authentication Web Service. Tests such as valid/invalid username/password combinations as well as verifying correct error messages.
There are many ways to test a website, and there could be lots of test cases to execute, how can you make sure the web application is fit for release?
Ans: We can Automate the majority of test cases, but most importantly we can use test techniques such as Pair-wise testing to reduce combinations and/or model-based testing to plan user journeys to ensure major functionality of web application works.
We can also use paralytics to gain insight into what users do on the website, which page is most popular and which feature is most used by users.
What is a Web Service?
Ans: A Web Service is a program that can be accessed by other programs over the web (HTTP).For example, let’s assume that you have a function that prints a text in HTML format. The application’s target is the web browser which renders the output, and a human being can easily read the text on the page.
On the other hand, a web service’s target audience is other programs or other web services that consume the data served by the web service. The output is normally in a standard language that can be understood by other programs. Take the above example, if the web service outputs the text in say XML format, then other web services which can read or understand XML can use the output.
The main advantage of a Web Service is that applications can be written in any language, but they can communicate and exchange data with each other through a Web Service. Software applications written in various programming languages and running on multiple platforms can use web services to transfer data over the internet (HTTP). This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards (XML, SOAP, HTTP).
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery, and Integration)
WSDL (Web Services Description Language)
Experienced Testing Interview Q&A
Tell me something about yourself?
Ans: I started my career as a QA in the year ____. Since then, I have worked on several operating systems such as Windows XP,2007, and Windows 8, etc. Testing applications come very handily to me. I have taken care of applications in a domain such as Healthcare, CRM, ERP, etc.
Being a QA, I also have experience in the field of writing. Test Plans, Test Cases are a few examples. I have also attended several meetings with project managers and business analysts.
When different kinds of testing come into question, I have explored that field as well. Whether it is Smoke Testing, Integration Testing, Regression Testing, Blackbox or UAT Testing, I have given all of them a shot. Writing defects is something other I laid special emphasis on. I would always assess, reassess, and test them thoroughly before passing it on. If the defects were not fixed, I would make an effort to reopen them again.
What do you think is a test plan? Have you written one before? What does it usually consist of?
Ans: A test plan is a sort of document which analyzes the resource, scope, approach, and schedule of several testing activities. It will help you to find items that need to be tested, its features that need further testing, the risks that come with some and the solutions as well.
Yes, I have written a test plan before. It consists of history, contents, introduction, scope, overview, and approach. The risks and assumptions are not left out either.
Define a Test Case and a Use Case? What do they consist of?
Ans: A test case is again a document which gives you a step by step detailed idea on how you can test an application. It usually comprises results (pass or fail), remarks, steps, outputs, and description.
A use case on the other is a document of another kind. It helps you understand the actions of the user and the response of the system found in a particular functionality.
What is a test strategy?
Ans: A test strategy helps you understand the process of testing in every software development cycle. It has been made in such a way that all project managers and developers will be informed about some of the most important issues of testing. All objectives, methods, total time and the resources which are needed for the project are explained.
A few components you will always find in a test strategy are tested level and test schedules, test groups, and test priorities, test summary, requirements of the environment, responsibilities, etc.
Name the different kinds of software testing
Ans: A more structured answer would be
Functional / Non-functional
Non-Functional: usability, portability, performance, load, stress, endurance, soak, reliability, install-ability, maintenance-ability, security, scalability
White-box / Gray-box / Black-box
Unit tests / Integration tests (inter-app / outer-app) / System tests / UAT
Alpha / beta / A-B
Supporting types: regression, smoke
What is SQL?
Ans: SQL stands for Structured Query Language. It is an American National Standards Institute computer language that is used for analyzing and assessing the database systems. The statements of SQL are used to get hold of data and retrieve it. They only work with database programs such as MS Access, Informix, Oracle, Sybase.
However, there are also different kinds of SQL languages found today. They have to be in compliance with the standards of the ANSI. The keywords should be supported in the same way.
Describe Change Control?
Ans: Change Control is also popularly known as Change Request. It tells us in detail about the additional functionalities which are included once the Business Requirement Document has been signed off.
What is the build?
Ans: A build is a component or a folder that contains one of the modules of the software. The Configuration Management Team usually prepares this.
Describe the bug life cycle?
Ans: Bug life cycle comprises various statuses of an error during its life cycle. A few examples are open, deferred, solved, reopened, fixed, solved and closed. You may also speak about this process and how you monitor and determine the status with the help of several points.
Tell us about the biggest bug you have ever found.
Ans: In my writing experience, I have found several defects. Some of them were small, whereas some of them were huge. The biggest one I have encountered so far is in the previous project on a page where I found a button called “More Information”. Once the person using the computer pressed that button, a new window would automatically pop up. I would then close the window by using three ways. First, I would click on ‘X’ located in the top right corner of the page. I would then click on a Close button and finally the combination keys on the keyboard.
How do you plan on dealing with your team members?
Ans: There are higher possibilities that I won’t be the only one on the team. At times dealing with the team members can get very difficult and frustrating. There will be quarrelsome dispositions and misunderstandings, and some will also try to ignore the other. But my purpose is to look beyond all of this. We are a team, and we should work together to reach a common goal. I will be friendly and invite them over for coffee. As a human, it is very important to share feelings and have important discussions, and that is exactly what I intend to do. This is something that not only me but everyone else in a working environment should apply.
Have you used automation tools before?
Ans: For Automation Tools, we are considering Functional Automation Testing Tools. In some projects, I used Selenium Web-driver for building Smoke and Critical Test Cases. We have also used JMeter for performance testing to check some performance parameters.
Do you like the QA job? If yes, tell us why?
Ans: Yes, I do like the QA job. The only reason behind this is because the job is process-oriented. This means that here I have the opportunity to do try several things at the time. I can analyze the needed documents, test the application, write test plans and test cases, prepare reports and retest them once again if the need arises. My favorite task would be reducing defects. The more defects I find while working, the happier I will be.
Consider if there is no Test lead, No Test Manager, and QA Manager. If you are the senior test engineer, you are getting pressure from the client to give the build. But you see that there r 5 high and 5 low severity bugs. So, what you will do and how you interact with the client?
Ans: As you said, 5 bugs are high, and 5 bugs are low severity. If there is no test lead or manager not available as a Senior Testing Engineer, I will concentrate on 5 high severity bugs. First, I will understand them and send them to the particular development team with the help of the project manager. If required, I will explain to them the situation and about the bug severity.
Also, I will interact with the client on behalf of my test team, and I will make them understand the current status of the application.
Suppose a website contains 20 pages & having a similar type of error in most pages. Tester checked one page & posted the bug in a bug-tracking system including that this bug remains in most pages, but the developer only debugged one page (the location Tester had written). Now, who is responsible for checking other pages, Developer or Tester?
Ans: Yes, it is the responsibility of the tester to identify the bug. While Posting bugs, we have to specify that this bug is repeated on another screen also.
By mistake you have posted a bug saying that error is displayed in a single page ….Then there is a thing called Defect discussion where the nature of the bug is discussed with the development team at the end of the day where the development may come to know the nature of the bug.
You have completed a project, and the release date is the next day, you got one big problem, but that problem can’t be resolved in a short time, and the estimate is 10 days. What are your options?
Ans: We could think of any workaround which would be suitable at that point of time for the problem, and make a note in the Release notes.
In case there is no workaround, then a note should be mentioned in the release notes stating it as a known issue.
You have tested the application, and it is released. The user asks for some changes in the project and gives one week’s time to complete it. Out of the one week, 6 days is taken by the developer to make the changes. So you have only one day to test it. What will you do in the case in case of manual testing?
Ans: In that case, we can test the main part of the application, we can found 80% of errors in that main functionality only, for that we can mainly concentrate on main functionality.
High priority, then why do priority given by project managers and severity given by testers?
Ans: High severity bugs affect the end-users. Testers tests an application with the user’s point of view, hence it is given as high severity. High priority is given to the bugs which affect the development. Project managers assign a high priority based on the development/deployment point of view.
If you have executed 100 test cases, every test case passed but apart from these test cases you found some defect for which test case is not prepared, then how you will report the bug?
Ans: While reporting this bug into a bug tracking tool, first you will generate the test case, write the steps to reproduce the bug. Then bug will be reported.
Suppose the product/application has to deliver to the client at 5.00 PM. At that time, you or your team member caught a high severity defect at 3 PM. (Remember defect is high severity)But the client cannot wait for a long time. You should deliver the product at 5.00 pm exactly. What procedure will you follow?
Ans: The bug is of high severity. So we can send the application to the client and find out the priority of the feature having a bug. If its priority is low, then we can hide that feature otherwise we should:-
Difference Between HTTP and HTTPS
- URL for the HTTP begins with HTTP:// and that for HTTPS with https://
- HTTP used port 80 for communication. HTTPS uses port 443.
- HTTPS requires an SSL digital certificate which is not required in case of HTTP.
- As discussed earlier, HTTP is unsecured, whereas HTTPS is secured.
- HTTPS uses encryption which is not used in HTTP.
- HTTPS operates at the transport layer of the OSI model. HTTP operates at the application layer.
Difference Between getting and POST
- GET request is sent via the URL string (appended to the URI with a question-mark as separator), which is visible.
- The POST request is encapsulated in the body of the HTTP request and can’t be seen.
- GET request goes via URL, so it has a limitation for its length.
- POST Request has no limitations on length.
- GET request is comparatively faster than POST request.
- GET request is sent via URL string and as we all know that URL can be text-only, so GET can carry only text data.
- POST request has no such restriction, and it can carry both texts as well as binary data.
- GET request is nothing but a URL; hence, it can be cached as well as Bookmarked.
- POST request doesn’t have such facilities.
- GET is the default method of the HTML FORM element.
- For the POST method, we need to specify the method attribute and give it the value “POST”.
- GET requests are restricted to use ASCII characters.
- Post requests can use the ‘enctype’ attribute with a value “multipart/form-data” to use the Universal Multiple-Octet Coded Character Set(UCS).
Difference Between Usability Testing and GUI Testing.
- Graphical User Interface testing is done to check the appearance of the application.
- Usability Testing is done to check the easiness of the application.
- GUI Testing is done to test the look and feel of the application.
- Usability Testing is done to test the user-friendliness of the application
- GUI Testing includes colors, fonts, font sizes, buttons, links, icons, which are displayed as specified or not.
- Usability Testing includes if the application displayed all mandatory fields, cursor positioning to enter the data into the right field, tab button should work easily, etc.
- GUI Testing– In this testing, we test only the front end of the application.
- Usability Testing – In this testing, we test the overall working of the application according to a non-technical user’s point of view.
Difference between Ad-hoc Testing and Exploratory Testing.
- Adhoc Testing begins with learning application first and then start working on the testing process
- Exploratory testing means test application while learning.
- Adhoc Testing– Tester knows the application in advance
- Exploratory Testing – Tester doesn’t know the functionality of the application at first.
- Adhoc Testing – Documentation is not mandatory.
- Exploratory Testing – Documentation is mandatory.
- Adhoc Testing – Expert tester is not needed for this type of testing
- Exploratory Testing – Expert Tester is needed for such type of testing
- Adhoc generally is the informal testing type to break the system. This testing is usually an unplanned activity.
- An exploratory is a testing approach that involves simultaneous learning, test design, and test execution.
- Adhoc Testing Example– While Testing WhatsApp user can start with any module to break the application. The tester can start any random module.
- Exploratory Testing Example – While Testing WhatsApp, the first scope has to be defined(Test Attach Document functionality), so now tester has defined area of testing and can explore this area and user his creativity to find issues
Explain Version, Revision, and Releases.
- Version: An initial release or re-release of a configuration item associated with a complete compilation or recompilation of the item.
- Different versions have different functionalityRevision: Change to a version that corrects only errors in the design/code, but does not affect the documented functionality.
- Release: The formal distribution of an approved version.
When do you start testing the application?
Ans: Criteria to start testing may include the following points:
- Definition of all test scenario and test cases are completed
- Functional and Business requirements should be cleared, confirmed and approved.
- Test Environment is ready(Availability of hardware and software for initiating testing is ensured)
- The bug tracking system is in place and accessible.
- Test Data is available.
- Unit Testing is done successfully by developers.
- Tester is having significant knowledge of the application under test
How would you test software applications without any formal documents like Requirement Document?
Ans: Have a meeting with Project Stakeholders who were part of project initiation(Business Analyst, Project Manager).
They can elaborate on functionalities present, Expected Results and Business rules that drive application Have a session with developers as they are part while developing software and have considered some requirements. They know the major functionality of the software and can elaborate more.
Do some exploratory testing and learn application functionalities wise. Exploratory testing is an excellent way to learn application from a tester point of view, and usually, self-learning adds boost or confidence. Most of the small scale companies don’t have documentation. In this testing, the tester has to rely on his previous experience in testing similar kind to application
What is the Quality Gates? Why should it be used?
Ans: Quality Gate is an activity that is present between stages of a project life cycle. This activity must be completed before moving to the next phase of the project lifecycle. It’s a general criterion that must be satisfied before moving to the next stage in the project life cycle.
e.g. Software Requirement Specification(SRS) may have Peer Review
A Requirement Traceability Matrix (From BRS to SRS) Signed Off by Client, Project Manager. After completing the above Quality Gate, then the only project moves to the next stage, i.e. High-Level Design Phase in Software Development Life cycleway to use it: As per definition, it can be used to improve the visibility of quality in SDLC Stages. It is used to reduce project risk through phase by phase quality gates. (You can compare Quality Gates with Entry and Exit Criteria used in Testing Phase. Both are on the same lines.)
If there are two defects in Application: One is with High Severity and Other with High Priority. Which one must be fixed first.
- Severity is related to testing/QA Term and its an impact of a defect on Application.
- While Priority is related to Business Term and its an impact of a defect on Overall Business or End Users.
So defect with High Priority have to be fixed first as it affects end-users or business.
How do you define software product quality?
Ans: Software Product Quality can be defined in terms of following quality attributes
- Reliability: Software products should be reliable in terms of Availability, Fault tolerance and consistent. Consistent means it should give correct results at any-time and under any conditions.
Maintainability: Maintainability is the ability of the system to change with a degree of ease. These changes could impact components, services, features, and interfaces when adding or changing the functionality, fixing errors, and meeting new business requirements.
- Re-usability: Reusability defines the capability for components and subsystems to be suitable for use in other applications and other scenarios. Reusability minimizes the duplication of components and also the implementation time.
- Usability: Usability defines how well the application meets the requirements of the user and consumer. It defined how the application is easy to use.
- Testability: Testability is a measure of how easy it is to create test criteria for the system and its components, and to execute these tests to determine if the criteria are met.
- Security: Security is the capability of a system to prevent malicious or accidental actions outside of the designed usage, and to prevent disclosure or loss of information. A secure system aims to protect assets and prevent unauthorized modification of information.
- Scalability: Scalability is the ability of a system to either handle increases in load without impact on the performance of the system, or the ability to be readily enlarged.
Performance: Performance is an indication of the responsiveness of a system to execute any action within a given time interval. It can be measured in terms of latency or throughput. Latency is the time taken to respond to any event. Throughput is the number of events that take place within a given amount of time.
- Interoperability: Interoperability is the ability of a system or different systems to operate successfully by communicating and exchanging information with other external systems written and run by external parties. An interoperable system makes it easier to exchange and reuse information internally as well as externally.
If you have ‘n’ requirements and you have less time, how do you prioritize the requirements?
Ans: In such a scenario, the most critical requirements need to be finalized with discussion from the client and stakeholders. In testing, requirements aren’t really ‘finalized’ by the testing team.
How do you find the regression scenarios if a defect is fixed?
Ans: Regression scenarios would be run on all the test cases that failed during manual testing because of the bug in the software. Checking the history of the bug may help to identify the regression scenarios. Also, we have to decide by observing bug and what could be affected functionalities due to such bug.
Let’s say you have a test-plan with over 200 test cases. How do you decide what should be automated, and what should still be done manually?
Ans: In such a case, we need to consider two points
- Priorities of Test Cases
- Feasibility of automation for Test Cases listed
- Some of the questions that the candidate should raise to evaluate: Now using the following criteria we have to divide test cases in Automation and Manual way
- Test cases taking a lot of time to execute manually and are tedious.
- Parts of the application which needs regular regression(We can check defect history to get most error-prone areas)
- Test cases can be done manually and easily.
- The test cases that are not easy for manual testing. (If Selenium tool is being used and the test case is more involved with Windows controls, i.e. nonbrowser)
- Areas of the software application that could be changed in the next weeks. This will prevent us from developing automated test cases for the same
What to do when we are out of time, the application is not bug-free, and tomorrow it’s going for production?
- Step1: Make a list of all open defects and share across all key stakeholders like Requirement Owner (PO, Business Analyst), Dev Lead, Dev Manager, Test Lead, Test Manager, Delivery Manager (stakeholders may vary.. depends on your project)
- Step2: Schedule a defect triage meeting to prioritize all defects in the following categories –
Category A: Issues that must be fixed. Software cant is released without that.
Category B: high-priority Issues that should be included in the solution if it is possible
Category C: Issues which is considered desirable but not necessary
Category D: Defects which will not be fixed (issues which do not generate any value addition to the software)
- Step 3: All stakeholders should decide to go/no-go based on the following:
– Can we accommodate Category A issues within deadlines?
If Yes – Can we accommodate category B issues within deadlines? If No – Can we accommodate category B issues post the release?
If No – Which all issues from category A can be accommodated? Can the release date be postponed? If Yes, are there any contractual obligations from the customer?
Note – “accommodate” means – Issues should be fixed, code reviewed, tested with impact areas. Remember that last minute’s major fixes are usually dangerous. So take a wise decision. This decision has to be taken by key stakeholders (not just the test team). Make sure that the team gives their inputs on impact and testing efforts based on the experience.
Also, remember that – the Testing team has “some” control on quality. The entire team (dev/test / PMS, etc.) are responsible for the quality.
What is defect measurement?
Ans: Defect Measurement is a process for analyzing the efficiency of the developer and tester and the process on the base of the bug details collected from one project.
Through Defect Measurement below are all the factors are measured
Efficiency of developer
Efficiency of tester
Whether the progress is in gear?
Why not use exhaustive testing? How to prioritize test cases?
Ans: Exhaustive testing is a test approach in which all possible data combinations are used for testing. It takes a lot of time, that’s why we need to use some testing techniques. In another way, we can priorities test cases so that testing efforts can be reduced and tester/QA can focus on more important functionalities. We can priorities test cases according to perceived risks, and customer expectations towards feature and tester can reduce the number of test cases. Below are some factors to consider in prioritizing test cases:
- Functionalities used mostly by end-users
- Functional Areas with a history of bugs. (Examining defect history)
- Most visible functionalities to end-users
- Newly added functionalities
How is load testing performed on a website? How does it work?
Ans: To access a website, a user sends a “request” to that website’s server, and the server sends back a response in the form of the website/page you want to access. To load test a website, QA engineers and Automation Engineers need to multiply the number of requests sent to the server to simulate different traffic loads. The web server’s response to the number of virtual users can then be measured by using a performance tool. This is used to determine performance issues and server capacity.
What are the different types of environments used in software releases?
Ans: Generally, companies have four environments. Dev, QA/Testing, Staging, and Production
- Dev Environment: Its generally used by developers to commit the working copy of the code. It contains the most recent version of the application. Many developers merge their code into this environment.
- QA Environment: This environment is solely used by Testers/QA to test applications.
- Staging Environment: This environment is a copy or mirror of the production environment. It looks the same as the production environment as it may contain very recent data from productions. We can call this release candidate. The staging area contains the “next” version of the application and tester tests application for the final release. The tester may find issues here as data is the same as of production environment.
- Production Environment: It is nothing but the live site.
What is meant by a test log?
Ans: Test log creates an environment which consists of an integrated management environment where you can create and manage your entire test plan, other than your test cases.
- It helps in managing the development life cycle.
- It also helps in promoting the reusability of the test cases.
- It helps in improving efficiency.
- It also helps in managing the xml database.
- It helps in documenting both automated and manual test cases.
What is the difference latent defects and masked defects?
- Latent Defects: These are the defects that are present in the system. These defects remain for a long time and can also be detected in different versions of the software. It may be detected after the release. The main reason for this defect is because the exact set of conditions haven’t met.
For Example, February has 28 days. The system will not recognize the leap year and shows an error for leap year. This defect remains in the system and will be recognized in the latent defect.
- Masked Defects: The main functionality of these defects is that they will hide the other defects in the system. These defects can be observed by in-page navigation.
If there is a defect in the current page and it causes a problem in moving to another page, then the defects on the next page can’t be seen.