Recap AgileTD Webinar “Quality Processes in an Agile Environment”

Or How the Whole Team is Responsible for a Good Product or Service
 

On Tuesday, June 30, the AgileTD team was fortunate to host a webinar with the wonderful Lisa Crispin and Janet Gregory. Over 180 viewers were the same opinion, and joined us for a 60-minute session packed with agile testing expertise, some great questions, fun moments and ATD love. With so many in-person events being rescheduled or canceled, we try to bring the community together, virtually. The AgileTD webinars offer a platform to share knowledge, network and meet across the globe, and discuss the ways we can improve work in an agile workplace. Look out for more upcoming webinars on our social channels! 

Janet and Lisa have long been essential members to the global agile testing community, and, we are happy to say, to the Agile Testing Days family. Both busy in their regular jobs as agile coaches and consultants, they still find the time to also run the Agile Testing Fellowship. The Agile Testing for the Team Course is offered globally and equips teams with practices, skills and techniques that can be used right away. And by joining the fellowship you will receive ongoing support for adopting the agile testing mindset to your team. We are happy they found the time to give this webinar.
 

What is Quality in Agile?
 

The idea for this particular presentation relates to W. Edward Deming’s 14 key principles for business effectiveness, that were postulated as early as 1982. Janet and Lisa argue that it is these principles that are alive and well in effective agile teams. In this talk they show how and why. 

It was then described how everyone’s understanding of added value is quite different. There is not ONE such “quality”! Janet actually compared this to how everyone has an individual understanding of “good coffee”. 

The ways in which we define quality also depends on the type of product or process we build, and essentially how we actually build it. This is when agile testing comes in, as it is a holistic activity, not just a phase, as it starts from the very beginning when creating a new product, service or process. Agile testing is more than testing code! Therefore, the whole team is responsible for quality, all the time, at every stage of development and operations.

When looking at the DevOps loop, this also implies that the ownership of quality is not merely limited to the team but goes way beyond. Everyone involved, from the team, to business owner, to user and customer contributes to the quality and testing is performed constantly.
 

Janet and Lisa go on to explain the varied forms of testing activities. What testing activities does your team actually execute? Most can be assorted in one of these four basic categories: ask questions, example and test guides, checking, and investigating, all of which have different tools and techniques at hand, for instance test automation for checking or stress tests to investigate. 

The story of “A potential speaker can submit a talk for a conference for review” then serves as an example to go through the asking questions activities in detail with different scenarios and according example tests. To check and investigate certain features or use cases, regression tests, automation and exploratory testing are essential, Lisa and Janet explain. Exploratory testing is pointed out as the main activity when testing quality attributes. Is the product reliable? Does it do what it’s supposed to do, every single time? Can it operate with other applications? And again, as with quality, the types of quality attributes you want to test, depend on the product you are building. Reliability or data security might be more important than how well the app or feature performs. Decide with the whole team what is most important for your product.

Continuous integration plays an essential role when trying to deliver and add business value often, when aiming for a successful product and business, Lisa claims.
 

The presentation is concluded with what could be referred to as substantial attempt to define quality and what the responsibilities in the organization and team are. Or, how Lisa and Janet put it “It’s all a balance, and it depends on the context”.

To get the whole picture of what was presented and discussed, you can just watch the recording. Everyone who attended the webinar can simply log back in and watch the replay there. For everyone else, please go to our YouTube channel. The edited video will be available within the next few days.

Time for Questions
 

Q: How do you recommend testing systems where dependent upon work products are made in separate sprints? System testing is not possible because the system is not ready, but testing only the product of a sprint leads to silo mentality meaning, lots of green ticks but quality aspects like scalability, security are tested later and by separate teams.
A: Product management is supposed to provide clear priorities to work effectively. Part of that is how we can make sure everybody is working on something to make it end-to-end in order to practice all that testing. If different teams are working together on one product and system, try and figure how you can build an end-to-end thin slice so that we can build in scalability and the different quality attributes. Taking that thin slice and how we slice those features is critical. That is part of product management and the whole team working together to achieve that. Working in silos is not helping
 

Q: Is it possible to attain a quality process certificate such as ISO 9001:2015 for testing & QA in an agile environment? Auditors will request a documented process and evidence for a lot of deliverables, interactions and risk management, all of which could probably undermine the very essence of agile testing.
A: Think about what is the audit trying to do? Most of the time it says “show evidence that”. In the past, this was done by paper document, which is fine, but it can also be done differently. For instance, teams can document their process through their automation. The process is the documentation, and no written documents are needed. But first, try to get an answer to the first question.

