agile test automation pyramid

Contributor(s): Matthew Haughn

The agile test automation pyramid is a graphical strategy guide for implementing automated software testing.

The model splits types of testing into three layers based on the return on investment (ROI) offered by automating that particular type. The components of each layer can vary from one organization to another but the bottom layer (the largest part of the pyramid structure) typically includes unit testing, representing the idea that automating it offers the best ROI to the organization. Unit tests involve testing small units of code. They are the least expensive to write and maintain, and they provide value to the team multiple times per day. Acceptance tests, in this particular model, provide the next greatest benefit and user interface testing the least.

In automated testing, software tools execute pre-scripted tests on a software application or program component to ensure it is functional. Automating testing makes it possible to run tests quickly and repeatedly and the software involved can also provide reports and compare results. Automation helps deal with problems resulting from manual testing, including missed deadlines, quality issues and human error. The order of testing can also impact its success and that of the agile development project as a whole.

The agile test automation pyramid was introduced by Mike Cohn in his book Succeeding with Agile. The image above represents Cohn’s version of the model.


This was last updated in September 2016

Continue Reading About agile test automation pyramid

Dig Deeper on Matching IT Resources to Application Requirements

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

In my experience, UI tests are only useful to verify new features deployed, not to verify correct functionality, especially in most fast paced agile teams.



I had a chance to work on a UAT environment on Loan IQ software which is in the Beta testing stage and would be releasing by Oct 2015, my experience with Agile methodology has been great, as a Beta tester the quality of UAT is a function of the script and how accurately the test scripts have been framed.

We do our best when working on applications to follow the Agile testing pyramid - on newer applications, we typically have excellent unit test coverage. On legacy applications, we do our best to build in better testability each time that we have the opportunity. 

Despite the fact that we have a mature team and great automated test coverage, I find myself doing more manual testing than I really ought to be. I nearly always find problems, sometimes pretty big ones. Oh well, I guess that's job security!

There's such concept: reification fallacy. Also called the fallacy of misplaced concreteness. It's a thinking error: taking something abstract, as an idea or model, as a concrete thing as if it exists in reality. But the map is not the territory.

There's no "Agile test automation pyramid". There are no "quadrants". Speaking of "using" these is kinda like speaking of "using Democracy". What has been your experience using Democracy in your country?

I realize I replied to this earlier, but the more I think about it.  The Less useful I find the quadrants.  They are only useful when trying to show all the distinct types of tests and their focus, they do very little to help you actually get the job done.
@Veretax, I think that diagram is very useful to show something cool and confusing.

Reminds of an old tale.

"Two weavers promised a king a new suit of clothes that is invisible to those who are unfit for their positions, stupid, or incompetent." Quote:'s_New_Clothes

I am reminded of the concepts behind Shu-Ha-Ri, which is prevalent in martial arts. Shu is the learning of forms, Ha is the refinement and experimentation within those forms, and Ri is the transcendence of forms altogether. So it is with the Agile testing quadrants and the pyramid. It's a form that we can become familiar with and hang ideas on. It's a checklist and a reminder, and it can teach us many avenues to help us test. As we progress, though, we tend to think and refer to it less and less, not because it is not important, but because we have internalized it and made it our own, or our organization's own.
On many past occurrences I could experience that we speak the same language with Michael Larsen, but certainly not this one :)

I'm familiar with the concept of Shu Ha Ri but my interpretation is different:
One can read and study academically about motion, intertia, balance, etc. - or one can just get on the bike and start learning riding it through practice. One doesn't need to know much theory or terminology to become a decent bike rider.

Shu Ha Ri is "learning by doing" in my interpretation.

Whilst those pyramids and quadrants are just cool-looking pictures that don't have anything that teaches to practice.
What has been your experience using Agile testing quadrants or the Agile test automation pyramid?
So how does the GUI testing work?