Not quiet sure if i’m right here and sorry for the not so meaningful title :D!
I have a question for all of you out there. I entered the testing by accident some time ago and i’m now really happy that i found my passion and space in the industry. As i never learned testing the regular way and only do testing with my experience i collected until now, i’m really insecure about some basic things.
When i prepare and write testcases i never know if i should collect some functions in one test or if i should make one testcase for each function.
As an example, i have a videoplayer to test:
This videoplayer contains controls like backward / forward & play / pause. Now i want to test if those controls behave as expected (i don’t think that i have to explain you what those controls do).
Solution 1:
I prepare one testcase with the title “use player controls”
Press the backward button => expected Result
Press the forward button => expected Result
Press the pause button => expected Result
Press the play button => expected Result
Solution 2:
I prepare for each function a separate testcase.
Testcase 1:
“Use the backward button”
Press the backward button => expected Result
Testcase 2:
“Use the forward button”
Press the forward button => expected Result
Testcase 3:
“Use the pause button”
Press the pause button => expected Result
Testcase 4:
“Use the play button”
Press the play button => expected Result
How do you organize your testcases? Is there no right or wrong and different each project or is there a golden rule how to do this?
I thank all of you for the time and maybe provided feedback.
My main thought with your question is, when you work out your test cases, are they being written by you for anyone else?
If you are writing them and then it is just you using it, I would say so long as you know what you are trying to prove, and if you get audited or asked to prove what you did, then don’t worry about it.
If you are building the tests to then hand over to someone else, or so if someone can cover for you if you were unavailable, I would go for the second option. That way if there is a problem with a particular test, it is easy to go back and point out what went wrong. Also, if the requirements change at any point, you can go back to change the specific tests more easily.
Welcome, there is no golden rule for this or even a right or wrong way to do it, completely dependent on the context you find yourself in.
There will be some answers here saying you don’t need test cases and there are other ways to organize your testing and there is a recent blog post by @mb1 about that.
If you are going to write test cases then again it is about your situation, what you want from the test cases and who else will be using them.
Worst case scenario would be the only interaction with testing the rest of the business has is reading the test case pass/fail numbers. So now if say the forward option is broke but everything else works then the difference would be all test cases failed or 1 failed and 3 passed. What message would you want to send to the rest of the teams?
Hi John ,
Solution 2 is always a better approach as if the requirements change or test case fails at any point ,you can go back to change the specific test cases more easily.
Solution 2 is also better from Automation point of view to call as individual functions and reusable .
As has been referenced there are no right or wrong answers and it depends on your context and circumstances.
I’d think about the following questions which may help you decide the correct level of details.
How will these test cases be used?
Who will be interested in them, or their detail, or their volume, or their results (if recorded)
Is there an expectation that the test cases can be used as documentation at some point? (speaks to detail)
What auditing will (or won’t) be done on these test cases?
What (if any) documentation will reference these test cases? (end of testing reports etc.)
So, if these are for you, used by you and unlikely to be reused, write at a level that you know what you mean and nothing more.
If these have broader purpose be clear on what that is and write accordingly. The value of test cases is only ever in their broader use, otherwise exploring with good notation can be quite adequate.
Good luck in your project and if you have any questions please ask
I will go with Solution 2 because it makes the most sense. The test cases are only for me so i could easy go with the first solution. But in the case i’m leaving my company or someone gets a job as tester to support me, i think it is the best way to think a bit ahead and don’t be lazy :)!
So again thank you all, it’s great how quick the community helped me. I hope someday i can give something back.
Sorry that it’s taken this long to reply, but I just noticed the notification.
Umberto, I’m wondering what problem you’re trying to solve here.
Despite what many people (including many testers) believe, testing to show that the problem is consistent with some expected result is a terribly weak form of testing. Test cases that provide an instruction to perform some specific action and observe some explicit and specific expected (anticipated? desired? required?) enable and emphasize this weak approach.
Thanks to Gordon Crawford (g.crawford20) for providing the link to the post above. You might also appreciate
Testcases needs to be planned as per the requirements of the application. Many features of application needs to be tested individually but some features rely on each other. So we can merge some testcases to avoid duplicate efforts.
Example:
If we need to create a test case for clicking on Login button, then we can cover providing FirstName , email id and password in same testcase.
In order to check the system’s response time , we can create scenarios for Volume testing along with our existing test coverage.