Q: How can QA bring business value other than identifying risks, preventing or finding defects.
A: Because in cross functional teams, everyone can participate. For example, a tester might be helping the dev team in finding solutions. Despite not having or just having little coding experience, the different viewpoints can help other members on the team. Testers mostly have a good overview of the whole system, understand the big picture, and know which changes might affect other areas in the product. Be open, and ask yourself, can I add value here?

Q: The 13th point from W. Edward Deming’s Quality Philosophy is “Implement education and self-improvement” … in this covid19 challenging time what areas and skills testing professional need to focus & learn to prepare them for future? What key areas & basic skills do you suggest testers and test leads need to work in the umbrella of “Self Improvement“ 
A: Try to make time for self-improvement regularly, read blog posts, articles, webinars, that is interesting to you. Take time to learn and listen to other opinions. For example, just recently people had to deal with the question, how can I work remotely? And that is something out of the typical work routine, you had to get acquainted with. Lisa then turned to DevOps, as being one of the key factors in successful teams and that testers are part of both, Dev and Ops. Don’t be afraid of the buzz word, and ask questions! There is a lot of great questions that can be asked there. Pay attention to what is on your radar, and go learn about it … and don’t be scared.
 

Q: How can I help a product team so bogged down in support tickets they're struggling to build new features?
A: Sometimes, the right thing to do, is to STOP. And ask yourself, is this making sense. Start addressing quality problems, and put new features on a hold and figure out where you are, and where you want to be. Also, what is the cost of not fixing your quality? Explain the risk to the business owner. What will happen when the bugs are NOT being fixed? Testers should be able to articulate the risk. The business owner has to decide what is more important – new features or fixing bugs, improving quality.

(written comment Lisa: One of my teams approached this by allocating a number of story points each sprint to addressing the backlog of support tickets, kind of a budget, so we fixed them over time, while also delivering new features. We also budgeted time to spend with business folks to learn the domain.)

Questions that could not be answered in the webinar
 

Q: How to plan a Test Strategy when Multiple systems are involved
A: There could be several ways to look at this but we’ll try to keep the answer generic enough to cover all interpretations. First, get people from each system talking – in a room if possible, but at least in the same conversation. Each application / system needs to understand how the change that is being made affects the other systems.  I find that using example (concrete examples) is the best way to show how something is affected. For example, if you had an order and you needed to follow it all the way through. Create an imaginary order, including all the information .. order number – how does that translate to an invoice number, how is the order matched to the invoice, and follow it through the system. Have a few scenarios like that and determine who will be responsible for testing it end to end.  Who / what systems talk to each other?  What does each team need to be responsible for testing. Someone commented in the webinar that each team should agree on the same definition of Done. That may not be exactly true – the systems may have different needs, but it is good to think about and know what to expect.  The teams all need to have the same priority to get the change in not necessarily work from the same backlog, but definitely know when they need to have their part done. Which means dependencies need to be highlighted and part of your quality strategy – not only for testing for overall development.
 

Q: What do you think when a team doesn't have a tester and the quality depends from the team (and they are all developers) I saw this kind of team in a lot of company.
A: If there is no tester, the developers need to pick up the slack. They need to learn to test. They need to learn to build the quality in from the beginning. I’ve worked with teams that had a quality coach – someone who helped them identify the kinds of tests they might need, and coached them to help them learn. 

Roundup
 

Webinar attendee Clare Norman created this visually perfect overview of the basic webinar findings. If you want to have a closer look, please go here. Thanks to all those awesome sketch noters for summarizing important content in such a lovely and artful way. Not much else can be said, just a big Thank You to Lisa and Janet for sharing this sweet AgileTD moment with almost 200 people and us. 

To attend one of our upcoming webinars, have a look at our social media channels or subscribe to the AgileTD newsletter. Do you have something to share with the agile testing community? Are you possibly interested to speak and present your topic? Experienced or not, we welcome everyone to step on stage in one of our next webinars. Just contact us at events@trendig.com and we’ll take it from there.

Are you interested in attending the Agile Testing Fellowship training "Agile Testing for the Whole Team"? Save 25% on all July and August trainings with the code Summer25. Learn more about this special offer here.

Stay safe and take care of one another 💜.
See you next time!

The Agile Testing Days Team