Test Cases- useful or not?
Let’s start with what a test case is and then I will follow up with the pros and cons, how it fits into the scrum world and maybe if we can use something different to substitute test cases.
Origin of test cases is in waterfall projects where you should have all requirements for the project clarified at the beginning of the project and it won’t change during the development of project scope. Discussion if it is happening in reality we will leave aside from this article. Process in waterfall roughly looks like, that test analyst according to requirements and functionality description, creates a test suite to test the whole solution developed during the project. Once those test cases are created, they shouldn’t be changed anymore during the project except maybe some small corrections.
The structure of the test case is a series of detailed steps that lead testers to prove that some functional part of the solution is working based on requirements. Each step is composed of action, expected result, and if needed some data which should be used for this particular step. In some cases predecessors are linked.
Test case Example
Scrum and agile world
So we know now how process more or less looks in the waterfall project, but how it is in the scrum or agile projects lets see.
It is a different world than in waterfall projects. At the beginning of the project you have a rough description of user stories with acceptance criteria, which most of the time are not written in detail and are clarified more on refinement meetings during the project. Also it is possible, that at the beginning of the project you don’t know the whole scope and development is based on time and material model.
Based on the previous paragraph creation of test cases at the start of the project doesn’t make sense at all, but when to create them. If you want to use test cases on your scrum / agile project, you can create them for stories that are taken to the sprint. A Sprint is basically a time-box usually 1 or 2 weeks long during which you should be able to deliver functionalities (user stories) that were taken to the sprint. User story then present functionality or some smaller part of it. Also if a user story is taken in a sprint it doesn’t mean that requirements are written in stone. Requirements can slightly change and it can lead to rewriting test cases especially if they are written to the smallest details.
Pros and cons of test cases
In previous paragraphs, we spoke about test cases and their usage in two different development processes. Now let’s move to the advantages and disadvantages.
First, let’s speak about the advantages. The main advantage for a manual tester is easy verification, that functionality fulfills requirements. They are also useful to track in a very detailed way what was tested. So you can highlight to your scrum master or customer how you tested functionality and even to attach screenshots or record video to each step to prove that functionality is working as expected. Test cases can also work partially as user documentation or as a base for the creation of user documentation. During the creation of test cases you can find holes in the description of requirements.
From the disadvantages I would mention time consumption of maintenance. Every time there is some change in functionality, test cases need to be updated which is not rare in the scrum world. Also to identify all test cases which need to be updated can be a challenging activity in a large solution. In Scrum sprint time is really limited and time for creating, updating test cases can be used for different activities like the development of automatic tests or writing user documentation, etc. which can bring, in my opinion, bigger value for the project than test cases.
Possible substitution of test cases
User Documentation can be partially substituted for test cases. During the testing of the user story tester writes documentation. It helps him put together what needs to be tested and also he is bringing added value to the project. Documentation can help on-boarding new team members show customers how to use functionality, and in one place gather complex guidance on how to use solutions from a user perspective. Documentation is composed of a description of how to set up and use functionality with a combination of screenshots.
Video documentation is similar to user documentation. During testing or after testing of a user story, the tester records video to showcase the function of developed functionality. Additional value is basically the same as user documentation, the best is to use a combination of user and video documentation on the project.
Based on acceptance criteria tester prepares a simple checklist for the user story, but what is a checklist. The checklist is composed of steps to achieve testing all requirements in the agile world represented by acceptance criteria in the waterfall project in some product requirements document. Steps don’t need to be written in detail, but they should be detailed enough to describe what needs to be tested. Checklist and documentation are linked to developed functionality item in tracking system.
Checklist form example
Conclusion
Test cases are mainly useful in waterfall projects where you have fixed scope, fixed time and functionality shouldn’t change. In the scrum where changes happening frequently and user stories represent smaller developed functionality or part of bigger functionality. It is, in my opinion, better to use a combination of documentation and test checklists.
Test cases for automated functional regression tests
The last topic which I would like to touch in this article is test cases for automated regression tests. To be straightforward for functional automated regression tests is better to use Gherkin language or other similar languages depends on which programming language you are using.
Gherkin is a simple human-readable language that helps understand what was tested by developed automated tests. It is using basic syntax keywords given, when, then to create short understandable sentences. From the QA engineer perspective it is another level upon automation code. It is adding some complexity to the development of automation tests, but it is nothing incredibly time-consuming.
Gherkin can be written in the description of a task for creating automated test which can be linked to user stories.
Gherkin example
Given registered user
When he is logging to the application
And didn’t confirm newsletter yet
Then newsletter pop up window appears
We are ACTUM Digital and this piece was written by Vlastimil Matějka, QA Team Leader of Apollo Division. Feel free to get in touch.
