Quality Assurance in Agile Software

continuous delivery is the most effective approach that we know of for creating software it's fast efficient and high quality it gives us great feedback on our progress and the opportunity to evolve world-beating products but it's challenging it challenges many of our assumptions about how software development works and often our role in its production continuous delivery changes how everyone involved in the production of software works and often challenges assumptions about people's roles too one of the roles that continuous delivery changes significantly is that of quality assurance [Music] hi i'm dave farley of continuous delivery welcome to my channel if you haven't been here before please do hit subscribe and if you enjoy the content today hit like as well i'd like to begin by thanking our sponsors harness equal experts octopus spec flow and linode they're all helping us to develop our channel so please do help them in return by checking out their links in the descriptions below my new book modern software engineering talks about a holistic approach to thinking about and practicing software development if you're interested in what it takes that allows us whatever the nature of our software to do a better job and create better software faster why don't you check it out there's a link in the description below my favorite way to describe continuous delivery is that we work so that our software is always in a releasable state this has implications for everyone involved in every aspect of software development product owners need to think about what it means to release change as a constant drip of small features rather than as a sporadic dump of grandiose plans developers need to shape their work and their software so that release can happen at any time maybe even in the middle of the development of a feature testers and qa people don't act as gatekeepers to release into production hang on a minute isn't that what qa teams do well no not in continuous delivery teams let's think about this from first principles if our aim is to work so that our software is always releasable then what does releasable really mean it's clearly contextual it will depend on the nature of your software and the nature of your organization but the most obvious definition is if that we think our code is releasable it means that there's no more work to do before we're happy for it to be released no more testing no more documentation no more sign offs it's ready to go the way that we determine the releasability of our software in continuous delivery is to create a deployment pipeline that defines what releasability means for our software the deployment pipeline is definitive it goes from commit to releasable outcome it's no good building a deployment pipeline that looks like this because at the end of the pipeline qa could still reject the change our change is not releasable and so the deployment pipeline is not definitive this adds complexity to the development process lengthens the feedback cycle and delivers bad news too late to really be useful whatever it is that it takes to figure out if your software is releasable it almost certainly involves two kinds of check does the software do what we meant it to do and does it still do what it used to do before this change for many more traditionally structured teams finding the answers to both of these questions is often left to a qa department or at least qa people looking at the software after we think it's finished most teams even most agile teams treat qa as some kind of gate into production the role of qa is to find the answers to these questions after the development on new features or bug fixes is complete this is problematic it doesn't really work very well it seems obvious that we should organize things this way but when we when you stop and think about it it doesn't really make very much sense let's imagine that we've been tasked with creating some green dots we begin churning them out but at some point during the production run we run out a blue dye so we end up with some of our dots being yellow by mistake the longer we wait the more yellow dots we make until they're all yellow so the bugs in our system the yellow dots grow until they overwhelm the system how could we prevent this well obviously this is a time sensitive thing the longer we leave things before we notice the problem the more waste yellow dots we will have created so if it takes one week for the blue paint to completely run out but we only test every two weeks nearly all of our output is going to be waste if we test every week a big fraction of our output is waste if we test every day maybe only a few dots were waste so the frequency with which we test matters a lot if we want to make high quality products we need to up the frequency with which we test them a better way to think of this is that we want to reduce the time between making a change and testing that the change was correct so what if instead of testing our dots every day we tested them as they were being produced as soon as we saw a problem we stopped and fixed it this is what lean people call one piece flow instead of testing changes in batches we're going to test every change now if a problem occurs like we ran out of blue die we're going to stop add blue die and then continue having had a single failure when you think of it like this it's obvious that check every change will result in higher quality aim then is to identify a mistake at the earliest possible opportunity the earliest opportunity is at the point when we make the change to put that in another way as edward deming said you can't inspect quality into a system you build it into the system this is true however good your qa team or tests they will spot mistakes after they happen what if instead we could spot mistakes while we were making them that's what deming really meant we want to build error detection into the process of creation the people that make these mistakes are the programmers that put them into the code so we need to catch them then as the programmer introduces them so we can do things like pair programming and automated testing to catch the mistakes as we are making them how far can we take that well let's go back to our green dots for a minute we could check each green dot after it was finished to see if it matched our standards but could we do any better than that assuming the green dot took time to create then we could monitor the quality of the dot during the course of its creation and as soon as we saw something that we didn't like we could correct it that's the step that test driven development takes not only do we test every change but we create these tests as little specifications of what we really want before we start and then we use them to guide the creation of our code if one of these tests spots a problem we stop and correct the mistake this is about as efficient as and as high quality as we can get some may think that this completely marginalizes the traditional role of qa and if you think of qa as gatekeepers staunching the flow of crap changes into production then maybe you're right but that is never really a good role for qa this traditional gatekeeper approach usually ends up in one of two bad places depending on the priorities of the organization either quality is seen as vital and then qa becomes a bottleneck slowing the pace of change it's pretty obvious that if your qa process takes two weeks you aren't going to be in a position to release every week let alone every day this has a big cost and sadly part of that cost is a reduction in the quality of the software that we produce you don't build high quality software by going slower high quality comes from working in small fast definitive steps where we can monitor the quality as we create the change so we need to be very wary of things that slow us down the other failure scenario is in organizations that prioritize delivery over quality in these organizations qa people are put into an unenviable position they're tasked with defending quality but they're not allowed enough time to evaluate the changes thoroughly enough testing time is squeezed to the point where lots of bugs slip through into production in really dysfunctional organizations qa is then often blamed for this now it may sound as though i'm trying to have my cake and eat it here i said that you need to go fast to get high quality but that going fast leads to low quality well yes that is kind of what i said but the key to unlocking this is what you mean by going fast the trick is to spend time in the right places testing after the fact is the wrong place to spend lots of time batching up changes and then testing huge collections of change is a very low quality approach you can't inspect quality into the system after all equally not testing and crossing your fingers hoping that this time our genius will tell and there will be no bugs is just fantasy sure you can write code like that but it won't be any good so we need to build quality in and we need lots of tests continuous testing isn't an add-on to continuous delivery it's a cornerstone of it in my continuous delivery book 6 out of the 15 chapters are primarily focused on different aspects of testing continuous delivery is aimed squarely at this problem our aim is not to marginalize quality completely the reverse our aim is to place quality front and center in our development process the whole team needs to become quality focused maybe even quality obsessed and this is one important role for qa professionals to take to act as guides experts on thinking about quality and testing not after we've finished but rather before we begin this rules out a few common approaches to qa in this continuous delivery world it is a bad idea to have a separate qa team you may have a qa community of people who share good ideas but the qa function is part of the development team qa professionals work alongside developers understanding new features before work on them starts and evaluating new features while they are being created not afterwards this way the team can spot mistakes as they happen rather than days weeks or even months later as a new feature comes into the team the team discuss it they all work to explore and understand the new feature and what it means for users of the system this encourages us to capture requirements from us the perspective of our users which is a very good thing it also means that while we're having this conversation the developers are thinking how does this fit into our design and the qa folk are thinking how does how do we test this when the teams start work on the feature my preference is that we organize a story kickoff of some kind in bdd circles this is sometimes called the three amigos meeting except in the teams that i worked on there were usually four of us we'd have the product owner who understands the need for the feature the goal that we're trying to achieve with this change we have a pair of developers who will start work on developing this new feature together and the qa who will act as an advisor and do any manual testing that we think worthwhile the conversation usually begins as an exploration of the new feature what it's for how does this fit in with the existing system how will the users make use of this and so on then the developers and the qa start to explore how they will be able to tell that the system does what it needs to do they think of examples that would demonstrate that the system has this new feature they may discuss various angles including what should happen if something goes wrong maybe they go back to the product owner at this point and ask for that for their opinion and some clarification on what the user expects either way these examples are always described from the user's perspective and now captured and form the acceptance criteria for the new feature now the developers and the qa discuss their testing strategy they all assume that the idea is that they're going to create tests for each of these acceptance criteria an executable specification that demonstrates and evaluates each example that they thought of this gives them all a structured definition of done for this feature when all of the executable specifications pass the feature is finished i particularly value having a qa person on the team at this point since they often think of examples that i as a developer might miss so we end up with better specifications this way whether the qa or the developers capture these specs as automated tests depends on the team and the individuals there's nothing wrong with either approach on the teams that i worked on qa people often wrote these tests but equally developers often wrote them too and nearly always added to them even if the qa person writes the specifications they're the developers responsibility after all they are the people that will commit changes that will cause these tests to fail so they need to be the people who will see the result first via their deployment pipeline this way they can respond to failures fast after all why slow things down with a middleman at this point during this conversation one of the goals is to strategize about any manual testing it may surprise some people that i'm talking about manual testing but i think that manual testing is really valuable in the right context i just don't think that manual regression testing is valuable in any context if our aim is to be efficient in delivering feedback into development teams our goal needs to be or to automate all regression testing but there are some kinds of tests that humans are much better at for these things manual testing is best if our software works and our automated testing should assure us of that then what humans add is does it work well is it nice to use does it paint pictures in our minds that help us to understand what's going on does this new feature look good does it fit in with the rest of the system this more subjective exploration of the system doesn't need to be repeated all of the time it happens once at the time when we make the change i think of this exploratory approach to manual testing as surfing the leading edge of change in our system qa people are looking at changes as they are being developed and give feedback on these changes to their dev teammates in fact that's part of the planning at the kickoff once you've done this part i can test it so let me know as soon as you're ready for me to take a look our aim is to avoid building mini waterfalls into our development process we don't want the developers to work on a feature until they think it's complete and then hand it over to a qa person we want everyone to be working alongside each other on the feature as it evolves and ideally everyone finishing at roughly the same time so if a qa person spots a dumb mistake in the feature they can point out the mistake to the development team while they're still working on the code no need for a formal bug report just have a chat no need to wait for the feature to be finished before starting work on fixing it or on testing it continuous delivery is a challenging change for everyone but it is a particularly big change for qa people at least for those who are used to working in more traditional settings my experience of seeing people make this transition though is that this approach to qa is much more rewarding and that the qa professionals that i have seen make this step would never willingly go back to the old way of doing things thank you very much for watching [Music]

Channel: Continuous Delivery

Views: 68,779

Keywords: the role of qa, qa in software, qa, what is quality assurance, quality assurance, qa testing, software quality assurance, qa in software testing, quality assurance vs quality control, qa training, agile quality assurance, agile, software development, software engineering, computer science, continuous delivery, devops, Dave Farley

Id: XhFVtuNDAoM

Length: 17min 41sec (1061 seconds)

Published: Wed Mar 02 2022