 |
 |
 |
Test cases is a sequence of steps to test the correct behavior of a functionality/feature of an application. A test case should have an input description, Test Sequence and an Expected Behaviour. Test Sequence: Schedule a report [This can be treated as a Title as well as Test Sequence. Sequence here is the order in which this step is to be executed. The test case document should be prepared in such a way that the test cases should follow a sequence].
Test Input Description:
1.Login to <Abc page> as administrator.
2. Go to Reports page
3. Click on the ‘Schedule reports' button
4. Add reports
5. Update
Expected Results:
The report schedule should get added to the report schedule table. Provisioning status of the reports should get handled
Test Input Description:
1.Login to <Abc page> as administrator.
2. Go to Reports page
3. Click on the ‘Schedule reports' button
4. Add reports
5. Update
Expected Results:
The report schedule should get added to the report schedule table. Provisioning status of the reports should get handled
Test Case Design Techniques
These Test Case Design Techniques help to ensure that Test Cases are as effective as possible at identifying Defects. People talk of software testing in terms of Black Box and White Box Testing, and test case design techniques are often organised into these two categories. Black box and White Box are not Testing phases or types of testing, they are categories for techniques used to select and create test cases.
Black Box
As the name itself suggests , we cannot see anything in a black box. In the same way in black box testing it is not required to know about code but the knowledge of functionality is mandatory. Black Box testing is done when the functionality/flow of the system is clearly defined and the internal logic is not looked into.
These Test Case Design Techniques help to ensure that Test Cases are as effective as possible at identifying Defects. People talk of software testing in terms of Black Box and White Box Testing, and test case design techniques are often organised into these two categories. Black box and White Box are not Testing phases or types of testing, they are categories for techniques used to select and create test cases.
Black Box
As the name itself suggests , we cannot see anything in a black box. In the same way in black box testing it is not required to know about code but the knowledge of functionality is mandatory. Black Box testing is done when the functionality/flow of the system is clearly defined and the internal logic is not looked into.
Requirements Based Tests
The most common method for creating test cases is to analyse the functional specification or requirements and create test cases that specifically prove or attempt to disprove that the application meets those requirements.
This may not be the best method for planning test cases because it focuses too narrowly on the application and often produced a ‘positive testing’ approach where the test cases are designed to show the feature works. The test cases can also include negative scenarios wherein an application does not do what it is not supposed to do. We should also include the test cases to test those parts of the system which might be impacted indirectly due to the changes and implementation of the requirements.
The most common method for creating test cases is to analyse the functional specification or requirements and create test cases that specifically prove or attempt to disprove that the application meets those requirements.
This may not be the best method for planning test cases because it focuses too narrowly on the application and often produced a ‘positive testing’ approach where the test cases are designed to show the feature works. The test cases can also include negative scenarios wherein an application does not do what it is not supposed to do. We should also include the test cases to test those parts of the system which might be impacted indirectly due to the changes and implementation of the requirements.
Scenario Based Tests
Tests based on the scenario a real user may follow to perform a function on the system. In Scenario Based Testing we use the Use cases Document for creating the flows/Scenario. And according to main, alternate and exception flow we prepared the scenario. Scenario can be on function points or End to End. So Testcases generated are good to trace the Defects..
Risk Based / Error Guessing
Design Tests based on where you think the application may go wrong. Use the experience of the test analyst to anticipate where errors may occur and create test cases to test this area of the application.
Condition Tables
A condition describes the behaviour of the system and a number of different values for each condition are identified, these are drawn in a grid format, each cell of the grid can be considered a test case.
A simple example could be that of a login screen.
These all are the combination of the values for each condition. Now We have to select the values for which system behave in different way. for Eg. Invalid username with valid password & Invalid username with Invalid password, System would react in same manor.
Tests based on the scenario a real user may follow to perform a function on the system. In Scenario Based Testing we use the Use cases Document for creating the flows/Scenario. And according to main, alternate and exception flow we prepared the scenario. Scenario can be on function points or End to End. So Testcases generated are good to trace the Defects..
Risk Based / Error Guessing
Design Tests based on where you think the application may go wrong. Use the experience of the test analyst to anticipate where errors may occur and create test cases to test this area of the application.
Condition Tables
A condition describes the behaviour of the system and a number of different values for each condition are identified, these are drawn in a grid format, each cell of the grid can be considered a test case.
A simple example could be that of a login screen.
These all are the combination of the values for each condition. Now We have to select the values for which system behave in different way. for Eg. Invalid username with valid password & Invalid username with Invalid password, System would react in same manor.
White Box
White Box, like Black Box, is a test design method. Tests based on the internal logic of the application are called White Box tests. White box testing is often more thorough, but also much more time consuming than Black box testing and requires some knowledge of development processes.
White Box often talks of Code Coverage, which is where the code itself is covered by test cases. There are several levels of Code coverage.
Statement CoverageIn order to achieve statement coverage, each statement of the code has to be covered by a Test Case.
Branch Coverage The testing of each branch condition. For each branch statement, each branch of the statement must be performed by a test case in order to achieve branch coverage.
Path Testing If every distinct path is covered by a test case then path coverage is achieved.
The goal of code coverage is often unrealistic with anything but the smallest of systems as it takes a long time to analyse the program code. There are a number of different techniques to approach code coverage...
Boundary - Interior Path Coverage
For each loop 2 conditions are tested
* Paths with enter the loop but do not iterate
* Paths that enter the loop and iterate it at least once.
White Box, like Black Box, is a test design method. Tests based on the internal logic of the application are called White Box tests. White box testing is often more thorough, but also much more time consuming than Black box testing and requires some knowledge of development processes.
White Box often talks of Code Coverage, which is where the code itself is covered by test cases. There are several levels of Code coverage.
Statement CoverageIn order to achieve statement coverage, each statement of the code has to be covered by a Test Case.
Branch Coverage The testing of each branch condition. For each branch statement, each branch of the statement must be performed by a test case in order to achieve branch coverage.
Path Testing If every distinct path is covered by a test case then path coverage is achieved.
The goal of code coverage is often unrealistic with anything but the smallest of systems as it takes a long time to analyse the program code. There are a number of different techniques to approach code coverage...
Boundary - Interior Path Coverage
For each loop 2 conditions are tested
* Paths with enter the loop but do not iterate
* Paths that enter the loop and iterate it at least once.
Equivalence Partitioning
An equivalence partition (or equivalence class) is series of values where the expected outcome is the same, and therefore using 1 value will test the expected outcome as well as 10 values would. As an example imagine an application where entering your age would tell you if you were old enough to vote or not. Entering any age from 1 to 15 would produce the same result and therefore would be in the same equivalence partition. Therefore only 1 value from this group needs to be used during testing.
Data Flow Analysis
The aim is to produce test cases to cover all of the data-flow relationships. A Data-Flow relationship is where a variable (Data) is assigned a value by one statement and then used later in the code by another statement (flow). Those 2 statements are said to have a data-flow relationship.
There are different approaches to this, for example you may decide to have test cases only for the data-flow relationships that have at least 5 statements that use the variable.
Mutation Testing
Where minor changes are made to the implemented system to create ‘mutant’ code. The test is re-run and results compared to the original system. If the test results differ, then the mutant has been killed; however if the results are the same, then the original test may not be thorough enough.
Where minor changes are made to the implemented system to create ‘mutant’ code. The test is re-run and results compared to the original system. If the test results differ, then the mutant has been killed; however if the results are the same, theWhere minor changes are made to the implemented system to create ‘mutant’ code. The test is re-run and results compared to the original system. If the test results differ, then the mutant has been killed; however if the results are the same, then the original test may not be thorough enough.
Black or White Some test case design techniques can fit into either Black Box or White Box categories. Black Box testing disregards actual code and structure, concentrating on whether the application meets specified requirements.
Boundary Value Analysis
It is more common for errors to occur during the processing at the boundaries of values, this is often an area subject to misinterpretation. For example, the requirement may say that the search result page will display up to 10 results before creating a second page of results.
Test cases should be created to test for 9, 10 and 11 matching results, ensuring that a second page is only created when 11 matches are returned. Similarly an input field may be said to only accept 20 characters, so test cases can be created to test for entering 19, 20 and 21 characters into the field.
Both examples above test the upper boundaries. Many times a lower boundary also exists, and should be tested. Does your search result page correctly report no matches? What happens to your input field if nothing is entered?
An equivalence partition (or equivalence class) is series of values where the expected outcome is the same, and therefore using 1 value will test the expected outcome as well as 10 values would. As an example imagine an application where entering your age would tell you if you were old enough to vote or not. Entering any age from 1 to 15 would produce the same result and therefore would be in the same equivalence partition. Therefore only 1 value from this group needs to be used during testing.
Data Flow Analysis
The aim is to produce test cases to cover all of the data-flow relationships. A Data-Flow relationship is where a variable (Data) is assigned a value by one statement and then used later in the code by another statement (flow). Those 2 statements are said to have a data-flow relationship.
There are different approaches to this, for example you may decide to have test cases only for the data-flow relationships that have at least 5 statements that use the variable.
Mutation Testing
Where minor changes are made to the implemented system to create ‘mutant’ code. The test is re-run and results compared to the original system. If the test results differ, then the mutant has been killed; however if the results are the same, then the original test may not be thorough enough.
Where minor changes are made to the implemented system to create ‘mutant’ code. The test is re-run and results compared to the original system. If the test results differ, then the mutant has been killed; however if the results are the same, theWhere minor changes are made to the implemented system to create ‘mutant’ code. The test is re-run and results compared to the original system. If the test results differ, then the mutant has been killed; however if the results are the same, then the original test may not be thorough enough.
Black or White Some test case design techniques can fit into either Black Box or White Box categories. Black Box testing disregards actual code and structure, concentrating on whether the application meets specified requirements.
Boundary Value Analysis
It is more common for errors to occur during the processing at the boundaries of values, this is often an area subject to misinterpretation. For example, the requirement may say that the search result page will display up to 10 results before creating a second page of results.
Test cases should be created to test for 9, 10 and 11 matching results, ensuring that a second page is only created when 11 matches are returned. Similarly an input field may be said to only accept 20 characters, so test cases can be created to test for entering 19, 20 and 21 characters into the field.
Both examples above test the upper boundaries. Many times a lower boundary also exists, and should be tested. Does your search result page correctly report no matches? What happens to your input field if nothing is entered?
Test Case & Test Design techniques