Those of us who are passionate about delivering valuable, high-quality software to our customers frequently and at a sustainable pace are living in exciting times.
Many are embracing “modern testing” principles. We’re acquiring new skills such as how to help non-testing teammates learn to test, how to analyze production use data, and how to use that data for testing. Testing is at the heart of DevOps culture, providing new opportunities for testers. We have amazing tools to help us with activities such as regression test automation and learning from production monitoring, logging, and observing.
At the same time, I still encounter many companies who are doing testing the way most people approached it 20 or more years ago. They have siloed testing/QA teams who don’t collaborate with development teams, operation teams, or even product and design teams. They have no automated regression tests or are struggling mightily to get traction on that automation. They’re doing only manual regression testing, working from written scripts, and no exploratory testing.
Why??!!!
I’ve seen leading agile practitioners scratch their heads and wonder – after two decades of sharing agile values, principles, and practices with the world, why are so many people not using them?
Teams that do use a whole team approach to testing and quality are successful at improving their processes and their product. The State of DevOps report shows correlations between the use of modern testing approaches and high team performance. So why isn’t everyone trying to use what we’ve seen work well for 20 years now?
I have no actual evidence as to why this is, but I have some unscientific theories which I’d like to share. I’d love to hear your theories too.
Lots of Newbies
The number of new software professionals is growing fast. The Bureau of Labor Statistics predicted a 24% increase in software developers alone from 2016 to 2026. Despite having heard “testing is dead” for the past 15 or so years, I see more and more testing conferences with more and more people attending them, so I surmise our profession is also growing fast.
Universities are still generally poor at teaching modern development and testing approaches, so people come out of school without expertise in agile or DevOps values, principles, and practices. They certainly don’t learn much about testing in university. So, they have to somehow discover all this once they’re on the job. If they join a company whose software process is still stuck in the 90’s, doing poor waterfall at best, they’re unlikely to be exposed to modern testing.
Culture is Hard to Change
In my experience, it’s extremely difficult to change an established company culture, especially in a large organization. Even big enterprise companies who “go agile” often transition from role-based silos to having dozens of siloed Scrum teams that don’t talk to each other. All too often, an IT organization transitions to “agile” and either leaves the testers on their own test/QA team or sticks them in a cross-functional delivery team with no training or support to figure out how they should now work with people in other roles.
Large companies often have a complicated power structure. Upper managers may be more interested in protecting their domain than in delivering better software to their customers more frequently – and they don’t always prioritize a sustainable pace. If nobody educates them on how an investment in software quality – doing things like giving teams time to experiment and learn — pays off in the long run, they just keep imposing unrealistic deadlines while their software teams burn out.
Change is hard. Even when management is receptive, maybe not all team members are willing to try something new. It often takes only one naysayer to kill an effort to move away from “the way we’ve always done it”. Companies that are strapped for money may not be able to see how an investment in learning pays off.
I once worked in a company with a “hero culture” where the person who fixed the problem that brought down the website was lauded and rewarded – so why try to prevent production problems from happening? Even after leading a successful agile project to meet an “impossible” deadline, I couldn’t affect change in that culture.
Life is Challenging
If your management doesn’t support you learning how to improve the way you deliver your software, you have to do it on your own time. As you learn, you can be a change agent and try to help your team improve.
But that takes time, and we all have many demands on our time. Some people have to work two or more jobs to support their family. Some people must spend much of each day caring for a family member. Others have health issues that limit their activities. Perhaps they can’t afford to go to conferences. Perhaps they can’t take an evening off to go to a meetup or watch online video courses. There are so many reasons people aren’t able to learn on their own time.
So, how do we promote adoption of modern software delivery principles and practices?
I don’t have any easy answers, but I’d like to start more conversations about this. I think we can raise awareness that there are better ways to work, that it’s possible to make our customers happier while enjoying our work a lot more. Here are some ideas:
- If you can, make time to educate yourself with the many resources available to us these days: online courses, webinars, blogs, books, articles, podcasts, local meetups, conferences.
- Share what you learn with your teammates. Help them learn about different types of testing. Try small experiments together to improve.
- When you meet other software professionals, for example in a social situation, encourage them to join you at your local tech meetup
- Write about your own experiences, share them at meetups and conferences, to show others that improvements are doable and effective (if public speaking scares the pants off you, check out the SpeakEasy mentoring program)
- Contribute to scholarship programs that help people attend conferences and access online content such as webinars and videos of conference talks
We have new people joining our profession all the time. What ideas do you have to help them embrace 2018 rather than 1988?
About Lisa Crispin: Lisa is a tester who enjoys sharing her experiences and learning from others. She works as a Testing Advocate at mabl, is a co-author of Agile Testing: A Practical Guide for Testers and Agile Teams as well More Agile Testing: Learning Journeys for the Whole Team, she’s a frequent conference attendee and organizer, and she is an avid donkey lover. To find out more, find her on Twitter or LinkedIn.
Leave a Reply