It’s a profile that analyses and assures quality of different products and services. QA are the English initials for Quality Assurance, which is related to QM Quality Management and QC Quality Control.

Count on a QA profile is key from the beginning of the project, working coordinately with business, development and design teams among others.

This professional participates in the requirements gathering, preparation, planning, design, development and launching of your services. Their presence prevents from errors once software is already in the market, help to timmings reduction and costs savings of corrective stage at the end of the process. Likewise, there is more confidence in the quality and safety of the product.

For more information you can read this article about the QA analyst profile.

Quality Assurance is the set of planned and systematically applied activities to satisfy quality requirements of a product or service. Among those activities are: systematic measurement, standards comparision and processes following that contributes to errors prevention in the whole life cycle.

According to a report of Capgemini and Microfocus, the most of the organizations find difficulties to adapt their QA and testing processes to the agile development. Strike a balance between tests speed and frequencyand the continuous delivering of releases, requires to increase QA maturity of your organization or externalize it. In the same report it is mentioned that a list of companies face problems with tests in sprints (a 56%) and it’s a huge effort to find professionals with the specific know-how of software continuous testing (62%).

For more information you can read this article about QA’s importance in the agile methodologies, this article about tendencies and prospective in QA’s world and this other one about Quality Assurance in ecommerce.

How can I launch automatic testing in my organization?

• First of all, QA maturity level must be assessed to determine if the organization can start with automatization process. For that purpose, it’s needed to analyse if there are a product and a team with knowledge enough about manual tests.
• If the answer is “yes”, then a trial around this product can be started.
• After that, metrics must be listed and adapted to the grade of maturity of the company and the project, for instance: testing hours, number of errors found by the customer, number of errors found by development, system size, time of detection of errors…
• Then, people to do automatic testing will be assigned. Ideally, those people must know the product or did manual testing about it. If not, it will be needed to give them functional and testing documentation of the product.
• As follows, test cases to be automated will be selected. If there is a battery of manual tests, we can use it as a base. It’s important to classify tests per tipology since not all of them can be automatized and others will be easier than anothers. Tests can be classified in functionals and non-functionals (Reliability, Usability, Efficiency, Compatibility, Security, Maintainability, Portability).
• Classify tests in functionals and non-functionals (Reliability, Usability, Efficiency, Compatibility, Security, Maintainability, Portability).
• Once test cases are selected, they must be prioritized and classified according to their characteristics: simple, repetitive, common, less automatization cost, most impact in business. The most common error is to try to automate everything from scratch, but it’s not recommended. All will be automatized progresively.
• Depending on the test cases and the type of product, tools will be selected and adapted to the scope and trial project maturity.
• Environment, test data and additional tools will be prepared.
• Usually a batch of no more of ten test cases is the first to be automatized.
• It will be needed to document and follow-up all the process.

For more information you can read this article about automation.

• First of all, QA maturity level must be assessed to determine if the organization can start with automatization process. For that purpose, it’s needed to analyse if there are a product and a team with knowledge enough about manual tests.
• If the answer is “yes”, then a trial around this product can be started.
• After that, metrics must be listed and adapted to the grade of maturity of the company and the project, for instance: testing hours, number of errors found by the customer, number of errors found by development, system size, time of detection of errors
• Then, people to do automatic testing will be assigned. Ideally, those people must know the product or did manual testing about it. If not, it will be needed to give them functional and testing documentation of the product.
• As follows, test cases to be automated will be selected. If there is a battery of manual tests, we can use it as a base. It’s important to classify tests per tipology since not all of them can be automatized and others will be easier than anothers. Tests can be classified in functionals and non-functionals (Reliability, Usability, Efficiency, Compatibility, Security, Maintainability, Portability).
• Classify tests in functionals and non-functionals (Reliability, Usability, Efficiency, Compatibility, Security, Maintainability, Portability).
• Once test cases are selected, they must be prioritized and classified according to their characteristics: simple, repetitive, common, less automatization cost, most impact in business. The most common error is to try to automate everything from scratch, but it’s not recommended. All will be automatized progresively.
• Depending on the test cases and the type of product, tools will be selected and adapted to the scope and trial project maturity.
• Environment, test data and additional tools will be prepared.
• Usually a batch of no more of ten test cases is the first to be automatized.
• It will be needed to document and follow-up all the process.

For more information you can read this article about automation.

Standard ISO IEC 25010 System and software quality models can be applied since it describes the quality model for the software product and the quality of usage. This regulation presents all characteristics and sub.characteristics of quality to evaluate a software product.

It belongs to ISO/IEC 25000, a.k.a. SQuaRE (System and Software Quality Requirements and Evaluation), a family of regulations whose purpose is to create a common framework to evaluate the quality of the software product.

The quality model defined by ISO/IEC 25010 is composed of eight features that can be splitted into sub-characteristics for a detailed analysis:

• Functional adaptation
• Reliability
• Usability
• Efficiency
• Compatibility
• Security
• Maintainability
• Portability

Initially, basic tools of project management can be used. However, as QA maturity evolves in the project and the organization, the following tools could be used (clasified by are of work):

• Tests management: JIRA, XRay, Zephy, testlink, ALM
• Programming: Java, Python
• Data Bases: SQL, Oracle, MySQL
• Frameworks: Spring, Angular
• Automatization: Cucumber, Specflow, Behave, Selenium, Appium
• Codeless testing: NoCode/LowCode technologies for tests automation without code.

For more information about QA tools and skills you can consult the following article.

• Test Management Office y Quality Management Office (TMo and QMO)
• CI/CD DevOps
• Testing strategy design
• Master test plan
• Tests plans definition
• Assessment of tests processes
• Assessment of testing tools
• Implementation of tests processes
• Functional tests
• Tests automatization
• Performance tests
• QA trainig around methodologies, tools and processes