Testing Skyscraper Pattern Explained

Hari Mahesh

Today, testing approaches need to change as rapidly as the systems they serve. The Testing Pyramid has shaped how teams model their thoughts about automated test design for years. It’s the pyramid model with lots of unit tests at the bottom, fewer integration tests in the middle, and even fewer end-to-end (or UI) tests at the top. This became an accepted mental model for what a well-balanced test coverage pyramid should look like.

But modern engineering practices, distributed architectures, and AI-powered interfaces have transformed the way applications work and the way we interact with them. The old pyramid is outdated and no longer accurately represents modern systems. New thinking is now emerging that suggests testing should grow tall, like a skyscraper, but be flexible enough to include layered complexities, connected services, and wider-reaching user journeys.

This new metaphor underscores the need for test strategies that can grow over many layers of validation and accommodate everything in the height and depth of modern software, from ground-level logic to dynamic user experience.

Why the Pyramid Fits the Past

The Testing Pyramid was a reaction to a time when web apps were simpler, testing UI was fragile and slow, and automated test infrastructure was basic. In such a context:

• Unit tests were small, isolated, and fast, and worked well for confirming the correctness right next to the code base.
• Integration or API tests provided only a narrow view of how components interacted with each other.
• UI or end-to-end were slow and fragile with flaky browser behavior, unreliable drivers, and timing issues, so expensive to maintain.

So the pyramid shape with a broad base (lots of unit tests), thinner middle (fewer integration/API tests), and smallest peak (only key UI/E2E tests) felt right. The vast majority of quality could be delivered through fast and reliable unit tests, with cross-component things being chased down in integration tests, while a small subset of critical user flows would be covered by UI tests.

Read: How to Customize the Testing Pyramid: The Complete Guide.

Benefits and Strengths of the Pyramid Model

The test automation pyramid gained popularity because it provided an organized and relatively cost-effective way to account for different types of tests. By focusing on cheap, fast, and stable lower-level tests, it enabled teams to keep reliability high without racking up maintenance costs. Its successes were the basis of modern testing strategies.

• Speed and Feedback: Unit tests provide fast feedback, often within milliseconds, allowing quick iteration and the discovery of significant bugs early.
• Maintainability & Cost: It’s easier to write, maintain, and debug low-level tests. UI/E2E tests are costly in terms of time and dependencies, and can be brittle.
• Scalability: Large tests can be easily constructed in a cost-effective manner using unit and integration tests. The cost and slowness of many UI tests are often skipped.
• Predictability: Test execution time stays manageable, and it’s easier to maintain stable CI/CD pipelines.

Because of these advantages, the Testing Pyramid became deeply embedded in how many teams plan and reason about their test automation strategy.

Time to Rethink the Pyramid

A lot of the context behind what influenced and made sense around the testing pyramid has changed. Development practices, tooling, and automation capabilities have changed since then, and it’s time to rethink whether the conventional model even fits modern teams. Here are some major changes:

Improved Tools & Infrastructure

The modern UI-testing toolchains are noticeably more stable, faster (yes, they are fast), and reliable than the old ones. Many of the problems that scrambled previous legacy automation efforts have been largely mitigated or solved. The constant progress of testing infrastructure has made UI automation more reliable, resulting in less maintenance and better trust in test results. Tools like testRigor reduce test flakiness by interacting with the UI the same way a human would through visible elements and natural language, that is why testRigor is a human emulator.

Read: What are Flaky Tests in Software Testing? Causes, Impacts, and Solutions.

Alternative Testing Approaches

Teams are using various levels of testing, such as the unit level for core logic and contract tests to verify service interactions, with less overlap. E2E tests are also written judiciously to ensure that the system as a whole is functioning properly and not to overduplicate at every level in your stack.

Continuous Testing & Fast Feedback

Today’s development scenarios require instant feedback. Any delay in a test cycle becomes redundant and archaic. The teams hence get fast running tests on every commit and keep full end-to-end runs to selected moments, so that they can stay speedy and confident in the development cycle.

Thus, the development and testing landscape has changed dramatically. As a result, the assumptions underlying the Testing Pyramid no longer always hold. Because of these shifts, clinging rigidly to the Pyramid structure, especially its implied quotas, can become limiting, inefficient, or even harmful in modern contexts. This is where the Testing Skyscraper pattern comes into play.

