Quality assurance, Plexteqwise


Quality Assurance (QA) is a form of trust in a certified way that assures you that a product or service will not fail you or become obsolete due to being faulty. In other terms, quality assurance is your money, meaning exactly what they mean, nothing wasted.


With a well-formulated Quality Assurance (QA), you get what you pay for, and that is crucial when it comes to any form of marketing. The economy itself relies on the very same unwritten principle.


Regarding principles, a reasonable Quality Assurance is built on two parallels of the same mission: the product or the service needs have to be compliant to the actual purpose or use, and also, it should all start with a successful first trial.


Plexteq's experts are skilled at providing their knowledge and experience to prevent defects in manufactured software products and assuring impeccable transportation of the said product, from manufacturer to consumer/client.


Technically speaking, quality assurance stands for preventing defects in manufactured products and avoiding problems when delivering products or services to customers.


In Plexteq, the quality assurance process goes adhering to quality models and quality measurement framework defined in an industry-standard ISO/IEC 25010:2011.

Why that's important, and what's the quality model is? The quality model determines which quality characteristics will be taken into account when evaluating a software product's properties. The quality of a system is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value. Those stakeholders' needs (functionality, performance, security, maintainability, etc.) are precisely what is represented in the quality model, which categorizes the product quality into characteristics and sub-characteristics.


As a customer, you are mostly concerned to have a quality app that meets the following requirements:

  • must work without crashing or producing errors;

  • must be stable;

  • all of its functionalities must work, too;

  • must make all necessary calculations;

  • must show accurate data;

  • all users must have appropriate permissions.


Essentially these and many other requirements are all included in ISO 25010:2011. The standard itself has emerged to standardize quality models taking into account the immense experience of various government and commercial organizations that develop software products. The standard is based on the real experience of thousands of projects.


ISO 25010 defines eight quality model domains shown on the following figure:

Let's go quickly through them.


Functional Suitability. The degree to which a product or system provides functions that meet stated and implied needs when used under specified conditions. In other words – what does the app do? In particular:

  • Functional completeness – is the app in line with the specification? Does it have the functions it was supposed to have?

  • Functional correctness – does it provide the correct results?

  • Functional appropriateness – does it fulfill its function?

Performance efficiency. Represents the performance relative to the amount of resources used under stated conditions. In other words – whether the app uses an optimal amount of resources and whether it uses them reasonably. In particular:

  • Time behavior – are the response and processing times or throughput rates reasonable?

  • Resource utilization – are the amounts and types of resources used reasonable?

  • Capacity – are the maximum limits reasonable?


Compatibility. The degree to which a product, system, or component can exchange information with other products, systems or components, and/or perform its required functions while sharing the same hardware or software environment. In other words – can the app work cross-platform or share data with other products, systems, or components? In particular:

  • Co-existence – can the app share a common environment and resources with other products?

  • Interoperability – can it exchange information and use the information that has been exchanged?

Usability. The degree to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use. Or in other words, whether specific users use the app in specific conditions. In particular:

  • Appropriateness recognizability – can users recognize whether the app is appropriate for their needs?

  • Learnability – is it easy to learn how the app works?

  • Operability – is the app easy to operate and control?

  • User error protection – does the app protect users against making errors?

  • User interface aesthetics – is the user interface pleasing to the eye? (watch out—that’s a very subjective issue!)

  • Accessibility – can the app be used by people of all characteristics and capabilities?

The last factor is particularly important, as we should keep in mind all sorts of prospective users that might end up using our app.


Reliability. The degree to which a system, product, or component performs specified functions under specified conditions for a specified period of time. This is an extremely important characteristic. Here, we look closer at:

  • Maturity – how stable is the app during everyday use?

  • Availability – can the users use the app when they need to? Remember, some apps really need to work under specific conditions. E.g., for some applications, it’s important to function offline out of the mobile broadband reach.

  • Fault tolerance – can the app work even when there are some hardware or software faults?

  • Recoverability – in the event of an interruption or a failure, can the app recover the data affected directly and re-establish the system? For a bank or any other business dealing with large amounts of data, recoverability is of prime importance.

Security. The degree to which a product or system protects information and data so that persons or other products or systems have the degree of data access appropriate to their types and levels of authorization.


For EU countries this is additionally connected with GDPR rules, which we need to be particularly aware of. For US biotech and healthcare companies this is also connected with HIPAA.

  • Confidentiality – is data accessible only to authorized people?

  • Integrity – does the app prevent unauthorized access to, or modification of, computer programs or data?

  • Non-repudiation – does the app collect information on whether specific actions or events have taken place?

  • Accountability – can the actions of an entity can be traced back to that particular entity?

  • Authenticity – can you prove the identity of a subject or resource?

