Pinscher Testing

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

Category: process (Page 1 of 2)

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.

What is System Testing?

The System Testing verify the correct execution of the entire application, including interfaces with other applications.
As a rule, system testing takes, as its input, all of the “integrated” software components that have passed integration testing.

It provides several specific tests:

  • Functional Test: check that all functions are properly completed in a scenario similar to that of the end users.
  • Usability Testing: check the ease of use and understandability of the application from the end users.
  • Performance Test: check the performance of the product such as response time and resource usage (memory, transmission lines, databases, other components).
  • Reliability Test: check the reliability of the product when it is explicitly requested. The reliability is defined as the ability of the product to operate for an entire period of time (8 working hours, or H24/7×7) without being detected any defect that disrupts the operation.
  • Stress/Load Test: check the product’s ability to sustain a given workload.
  • Security Test: check of the level of security provided by the system.

What is Integration Testing?

Integration testing (IT) is the phase in software testing in which individual software modules are combined and tested as a group. It occurs after unit testing.
The modules of the component have been tested, in an integrated manner, in the test environment prepared, isolated and controlled.

The integration can be done in three different ways:

  • Integration Top-down: requires that simulated the components of lowest level.
  • Integration Bottom-up: requires that simulated the components of higher level.
  • Integrating mixed (both previous techniques).

The simulations with other subsystems not yet ready are programs simulated using “ghost” called scaffolding (drivers, stubs).

What is Unit Testing?

Unit Testing (UT) is the first dynamic test of the executable code, both in its initial and any subsequent changes.
Executed directly by the developer in its development environment, it checks the adherence to specific programming from the logical point of view the program; valid then its internal logic.

The advantages of the unitary test are:

  • find problems early in the development cycle
  • facilitates the modification of the code of the module at a later date (refactoring)
  • simplifies the integration of different modules
  • provides a sort of living documentation of the system.

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.

ISO/IEC 9126 – Model of Product quality

Product quality is an international standard for the evaluation of software quality. The fundamental objective of this standard is to address some of the well known human biases that can adversely affect the delivery and perception of a software development project. By clarifying, then agreeing on the project priorities and subsequently converting abstract priorities to measurable values, ISO/IEC 9126 tries to develop a common understanding of the project’s objectives and goals.

The quality model presented in the first part of the standard, ISO/IEC 9126-1, classifies software quality in a structured set of characteristics and sub-characteristics.

iso9126-1

  • Functionality – A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.
  • Reliability – A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.
  • Usability – A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users.
  • Efficiency – A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.
  • Maintainability – A set of attributes that bear on the effort needed to make specified modifications.
  • Portability – A set of attributes that bear on the ability of software to be transferred from one environment to another.

Potential benefits and risks of support tools for testing

The potential benefits in the use of testing tools include:

  • repetitive work is reduced (regression testing);
  • greater consistency and repeatability;
  • an objective assessment (static measurements, coverage);
  • greater ease of access to information relating to the test or the test (statistics and graphs on the progress of testing, performance, and frequency of accidents).

The potential risks in the use of testing tools include:

  • unrealistic expectations about the characteristics of the instrument;
  • underestimation of the time, cost and labor for the initial introduction of an instrument;
  • underestimation of the time and effort required to achieve significant and sustained benefits from the instrument;
  • Underestimation of the work required to maintain configurations and outputs generated by the instrument;
  • Excessive confidence in the instrument;
  • Risk that the instrument’s supplier goes out of business or withdraw the instrument;
  • Lacking support of the provider, in the release of improvements and correcting errors.

Support tools for testing

The testing tools can be used for one or more activities in support of testing. They include:

  • instruments that are directly used in testing, as tools for test execution, evidence of generation of test data, comparison of test results;
  • instruments that support the management of the testing process, such as those used to manage directly the test, its data, requirements, incidents, defects, etc., and for the reporting and monitoring of their implementation;
  • instruments that are used in exploration (eg, tools that monitor the activities of a file for an application);
  • any other tool that supports the testing (including a spreadsheet).

The term test framework is often used in IT, with at least three meanings:

  • reusable and extensible testing Libraries that can be used to build test instruments (called test harness);
  • a type of design automation of the testing (for example, data-driven, keyword-driven);
  • the overall process of testing.

Page 1 of 2

Powered by WordPress & Theme by Anders Norén