An Interview with mabl’s Lisa Crispin
Please welcome our weekly sponsor mabl to Hacker Noon! mabl is a powerful test automation integrated with your delivery pipeline. Create your free mabl account today.
Today we’re going to catch up with mabl’s testing advocate & agile development expert Lisa Crispin, to discuss the often underrated role of testers in programming, what “waterfall” really means, & the intersection of AI/ML & software development.
Can you tell us a bit about your background prior to collaborating with mabl? How did you first learn about agile development?
Back in 2000, the startup where I was director of testing had been bought by a big company. Eight of the senior developers left to form another startup. They gave me a copy of Kent Beck’s Extreme Programming Explained to read — they were all excited to try XP. I read it and realized, “Yes, this is all about the people and quality, this is how to successfully deliver a product, I need to do it!” Though the publications about XP at the time were centered on testing, they didn’t mention testers. I convinced my friends to hire me, and together we figured out how testers add value to agile teams. I shared what we learned with the XP community so that we could tackle more problems together.
What made you join mabl as a test consultant? What do you hope to achieve during your time here?
I’ve actually changed my title to “testing advocate” to better reflect what I hope I can contribute to the software community. Teams wanting to adopt a DevOps culture and succeed with continuous delivery need to learn the latest advancements in testing. A lot of testers need help finding their voice so they can help their software delivery team build quality into their product. I’ll be advocating for “modern testing”, using the work in agile testing that Janet Gregory and I have done (https://agiletester.ca ), plus the “modern testing principles” from Alan Page and Brent Jensen (https://moderntesting.org). Quality and testing are a team sport, but a lot of teams need help learning about them. Testers can help everyone on the delivery team change their mindset to bake quality into their code from the start.
What are your thoughts on the role of ML in test automation?
I see huge potential in making automated regression tests more reliable and valuable. We need effective automation to free up time for the activities that allow us to deliver value frequently: building shared understanding of each feature and story from the start; exploring requirements; verifying all the quality attributes such as security, reliability, accessibility, performance, usability; exploratory testing; learning how people use our product in production.
Why do testers need to learn Data Science?
We know we do not have the time to test All the Things — this is even more true with continuous delivery and continuous deployment. Even the best test environments are different from production. Now that technology allows us to gather huge amounts of information about production use, testers need to learn how to use that data. We can learn where to focus our testing efforts, and we can help the team figure out how to delight our customers.
Have you successfully trained mabl? Is she easy to work with? What are her strengths and weaknesses?
I tried mabl out while working on my previous team. I’ve been automating tests for about 25 years. I found I had to shift my mindset a bit. I’m used to coding the test scripts, using open source frameworks such as Robot Framework and Cucumber, using models such as Page Object and Screen Play. It’s easy to train mabl, but if something didn’t work as I expected, my first instinct is “look at the test script code!” Now that I’m getting the hang of it, I find mabl offers a lot of debugging help. It’s great to have the added flexibility of putting in your own CSS selectors or Javascript. The team is adding features so fast, I need more time to explore them! I know lots of teams who are quite successful at automating tests, but even so, UI tests are usually inherently costly to maintain. That’s a gap mabl can fill. For teams who have not yet gotten traction on automation, mabl can be an accessible way to get started. You still need to apply good automation patterns and practices, as with any test automation tool. I hope to help teams learn those so they can use any tool, whether it’s mabl or not, successfully.
We recently attended a Microsoft event about the future of AI, where most people agree that the role of AI (and ML) should be to help, not to replace, humans. The trend with technology though — is that eventually, tech would become so advanced that some jobs will be permanently lost. Do you see a future where ML-driven test automation will actually replace, not just help, the testers?
I think machine learning is more likely to replace coders. From what little I know about AI and ML, it sounds like it’s possible to train a machine how to write good code, by giving it huge amounts of “good” and “bad” code examples. There is a huge lack of understanding out there in the software community about all the ways testers add value — something I will continue working to change! We contribute the most by asking questions nobody else thinks of — we have a unique perspective. We know who are the right people to get together to have a conversation about how a feature should be have, what value the customer wants, how can we shorten cycle time. We are able to step back and see the big picture, see our product as our users see it, whereas developers really have to be focused in the narrow area where they are writing code at the moment. Machine learning can help us devote more time to more valuable activities.
How do you think ML fits into agile development?
It has the potential to transform our ability to learn how users REALLY use our applications. We can gather so much production use data and identify the most common use patterns. We’ll know what users are finding valuable and we can keep adding to that value. Agile development is all about delivering value to our customers frequently, at a sustainable pace (to paraphrase Elisabeth Hendrickson). Machine learning can enable us to shorten feedback loops and learn about customer pain points more quickly.
You wrote a few books on agile testing. What was the most difficult chapter(s) to write and why?
In Janet Gregory’s and my second book, More Agile Testing: Learning Journeys for the Whole Team, we wanted to help teams in a variety of contexts, such as big enterprise organizations, distributed teams, regulated environments, mobile and embedded software, big data, DevOps, etc. Obviously the two of us can’t be experts in everything. We reached out to leading practitioners in those various fields. But we still had to get a basic knowledge about all those different contexts ourselves. That was really tough. That’s “Part VII, What’s Your Context?” in the book.
Why do you think a lot of organizations still stick with waterfall rather than agile methodology? It it just a bad habit that’s hard to change or are there benefits to it?
In my experience, people use the term “waterfall” to mean “completely dysfunctional”. I worked on a great waterfall team back in the mid-90s. We had many of the development practices that are known as “agile” today. We automated regression tests at all levels, from unit to the UI. We had continuous integration and automated deploys to about 20 different Unix environments. Testers were involved throughout the cycle, from initial design meetings on. We were a big cross-functional team. Since our customers only wanted a new release every 6–12 months, a phased and gated approach was ok. But today, for most industries, we need to be continually updating our application to be competitive. It’s still more about finding good people and letting them do their best work, using the leading development (including testing) practices available. Transitioning to agile is a huge investment — to do it successfully, business executives need to be willing to let teams take the time they need to learn. Most executives do not understand how this will help their business in the long run.
You will lead a workshop called “Thinking outside the box” in Agile Testing Day conference this coming fall in Germany. How can people work around their own unconscious bias and become better testers?
Since they are unconscious biases, it’s pretty tough! Knowing we have them is the first step. In our workshop, Stephanie Desby and I will guide participants through some fun exercises to reveal some common biases. I think the key to working around these biases is to have a diverse team. Hopefully we each have a different set of biases, so as a team, someone is going to spot the pattern that the rest of us miss. I’ve found techniques such as Visual Thinking Strategy are a great way to exercise our critical thinking and observational muscles and work together well, I wrote about that: https://lisacrispin.com/2018/01/24/telling-stories-together-practicing-critical-thinking-vts/
What’s your general advice for beginner testers? For teams that want to go agile?
Beginner testers — the testing world has room for you! Bring your curiosity! In our technology world, we seem to focus on the “technical” things. I’ve heard it said that software development is 20% coding skills and 80% what I like to call “thinking skills” — communication, collaboration, creativity, problem-solving… but we seem to value people only by how “technical” they are. Work on your thinking skills. We have so many great testing communities now where we can get help and learn. Get online and find them, look for your local testing meetup, if you don’t have one, start one.
For teams that want to transition to agile, my biggest piece of advice is that it’s not going to speed you up — it’s going to slow you down for a significant period of time. There’s a huge learning curve to practices such as test-driven development, even to behavior driven or acceptance test-driven development. It’s really hard to learn to be a self-organizing team. This is a huge investment. If you focus on speed, you’re going to get technical debt that will grind your team to a halt. If you focus on quality, I promise you that in a year or two, you WILL be able to deliver value frequently. Not because you got faster at typing, but because your team learned to do small experiments to test out hypotheses about what will help them improve their product and process, and use retrospectives to “inspect and adapt”. You don’t “do” agile, you “are” agile.
What’s the implication for remote work culture when team goes agile?
In my experience, having the right people on the team is more important than having the team co-located. Sure, it’s awesome if we’re all in the same space. I’d rather work with humans in an office. However, if your team is disciplined and uses today’s technology properly, there’s no reason a team with remote people or even a fully distributed team can’t be awesome.
Are there many women in the agile development community? Would you say agile attracts more women than traditional tech?
There are more and more women and other underrepresented minorities in both agile development and testing, yay! I do believe women find agile teams a more welcoming environment. Agile is people-focused, nobody should be sitting in a basement corner cranking out code. It’s about continual conversations and continual reflection and improvement. That said, I still hear of a lot of abuse and disrespect of women even on “agile” teams. I started out as a programmer in the early 80s when programming was a low-status, low-paid job and there were as many women as men. I really hoped we’d be farther along in terms of inclusion and equality in the workplace by now. But I see a lot of change going on now.
What makes a great work day for you? When do you feel most accomplished?
Collaborating with other people to learn something, especially if we can deliver something that makes our customers’ day a bit better, is the most fun!
What legacy do you want to leave the world with?
I want to make the software world safe for testers. It’s such a misunderstood profession. I hear people use terms like “manual tester” and “automated tester”. The implication is that if you aren’t automating tests, you’re just banging on a keyboard. Nothing could be further from the truth. Testers make their biggest contributions by collaborating with programmers, product people, designers, operations, business stakeholders and others to figure out what is valuable to the business, and finding ways to deliver that value incrementally and iteratively, learning via short feedback loops. Testers help everyone on the team learn how to prevent defects from happening, and make sure we aren’t missing important features. Automating tests is a job for the team — testers are great at specifying test cases, and the people who write the production code are skilled at coding, so automation is an activity best done together. Testers are as valuable as anyone else on the team. I’d love to leave a world where that’s true for all software delivery teams.
mabl, our weekly sponsor, is a powerful test automation integrated with your delivery pipeline. Create your free mabl account today.