When we adopted Agile at MCA Solutions, management handed us what seemed like an impossible requirement:

Every feature had to be developed and tested in the same sprint.

At the time our sprints were three weeks long. Development alone could consume the entire sprint. QA often tested features weeks or even months later. The idea that testing would somehow happen alongside development felt detached from reality.

If we said yes, how would it work?

By then we had already survived several other “impossible” Agile prescriptions. Instead of arguing about why this one couldn’t work, we asked a different question:

If it had to work, what would have to change?

Cross-functional teams have one huge advantage: everyone is allowed to improve the entire process instead of defending their own territory.

The impossible part wasn’t testing.

The impossible part was that our QA engineers were spending their time clicking buttons instead of doing the work that actually required human judgment.

The most valuable artifacts

Instead of marking the ticket as done in JIRA and forgetting about it, we started working with QA directly on every task. QA shared the Word documents they had always used internally. As the developers got access to these test plans, the entire team realized that those documents were extremely valuable. In fact, they were the most valuable documents in the company. They were not just test cases. They were the specification. They described the happy path, every edge case, every business rule, and every assumption about how the system should behave. If you lost the source code but kept those documents, rebuilding the product would be possible. If you lost the documents but kept the code, understanding what the software was supposed to do would be much harder.

The transformation

Our sprints were transformed: We would write user stories, then the team would generate a preliminary test plan before we wrote a single line of code. We would then have a quick meeting where we would discuss the feature and have QA sign off on it. Having a separate org was important because dev and PM are biased towards shipping. We were able to streamline and eliminate a boatload of unnecessary work just by getting everyone on the same page about what we would be doing. Instead of coding up unneeded features developers made tools to speed up and automate testing.

Stop testing. Start building testing tools.

The product we were making did a lot of math. When the developers found out that QA used a spreadsheet to test the math, we built a testbed that accepted an Excel file as input. One tab contained input values and another contained formulas and results for the expected output.

Our test harness fed the input into the application through Selenium or direct database updates. It then compared the application’s output against the spreadsheet and generated another worksheet for the test run. Matching values were highlighted in green. Mismatches were red. Values that were close enough to be explained by floating-point math were yellow.

Understand your value

We had a company with a good team of seasoned professionals. But all of us including QA thought that their value was in the clicking and the checking, in being thorough and working late to make sure all the scenarios were done.

We all believed QA’s value was clicking through screens.

We were wrong.

Our Selenium tests coupled with db and app state snapshots could work through the application many times faster than the QA people. That was not their value. Their value was in defining what the software was supposed to do. They were creating a shared understanding of what would truly satisfy the requirements. By discussing the test plans we could make better choices and see the true scope of work.

Every profession accumulates work that can be automated.

The trick is figuring out whether that work is actually the reason you were hired.

For our QA team, clicking buttons wasn’t the job.

Creating a shared understanding of what “correct” meant was the job.

Once we realized that, developers automated the clicking and QA spent more time defining quality.

The software got better.

The developers moved faster.

QA became more valuable, not less.

If I started another software company tomorrow, my first hire would be a developer.

My second hire would be someone who thinks like a tester.

Software is built with code.

Great software is built with shared understanding.