Recently I went through nearly all of the Manual Test Cases I wrote for our legacy application. Hundreds of them were written 2-3 years ago, and the UI or other components had changed significantly since then. I went through and updated these test cases, initially begrudgingly and a little irritated at having to re-do this menial task. This led me to consider, are manual test cases useful given the need to update them fairly often? Is this test debt valuable to the organization or the tester?
I hadn’t used these test cases to manually test the UI in a long time – I could go through many of these with my eyes closed and my mouse-hand tied behind my back. Occasionally, someone from another team would ask how something was designed to work or request help in testing an area and I could point to these (increasingly outdated) test cases as a reference. Quite honestly, I hadn’t realized they had become so dated and nobody pointed this out. Why even have manual test cases then?
Example Test Cases
I want to take a step back first and discuss the nature of many of the test cases I had written. Here’s an example of a manual test case I had written a few years ago:
- Go to url https://mycompanysite.test
- login with useraccount tester@mycompanysite.test
- select the “Admin” tab to navigate to the admin area of the website
- click “Add new subscription”
- enter valid entries into the following fields: Subscription Id, Subscription Name, Subscription GUID, User ID
- select “Enter”
- verify validation message “Your subscription has been added!”
This test case was no longer a valid case for the following reasons:
- test account was no longer valid/else corrupted
- UI updates including moving elements to new pages
- required fields had been changed
- text on buttons had changed
- validation messages had either changed or didn’t exist any longer as we moved to a different design
The way I’m currently writing tests looks like this.
- Login to mycompanysite.test
- navigate to AddSubscription page
- select button to add a subscription
- enter valid entries into required fields
- save
The new test case will be valid longer because it doesn’t reference specific pages, button names, text fields or otherwise. This will allow me to give others the “green path” to verify it works as expected, and will give the more analytical mind enough information so they can pose questions like “What if I enter invalid info into one or more fields?” or “what does the user expect to happen once I click Save?”.
reasons for detailed test cases
- New App – when I test a new thing I write down the steps to the tee, so that I can go back through the steps and consider what I can do to break the app. This will allow me to write more detailed test cases. This will also allow you to have documentation for every user action – and then you can tag your test cases about where test coverage lives (unit, system, integration, UI), which will in-turn help you identify gaps in testing.
- The app contains something you’re unaccustomed to testing. A little while ago we implemented security improvements on our legacy apps including two-factor authentication and more stringent password policies. The PM team had a strong idea of what things should look like, and the devs knew how they would implement it – but there were use cases we hadn’t considered which were revealed once I wrote my test cases and identified some gaps.
- Migrating existing functionality from a legacy app to a new app. A short time later, we would migrate all the new security features to a new application. Lucky for me, I had detailed test cases already written that I could port over to the new app. Also, this made writing test cases for the feature work a piece-of-cake.
Our dev shop has largely transitioned from a largely manual-testing shop to a shop that is trying really hard to build, maintain, and keep-relevant automated tests. We’re currently using Katalon Studio for our automation suites. I can see our growth of the implementation of automated tests simply by running queries in our ticket system. I can query for legacy app and type: test case and then by automated to determine our level of automated test coverage.
Having a robust suite of the right type of test cases is important in the growth of your dev team, whether it’s socializing “how do I test this thing?” or “what are the business rules for XYZ?” or “what percentage of our tests are automated?”. In the end, manual test cases are valuable, good luck and have fun testing!
