When you work in testing long enough, you develop or adopt positions on many aspects of testing. Some positions may be influenced by your environment, some by your peers (respected and otherwise), and some by practice. Work in testing longer and you may want to share your positions and occasionally encourage others to adopt them. We see this with testing models or techniques, testing schools of thought, and testing automation. I believe it is testing positions and the varied interpretations, discussions, and debates that makes the craft a satisfying career choice.
I believe it is becoming something more.
With the introduction and practice of agile methodologies (Scrum, DevOps, et al), the practice of testing inside those methodologies has grown in importance. Testing must not “wait until the end”, or plan large testing events “after the code is deployed to the test server”. Waiting impedes project pace by time spent waiting and by discovering defects that were in the code while we were waiting.
The demands of business are driving the adopting of CI/CD and testing can not only help with that, it can drive it. Testing must drive project pace and to drive project pace, we must become advocates.
Testers advocate for testability, shift left, and buying more than building.
Testers must advocate for testability in requirements and designs. Testing can no longer afford to wait for information. Rather, it must influence requirements for a single clarity and collaborate with team members to share that clarity.
Additionally, testers must actively participate is product designs (high level and detailed) to influence them for testability. Request the design be transparent with key information and behaviors by using some form of logging, and request the design be controllable by having the ability to mock product objects. When a product has good testability, it easier to test and can be tested earlier and quicker.
Testers must advocate for Shift Left. Shift Left encourages new and changed products be evaluated closer to construction. In many cases, this means more unit tests and deeper unit tests. In some cases, the unit tests become the regression suite that can execute at any time. Regression no longer need occur at the end of development! We need to know as soon as possible if a recent change has impacted the application.
If much of the testing is shifted left, what do testers do? They are reviewing the unit tests and suggesting more, they are exploring risks, and they are exploring environmental dependencies such as security, configurations, and connectivity.
Buy More Than You Build
Testers must advocate for buying tools and utilities rather than requesting them be built. There are certainly many cases where building a tool or utility makes sense. For several other cases, buying tools and utilities can get testers testing quickly.
I believe by advocating some or all of these ideas, testers become project drivers and CI/CD supporters.
Lead on, Testers!