Back to List

“O Testing Tree, O Testing Tree” - A Comprehensive Look at QA Testing for the Holidays

Tim Morrow Tim Morrow  |  
Dec 21, 2018
“O Testing Tree…O Testing Tree…how lovely are your branches!” Yes, for a Quality Analyst (QA) tester, the tree pictured below is a thing of beauty! It represents a comprehensive plan for testing an application and a roadmap for delivering high-quality products free of defects that delight our customers.

The Testing Tree picture below provides answers to three fundamental questions:
  1. How often should you test?
  2. What should you test?
  3. Who should perform testing?
Let’s take a closer look at each section of the tree together…

Unit Tests

These small, simple and fast coded tests written by developers form the foundation of all testing. These tests should be automated and run daily or hourly as new functionality is being developed. Their small size allows you to specifically identify where functionality may be broken. And when a multitude of these tests are strung together, they form a great barrier against bugs getting through into your application. The concept of Continuous Integration is a fundamental pillar of a DevOps world built primarily on the concept of test automation.

Integration Tests

Integration tests are designed to test the boundaries/connections of your application. These tests are more complex and will depend on the structure of your application. For more modern applications, these tests are very useful for API testing. These tests typically take longer in nature to run and are usually done nightly. The testing effort is usually handled by a combination of Devs + QA/Tester resources.

Acceptance Tests

Acceptance tests are manual tests conducted by the Business Analyst (BA) / Project Manager (PM) / QA based on the Acceptance Criteria surrounding the functionality being released. Acceptance tests are conditions that a software product must satisfy to be accepted by a user, customer, or stakeholder. Acceptance tests should center around Functional Criteria, Non-Functional Criteria (e.g. design elements) and Performance Criteria (e.g. speed/response time). These tests are very manual and thus costly to create and execute. 
A commonly used format of Acceptance tests is the “Given-When-Then” formula:
  • (Given) some context
  • (When) some action is carried out
  • (Then) a particular set of observable consequences should obtain
For example:
  • Given my bank account has a positive balance, and I made no withdrawals recently,
  • When I attempt to withdraw an amount less than my balance and account withdrawal limit,
  • Then the withdrawal should complete without errors or warnings

UI Tests

UI Tests are those tests which explore validation or other logic contained in the user interface, as in a web page, for example. These tests can be run manually or automated. Ideally, you would use manual UI tests during the early stages of development on a UI, and shift over to more automated testing as the UI becomes more stable. Automated tests can be difficult to maintain, so it’s important to employ these near the end of an application’s development.
During the creation of automated UI tests, a tester records a series of action recordings that can be reused and run at frequent intervals in the future when new functionality is released. The benefits of Automated UI tests are:
  1. Speed Time to Feedback
  2. Find Regression Errors
  3. Save Tester Effort and Time
  4. Validate Your Business Logic
  5. Improve Automated Deployments

For higher level testing of the UI, which may change much more often, manual exploratory testing is a better use of resources.

Exploratory Tests

Exploratory testing is ad-hoc testing carried out by development teams, including developers, testers, UX teams, product owners, BAs, QAs, and more, by exploring the software systems without using test plans or test suitesThese tests rely on a tester's intelligence and creativity to validate quality, usability, performance, and experience. They assume the tester has a general knowledge of the system and how a user would typically use the system. The goal is to break the software and/or identify anomalies in certain user-patterned scenarios. These tests are always manual and very expensive to run.


The testing tree provides us with a fun way to visualize all the elements needed in a comprehensive QA testing strategy. This strategy is vital to ensure the delivery and maintenance of quality products that delight and excite our customers. This holiday season, let's all make sure that our testing tree does not have any “bare spots”, and remember to water it regularly so that all of the products we create can shine bright this holiday season!
From all the team at Skyline Technologies, we wish you and yours a Happy Holiday season filled with laughter and joy.

*Special thanks to Microsoft’s DevOps Testing Class for introducing me to the concept of the Testing Tree and its associated concepts.


Love our Blogs?

Sign up to get notified of new Skyline posts.


Related Content

Blog Article
Focusing On Projects Rather Than Products (Agile Transformation Pain Point #17)
Rachael WilterdinkRachael Wilterdink  |  
Jan 10, 2019
This is a difficult transition for waterfall companies to wrap their heads around. It's a big mindset shift that needs to happen to be truly successful. I'm not saying that you can't have an agile Scrum team that works on projects with a distinct beginning and end. That might be a...
Blog Article
Skipping Over Quality (Agile Transformation Pain Point #16)
Rachael WilterdinkRachael Wilterdink  |  
Jan 03, 2019
You should not skip over quality because it’s inherently meant to be baked into agile. There are many ways you can do that. You could consider doing acceptance test-driven development, behavior-driven development, or you can write automated tests wherever possible. Again, I really like the...
Blog Article
Misusing Scrum Ceremonies (Agile Transformation Pain Point #15)
Rachael WilterdinkRachael Wilterdink  |  
Dec 20, 2018
Avoid having runaway meetings, meetings that go past their time boxes, and meetings that are not for their original purpose. Keep it focused. Create and follow an agenda for the more formal Scrum events –depending on your company and culture. I’ve worked at loose organizations and...
Blog Article
Pre-assigning Work to Team Members (Agile Transformation Pain Point #14)
Rachael WilterdinkRachael Wilterdink  |  
Dec 13, 2018
This pain point is something you definitely don’t want to do. Agile and Scrum teams are meant to be self-organizing. They should volunteer to pick up assignments, not be assigned. Development team members are volunteering to do stories, and they might want to learn something new &ndash...
Blog Article
Taking on Too Much Work in a Sprint (Agile Transformation Pain Point #13)
Rachael WilterdinkRachael Wilterdink  |  
Dec 06, 2018
Some teams are super ambitious, and they just think they can climb a whole mountain in a single Sprint, but the whole goal with agile is to maintain a sustainable pace. Take on only what you really think you can get done within your Sprint. Don't overestimate your velocity, and don't...