Read: The Ice Cream Cone Testing Approach: Benefits & Pitfalls.

Introducing the Testing Skyscraper Pattern

The Testing Skyscraper is a contemporary metaphor and concept that has re-envisioned the conventional Testing Pyramid. Rather than being forced through a series of rigid, narrowing arches, it takes your test suite for the easily expanding building that it is and treats each “floor” as a level of testing you decide to have based on what your application needs; (in other words) how many tests work there or if the floor even exists.

Key Aspects of the Skyscraper Metaphor

• Each “Floor” (Test Level) Can be Customized: Every layer of the Skyscraper can be tailored to fit the specific needs of a project. There is no expectation to follow fixed proportions across different applications.
• You Can Have Zero-to-many Tests at Any Level: Here, the number of tests per floor depends entirely on business goals, system complexity, and risks you want to mitigate. This allows teams to delegate the tests where they provide the most value.
• You Can Skip Levels When Appropriate: Certain floors may be empty based on whether the test types are not required for a certain release or workflow. Skipping levels starts to become an optimal choice rather than a strategic error.
• The Model Emphasizes Business Needs and Flexibility: It promotes teams to concentrate on providing value and mitigating risks rather than reaching an arbitrary test ratio. This pragmatic attitude helps to promote that the testing strategy is in line with real-world values.

AI-powered tools such as testRigor support the Skyscraper approach by allowing teams to quickly build or expand upper floors, especially E2E and cross-platform tests, without the traditional maintenance burden. This enables teams to create only the floors they need, scaling testing layers on demand. Read: Cross-browser Testing: Strategies, Tools, and Common Issues.

Comparing Skyscraper and Testing Pyramid

Modern software teams often struggle to choose the right testing strategy as systems become more complex and tools evolve rapidly. The traditional Testing Pyramid has guided teams for years, but the newer Testing Skyscraper model offers a more flexible, risk-driven alternative. Key differences between the two approaches to help teams understand when each model is most effective.

Skyscraper Approach: Benefits & Strengths

The Testing Skyscraper is a bit more flexible, context mindful, and may be more suitable for modern architectures or teams. Instead of enforcing strict ratios, it enables organizations to develop the test architecture that best suits their risks and priorities, as well as the pace of delivery. This flexibility results in better alignment with real business needs from testing efforts.

• Flexibility & Context-Driven Testing: Teams can define a testing mix that matches the application’s current needs, with any combination of unit, integration, UI or E2E, performance or exploratory tests. It’s not every level that needs settings; you only need to focus on the ones that add value. As the product changes, so too can the test structure grow (or shrink) floors as risks and needs change. Read: AI Context Explained: Why Context Matters in Artificial Intelligence.
• Better Use of Modern Tools & Infrastructure: With improvements made around testing infrastructure, UI, and end-to-end tests are now faster, more reliable, and much easier to maintain. The various layers, like component, integration, contract, and API tests, can be mixed together strategically to enhance reliability without redundancy. With modern CI/CD pipelines, you can also run mixed test suites with fast and continuous feedback.
• Risk-Based Test Planning & Efficiency: The Skyscraper technique follows the principle of testing where risk is greatest, so that teams can concentrate their efforts on the most important areas. It reduces both wasteful over-testing and harmful under-testing by eliminating fixed numerical targets. Testing resources are allocated in the areas where they deliver the most valuable business impact. Read: Risk-based Testing: A Strategic Approach to QA.
• Adaptability for Modern Architectures: For distributed or microservices systems, Skyscraper is also flexible enough to easily add more integration and/or contract test floors if necessary. For UI-heavy or mobile-focused products, teams can deliberately write more upper-level tests without the guilt of violating a pyramid “rule.” This flexibility underpins rapid iteration, continuous delivery, and the fluid nature of contemporary software operating environments.

Potential Challenges of the Skyscraper Approach

No model is ideal, and although the Testing Skyscraper enables more flexibility, it also brings new hurdles that need to be addressed in a sensible way. It takes deliberate planning, ongoing assessment, and discipline to succeed with this approach. Knowing about these caveats will help avoid misuse of the model and use it effectively.

