How to organize a quality check of a change to your Computerized System Landscape?

How to organize a quality check of a change to your Computerized System Landscape?


A big question, not easy to answer. Before answering this question, you must ask yourself: Do we need to organize this quality check? Yes, first of all due to limited availability of time & resources (budget / people) and to the desire to decrease time to market, companies don’t have the luxury to develop until the IT change is perfect. So, choices need to be made in how and what to develop and how to check product quality.

Secondly, you might be required to comply with regulation; delivery of documented evidence you are in control of your computerized system landscape.

For both the intrinsic and obligatory motivation to qualify your IT products, it’s important to control the development process including the test process, which makes companies need to organize and standardize the activities involved.

A standard way of working based on industrial standards and good practices helps to organize activities to develop new functionality and enables a reliable approach to identify risks, align time and budget and provides insight so that discissions and choices can be made.

Back to the question “How to organize a quality check?”:

Assuming the goal is to get an IT product that demonstrably meets the requirements and is fit for intended use within budget and timeline, it’s obvious to use the Quality Driven approach and set-up a Test Framework. Setting-up this framework depends on the delivery model (picture 1) applies to your organization and is done step by step and improved constantly.


Picture 1: Three different IT delivery models

Source: Sogeti TMAP® – Quality for DevOps teams

Rescop professionals support you setting up a customized framework or adjust your existing way of working up to the level that it meets the standard for modern software qualification and implementation.

Don’t go inventing the wheel but use best practices and industrial standards. The software development & testing community is constantly discovering better ways of delivering required changes to your computerized system landscape meeting requirements and quality through new testing approaches.

Following on the Agile Manifesto a Testing Manifesto (picture 2) was introduced in 2013 by Growing Agile.


Picture 2: The Testing Manifesto according GrowingAgile



In 2016 another Testing Manifesto was published by Dealertrack Technologies Quality Office. Instead of having 5 principles, this Testing Manifesto contains 4 values and 12 principles. Both Manifestos emphasize that built-in quality is achieved by:

  • testing as soon as possible
  • the acknowledgement that testing is not a tester responsibility but a shared responsibility of the project / change team
  • shared understanding of the (change to) the application and business process leads to ownership and enables Risk Based approach

These Manifestos not only changed the test approach, but they have also impact on software development.


These Testing Manifestos are not only to be used in Agile software development, the principles and values form the basis for organizing your test activities, regardless IT delivery model, location (SaaS or on-premise), product / change size or testing form (development – or acceptance testing). To keep it clear we use the 5 values of the “Growing Agile” Testing Manifesto.


Testing throughout OVER testing at the end

Organize testing activities in such a way that the test execution takes place as early and as often as possible and tests cover the development phase related parts.

Use the Testing Phased Model (picture 3) to enable executing the right test cases in the right stage in the correct order (picture 4).

Picture 3: Testing phase model

 Source: Sogeti TMAP® Next


Assign test types to each test execution phase and use test techniques to related test type.

Rely on test results achieved in previous test runs of the same change.

Focus on risks instead of easy to test.


Picture 4: Example of testing in every change creation stage (Sequential IT Delivery Model)


Preventing bugs OVER finding bugs

This principle is about “Built-in Quality”. Due to the fact defects are detected in an earlier stage by testing in an earlier stage, technical & functional related defects don’t accumulate during in later stages (e.g. User Acceptance Testing). By shifting Quality to the left, finding defects decreases and confidence on the right-side increases.


Testing understanding OVER checking functionality

This principle not about never test functionality anymore, it’s about getting every team member (really) understand the system / application and its function / purpose within the business process.

By start testing as soon as possible and throughout all change creation stages, using the Testing Phased Model (picture 3) and continuous monitoring during business use, shared understanding of system / application increases. Understanding leads to (improved ownership) and ultimately to higher quality.

Make sure team members check each other’s specification designs in early stages as preparation for code or configuration development and test cases.

Testing functionality becomes part of checking the expected.


Building the best system OVER breaking the system

By shifting Quality to the left and increasing ownership every team member participates in and is responsible for developing the best system meeting requirements and demonstrating fitness for intended use. Don’t try to find as much as possible defects at the end, which is very demotivating. Try to build the best system together creating business confidence.


Team responsibility for quality OVER tester responsibility

This principle seams very obvious; every team member is responsible for the required quality of the system. Unfortunately, in many change creation teams meeting the quality standards is a test (team) responsibility. Often change creation is started while basic development elements are not in place. “We don’t know exactly yet, but start development anyway, because the team is already in place (burning money).

Testers join later on and are expected to check product quality based on inaccurate or even missing basics. It becomes testers responsibly to create tests and record results to demonstrate quality.


Testers do not provide quality assurance; they assist the team taking ownership, sharing specific knowledge, introducing specific tooling and more to increase a continuous improvement mindset leading to a team responsibility for product quality.


Hopefully this contributes to a better understanding how to improve the quality of your computerized system landscape by organizing the quality check in a structured way. Feel free to contact Rescop’s Test Management Center of Excellence for more information, a quick chat to exchange ideas or a deep dive session for Test Management framework implementation or improvement.



Share this Post