测试金字塔及三种反模式

You have been in the software industry for a while, and you go – one more blog about Test Pyramid. Isn’t their million blogs already about Test Pyramid and anti-pattern to that pyramid. You might be wondering why is she writing about something that has already been written million times.

As a consultant, you see the world that most people think does not exist. Some of the clients I dealt with are the one who never had QA as a function ever and yes they built software products. Some caught in the never-ending loop of an end to end UI testing and don’t know how to get out of it. My responsibility falls in between building up QA/BA team to help the client get out of the never-ending end to end UI test loop and implement test under the UI. In the last couple of years, I have used Test Pyramid’s and the anti-pattern to it, again and again, to make my case and explain the architecture My team and I proposed. Though the internet is full of Test Pyramid’s related article, I have not come across one that defines the Test Pyramid as well their anti-patterns in one Blog. I had to document it for my clients, and then a co-worker recommended just to put it out there.

测试金字塔

The ever famous Test Pyramid is a concept developed by Mike Cohn and described in his book Succeeding with Agile. The pyramid answers the question of when and where to test. Because of the existing system in many software teams – Test Pyramid has its challenges to implementing, but it works very well when the software development team is building up its QA function or moving into new Tech Stack. Unit Testing and UI testing here is self-explanatory. It is the term service testing that confuses. It means any middle layer of your application API, Micro-services, Database, etc.

It is essential to understand what is not the right way to test to understand what is the right way to test. I have been surprised many times as how many experienced developers and other software professionals have not heard about these anti-patterns. Another reason I wanted to blog them all in one place.

The three anti-patterns of software development are ice-cream cone, cupcake, and hourglass.

蛋筒冰淇淋反模式 （Ice Cream Cone Anti-pattern）

Alister Scott first introduced ice-cream cone on his blog. We find this pattern in classic “I will do all my testing in UI” development team. This pattern is dangerous because testing in UI is expensive and exceptionally slow. If you cannot continuously test, you cannot continuously deploy and if you cannot continuously deploy your product will always be late to the market. Does that make Ice cream cone sound bad enough? There is a lot that I want to say about ice-cream pattern, but that is for another blog.

纸杯蛋糕反模式 （Cupcake Anti-Pattern）

ThoughtWorks blog introduced the cupcake pattern. There are different teams writing tests, and they sit on different floors or different locations. Developers are writing unit, integration and component tests whereas there is an automation engineer who is converting manual regression tests to automated tests. There is also a team who executes test manually. All the teams are repeating tests. Though more tests never hurt it is inefficient. The team won’t be able to focus on more complex test issues because everyone always has so much to do.

沙漏反模式（Hourglass Anti-Pattern）

Hourglass pattern was first introduced to us here. This pattern is where you have a kick-ass development team who is writing unit tests and then there is a QA team which is writing UI tests. No one writes service/middle layer tests. Though this anti-pattern is much better than ice cream cone, still Test Pyramid is where you want to be.

In which anti-pattern is your team stuck in and what you are doing to move towards Test Pyramid.

原文作者：KHUSHI

原文链接：Fixing a Test Hourglass

发表时间：FEBRUARY 7, 2019