Basics of Writing Test Cases:
#1. If test scenarios were all about, “What we are going to test” on the AUT – the test cases are all about “How we are going to test a requirement”.
For example, if the test scenario is “Validate the Admin login functionality” – This would yield in 3 test cases (or conditions) – Login (successful), Login-unsuccessful when incorrect username is entered, Login-unsuccessful when incorrect password is entered. Each test case would in turn have steps to address how we can check a particular test condition is satisfied or not.
#2. The input to create a test case document is FRD, Test scenarios created in the earlier step and any other reference documents if present.
#3. The test cases documentation is an important deliverable by the QA team and is shared to BA, PM and other teams, when done for their feedback.
#4. Work is divided among the team members and each member is going to be responsible for creating test cases for a certain module or a part of a certain module.
#5. Just like with the test scenarios, before we begin Test case documentation, a common template has to be agreed upon. Practically anything can be used to create test cases. The 2 most often used choices are MS Excel and MS word.
#6. The MS word template looks something like this:
#7. The Excel template could look like the following:
#1. If test scenarios were all about, “What we are going to test” on the AUT – the test cases are all about “How we are going to test a requirement”.
For example, if the test scenario is “Validate the Admin login functionality” – This would yield in 3 test cases (or conditions) – Login (successful), Login-unsuccessful when incorrect username is entered, Login-unsuccessful when incorrect password is entered. Each test case would in turn have steps to address how we can check a particular test condition is satisfied or not.
#2. The input to create a test case document is FRD, Test scenarios created in the earlier step and any other reference documents if present.
#3. The test cases documentation is an important deliverable by the QA team and is shared to BA, PM and other teams, when done for their feedback.
#4. Work is divided among the team members and each member is going to be responsible for creating test cases for a certain module or a part of a certain module.
#5. Just like with the test scenarios, before we begin Test case documentation, a common template has to be agreed upon. Practically anything can be used to create test cases. The 2 most often used choices are MS Excel and MS word.
#6. The MS word template looks something like this:
#8. From the above two templates it can be observed that the fields (or the components) that make up for a test case are the same, the only difference is the way in which they are organized.
So, as long as there is a field for each of the type of information to be included in a test, the format of the template does not matter. However, my personal favorite happens to be the excel sheet, because it is easy to expand, collapse, sort, etc. But again, choose any format that works best for you.
Below is a list and please check out the links provided for more information on these methods.
- Boundary value analysis
- Equivalence partitioning
- Error guessing - This is a very simple method and relies on a tester’s intuition. An example is: Say there is a date field on a page. The requirements are going to specify that a valid date is to be accepted by this field. Now, a tester can try “Feb 30” as a date- because as far as the numbers are concerned, it is a valid input, but February is a month that never has 30 days in it- so an invalid input.
- State transition diagrams
- Decision tables
Using the above techniques and following the general test case creation process, we create a set of test cases that would effective test the application on hand.
No comments:
Post a Comment