Posts Tagged ‘Case study’

TestCase Developement

Looking at so many projects which runs into problems because of client finding out defects in either production or client testing, though test execution plays big role but I feel test coverage plays a bigger role. I agree exhaustive testing is not possible but the target should be to test all possible path and bigger challenge is to identify all the possible path. The conventional way of writing test cases is not enough to achieve a good test coverage. You need to have a different approach matching today’s application complexity. With my experience I feel if we do just reverse of what we are doing in test case writing cycle will help.

Normally once we complete writing test cases we used to review the test cases based on the checklist which contains all the types of test cases possible for this project. I feel we should have a robust checklist which should be designed based on the domain and technology used in developing the application. While we start writing test cases instead of straightway writing the test cases if we first find out the scenarios and then match those scenarios with the checklist then probably we will have a small test case writing cycle and since the checklist is tailor made for the application we hardly miss scenarios. But this approach of test case writing has a dependency on how good is your checklist and how well it cover all the scenarios possible in the application. The following points can be considered while preparing the checklist.

Functionality – It should contain all the functionality scenarios, or the happy paths of the application which we say the positive scenarios. The positive scenarios can be found out from the SRS or Use cases. We normally don’t miss those scenarios as long as the project modules are tightly coupled. If that’s the case then we need to have knowledge on the complete flow of the application to write all the positive scenarios.

Negative Scenario – This is where we miss the scenarios and having maximum challenge .Most of the associates not able to identify all the negative scenarios possible. So the checklist should contain check points for all types of negative scenarios possible for the application. Negative scenario may be based on functionality, scenario based on data, scenarios related to DB, scenarios related to experience based on the domain, scenarios based on the technology etc.

Test data – The test data should be extensive. We should consider boundary value and equivalence partitioning where ever applicable. Normally what we do is we find out the business data and forget about the negative data and field level validation data. So the checklist should have the check points for such data as well.

Non-Functional – Non functional scenarios are basically kind of negative scenarios and basic level of security scenarios like user click the browser back button, click on the refresh button, user copy the url and paste in the address bar and access the application, user closes browser without closing the application etc. The checklist should cover those points as well.

Abnormal Scenarios – Abnormal scenarios are those like if the LAN cable is disconnected, Internet is down, DB is down and Server is down etc. These should give proper error message to user instead of misguiding the user.

Database checks – we normally forget the database checks for the actions we are doing on the application.  For every database action there should be a database check to ensure the DB entry is happening. And also the negative test should not entering data into the DB.

Experience – Experience plays a big role in preparing the checklist. With experience related to the domain and technology you can add check points which normally happens to be defect with the corresponding technology and domain.

Security – Apart from the authentication and authorization related security issues  the checklist should have check points for the security testing like SQL injection, CSS, LDAP ,XSS injections, concurrency issues etc.

All these points I guess will help you in getting a  good test coverage provided the checklist is prepared well. But don’t forget to do a monkey testing after each cycle of testing and convert the monkey testing defects into test cases.   I have implemented this approach successfully.

Reblog this post [with Zemanta]
%d bloggers like this: