Defining your testware can be a daunting task, yet not doing so often leads to problems just as your test initiatives are gathering steam and attention within your organization. Imagine, because of your excellent work, you have been asked to scale up the volume of tests, or to take on a new application, or to increase the scope from testing to full Quality Assurance… The list goes on, but without the foundational element of a defined testware, all of these have one thing in common, it will be difficult to bring the people that you need to on the journey.
What is testware
“Testware: the stuff of which tests are made.” – Mark Fewster.
Testware is all encompassing – everything you need to run a test, from automation, to walkthroughs, and every artifact in between. Testware and its popular subset, test automation frameworks, is simply a guide so we:
- Know how to work together
- Know what is expected
- Have a venue to learn from gaps and events
- Do not spend too much time “on the tools” vs “in the tools” producing value
The test architecture is the when, where, and how to use that “stuff”.
Getting started
The most important step is to commit to setting aside a few hours each week to review, build, and improve your testware. Start small and pace yourself. I am including the beginning of a checklist that you can build on for future use.
- Goals for testing activities (3 sentence max) … shorter is better, but these need to be clear and meaningful to the team.
- Test plan template
- Password management plan
- Data access plan with encryption and/or obfuscation sections.
- Test system standards (based on data about how the application is accessed)
- OS
- Browsers(s)
- Patch cycle
- Display resolution(s) to test against
- Naming standards
- Stuff (test artifact) location(s)
- Limited reports
- Review process
This list will likely grow, relative to the complexity of the systems and size of the team, and should be shared, adopted, and maintained by testing and surrounding teams. Having a sustainable, resilient system in place that supports the growth of test artifacts, and that identifies risks you encounter, is important to success.
Review
Begin your review by evaluating the first two or three test plans. Did they meet the overall testing goal? How did the plan perform? Is there data that looks out of place or any data that you would like to report on (e.g., lots of empty fields)? Remember that this is an iterative process, if you do not catch something this week, next week will be here soon enough.
Summary
A great article from our partner, Eggplant, had a nice introduction explaining test automation. It is a short read, and a great primer on test automation. About halfway through the article, is a suggestion for test automation frameworks, which I would like to extend to testware: Building up your testware slowly…, in parallel to creating real value, is much more likely to result in sustained testing success.
If you are formalizing your testing journey, incorporating automation or simply would like to discuss what you read here further reach out… we would love to share more insights… and support you in your journey.
Finally, remember that people are the most important element of testing. Make testing easy to consume through simple testware and you will be well on your way to propel yourself and see adoption take hold.
