Back in 2017, I wrote an internal blog post about my first visit at Agile Testing Days, called “Are Testers Obsolete? Spoiler Alert, They Aren’t”. Besides the occasional obsolete link, my inability to find the reference to the images (if they are yours please let me know), and my shifting away from testing I still find the content relevant. Sharing it here for others to enjoy.
A couple of weeks ago, I attended the Agile Testing Days conference in Potsdam, Germany a 5-day event focusing on Agile software testing. The first day is dedicated to tutorials while the remaining days are dedicated to workshops and presentations given by some of the most well-known names in the testing world. To name a few, Katrina Clokie gave a keynote on “A Practical Guide to Testing in DevOps”, Lisa Crispin along with Elizabeth Hocke a workshop on “Testing in a Continuous World” and Gáspár Nagy a presentation on “Behavior Driven UI Automation”.
After attending some presentations and workshops I started recognizing a theme in the conference:
What is the tester’s role in today’s development process?
The following two keynotes helped me narrow down a bit the answer to this question.
Setting the tone
“Continuous Delivery Sounds Great But It Won’t Work Here” by Jez Humble
There was no need for introductions for one of the co-authors of the Continuous Delivery book. As the title of the keynote suggested, the topic was the excuses various organizations listed for not being able to implement Continuous Delivery vs the real reasons behind their resistance to change.
He started by setting the record straight about continuous integration which is more than running Jenkins on a branch and ignoring it when the build breaks. He noted that it is the developers’responsibility to react fast on a broken build either by providing a fix or reverting the commit altogether if a speedy solution is not possible.
He then proceeded by giving examples to prove why the stated reason of not doing Continuous Delivery were just excuses. A U.S. federal government project for “we’re regulated”, a printer firmware for “we’re not building websites”, a company that invested years in changing their architecture for “too much legacy” and finally a company that changed their processes to enable people to work better for “our people are too stupid”.
For this last point, he noted that“a bad system will beat a good person every time” and topped it off with the following stichomythia
– We just can’t do Continuous Delivery. Our people are too stupid
– True. But it’s not the people you were thinking of.
Jez finished the keynote by providing some practical advice on how to move into Continuous Delivery, including:
- start with a measurable business goal
- consult experts but do the work yourself
- talk to other teams especially with the ones you are afraid of
- achieve quick wins and share
- enable the opportunity to learn from failure.
He identified architecture as the biggest determinant of successful Continuous Delivery and blindly copying other teams’ methodologies as the biggest pitfall.
Finally, he clarified something that is a frequent misconception
Continuous Delivery is not about getting rid of testers.
Even though he emphasized that manual regression testing is a terrible waste of human talent, he nevertheless asserted that exploratory testing is more than necessary before releasing your product. No matter the amount of test automation there is no way to replace human intellect and judgement essentially what testers provide and that requires no programming skills.
One of the following keynotes would challenge the testers’ skill set and mentality even further.
Embracing change
“Owning Our Narrative” by Angie Jones
A talk by a Sr. Automation Engineer at Twitter seemed like a great opportunity to hear the insights of a developer with first-hand experience in test automation. To everybody’s surprise Angie started talking about the history of recorded music.
With the invention of the phonograph some instruments had to be abandoned because they didn’t sound good on record. When the jukeboxes almost deemed live performances obsolete, the musicians provided samples to the machines as teasers to boost record sales. When new technologies would come along like the cassette player that could record songs from the radio, the musicians focused on improving the quality of their recordings so that the public went for the original. Finally, when mp3s became the norm the musicians understood that they needed to rethink how to measure success not only in record sales but also in track sales.
Angie finished the chronicle with this key conclusion.
The music biz and tech changed but the role of the musician remained!
She then proceeded with drawing the parallels between the musicians and testers narrowing it down to the following key points.
Make automation work for you
She emphasized that automation is a reality that is here to stay. Testers can use the options that new tools provide to their benefit so that they can perform their role better. They don’t necessarily need to be the ones that program the tools but they can be the ones guiding the automation as usually they are the ones who know the bigger picture.
Our tools don’t always shift with us
If you feel that you can’t cope with the latest changes in software development it might that you are not using the correct tools. That might mean moving out of your comfort zone and start learning new techniques, tools or thought processes as well as giving up somethings you hold dear. As a last remark
Guess what, people don’t want collaborate with you if you have 12 spreadsheets to go through.
Shifting imposes limitations
As development cycles become shorter and shorter testing needs to be done fast and in an efficient matter. As the musicians needed to move from the live stage to a studio, testers need to contribute to both business and development so that bugs can be prevented instead of just discovered at the end that the time is limited.
Adjust measurements of success
That last point was aiming at organizations that still use the number of bugs found during testing as a metrics to measure quality. She rightfully asked,
Why on earth are we using bugs as metrics when we want to build quality in?
As alternative, she suggested to monitor risks and celebrate the things the team needs to see more of.
As in the previous keynote, Angie emphasized that testers are still very much needed but they need to claim their space and embrace change instead of fighting it off.
Stay calm and keep on testing
After 3 days, packed with interesting presentations and discussions the answer to the tester’s role came by the definition of testing itself (well at least in one of those I subscribe to)
Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test.
Cem Kaner
The way we conduct our investigation,whether it is with exploratory testing or using automation tools it is up to the needs of the product we are testing. No matter how fast or slow our development cycle is, the important thing is to be able to provide information about the risks, issues and even the good parts of our software. In that context, that may mean doing our own retrospective to evaluate how we plan our tests, how we execute them and how the information and its implications reach our stakeholders. And then comes the hardest part, changing our ways.
Wrap up
This was my first Agile Testing Days but not the first time I attended a testing conference. One of the first things that was obvious upon arrival, was that it promoted an open culture. The event is structured in such a way, so that discussions are encouraged in the means of open spaces, daily early morning Lean coffee or even Agile games. At any given time, you could have a chat with one of the speakers about your pain points or observations. Everybody was there to exchange ideas, failures and accomplishments without passing judgement on the others. This conference was a meeting of a community that is there to provide guidance but also support to its members. I am happy I was able to attend and I hope more colleagues get the chance to participate in the future.
More Questions Than Answers 
Still relevant
LikeLiked by 1 person