5

How do I ensure that my test cases covers every aspect of the requirements?

For example I had written test cases for the login page with all possible combinations I can think of and submitted for review.

My manager reviewed and updated me that I am missing test cases for color of buttons.

Again after updating these cases, when someone else was testing the application using my test cases, he missed the alignment issues of page/text boxes. In a meeting our conclusion was that I had missed test cases related to that.

Now, I am not sure how to confirm that my test cases gives 100% coverage.

9

As testing is a never ending process we can never assume that 100 % test cases have been prepared, we can only minimize the risk of shipping the product to a client.

Complete testing is impossible for several reasons:

  • We can’t test all the inputs to the program.
  • We can’t test all the combinations of inputs to the program.
  • We can’t test all the paths through the program.
  • We can’t test for all of the other potential failures, such as those caused by user interface design errors or incomplete requirements analyses.

Writing effective test cases is a skill and that can be achieved by some experience and in-depth study of the application on which test cases are being written. There are levels in which each test case will fall in order to avoid missing of test scenarios.

  1. In this level, you will write the basic test cases from the available specification and user documentation.
  2. This is the practical stage in which writing test cases depend on actual functional and system flow of the application.
  3. This is the stage in which you will group some test cases and write a test procedure. A test procedure is nothing but a group of small test cases maximum of 10.
  4. Automation of the project. This will minimize human interaction with system and thus QA can focus on current updated functionalities to test rather than remaining busy with regression testing.

So you can observe a systematic growth from no testable item to an Automation suit. For any application basically you will cover all the types of test cases including functional, negative and boundary value test cases.

0

there is a way named MECE(Mutual Exclusive and Collectively Exhaustive ) To cover all the test scenario as more as possible , you need a thinking map.

for example, ISO9000 quality standard it has 6 big-categories, and 24 sub-categories under that.

take your login page for example:

  • can we login with correct username and password
  • can we not able to login without correct username and password
  • can the login page display properly in the different browsers or platform?(pc or mobile)
  • does the page confront to the ui design?
  • can the login page display language in different country?
  • when many people login at the same time, can the login page work in time?
  • when people forget the username and password , can they find hint in the login page?
  • does the login page supports https?
  • in different place in the country , people can access this page as fast as in your company?
  • can the page prevent hacker to crack the page? does the page need to prevent robot to login?
  • can the login page work properly forever?

you need divide this question(aka risks) into different categories, such as functional, performance, compatible, Maintenance, stability and so on

there is a trick to ask question, it's called who-when-what-how-why-exception

when you missed something ,let bugs escape, you can record which category it belongs, and improve your test coverage.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.