The Software Quality Assurance (SQA) is intended to ensure that the software conforms to quality standards defined and is a continuous process that accompanies the entire life cycle of the product.
The most relevant quality measures of the software can be grouped as follows:

Is that for which it was designed – Functional requirement
No unexpected behavior – Functional requirement

Performance – Non-functional requirement
Safety -Non-functional requirement

The QA is the one that processes the testing strategy for the Team and, consequently, for the company in which he works.

The capabilities required to QA are various, such as maintaining governance during test development, collaborate with other professionals, know how to communicate, able to move in changing scenarios that present increasingly different functionality.
Everything, always keeping a clear objective to ensure product quality.
We conclude that the QA is architect of the testing process.

The first step which underpins the entire testing process is the definition of the User Acceptance Criteria (UAC) that establish the proper operation and completion of the product.
More specifically, the UAC is a set of instructions, which specify the functional requirements and not of the product, by defining the concept of quality of the same. The UAC constitute our “Definition of Done” in respect of an Epic, Feature and Story.
The definition of UAC allows the Team to figure out when it’s done and not to forget important borderline issues.
The UAC are produced through collaboration between developers, testers, and product owner and are created before the development, during the planning phase.
UAC are expressed at high levels (conceptual, not detailed) and then in the form that works best for the Team (keep it minimal).

During Kick off, QA and developer, in a 10-15 minute session must explicate the User Acceptance Test (UAT) in order to define the behavior of the system and ensure the realization of the product as expected.
The QA and developers agree, also, the tests to implement, sometimes also including the product owner and the other stackeholder.
The implementation of the test takes place during development (ideally test-first).
It is considered appropriate to build a Map of User Acceptance Test automatic and/or manual in order to improve the testing and development process. They will be designed at the level of User Tests, Unit Tests, Integration Tests, Alpha/Beta Tests, Exploratory Tests, Performance Tests, Security Tests, and Static Tests.
So that QA does not become a bottle neck the quality should be the responsibility of the company and the Team.

Why “Test Tower” instead of “Test Pyramid”?
Because the pyramids are the XXVII century A.C.

ahahahah - no!






The test pyramid is a concept developed by Mike Cohn, described in His Book “Succeeding with Agile”.
The pyramids of testing allow you to see which test levels to be performed and highlight the amount of tests for each type.
Over the years we have been developed various types of testing pyramids, but now we wonder if we still need to see the testing through a pyramid.

As well as products developed by companies that are revolutionizing the behaviors and habits of people (social networks, search engines, online reservations, online shopper, car-bike sharing, online services) go towards quality and focus on it to differ from continuous rising competitors, even the testing has to go in that direction. One must speak of towers, towers where testing are not important quantities for each level but the quality of each test for each level!

Instead of displaying the levels and types of tests through the pyramids I prefer to take inspiration from the palaces and towers (Unicredit Tower), populating the city where I live for a while, Milan.

Test Tower










As mentioned in the first part of this article, it is essential to clearly define the User Acceptance Criteria for PO, UX, Team Manager, and convert them to User Acceptance Tests.
Is essential, also, do the following:

  • Define a set of User Tests with the UX department, before and after the development of the Feature.
  • Create Unit Tests and Integration Tests, backend and frontend and from backend to frontend (EndToEnd Tests).
  • Create user groups who want to try out the product with Feature realized, internally and/or externally of the company.
  • Minimize Exploratory Tests but remember that the software is full of surprises. No matter how careful or skilled you are, when you create software it can behave differently than you intended. Exploratory testing mitigates those risks.

Remember that Performance, Security and Static Tests will highlight other critical aspects of the produced Feature, up to rethink it completely.
Finally, the CI (Continuous Integration) allow control of the Feature to every Build.

Finally, although it is important to define the amount of tests to be performed for each test level (Test Pyramid), the quality of each single test for each level of testing and careful planning of the testing process and strategy will lead to Products high quality (Test Tower).


Giuseppe Cilia, Quality Assurance Engineer at Wind Digital S.P.A., Milan.