The Dilemma of Test Scripts
Mention software testing to 10 people in IT and you will get several different responses.
“That’s what QA is for.”
“Unit testing covers what we need.”
“What do we need to test for? The application works fine!”
“We’re Agile. We don’t need to test.”
“The client’s not banging down my door – so all is good.”
“No, we can’t release to UAT yet. I’m only halfway through writing the test scripts.”
“I don’t have time to test.”
“I don’t know how to test this. I’ll need some guidelines.”
“That’s not in the budget.”
If you work as a BA in an IT department, you have likely heard all of these retorts – sometimes even from those who should know better.
It is also a trigger that can lead down a deep rabbit hole of shortcuts and excuses, with the ultimate result being sloppy code, error-prone software, and possibly tons of rework post-release. Not only impacting you and your team, but also potentially leaving your company with very unhappy customers.
Software testing has several variations, all meant to ensure that the customer is happy in the end and that fewer issues, or bugs come back to haunt the product development team. Unit testing and smoke-testing are two of the most common types of testing. Unit testing is ordinarily done by the engineer as a part of coding and is meant to test the individual functions of the various components of the specific software. Smoke-testing is done after the release of the code into production. It serves as a means to make sure that nothing has been broken by the new code. Another critical form of testing is called regression testing, which focuses on how the new code works with the existing code. Regression testing requires additional planning and visibility of enhancements between releases.
At a bare minimum, unit testing and smoke-testing are essential. They are cheap and easy and require a minimal amount of effort.
The real testing, however, comes in the form of functional tests and acceptance tests. This is how you connect the code that is created by the engineers with the business needs of the customers and the real-life use of the application.
Functional tests validate that the newly designed process aligns with the requirements that were provided to the development team. Functional testing is best performed by either the business analyst or the QA analyst. A distinct benefit is gained here when functional tests are designed and completed by someone who is familiar with both the application and the enhancement requirements. Here is a tip: well written requirements and an experienced QA analyst are your best friend for stellar results!
Acceptance tests (also known as User Acceptance Testing or UAT) validate that the finished product aligns with the needs of the business user. This type of testing allows the end user to touch-and-feel the new process to make sure that it will correctly address the defined business need. An end user is also looking to make sure that the workflow is not made worse. At the end of the day, the user still has a job to do!
Advertisement
A well-designed set of test scripts is the most efficient way to track results, and to facilitate tracing the functionality back to the requirements. A plethora of applications exist that do this for you! Many of these applications can also run the test scripts in an automated fashion, which works great for regression testing. If I have access to an experienced QA analyst, I leave the decision up to that person. I simply provide rock-solid requirements and expectations and make myself available for questions.
That said, I am a big advocate of DIY.
If I am running functional tests myself, I create test scripts the old-fashioned way: Excel spreadsheets. The perception is that this takes too much time. Yes. It can be tedious. However, if you consider that good test scripts can also be used for system and user documentation – a bonus for start-ups – it is an essential task, regardless of the effort. They can be maintained and re-used.
Put your user hat on and give it a try!
Begin with a few basic columns:
Who is the user? What role is the user filling while performing this task?
What is being tested? Describe the function in simple terms.
What are the exact steps to get the desired result?
What is supposed to happen when the steps are completed?
What actually happened when the steps were completed? Ideally, you would want this to be the same as what was supposed to happen. Many times, it is not.
Did the test Pass or Fail?
Add more context for tracking and tracing back to the requirements, like test IDs for each test and date tracking to facilitate repeat testing. Add a column for additional comments so that the person who is running through the tests can add additional observations about what was experienced during the test.
In short, product quality drives customer satisfaction. Complete and consistent testing and retesting is one of the best ways to drive customer satisfaction with new products and product enhancements. It’s well worth your time and effort.
Happy testing!