| Looking at so many projects which runs into problems | | | | scenarios related to DB, scenarios related to |
| because of client finding out defects in either | | | | experience based on the domain, scenarios based on |
| production or client testing, though test execution plays | | | | the technology etc. |
| big role but I feel test coverage plays a bigger role. I | | | | Test data - The test data should be extensive. We |
| agree exhaustive testing is not possible but the target | | | | should consider boundary value and equivalence |
| should be to test all possible path and bigger challenge | | | | partitioning where ever applicable. Normally what we |
| is to identify all the possible path. The conventional way | | | | do is we find out the business data and forget about |
| of writing test cases is not enough to achieve a good | | | | the negative data and field level validation data. So the |
| test coverage. You need to have a different approach | | | | checklist should have the check points for such data |
| matching today's application complexity. With my | | | | as well. |
| experience I feel if we do just reverse of what we | | | | Non-Functional - Non functional scenarios are basically |
| are doing in test case writing cycle will help. | | | | kind of negative scenarios and basic level of security |
| Normally once we complete writing test cases we | | | | scenarios like user click the browser back button, click |
| used to review the test cases based on the checklist | | | | on the refresh button, user copy the url and paste in |
| which contains all the types of test cases possible for | | | | the address bar and access the application, user |
| this project. I feel we should have a robust checklist | | | | closes browser without closing the application etc. The |
| which should be designed based on the domain and | | | | checklist should cover those points as well. |
| technology used in developing the application. While we | | | | Abnormal Scenarios - Abnormal scenarios are those |
| start writing test cases instead of straightway writing | | | | like if the LAN cable is disconnected, Internet is down, |
| the test cases if we first find out the scenarios and | | | | DB is down and Server is down etc. These should |
| then match those scenarios with the checklist then | | | | give proper error message to user instead of |
| probably we will have a small test case writing cycle | | | | misguiding the user. |
| and since the checklist is tailor made for the application | | | | Database checks - we normally forget the database |
| we hardly miss scenarios. But this approach of test | | | | checks for the actions we are doing on the application. |
| case writing has a dependency on how good is your | | | | For every database action there should be a |
| checklist and how well it cover all the scenarios | | | | database check to ensure the DB entry is happening. |
| possible in the application. The following points can be | | | | And also the negative test should not entering data |
| considered while preparing the checklist. | | | | into the DB. |
| Functionality - It should contain all the functionality | | | | Experience - Experience plays a big role in preparing |
| scenarios, or the happy paths of the application which | | | | the checklist. With experience related to the domain |
| we say the positive scenarios. The positive scenarios | | | | and technology you can add check points which |
| can be found out from the SRS or Use cases. We | | | | normally happens to be defect with the corresponding |
| normally don't miss those scenarios as long as the | | | | technology and domain. |
| project modules are tightly coupled. If that's the case | | | | Security - Apart from the authentication and |
| then we need to have knowledge on the complete | | | | authorization related security issues the checklist |
| flow of the application to write all the positive | | | | should have check points for the security testing like |
| scenarios. | | | | SQL injection , CSS , LDAP ,XSS injections, |
| Negative Scenario - This is where we miss the | | | | concurrency issues etc. |
| scenarios and having maximum challenge .Most of the | | | | All these points I guess will help you in getting a good |
| associates not able to identify all the negative | | | | test coverage provided the checklist is prepared well. |
| scenarios possible. So the checklist should contain | | | | But don't forget to do a monkey testing after each |
| check points for all types of negative scenarios | | | | cycle of testing and convert the monkey testing |
| possible for the application. Negative scenario may be | | | | defects into test cases. I have implemented this |
| based on functionality, scenario based on data, | | | | approach successfully. |