As a tester, how often do you refer to yourself as a “tester” without qualifying specifics, such as a functional tester, performance tester, security tester, etc.? Almost always, right? However, the moment testers start to drill into details, they often limit their scope of operations to their core focus areas.
In a recent interview that I was conducting, I was shocked to hear a functional automation tester mention that her scope is limited to automation and that she's hardly done any manual testing. This limited landscape is changing—and for the right reasons.
There are frameworks that you can build on top of functional frameworks, such as Selenium, to support other attributes such as security and accessibility testing. Studies show that performance testing is best done when implemented in conjunction with functional testing. While it is important to have distinction between efforts to maintain specialization and core subject matter expertise, overlap in test efforts—even in niche areas such as security—is becoming a common practice.
A visually-impaired tester on our accessibility team explained recently the importance of accessibility testing in localization and how bookmarks and tools such as browser add-ons are making it feasible to take on combined test efforts. For example, Favelets are easy to use bookmarks that enable accessibility testing for both English and localized versions of applications.
Having individual specialized teams that focus on specific test areas brings certain advantages around focus, expertise in tools, processes, optimizations, and efficiencies. However, letting a function operate as an individual silo has several downsides, especially around coherence in application quality, optimization in re-use of resources, and more importantly, enabling testers to think holistically when bringing creative test scenarios to the table. For example, several functional test scenarios can be leveraged for performance testing. Such collaboration not only tightly couples various pieces of product quality but it also reduces the cost of quality and time to market.
Where is the best place to start with testing in conjunction? It starts with a mindset change, where testers are encouraged to understand other quality attributes in the mix. Testers should be encouraged to understand and implement a simple set of scenarios across test attributes.
Top 10 OWASP vulnerabilities is a good place to start in security for non-security testers. The following is a brief but good accessibility checklist—ensure meaningful alt text, purpose of links, keyboard accessibility across the workflow, and correct use of color. From a usability angle everyone should be encouraged to empathize with end users, including the intuitiveness of the application, graceful error recovery, and overall simplicity in a feature-rich design.
Once the industry starts embracing the value co-exising testing attributes, testers will become even more indispensable in the quality game. The best place to initiate this is within your team, so start today if you have not yet implemented testing in conjunction!
