5 Ways Agile Development Changed QA Dayana Mayfield , Dayana is a QA engineer turned technology writer living in Milan, Italy. She's always down for a smoothie. March 9th, 2017 Agile development practices were designed to help businesses get to market faster. Around the turn of the millennium, a now well-known group of developers and engineers across industries convened to solve an all-too-common issue in software during the 90s: application delivery lag. In the 90s, products didn’t make it to market until 2-3 years after a business need was validated. If the product failed to stay relevant, updating it usually took too long. The “lightweight methodologists” as they called themselves, were searching for development processes that would be faster and more responsive. Until then, software development followed a step-by-step approach (known as the waterfall method) starting with requirements and ending with deployment. Only after one phase was complete would the next begin. Continuing with this methodology couldn’t possibly speed up lead times or get applications to market faster. The Agile Manifesto, written in 2001, included 12 principles that would help steer slow, lengthy processes towards continuous delivery and increased responsiveness to customer needs. Agile development practices have changed the world of quality assurance.When development teams move to agile, QA engineers have less planning, less documentation, and can struggle to accomplish regression testing on time. They’re also required to think more creatively and holistically than ever before. Here are some of the ways that the shift to agile has heightened the impact that QA teams can have on products. No more saving testing until the end Remember when software came on CDs? Yeah, well those CDs had to be designed, manufactured, packaged, and shipped. No wonder there was a lengthy quality control process at the end of development. No one wanted to be responsible for recalling thousands of CDs. When I first got into QA, everything was delivered via physical media, and so if you had a critical bug in your final shipping product, the cost was pretty significant to actually recall all of your disks and then issue new ones. Aaron Dolberg Today, web and mobile apps are updated weekly and monthly. Large corporations even push fixes to their websites daily. (Could it really be possible that Amazon deploys every 11 seconds?) With continuous delivery, it’s important that QA happen continuously as well. Testing can occur on one feature while development is working on a different feature in the same sprint. Testers have also adapted to checking parts of a feature as they become available. QA teams don’t always have weeks to analyze requirements and create test cases in isolation. They have to think on their feet, rapidly developing new test plans as products evolve. Greater reliance on automation With so much attention now spent on new feature development (rather than creating a large product in one go), there’s a greater need for QA automation. Teams need to feel confident that while they are adding new functionality, no existing functionality is being put at risk, and in most teams, there isn’t enough time between releases for thorough manual regression testing. QA engineers now have a constant eye on what can be automated. During manual testing, they need to identify tests that can be integrated with existing automation so that regression testing can keep up. At the same time, companies can’t just rely on testing automation to identify all issues. Especially on mobile applications, there are many features, UX elements and swiping actions whose usage can’t be automated. So while testers need to expand their automation scripts, they also have to conduct manual testing on complex features that can be challenging to cover. QA now shapes product design QA teams haven’t always had a say in project requirements and how those requirements would be satisfied. Typically, they were handed down the project requirements and then they would begin creating tests to validate whether or not those requirements had been satisfied. Today, if QA engineers can’t give design input on products, it’s seen as a management problem, not a process problem. Agile development is partly based on the idea that everyone involved should be able to creatively shape (and re-shape) the finished product. With the growing focus on the customer experience, customer satisfaction has become the responsibility of every core business function. As a result, product development is now far more collaborative. Greater focus on communication over documentation Gone are the days of separation between business and IT, between development and QA, between QA and the customer. People over process is key. Too many pre-defined processes just get in the way. The evolution of QA is not WHAT has changed, but rather HOW it has changed. QA is still responsible for analyzing and validating requirements, developing and executing test cases, finding opportunities for automation, and assisting in the resolution of bugs. But everything is much more fluid. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. The Agile Manifesto Communication and interaction between teams as new changes and requirement arise are what demand improvement. With waterfall development, breaks in the process are solved with clearer documentation. Agile teams ask themselves, how can we improve communication? This holds true for co-located and dispersed teams. One of our top testers, Zuzana Cechivska, describes the difference in her own work experience: On the waterfall projects, as the testers we were just submitting tickets but we didn’t know which developers were responsible for fixing. We mostly communicated just through the tickets. The developer changed the ticket state to ‘fixed’ and if tester didn’t agree they wrote their comment and developer replied and so on. In agile, I knew exactly who from the developers was responsible for which feature. I could go directly to their desk to discuss. They used to call us as testers to their desks to show their solutions or they came to our desks so that we will show them what is not correct. Zuzana Cechivska Sprint planning, daily stand-ups, and sprint reviews are additional avenues where issues get fleshed out. QA takes an active part in any discussion of new tasks, unresolved problems, and where the product is headed. The temptation to leave testing to customers Agile development can be a double-edged sword for teams that practice it. Releasing imperfect products on purpose is widespread nowadays, with the heavy focus on speed to market. Cechivska, puts it this way: I started in June 2007. At that time there was a waterfall model—applications were developed more slowly and there was time for proper documentation of everything and testing was coming as the last stage and everything was quite precise I would say. At least at the projects I was working on the focus on quality was very high. Over time we moved to agile and apps are developed very fast and often goes to the users more buggy. What matters is the speed—how fast the app and new features can be released to the users. There is an approach that the users will report problems and they will be fixed on an ongoing basis while the app is already in use. Zuzana Cechivska This has been an ongoing concern since the early years of agile adoption. Quality consultant Elisabeth Hendrickson imagined a scenario in which programmers can take this trend a little too far (thus reminding us why agile doesn’t mean you can disband QA): “The Customers should be held accountable for creating the Acceptance Tests!” Elisabeth Hendrickson Clearly, testing is not the customers’ job. Working with QA professionals is better for developers, too, because they won’t have to worry about urgent hotfixes ruining their weekend plans. QA teams have had to develop lean and flexible processes for analyzing and validating requirements. Plus, they’re involved in more collaboration and communication channels outside of bug logging systems. The increased level of input and responsibility has made QA a more desirable career for people who would previously have only considered development. QA teams are now more adaptive, responsive and focused on the customer than ever before, making professional QA that much more valuable. Testlio is a fully managed QA solution for teams in need of top testing strategies and global talent. Get in touch with us.