5 Reasons why you don't need test cases
Tags: testing
Published: 2022-05-01 20:17:59

Before I start to convince you that test cases are not needed let’s see what they are, so, test cases are a descriptive form of the tests we want to perform, they usually contain steps, expected output, some preconditions and other information about the environment etc., In theory, this sounds informative and as a thing that can improve testing, since all tests are defined and written down.

I have been working on various projects and a significant part of them had test cases, today I remember it as a nightmare. Just imagine this situation, you have a feature to test, based on that we need to create test cases, it requires time. After that, we need to test a feature based on the test cases we created or write some automated tests. Sounds like a fairly long process, isn't it? You may want to say, ok, so why don’t you create test cases before the feature is ready? Good point, I was trying to do that, but usually, acceptance criteria are not ideal, designs are not attached, so created test cases will touch only a high level of the functionality, there is also a high risk that something will change and you will spend extra time to correct all test cases. Let’s now consider how our life would look without test cases.

**Reason 1 – Documentation**
When we are creating test cases the main reason is to have test documentation, so something which will allow us to go there, get knowledge about application, and speed up with testing. Now imagine, that project documentation contains all information, and the acceptance criteria are written well. That would give you all the required information about the application and the whole team could benefit from that. I know, that might sound a bit idyllic, but as QA we should keep an eye on all aspects of developed software, If we take care of documentation, why do we need to duplicate it?

**Reason 2 – Maintenance**
Let’s imagine that you have an application and with each iteration, it’s growing, according to that, you are adding new test cases, more, more, and more. Then an application has been updated so you need to update all required test cases. Over time the number of test cases increased drastically and you need to hire another QA to help in the maintenance. Sounds familiar? 

**Reason 3 – Automate and save time in the future**
We all know that test automation is time-consuming, but the benefits from it are significant. Well designed automated tests will bring more value to the test process rather than manual test cases.

**Reason 4 – Use Gherkin language properly**
The main point of the Behaviour Driven  Development approach is to create a communication layer between the product and dev teams, so they can communicate in an effective way. Not all product team members will understand code created by devs, also devs need some structured information about features they need to create. Unfortunately, I didn’t see in my whole career a project where this approach would be used properly. Usually, it’s just some additional lines in a set of automated tests, not used by anyone or just by the QA team. Now, what would happen If you use the BDD approach as it should be? Test cases won’t be needed, you will get all with Given, When, Then nomenclature.

**Reason 5 –  Don’t do something just because someone told you how it needs to be done**
When I was starting my career I went through a number of courses where each contained a chapter about test cases, when you think about testing, I am sure you also think of test cases. Why? Because someone in a past told everyone how the test process should look? But, we know that each project is different, so why we should implement the same pattern everywhere? Just be creative, see what’s the better solution for project needs, what’s the resources, do you have time to write test cases every time and maintain them?

To summarize, depending on the project the approach should be different, we should always consider if we have time to create and maintain a set of the test cases, but in my opinion, well-designed project documentation and/or automated tests will cover the same thing as test cases and save your time.