This was first published in Testing Circus Magazine – March 2016 Edition .
Feeding the revolution in web technology and development has been the advent of evergreen browsers. These browsers will update automatically as new features are added or bugs fixed often without any intervention from the end users.
This change has unshackled web based applications from chains of supporting legacy environments. While software has always grown and evolved, since evergreen browsers arrived on the scene, it has reached a frenetic pace. Couple this with the increasing adoption of agile/incremental development and the result is software development and technological innovation is occurring at record breaking speeds.
But that’s the Developers Problem
So why should testers care, unless you are focused on automation then an app is an app right? Don’t the technical implementation details just provide some additional insight to testing? They aren’t the primary drivers of test design or considerations. As testers we care about the behavior, the business logic, the usability and functionality. Isn’t the rest just a means to an end?
That may be true, but this shift in development has also been changing the process in which software is being designed and developed. Agile methodologies, DevOps, the shift to the cloud… All of these things and more are changing where, when and how testing is integrated into the software development lifecycle.
If they haven’t passed completely, the days of testing beginning after development of project has completed are numbered. In some cases these days, time to market/release is more important than a completely polished or fully featured experience. This means imbuing quality earlier and/or in different ways than formal test plans and detailed procedural test cases. There just isn’t time for a mini test waterfall inside of an agile sprint.
When the practices around the act of testing introduce more risk than reward, the testers value within the organization falls. We need to be aware of these changes internally within our organization and also within the context of the software industry.
The Sky Isn’t Falling
This isn’t a fire and brimstone story, I’m not here to tell you QA is dead or that all testing jobs are going away. If you have been in the game for a while, there seems to constantly be some doom and gloom projection that testers will be replaced by some technology or practice. There’s been the impending doom of being replaced by automation, being outsourced, or even developers unit testing us out of a job.
The yarn I’m spinning is the polar opposite, it is possibly the best time to be a tester. Things are changing but the software world is always changing. While testing is changing, so much of what a tester has always dreamed of is within reach or for some is already here.
In the days where waterfall application development was all the rage, testers often begged for someone to open up the doors for them at design reviews. We were often physically separated from development teams. Segregated to maintain the sanctity of test from the perilous development influence. Segregated to alleviate developers frustration at the interruptions from testers vandalizing their coding efforts. While those statements are written in jest, there are plenty of veteran testers out there that can regale you with tales that may sound eerily similar to what I have described above.
We’ve wanted a voice in the conversation, a place at the table, an opportunity to show we can improve quality in ways beyond bug reports. More than ever, we have that. Testers are pairing with developers while they are writing code. Not to do the coding but to be a voice for quality, to share our mindset and how we would approach using the software. Testers help groom the product backlog, adding acceptance criteria and setting expectations for how software will need to function before code is written. Developers are even making changes to help make testing easier, sometimes even asking testers what they might need in advance. While it’s not happening everywhere and maybe not occurring all the time, it is happening and it’s not rare like discovering a unicorn.
Just like everything else this change comes with a price tag. Tester’s have to put their money where their mouth is and have to bring meaningful contributions to these conversations.
What it means to be an Evergreen Tester
In an interesting twist of fate testers face a similar set of circumstances to that of the state of web applications and development in the days prior to evergreen revolution.
From the craze of browser wars, to the weight and baggage associated with supporting multiple platforms and versions, the browsers, applications and people that used them carry physical and emotional baggage from the journey. Don’t believe me bring up Internet Explorer 6 in your next team meeting and watch people physically cringe.
Similar pain and baggage runs as deep or even deeper in the testing world. There seems to be a never ending stream of people selling the next product or practice that will eliminate every teams testing problem. While that takes a toll on the testers, it also warps the perspective of developers and management and fosters misunderstanding and misgivings over testers practices. So we often feel under the gun to not rock the boat, not speak up and avoid the spotlight while still show value.
Just like the web browsers evolution to automatic self-upgrading pieces of software has fueled software revolution and innovation, testers need to evolve and shake loose from the related baggage.We do this by becoming evergreen and continuously and proactively growing and learning independently. Upgrading ourselves in order to take full advantage of the changing landscape of software development.
We do this by:
Building A Solid Root System
A strong, healthy root system is what secures a tree and allows it to stand tall and straight. First and foremost an evergreen tester needs to be rooted in a solid foundation of testing skills and methodology. The roots also allow a tree to take in nutrients from its surroundings. These nutrients are what enable the trees growth. By fostering growth in our core competency it enables a tester dig deeper into their craft and become exposed to new areas and possibilities.
With this solid foundation a tester can evolve and adapt to fit into the current environment. As dedicated test teams shrink and testers are increasingly embedded on cross functional teams you will be expected to stand tall as your teams ambassador of test. We can’t know only one way to approach testing or be locked into a single way of doing things. Showcasing our competency and adaptability is what opens the door to tester’s influencing other areas of the business.
If you aren’t sure how build up your testing roots, the testing community is incredibly welcoming. You just need to plug in and there is a forest of resources available including this periodical, the Black Box Software testing classes offered by the Association for Software Testing, the Dojo at Ministry of Test, Weekend Testing sessions, even Twitter. These all allow you to stay informed, educated and even practice testing in contexts you may not have available to you in your day job.
This new level of access across the team means testers will be more deeply involved in conversations that while directly related to the product are only tangentially related to testing. This isn’t a fancy way of saying that testers need to learn to code. It is reasonable to though to assume the more a tester understands about a system and its design the greater insight they can provide into increasing its quality. Coding isn’t the darkside for testers anymore, it’s just another way you can contribute to your team. You don’t need to be an expert or go around giving performance tips to current developers. It goes a long way to strengthen the connection between developers and testers to just be partially code literate and be able to follow more technical conversations.
It doesn’t have to be code though, we are just as involved in the product, program or project management processes. Read up on agile, scrum or whatever your team is using so you are better prepared to chime in with some insights or maybe serve as scrum master for your team. Go deep on your softwares domain or your customers needs, it’ll help you be test better and you’ll be of greater benefit to your product team.
There isn’t a specific predetermined set of skills here, but to be a successful tester you need to love software. So let your branches stretch and grow and follow your passions.
It’s Not Easy Being (Ever)Green
That’s a lot to ask of anyone, but we are the quality people so the standards for ourselves (and our craft) should be as high as the those we hold the software we test to.
Beyond that honorable call to action is a pragmatic reaction to the fact that testing will always be a target because it is a proactive practice that potentially saves money but generates none. There is also this dangerous sentiment out there that anyone can test. That sentiment derives from a lack understanding of what testers do and the value that they bring to a team. So please join me, whether out of noble pursuit of craft or out of self preservation, in seeking to change those assumptions one interaction at a time by striving to be an evergreen tester.