June 08, 2013

Defect Management

        Once the testing activity is over we will record all the discrepancies and errors identified during the test run. These observations are documented and sent for corrections or fixes. The errors identified are called as defects or bugs. The testing team will log those errors after completing the test cycle and they will categorise the Priority and Criticality of the defects. After this the defects are monitored till it is being fixed by the development team. This process of checking the defect till it gets closed is called defect management.
        The Key aspect of the defect management process is that to keep track on the bugs identified and ensure they are closed before the software is released. The defects logged are allocated with a specific time period to fix it called as Defect Life Time or it can be cut off time for the development team. The defects reported are closely monitored by the testing team and updates on them will be shared to the management team regarding the status. A typical Defect Life cycle in the image.

Test Management

       We have studied various testing concepts in the previous posts but the post is particularly about how an entire testing activity is being managed. Here the various activities from Requirement gathering till Release all the activities are monitored and the various changes or improvisations are documented. The test management is shown in the picture below.

User Acceptance Test

After all the levels of testing is completed, the last and final testing level is User Acceptance Testing(UAT). It is done by the user or the client who is going to use the system as the end user. User acceptance testing process helps to identify the practical defects which were not identified during other phases of testing. Here the testing is carried out in terms of the practical approach without considering the technical specification of the software. 
Lets assume a mobile based application is under UAT here the end user will be asked to test the app. The end user may not be a technical expert about the app but he has some need to use that app. So he will test the app as per his needs without considering technical specifications of it. He will use the app in a manner to help him in resolving his problem or satisfying his needs. Testing team can help him to understand how to operate the system or with the basic operations of the system. 
UAT can be done in two ways first being Alpha Testing, inviting the customer to our location and asking to test the software in a simulated environment which resembles the actual environment. Guidelines will be given to the customer about handling the software and it will be tested. Second is providing an evaluation copy of the software to the customer and asking him to test it in his own location, i.e, a beta version will be released and then the software will be used by the end users and the defects identified will be notified to the corresponding development team and it will rectified. This method is called beta testing.

March 27, 2013

Test Strategy Vs Test Plan

Test Strategy:
It is a company level document and developed by QA category people like Quality Controller. This document defines "Testing Approach" to achieve testing objective. Test strategy is the freezed part of SRS from which we get Test Policy and Test Strategy.

Components in the Test Strategy are as follows:
1. Scope and objective
2. Business issues
3. Roles and responsibilities
4. Communication and status reporting
5. Test deliverability
6. Test approach
7. Test automation and tools
8. Testing measurements and metrics
9. Risks and mitigation
10. Defect reporting and tracking
11. Change and configuration management
12. Training plan

Test Plan:
Test plan is the freezed document developed from SRS. After completion of testing team formation and risk analysis, Test Lead is preparing test plan document in term of what to test, how to test, who to test, and when to test.
There is one Master Test Plan consists of reviewed Project Test Plan and Phase Test Plan. So there is general talk about Project Test Plan.
Components are as follows:

1. Test Plan id
2. Introduction
3. Test items
4. Features to be tested
5. Features not to be tested
6. Approach
7. Testing tasks
8. Suspension criteria
9. Features pass or fail criteria
10. Test environment (Entry criteria, Exit criteria)
11. Test deliverables
12. Staff and training needs
13. Responsibilities
14. Schedule
15. Risk and mitigation
16. Approach

This is one of the standard approaches to prepare test plan document, but things can vary company-to-company

January 16, 2013

Process of Deriving Test Cases

A test case is nothing but the inputs which are given to the program or software to test its capabilities and operations. Here our intention is to find if the software meets the specifications given by the customer. Test case should be derived effectively in order to find defects in the system.
Let’s discuss the process of deriving test cases for given program for both functional and structural testing.
Before identifying the test cases as a tester you should be through with functionality and the specifications of the software under test. And the test cases derived should test the system in terms identifying the defects. The test cases should be derived for the functions which the system should not work i.e negative test cases.

Read A,B
If A>B then
Print “A is greater”
Print “B is greater”

Now from the program we can identify that the function of the program is to find greatest of two numbers. Let’s try and find out the required test cases for the program.
With the known details the program will identify the greatest of two numbers and will produce any one of the results “A is greater” or “B is greater”. So the inputs which will make the program to give the result are A=10 and B=100 for “B is greater” and A=100 and B=10 for “A is greater”. Hence we have identified test cases for the actual or expected output.
Now let’s think this way, What if both I/P have same values? And what should the program do at this state? This type thinking is actually required for the testers to derive effective test cases. This method of identifying test cases that are opposite to the function is called negative cases or negative testing. In this case if both I/P are same the program is not coded to produce any error pop up or warning. Which means my application will crash or will not produce any result. Another possibility is that the I/P given can be any value apart from numbers, but this is extreme case and this can also happen.

Then summarizing the various Test cases in a template as follows,

The actual result column and Pass/Fail column has to be filled after completing the test process. For static test techniques the test cases cannot be derived as the program will not be executed. Test cases will be derived only for the blackbox and whitebox techniques. The number of test cases can be varied based on the requirements and amount of testing required.