Definition

agile test automation pyramid

This definition is part of our Essential Guide: What you need to know about software testing automation
Contributor(s): Matthew Haughn

agile test automation pyramid

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

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

10 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

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.


Cancel

Hi

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.

Cancel
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!
Cancel

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?

Cancel
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.
Cancel
@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: https://en.wikipedia.org/wiki/The_Emperor's_New_Clothes


Cancel
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.
Cancel
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.
Cancel
What has been your experience using Agile testing quadrants or the Agile test automation pyramid?
Cancel
So how does the GUI testing work? 
Cancel

-ADS BY GOOGLE

File Extensions and File Formats

Powered by:

SearchDataCenter

SearchAWS

SearchServerVirtualization

SearchCloudApplications

SearchCloudComputing

DevOpsAgenda

Close