• Risk of Inconsistent or Unbalanced Test Suites: In the absence of guidance, teams can over-index on specific test types at the expense of others, resulting in brittle or bloated suites. Skipping levels too much can lead to blind spots in coverage that you might not immediately notice until things catch on fire.
• Complexity of Planning & Maintenance: Building your own multi-level test architecture has to be planned strategically, rather than being copied. The larger the suite gets, the more dependencies and varying complexities on various levels of the stack increase maintenance overhead.
• Risk of Misuse or Misjudgment of Business Needs: Matching test level to business significance can be challenging, and incorrect assessment of risks could lead to inadequate coverage. Unless early bets turn out to be wrong and dates shift, vacancies may linger longer than people hoped, making subsequent fixes expensive.
• Cultural and Process Change Required: Teams that are used to a fixed model may be reluctant to shift toward greater flexibility and evolution. This will take leadership and regular review, with the buy-in from stakeholders to prioritize risk above arbitrary test numbers.

Skyscraper in Comparison with Other Models

It’s useful to see the Testing Skyscraper in perspective, next to other popular testing models or metaphors that have been suggested or implemented in software engineering.

Exploring these paradigms and contrasting them can help shed light on where the Skyscraper model fits into current generation testing philosophies, and why it appears to be so popular. It also accentuates the flexibility we provide, especially for teams working with multiple architectures and changing product requirements.

How to Adopt the Testing Skyscraper

Moving from a pyramid-style team building formula to that of a skyscraper model will take careful planning and concerted effort across the entire organization. The trick is to come up with a testing process that mirrors real business priorities and system complexity, and the feedback required by developers. These practices help to ensure that the model is adopted successfully and scales with the product.

Evaluate Current Testing Landscape and Business Needs

Start by charting your current tests, the degree to which they are stable, and how expensive it is to maintain them. Figure out what parts of the system are the most important or risky, and where you need fast feedback in order to flow through development. This is the evaluation to use when determining your skyscraper’s construction.

Define Floors in Your Skyscraper

Select the test levels you’d like to cover based on your system requirements, whether it’s the whole range from unit, contract, integration, UI/E2E testing or performance and security testing. Each level should have a descriptive purpose that supports the system and business objectives. Work on your floors one piece at a time instead of trying to do the whole floor at once.

Prioritize Based on Risk, Value, and Feedback Needs

Prioritize higher-risk or business impact areas, and see that their critical flows get more coverage. Even lower-risk or stable regions might not need as many tests, preventing wasted effort. I think we need to revisit priorities often as the code & tooling changes, as well as features. It may change which floors require more investment.

Use Modern Tooling and Automation Infrastructure

Utilize next-generation automation tools and testing frameworks to ensure resilient and maintainable suites at all levels. Automate test orchestration to ensure that the right tests run at the right times across your development pipeline. Keep track of the health of your suite and clean up flaky, duplicate or no longer needed tests.

Choosing tools that minimize test brittleness is essential. testRigor allows teams to automate complex end-to-end scenarios, including web, mobile, desktop, and API workflows, without dealing with selectors or infrastructure complexity. This makes it easier to maintain a healthy Skyscraper over time. Read: How to do mobile testing using testRigor?

Document, Communicate & Embed in Team Culture

Clearly document your test floors, their purpose, and the reasoning behind your decisions so the whole team understands the architecture. Communicate how this model supports risk mitigation and continuous improvement. Treat the skyscraper as a living structure, adjusting it over time and reinforcing its principles across the team.

Skyscraper: When it Fits vs. When it Doesn’t

Understanding when the Testing Skyscraper is appropriate helps teams apply it effectively without unnecessary complexity. A clear distinction between suitable and unsuitable scenarios ensures the model delivers value rather than overhead.

Conclusion

The shift from the Testing Pyramid to the Testing Skyscraper demonstrates how modern software demands more flexible, context-aware, and risk-driven testing strategies. By designing testing layers based on real architectural needs rather than rigid ratios, teams can build more resilient, scalable, and business-aligned quality practices. When applied thoughtfully, the Skyscraper model empowers organizations to evolve their testing approach alongside the rapidly changing nature of software itself.

“We spent so much time on maintenance when using Selenium, and we spend nearly zero time with maintenance using testRigor.”

Keith Powe VP Of Engineering - IDT