Have a question?
Message sent Close

News & Events

SAFe & Agile Leadership Training

Category: Agile Leadership

Does Your Test Automation Arrive Too Late?

Date of Release: January 29th, 2022
Reading Time: 02 mins

Leslie

Written by Leslie Brooks
linkedinicon

Traditional test automation arrives one release behind the new features – after the manual QA team has spent at least two weeks testing the new features, and long after the developers have moved on to other things.

This is too late to deliver real value; at a minimum the automation should be available as soon as the code is delivered to QA; ideally the automation should be delivered to the developers in-sprint. If it is delivered at the same time as the code, the manual QA team has a lot less work to do; if it is delivered in-sprint, the developers can run all of the tests before their changes are even merged into the Release branch.

Real World Examples

At General Motors I came in to help a test automation team that was doing things the traditional way – automating the manual test cases using Java and Selenium and delivering the automation one release behind the developers. A year later they became the first QA team in all of GM IT to deliver automated tests to the developers while they were still writing the code. For another website they went from delivering one release behind to delivering two or three days after the code was put into an integrated environment – and they went from using eight automation engineers to maintain and update the code, to one-half of an automation engineer, plus one manual QA person to run the tests.

At United Technologies I worked with a team of developers writing data science applications in Python; a year later they had transitioned from 100% manual testing to almost all automation, and were delivering the automated tests in-sprint. Because the developers were able to run fully automated regression tests plus fully automated tests for the new functionality before they opened a pull request, they quit delivering bugs. Code reviews were no longer about finding bugs; they were about ensuring that the code was clean, well designed, and easily maintained. That team went on to deliver just two bugs into Production over the next year!

How is this possible?

It requires a fundamental paradigm shift, from traditional narrative requirements to Specification by Example/BDD, and it requires a full-team effort:

  • The Product Owner and Business Analysts must learn how to write requirements that are more detailed and more explicit than traditional narrative requirements – Specification by Example says that all requirements must include concrete examples.
  • The Developers must learn how to collaborate with the Product Owners and BAs, to write the requirements together.
  • The QAs must learn how to help write the requirements, and how to automate early and reliably. This means that test automation code must be first-class code, not second-class code. At United Technologies the Developers reviewed every pull request opened by the QA team and used the same review standards as for production application code.

I can teach your teams how to do this; contact us and let’s schedule some time to talk.

Trending Posts

Creating a Culture of Accountability within Your Agile Team

Accountability serves as the vital link connecting tasks to objectives and aligning individuals across an organization.
Last updated on 13th July 2023

 

The QA Team Should NEVER Find a Bug!

Many companies use metrics to measure the performance of the Sales Team, the Developers, the QA Team, etc.
Last updated on 14th May 2023

 

Do You Want to Save $50,000 per Developer per Year?

A number of case studies have shown that a typical developer spends 30% to 40% of their time fixing bugs.
Last updated on 11th October 2021

 

Follow Us

Creating a Culture of Accountability within your Agile Team
July 13th, 2023
Writer: Stephen Otterstrom

Creating a Culture of Accountability within your Agile Team

Accountability serves as the vital link connecting tasks to objectives and aligning individuals across an organization.

Agile Leadership
October 11th, 2021
Writer: Leslie Brooks

Pytest-BDD vs. Behave

Love it or loath it, Python is the language of choice for most Data Scientists – so if the work is done in Python and you are writing the requirements in Gherkin, what tool should you use to automate testing?

Data Science
November 8th, 2021
Writer: Leslie Brooks

SBE BDD for Data Science

Data Science and Big Data are hot topics, and rightly so – companies can save huge sums, or dramatically increase sales, by analyzing the data that they already collect. Specification by Example is a great partner in this effort.

Be a part of SevenSparx community to enjoy free resources in your inbox!

Right Menu IconAll Courses