Saturday, 27 August 2016


1. During testing, you find a bug and assigned it to developer. But developer rejects the bug saying that it is not a defect. How you will handle this situation?

First of all bugs should be logged with proper reproducible steps, screen shots etc…
If developer rejects the bug, then first thing to look out for is the reason or justification on why the bug was rejected. If the justification is valid I would agree for the rejection. However, if the reason is not justified then, I will go back and try to reproduce the bug with the steps I had provided earlier. If it is still reproducible, I shall reopen the bug with valid comments and will provide additional information if I found any. Then I would go back to the developer asking for justification on the rejection. At this point I shall include BA and technical lead also is to take confirmation on the defects

2. If there is no enough time for test execution, how will you approach?

If there is no enough time for testing, my first focus will be on the priority of the requirements. The functionality which is the most important for the release would be the first tested. Next I would focus on the areas where the probability of finding defects is high. I would also analyze by test cases and execute the high priority test cases first followed by medium and low if time permits. If I know the application well and have previously worked on it, then exploratory testing is a good approach when there is no much time. All these should be approved by the Test Manager and should be documented in the test strategy.

3. What is QA role in each phase of SDLC?

It is always a good approach to include QA from the first phase of SDLC. In requirement planning and analysis phase QA gets involved in document review of requirements (SRS). This will help in understanding the requirement right from the early stages. In Design phase, the main task is to prepare the Test Plan, Test Strategy. We can also come up with test scenarios in this phase. During development phase QA will break the test scenarios into test cases. Test data, test scripts, test environment setup etc… is done in this phase. Various kinds of testing is performed during the test execution phase and defects are logged. Defects summary reports and generated and sent to the team. We closely work with the development team in closing the bug. During the maintenance phase test summary report is sent to all the stakeholders and we also participate in the lessons learnt sessions.

4. What is exit criteria of testing? / When to stop testing?

It is not possible to ensure that an application is 100% free of defects. At some point the testing should be stopped and we have to give a sign off so that the application can be released. The exit criteria of testing will be mentioned in the Test Plan before testing itself. We consider a lot of criteria to decide when to stop the testing. For example the project timelines (we cannot test endlessly, testing cycle should be estimated by keeping the project release dates), All the defects have been addressed and closed, all the test cases have been executed, traceability metrics is done (which means test cases have been executed for each of the requirements). These are some of the factors which are considered for stopping the testing.

5. When do we start testing?

It is always better to start the application right from the beginning of SDLC rather than waiting for the testing phase. Because the cost of defect fix increases based on the time it was found. Start of testing activities would start from Analysis phase itself. There we will involve ourselves in understanding the requirements. Once test plan, test cases etc… are written, it is always better to get involved in the unit testing itself. In addition to in during testing phase testers will not simply start testing. Testing would began when the testing entry criteria are met. For example developers should stop the coding and code freeze should be done. We cannot test if developers are working on the application and have not finished their coding. Also they need to deploy the code in a separate environment and proper release notes should be sent.

6. Have you written any test plan? What are the contents of test plan?

Yes I have been involved in writing test plan. Test plan will contain the scope and all the activities of testing. The main contents of test plan is testing scope, testing approach, resources and testing schedule. In testing scope we will say the testable and non-testable functionalities. In testing approach we would mainly mention the testing environments, different kinds of testing, testing cycles, the test cases which will be executed, testing data and scripts etc…It will also say the test entry and exit criteria. Which means when testing will be started and stopped. The roles and responsibilities of each resources would be mentioned and testing schedule and timelines are also mentioned in the test plan. In addition any risk/assumptions and dependencies are also mentioned in the test plan.

7. Explain STLC?

Software Testing Life Cycle is a testing process which is executed in a sequential manner to meet the testing goals. There are different phases of the STLC. Each phase will have different activities and deliverables. Different phases of STLC are
Test Planning Phase: - Here testing objectives are defined and we come up with the test plan. In this phase we will check on automation feasibility, we will prepare the test plan and test effort estimation.
Test Analysis and Design Phase: - In this phase we will do the test case designing, write test scripts, prepare the test data. We will make the test environment ready
Test implementation Phase: Actual testing is done in this phase. Different types are testing is executed, test results are shared and bugs are logged. Re-testing and bug closure is also done in this phase. We will come up with test results and bug report in this phase
Test Exit Phase: - In this phase we will verify if more testing is required. Testing closure activities are carried out in this phase. Test summary reports and testing metrics are created and shared to the stakeholders in this phase.
Test Closure Phase: - Once the test exit criteria is reached, in this phase we will archive all the documents that we have prepared from the beginning. So that it can be used later. Lessons learnt sessions are done in this phase so that we can know what went well and what can be improved so that upcoming releases are smoother.

8. Have you done any reviews for QA deliverables?

Yes, I have reviewed QA deliverables mainly test plan and test cases. QA checklist is maintained for each of the deliverables and the reviews will happen against the checklist. First of all for all the deliverables that I prepare, I do a self-review. Then I would give it to my team member who does the peer review. Similarly I have also done peer reviews of my team mates documents. Before the review walkthrough of the document is done so that it becomes easier to read the document. My team maintains a checklist which needs to be given important during the reviews. For example if I am reviewing the test plan, I ensure that areas to be tested and non-testable requirements are properly documented. All the test cases and test data is inserted, risk and dependencies are described etc… During reviewing test cases my focus will be first to check the requirement traceability, which means for each requirements if the test cases are available. Next my focus will be on test coverage. I will check of all the scenarios have been covered etc…

9. What is the difference between verification and validation?

Verification means “Are we building the product right?” and validation means “Are we building the right product?”
Which means in verification the focus will be are we building the product based on the requirements and design. Where as in validation the focus is on is the product behaving properly (in terms of customer expectation).
Verification examples: reviews, meetings
Validation example: testing (different types of testing

10. What is difference between regression and retesting?

Regression testing: Once the application is changed (for example after fixing a defect or some enhancement is done), we need to test and ensure the existing functionalities are working fine. This is called regression testing. For example if a new text box is added to a web page. Then we have to ensure the look and feel is not disturbed after introducing the text box also other fields which were already there in the page is working as expected. This is regression testing
Re-testing:- after a defect is found by testers and then fixed by developers, it is again tested to confirm that the original defect is actually fixed. Retesting is done to make sure that the test cases which were failed earlier due to some defect is now passing after the defect is fixed.

No comments:

Post a Comment

Search This Blog