Agile development allows a team to incrementally and continuously deliver value to their client. In order for this happen, the team needs quick testing feedback as changes are merged. The old strategy of getting QA involved for some manual testing after the coding is complete just does not work in an agile environment.

We sometimes see a QA team that is primarily focused on manual testing, with little to no automation. As more changes start coming through, thorough manual testing typically results in the dreaded "QA bottleneck". On projects like this, thoroughly testing the application with each change is impossible to do quickly, so we do a handful of tests and hope for the best.

As bugs start slipping through to production, confidence in the application fades and there is plenty of fear related to each deployment.

It turns out that automated testing is a critical part of agile delivery. So where do we start?

Talk testing immediately

If QA is not included in your story discovery and grooming, you are missing a great opportunity to increase quality and throughput. The 3 amigos process is a collaborative discussion with representatives from the business, development, and QA. The unique perspective of these 3 groups can help clearly define the work to be completed, and ensure requirements are clear and testable.

It’s also important to have early conversation about what automated tests are required for the new feature. Every user story does not require an end-to-end test. We want appropriate automated testing and we want to test at the lowest possible level of the test pyramid. That means minimize the use of slow, brittle UI tests in favor of fast unit, integration, and API tests. Dev and QA needs to work together create a test strategy for the new feature.

Work is not done until testing is done

On many teams, QA starts ramping up once the coding is complete. This behavior can result in a lot of back and forth between Dev and QA, as well as lots of finger-pointing.

The solution to this is to do development and testing in parallel. Pairing between Dev and QA as the code is being written can ensure the code is testable, the automated tests are built and green, and any surprises related to exploratory testing or scope creep are addressed early. Merging code should require all of the appropriate automated tests.

Once automated (and exploratory) testing is complete, it's time to merge the code to the code repository. After a code review, the code is merged.

Include automated tests in the CI pipeline

Once the code is merged, the build pipeline should build the app, run unit and integration tests, deploy to a test environment, and then run the necessary API and E2E tests. A failed test equates to a failed build, which means immediate feedback. Check out by my post Stop Creating a Git Repo for Automated Tests for my thoughts on the code repo for automated tests.

We now have the required automated tests included with all code changes, and these tests are run when the code is merged. This process is helping to limit defects in our code base and providing immediate feedback, which allows us to move more quickly!

Break down the walls!

I've talked about Dev and QA a lot in this post, and it made my eye twitch a bit every time I did it. Hopefully the days of a "Dev" and "QA" team are numbered. Ideally there is one team; the project team. Some team members may specialize in particular areas, but they all work together with the goal of delivering quality code more quickly.