4 Ways QA Can Supercharge Your Release Cycle Dayana Mayfield , Dayana is a QA engineer turned technology writer living in Milan, Italy. She's always down for a smoothie. May 23rd, 2017 Testing is often seen as the biggest hindrance to release. QA is known as the number one bottleneck. It’s the phase that’s always in the way. That’s not really fair, is it? First off, there may be organizational shifts that have yet to occur (ones that would reduce delays), things like breaking down silos, improving collaboration, clarifying requirements. Also, once a critical bug is found, isn’t that a development problem, rather than a QA problem? Luckily, the agile approach to software development not only combines project phases into short cycles, but it also helps alleviate the blame game by bringing people of different roles together. The fact is that QA has changed a lot recently. Testing early and often, running automated scripts, and other ways of optimizing the testing process are making it so that QA is (hopefully) no longer associated with the word “bottleneck.” It would seem now that analyzing the market, getting real customer validation and feedback, and creating project requirements is of a greater concern to speed. We shifted the bottleneck. It’s not tests anymore. Now it’s requirements and business analysis. Matt Heusser, Excelon Development Teams who work together finish together—meaning that there are definitely strategic ways to obliterate QA bottlenecks and get products ready for release on schedule. Here are some of the QA practices that contribute to product readiness and obliterate the idea that testing causes lag. Collaborate early on with user stories In a fully collaborative, test left approach, user stories are the first place that developers and QAs intersect. Typically written by product owners and based on documented project requirements, user stories are the initial basis for work done by testers and by developers. User stories are not intended to tell coders exactly how to code or to tell testers exactly what to test. Rather, they detail what the user will do with the small facet of an application currently being worked on. From there, user stories are used to write acceptance tests, which are clearer definitions of the tests that must be run in order to determine whether requirements have been met. Using these, developers can know functions are required and know what to code. A test-driven development approach is increasingly common in agile because it makes use of strategic automation, brings development and testing together, and ensures the maximum amount of code coverage, since code is written to pass the tests, rather than tests being written to pass (or fail) the code. Have software testers (not developers) do unit testing Unit testing allows for the testing of small, disconnected components of software. Units should be calling on one action, and never involve complex steps or multiple features. Because unit tests are written with scripting languages, they are typically done by developers and not testers. Continuing to leave unit testing to developers can actually cause delays because developers tend to view them as non-critical tasks. Developers may be more likely to move on to the next item to code rather than write a script that will test something they’ve just completed in isolation. But getting these tests done is a must for QA engineers, who need to verify the success of small components as early as possible, so that at the end of the cycle testing is being done end-to-end. That’s why one of the best practices a QA team can adopt is to learn to do their own unit testing. They’ll increase their skills by learning to code, ensure that they get the results they need to move forward, and free up development to work on other tasks. In addition, since the unit tests will written by someone other than those who wrote the code, the tests themselves are likely to be more critical and thus more effective. Testers learn the flow and function of the code and can use this knowledge in later test design. Anastasios Daskalopoulos Stay on top of changes One reason that QA can fall behind is because they are simply not always in the loop. It’s not uncommon for QA to be handed code that doesn’t meet requirements. Maybe requirements changed due to time constraints. Maybe there was a push back of one small piece of functionality, or it was decided that user feedback would be collected on the smallest iteration of a new feature before developing it more fully. If QA engineers feel like they’re routinely in the dark, then they probably also are routinely behind. Unexpected changes can cause adaptations to test plans and test scripts or can drag out the exploratory phase. Agile teams notoriously keep documentation processes lean, but any resulting gaps need to be filled somehow. Maybe it’s with better standups or daily check-ins with representatives from different teams. Fortunately, writing unit tests can help with communication barriers too because testers will know about changes as soon as possible, rather than be handed code that doesn’t match up to their test plans later down the line. Use the same tools as development Breaking down barriers between QA and development is essential for continuous testing and continuous delivery. Sometimes those barriers are procedural. Sometimes they’re a problem of project language or skillset differences. And sometimes those barriers are more tangible. Namely, tools. When QA and development work in separate environments, knowledge transfer is that much harder. Whether they work inside a platform that handles just about everything or using an integrated development system that integrates with just about everything, the point is that QA and development can work together. This can help streamline collaboration on: Bug fixes Test automation Cycle pivots Requirements changes Our Testlio developers have worked hard to build extensive integrations into our test management platform, so that even with a remote community of testers on board, there is no barrier to communication or collaboration. Involved testers are happy testers. Valued testers are happy testers. Testers who have contributed to the meeting of project goals and deadlines are happy testers. When QA teams are supported in the pursuit of practices that obliterate bottlenecks and increase velocity, then not only can businesses get to market faster, but they can also contribute to the skill growth of their employees. Speed doesn’t have to mean high-stress scrambling at the end. It’s something that’s achieved all cycle long. For testing that gets your product ready for release on schedule, get in touch with us for a demo.