Pinscher Testing

“How can I best get up the mountain?” – Just climb upwards, and don’t think about it! Friedrich Nietzsche

Category: agile

Pinscher Testing is on Tea-time with Testers

Tea-time with Testers, is the largest-circulated software testing monthly in the world. As the wave of change sweeps business, testing field and community of testers like never before, Tea-time with Testers has ensured that its readers have all the necessary upgrades to challenge tomorrow. It takes its readers deeper to give a complete understanding of the world of software testing.

Ever since its inception in 2011, it has set one benchmark after another in testing publication circle. It was the first to do serious reporting on software testing theories and thoughts. And then again, it is the first to bring a whole new genre of technical/corporate journalism more upclose and more incisive. It is the only monthly magazine in global testing community known for quality of its content, authors and unique way of presenting the information.Today, Tea-time with Testers commands the highest circulation and readership among all English language testing magazines in the world.

Tea-time with Testers Site
 

You can click on cover to download the PDF with my article, The Test Tower by Giuseppe Cilia.

PDF of last edition with my article

Happy testing with Tea-time with Testers, thank you very much!:)
 

The Test Tower

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.

Acceptance Criteria and Acceptance Test

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

During the Kick off QA and developer in a session of 10-15 minutes should achieve the Acceptance Test (AT) in order to define the behavior of the system and ensure the realization of the product as expected.
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 Acceptance Test automatic and / or manual to improve the process of testing and development. They will be designed at the level of Unit Testing, Integration Testing, End to End Test, UI Test and Boundary Test.
A basic rule during the writing test, especially when we talk about Unit Test, often difficult to understand, is to assign a meaningful name so that the QA and the developer can then maintain them. So once defined the test or set of tests anyone can test the story, feature or epic.

Code of ethics for the profession of Software Engineer

Audience: software engineers working for the public interest.
Clients and employers: software engineers working to serve the interests of their clients and their employers, consistent with the public interest.
Product: Software engineers shall ensure that their products and related modifications meet the highest professional standards.
Rating: software engineers maintain the integrity and independence of their professional judgment.
Management: the manager of the designers endorse and promote an ethical approach to the management of software development and maintenance.
Profession: designers will promote the integrity and reputation of the profession consistent with the public interest.
Colleagues: software engineers are correct and cooperative towards their colleagues.
Themselves: software engineers undertake to update its preparation during the whole of their lives, and promote an ethical approach to the practice of the profession.

All of these points are very important, but in particular mode I appreciate the last…improve themselves always.

Scrum, an Agile Method

Scrum is:
– Lightweight
– Simple to understand
– Difficult to master

Scrum is a process framework that has been used to manage complex product development since the early 1990s. Scrum is not a process or a technique for building products; rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and development practices so that you can improve.

The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and is essential to Scrum’s success and usage.

The rules of Scrum bind together the events, roles, and artifacts, governing the relationships and interaction between them. The rules of Scrum are described throughout the body of this document.

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional.
Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

I agree!:)

agilemanifesto.org

Powered by WordPress & Theme by Anders Norén