Drawing and writing Test Cases is one of the key elements tested. It is receiving much attention in various publications on the subject of testing. We will not dwell on the definition and rules of drawing Test Cases. The purpose of this article – to give an unusual perspective on the problem.
We have repeatedly faced with different opinions on this issue. In one of the conferences was launched a whole discussion on this topic. As usual, opinions were divided.
Compilation of Test Cases in addition to all the best and has one drawback – the time to write. It is on writing, because develop them in one form or another is still there in most cases.
Consider this variant: small software company. Compete in the market can manufacture high quality software in the shortest possible time. The need for testing is obvious, but timing is everything. The developer is always easier to write code rather than documentation. And, if for 1 month, he will prepare for the transfer to product testing, writing documentation, then this period will extend for 1.5 – 2 months. Any delay in development – reducing the time for testing. The first, probably wrong, but often make decisions – do not write documentation. For the tester in this case there is only one way – the development of Test Cases in the course of the study product, as it will be submitted for testing.
In this situation (meaning very little development time or, for example, a small team working on a very large project) tester for the development and writing Test Cases need to unnecessarily (especially if the leadership thinks so) a lot of time. Convince management in most cases – just a waste of time (though for frequent unjustified). What can be done in this situation?
In our view, the alternative would be to formulate the objectives of each Test Cases (not a complete and detailed description, namely the formulation of what should be checked). This list will not miss anything when checking and at the same time will save time on "writings".
And one more thought. The programs interface with step by step (and its elements are present in many software products), where the transition to the next step is possible only after all the "mandatory" in the previous action, in our view, it is possible to use complex (or composite) Test Cases.
Ie if in a program in a window Step 1 button Step 2 is available only after filling in the correct field.1, we conducted such a test:
when you turn it necessary checks, it is possible to "kill" once the whole "bunch of" things:
If some element of verification during this Test Case is missing – the program can be considered "not working" because its further use is not possible (this version would be "handed over on completion"). We are talking mainly about the "manual" testing. Although the inclusion of elements of the verification on each of these points allows the use of this Test Case and automation (at least acceptance tests).
In our view, Test Cases can be divided into simple and complex (or composite). By "simple" we mean a Test Case, which along with the initial (cast in the necessary state programs) and end (translation program to its original state) elements has only one element of verification. "Compound" can be called a Test Case, which on past the initial and final elements would include two or more elements of the verification.
Simple Test Cases can be viewed as a "perfect" version that you want to aspire to. He has successfully fit large or medium-sized company with a well-funded, time-bound, a sufficient number of staff and well-delivered document.
Complex (composite) Test Cases – an alternative way for small companies with complicated (or greatly reduced) terms, the lack of documentation and lack of staff.