To test or not to test? 🤔 We agree the answer is to test as thoroughly and as practically as possible. It’s the how to test that varies widely. No matter how you manage software testing, maintaining test scripts is unavoidable if you want to develop a collection of reusable test scripts.
One main advantage of creating a collection of reusable test scripts, either manual or automated, is documented application functionality. Once a test script is written, the application functionality is documented. It may not be the only documentation, but it is the one the testing team uses for current, or future testing projects. Tests may also be used for QA tester training on the application, or for sharing with customers who benefit from executing known application functions.
However, a software business may opt for creating only temporary, throw-away test scripts in order to avoid spending time maintaining test scripts. They simply recreate them every time a testing cycle is needed. Optionally, a software business may also opt to test in an exploratory manner and never create a test script. The script only exists in the tester’s memory.
The options to not create reusable test scripts are valid. Personally, unless your application is temporary or only being released once, it’s impractical and a waste of testing resources. Why do software companies decry software testing? The easy answer is test maintenance 🤯
Test Maintenance – The Ball & Chain of Testing
Test maintenance is the heavy ball & chain following around the QA tester everywhere. It’s inescapable. Once a test is created, it’s going to need maintenance every time the software application changes. Significant changes in feature functionality in the application require updating the test case(s) prior to a subsequent release. Since releases vary, there may be a few days, hours or even weeks for test maintenance activities. Regardless of the timing, in order to be valuable and useful, the test scripts must be maintained routinely. Manual test scripts and automated test scripts have different maintainability levels. Manual is more direct, and possibly more tedious. Yet, both are time-consuming, if the application’s functions change on a frequent or regular basis.
Let’s review some tips for both manual and automated scripts, that ease the pain of test maintenance by increasing maintainability:
Improving Maintainability – Manual test scripts
Manual test scripts need to be updated on a consistent basis, otherwise their reusability is affected. If a test script that is not kept updated is used by a different, or new QA tester – they’ll lose significant testing time asking questions, and tracking down changes in the application functionality. Most likely, they’ll end up updating the test script which means they spend less time actually testing the functionality. There are methods you can use to improve the maintainability of manual test cases to consider.
- Exploratory test stories rather than precise step by step scripts
Writing exploratory test stories reduce the need to update longer, step by step scripts. When the manual test case is created, it does not move through a step by step execution sequence. Rather, it’s a paragraph or two that describes the function and expected results. There’s less to update, unless the function changes significantly. Minor changes to display items don’t require any updates because only the basic workflow is described rather than the details of how to execute each step and verify every image, link, or data presented.
- Text only, no images or screenshots
Skip the images when creating a test script. Stick to descriptive text only. Textual test scripts describe precisely what the user sees on each page, or during the workflow through the application. Not adding in screenshot examples or images, significantly reduces the need to update images each time a display change is made to the application. Only if the functionality described changes significantly, does the test script need to be updated.
- Modular test scripts written per function then grouped together into a workflow during test execution
Modular test scripts are written per function. They are short and direct, step by step textual description of the function being tested. For example, for nearly any application the first modular test script is authentication or login. The functionality is described step by step for a valid user login only. That’s it. The test script ends. A separate modular test script is created for verifying the authenticated user lands on the correct page, etc.
Improving Maintainability – Automated test scripts
Automated test script maintenance has long been the main reason automated testing projects fail. Why? 😵 Usually, because the test maintenance is not part of the project plan. When planning an automated test project, don’t forget that once all those automated tests are scripted and running, the next time the application changes – they will need to be updated immediately in order to execute them. There are a few ways to make automated test scripts easier to update or maintain:
- Modular test framework
Exactly like the manual test script, the automated modular test script is developed to cover testing a single function only. The catch with automated test scripts is, where you left off in the first functional module, you must include in the second module. The automation code isn’t able to skip steps like a manual tester. You’ll have to code in the following modular test where the automated script must start. For example, if you create an automated test script that covers a user logging in with valid authentication credentials. The next modular script needs to pick up at that point and continue to the next step. By modularizing automated tests into small, functional pieces, it’s easier to locate the code that needs to be updated.
- Automate only critical smoke tests
When creating automated test scripts, only automate critical smoke tests. Leave the workflow or full functional testing to manual scripts. Automating only critical smoke tests reduces the number of tests that need to be maintained when application changes occur.
- Create one test for each verification point
Many automated test developers are gifted coders able to create large, complex scripts with numerous verification points. The problem is, complex scripts with multiple verification points are difficult to edit for anyone other than the coder. Pinpointing where an update is needed may be time-consuming and require significant testing time to ensure the script still functions as expected. Automated test scripts that only contain one verification point are easier for a testing team to update as needed with less chance of altering the validity of the script.
I hope you’ll use some of these tips for improving the maintainability of your manual and automated test scripts, and think twice before jumping head-first into testing, without knowing the how and planning ahead.
Go ahead and share in the comments below your maintainability tips! 🎯