A Sober Look at QA

At the center of every software development shop is the infamous QA team, often viewed as a bottleneck to rapid releases. Done perfectly, QA goes unnoticed, a thankless job that allows teams to make frequent releases through delicate, complex systems.

What can possibly go wrong?

  • As demands on IT grow and the application throughput becomes more complex, QA is forced to keep up, giving them less time to identify and fix any given defect, and risk poor quality releases.
  • As IT becomes more complex, it becomes increasingly difficult to know everything that’s going on.
  • The business has placed IT in the dual roles of maintenance and innovation, reliable infrastructure and agile development.
  • Without an end-to-end view of process, costs, and key risks QA teams face, implementing quality controls becomes a shot in the dark.

Most enterprises weren’t created yesterday. There is no blank slate, greenfield advantage that new cloud-native start-ups enjoys. The enterprise is crowded with a hodgepodge of applications from different eras, each with different architectures and moving at different paces. To support these applications they have different approaches to testing them, often using an inconsistent set of tools and processes.

And when the enterprise adopts an automation framework they soon find that maintaining existing automation is harder and more error prone than manual testing. This leads to poor quality, low coverage, and a heavy amount of rework time. For the enterprise to become the responsive, agile resource that the business will perpetually demand, they must leverage automation to fully support development and maintenance needs.

So how can automation be implemented to amplify a tester’s ability, speed up testing, and expand QA’s coverage?

First off, the process must be streamlined and scalable. After companies learn to monitor quality end to end, they can use this extensive view as a blueprint for automation. Once streamlined and centralized, the enterprise must identify areas that are repetitive in order to make QA a point of leverage for IT. Automating processes like scripting and data generation allow testers to improve coverage, rapidly detect problems that development missed, and ensure quality for business stakeholders, rather than firefight against production defects.

However, implementing generic automation to these processes creates two risks: maintaining automation can take more time than the original process, and it won’t be able to cope with an extraordinarily dynamic IT landscape.

Here’s where Autonomous Testing comes to the rescue.

Selenium Scripting is the leading scripting language to automate functional testing, but the entire process is manual, slow, and difficult to maintain.

Most companies use Selenium scripting as follows:

  • Sprint team decides on user stories for each sprint.
  • Developers code user stories.
  • SDETs begin scripting to test code and spend 3-4 hours writing a single Selenium Script.
  • SDETs execute tests on what they scripted until they hit a bug.
  • Developers fix bug and SDETs rewrite and retest scripts.
  • Team manually tests what their scripts couldn’t reach before the end of the sprint.
  • New code is released.



The process starts again, but they must spend an hour or two maintaining every script they wrote for just a small change in the application being tested, compounding effort release after release and remaining a drag on development.

This is a big enough problem that several new companies have emerged dedicated to this one problem. They try to solve this problem by recording manual tests and replaying the recorded scripts (just like the old Excel Macros).

This approach does not allow them to capture all the dependencies applications have, nor does it allow them to maintain the scripts if the application changes.

By leveraging autonomous testing, teams can automatically generate scripts based on a deep understanding of the applications under test and the requirements development teams provide to test. This way, companies can keep up with the dynamic changes to their applications, not remain locked into a manual process, and not have to worry about maintaining work from previous development efforts. Now they can focus on net new innovation, knowing quality is one click away.