Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

There is a question which has been bothering me a lot while writing test cases. For every Test suite, say we have a login window. When writing the testcases do we need to list out all the possible test cases? Is there any standard or way that we can avoid some basic test cases?(For example editable ability of fields) There can be many test cases if we extend our imagination; but do we have to list them all?

If some of the basic ones can be avoided, who takes that decision in the real time software development cycle?

share|improve this question

3 Answers 3

When writing the testcases do we need to list out all the possible test cases?

You have a limited amount of time for testing, and if you think about it long enough, you will realize there is no end to the number of test cases. You need to consider as many as you can, but you need to prioritize them according to how hard they are to test and how much pain they cause if they fail.

Is there any standard or way that we can avoid some basic test cases? (For example editable ability of fields)

I don't know anything about testing standards, but here are some techniques you can use to avoid some basic test cases, using editability of text fields as an example:

  • Don't test every editable field if they are all coded the same way. In manufacturing, when there are too many units to test every one, testers use sampling to infer something about their product's quality. They can do that because every unit is made the same way. A similar idea holds in software testing. If every editable field is implemented in exactly the same way, you may be able to test a small number of fields (or perhaps just a single one) and infer from the results whether the other fields are correct. To draw that inference, you need to know how the software is put together.
  • Spend less effort on editable fields that were unit tested. Sometimes, developers test their software themselves before they make it available to testers. You can ask your developers whether (and how) they tested a feature, and use that information to decide how much additional testing you need to do.
  • Spend less effort on editable fields if they have not changed. If a feature hasn't changed since the last time you tested, you may not need to test it. Be careful though; those fields interact with other components, which in turn interact with other components, and so on.
  • Spend less effort on editable fields if they don't tend to break. If editability doesn't tend to be a problem, it may be better to spend time on things that do tend to break.

None of these techniques are perfect, but when you have limited time, you have to make judgement calls based on the information you have.

There can be many test cases if we extend our imagination; but do we have to list them all?

I assume this question is more about the quantity of test cases than about whether you should actually list them. If you are curious and you pay attention, you will realize that it is not possible to test (or list) everything.

If some of the basic ones can be avoided, who takes that decision in the real time software development cycle?

Go ask someone your manager or a co-worker. Or if there is no one to ask, you get to decide.

Software changes constantly. To do a good job, you need to keep track of how it is changing and which aspects of it matter the most. It is not easy, and none of us do it perfectly. Get as much information as you can absorb, make deliberate decisions, and when your fail, try to learn from your mistakes. That is what the rest of us try to do.

share|improve this answer
1  
"Spend less effort on editable fields if they don't tend to break. If editability doesn't tend to be a problem, it may be better to spend time on things that do tend to break." I would add, spend less effort on items that will cause problems if they break. If a login field is no longer editable, it will quickly fail when there is a test that tries to log in. –  Jeff Price Aug 5 at 14:07
    
I might add here that you still need to check every field at least once. This is because the UI components have to be wired up properly to the back end, even if the functionality of the component doesn't change. –  Bob Dalgleish Aug 5 at 20:23

Yes, although I agree with the other statements, I would recommend taking a risk based testing approach.

It is always important to identify all test cases and then assess the risk of that test case causing and issues and the impact if it was not tested and caused a live issue.

So I normally have a state of 'Risk and 'Impact' and apply a RAG status (Red, Orange, Green so basically /High/Medium/Low). You can do it just base don risk or impact as well, depends on your style.

I then execute the tests in order risk and impact and outline to the project manager or business owner that this can be completed in the timescales given, I highlight there is still a risk of not testing these test cases, but it has lower risk and a lower impact that those with a high impact/low impact. They then make the decision whether to extend the time or provide more resource.

http://en.wikipedia.org/wiki/Risk-based_testing

share|improve this answer

When and how to skip tests will depend on your build test release cycle. Generally most of your focus should be in the high risk areas, such as new development and bug fixing. If you were to have a spreadsheet of tests you could mark some to complete for this build and have others for the next build. Generally you reserve this for items that have been stable for a while. If your cadence of build/test is quick it can be easier to skip stable areas, and rotate what parts of the stable areas you test each cycle so you end up with a complete pass of all your test cases over time.

Another strategy is to do smoke tests where you do a quick run through looking for major breakage, but not checking all the possible combinations and permutations. Such as online ordering, you might do a smoke test of signing up as a new user and ordering 2 items, adding the shipping and payment options and completing the order where you enter in only valid data. That would check the basic functionality of the process, it would not check the validation for all the steps in the process, such as the address not being valid for a zip code or entering in a bad credit card number.

Basically you have to logic it out and know where your pain areas are and ensure they have good coverage. How to manage the testing is generally a decision of the test manager, but it should involve all the appropriate stakeholders to ensure they are comfortable with the level of risk compared to how much they want to spend on testing resources.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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