In Plexteq we have worked with both GDPR and HIPAA environments and have a valuable experience implementing such kind of regulations in e-Gov, healthcare, and disaster recovery systems.


Maintainability. The degree of effectiveness and efficiency with which a product or system can be modified to improve it, correct it, or adapt it to changes in the environment, and in requirements. In particular:

  • Modularity – if an app is built with components, does changing one component impact other components? (Which makes any changes to the app easier and faster.)

  • Reusability – can an asset be used in more than one system, or in building other assets? Again, this might be extremely timesaving when changing or expanding the app.

  • Analyzability – is it easy to analyze any activities in the app that need to be taken into account? (Again, do not overanalyze. Look at what is important.)

  • Modifiability – is the app easy to modify without harming present product quality?

  • Testability – can the app be tested, also automatically?

Maintainability should be taken into account at the planning stage of the app development cycle.


Portability. Degree of effectiveness and efficiency with which a system, product or component can be transferred from one hardware, software or other operational or usage environment to another.

Or in other words – can the software be used in various environments?

  • Adaptability – can the app be adapted for different or evolving hardware, software, or other operational or usage environments?

  • Installability – is key for mobile apps – can they be successfully installed and/or uninstalled in a specified environment?

  • Replaceability – can the app replace another software product for the same purpose in the same environment?

As you can see, quality models and metrics cover many functional and non-functional aspects of a software product.


ISO 25010 is a great framework to define software metrics important for a particular project. Each project is different, so we cannot precisely treat the list as a ready-made plan of action.


It is essential to understand that a proper and efficient QA stands for a process, not an individual effort. It means that a top priority after picking the relevant quality models and metrics would be to construct an appropriate process on top.

At this point, you may get interested in how to embed quality assurance into a development process. An optimal generic one may look as shown below (it’s not final as software projects differ, and the process is flexible enough to adjust to our project specifics). In Plexteq, we believe that process should follow the business realities, not vice versa.


As you might have noticed, quality assurance touches almost all the aspects of the software development life cycle, including business requirements analysis, development, and post-deployment phases. That’s why, while making QA a repeatable ongoing process is a challenge, it’s the same way important as having regular code reviews, releases, and proper DevOps processes in place. It all works right just in tight conjunction.

3...2...1...Go!

QA work starts at an early stage with requirements validation. Here QA team builds a bridge between non-technical stakeholders and over-technical developers. QA engineers clarify how the new feature relates to existing ones and formalize higher-level business points to lower-level technical aspects. The main goal here is to avoid unexpected lack of edge case coverage.


Once development starts, the QA team begins to work on testing documentation, which, in case properly maintained, becomes the central project document that specifies overall system behavior.


Besides the functional verification, QAs assist with testing non-functional domains, such as security, performance/stress/load testing, depending on project specifics.


After deployment completes, QAs continue to verify production environments with a recurring smoke test to ensure smooth day-to-day operations.


Once the process is built and adopted, it's a good time to consider automating it.

Once the testing documentation is defined, and manual pipelines are launched, some test phases might be automated using testing automation frameworks such as Selenium, Cucumber, Gatling, and Ranorex. Automation is an important step that helps to boost release processes and decrease time to market. In Plexteq, we have successful experience with automating functional, security, performance testing for Web, Desktop, API, and mobile applications.


The benefits of a properly built QA process come almost immediately. and are listed below:

  • testing becomes more transparent and brings a clear understanding of what is tested and how;

  • QAs determine if new features are consistent with existing system design and validate how those new features fit into the system;

  • saves time of developers and business reps to test an app; brings clarity into the responsibilities matrix and team members do just what they have to;

  • QA team creates testing documentation that helps understanding system logic to all project stakeholders which helps to avoid bugs in the future;

  • testing documentation that’s appropriately maintained becomes the primary document that specified system features and behavior;

  • QA team finds defects before customers; as a result, customer satisfaction increases.


Backed up by a hands-on team, Plexteq brings it all together.


Software development is a process, and quality assurance is its integral part. And we need to have full control of this process to arrive at satisfactory results – i.e., a working piece of software that meets our requirements and quality goals – and do so within a reasonable timeframe and budget. In Plexteq, we build, deploy, and maintain efficient quality assurance processes owned by product stakeholders as we believe that quality products bring competitive advantage to their owners.


Imagine how much better everything gets when you know your products are thoroughly tested and certified by the advanced techniques, methodologies, and the smartest software out there, specifically designed.


Software testing speaks the language of the future, so it has already established itself in this day and age and beyond.


Want to learn more about our QA offering? Contact us today!

Have a question?