Continuous QA
Discover the importance of continuous quality assurance coming from the Middle Ages up to our days in our article!
Since the Middle Ages, quality is an attribute society has always strived for. From architecture to technological innovations, quality assurance (QA) has been a top priority in all industries. It is no surprise then that organizations stepped up their game when it came to software development and created a more sophisticated approach to quality assurance. However, as with anything, nothing stays the same for long.
Development cycles were once much longer than they are today and QA was continuous as a result. However, development cycles have shortened dramatically, which has placed QA teams behind the eight ball. According to the World Quality Report states, more than 93 percent of development projects today use agile methodologies.
To combat shortened development cycles, organizations have tried to place QA teams closer to the development teams, preferring onshore or nearshore options to offshoring. This creates better communication between QA and development teams, and allows for quicker build times. Another thing that has become clear is that QA teams who fully understand the business model can build more meaningful test cases which cuts down on the total number of required test cases and increases coverage.
The end result is a highly-trained, highly-specialized QA team that can overcome an extremely large set of ever-growing hurdles. The issue, however, is that most QA solutions are not scalable.
Across the world, organizations are competing for the same pool of talented QA engineers. Moreover, they’re hoping these QA engineers can deliver results in a particular environment if and when they can be found. However, the cost of high quality QA engineers is substantial. Additionally, you’re limited even further with whom you can bring onboard if you already have an existing QA process with specific tools in place.
Applications are only becoming more complex as time goes on. New apps created today are more involved and require additional QA and testing than those made even a couple years ago. As apps age, QA teams need to deal with regression issues, which further increases QA workload.
Imagine this process, which probably already sounds all too familiar: The development team is ready to push a build out and they send it to QA for testing. The QA team edits a number of existing test cases to ensure they’ll run on the new version of the app -- a timely process with today’s test automation tools. After the test cases are successfully edited, one by one, they are being run on a local machine.
This is not a scalable process. Period.
The time it takes to edit a test case needs to be brought down and QA teams need the ability to execute hundreds of test cases in parallel. This alone will help take continuous integration processes down a number of hours.
Alongside all of this, online competition for local and global organizations has fiercely increased. Pressure is not only increasing for the QA team, but also for the executive level. With all the choices out there, if a user hits an error, they have an abundance of alternatives they can use at the click of a button.
Organizations today can’t afford a minimal amount of automated test coverage. It’s more important than ever that apps and sites function properly, every time, across an ever-growing number of devices. QA needs to be continuous and in order to get there, we have to fundamentally shift the way we’re approaching the problem.
