Least Burdensome Approach

The software engineering community have been striving to make better, more maintainable and easily updatable software since the 1950’s. They have done so in order to reduce the scope of error and to allow for increased through put. They have developed specialised QA & test roles, processes and techniques to help in this aim. Why?

 

 

Computerised systems are intrinsically complex. Errors can stem from misunderstandings, miscommunications, undisclosed requirements, poorly defined requirements, not including project stakeholders throughout the software process, poor direction, poor foresight, poor design choices, unforeseen tasks, requirements changes, change of personnel, a lack of appropriate support processes (QMS), a lack of understanding of how IT systems are built, poor technology decisions and poor test decisions which combine to disperse computerised systems with defects. A relatively simple concept can require a complex implementation as a computerised solution. The verification of computerised systems demand specialised skills which many software organisations do not posses.

Without the use of correct verification skills, issues can remain undetected in the computerised system and can remain undetected until the operational phase. The net result here is that costs of corrective action can be exponential ,with a possible erosion of competitive advantage, lawsuits, closures and even death. The IT world is awash of troublesome software.

 

One of the primary aims of the QA & Test engineer is to identify, plan, document, perform and update activities that will counter against the above sources of errors.   The input and output to the QA & Test activities are designed so that every action and decision is documented to ensure:

 

•  Lessons can be learned at the end of a software project and applied for the next one.
• Decisions are tracked
• Enhance decision making based on objective, independent evidence can be made.
• Processes can be improved upon by corrective and preventive actions.
• Tests are uniquely identified and prioritised in order to help identify suitable tests for regression runs for bug fixes, maintenance cycles and for change controls.
• Tests designs can be independently reviewed for application and effectiveness.
• Tests are easily executed.
• Test results can be easily reviewed.
• Software bugs can be easily captured, described and once fixed, verified.
• Requirement coverage can be easily identified as each test is traceable to a requirement.
• Ripple effects can be easily identified as test flows are composed of several modular tests where the output of one test will form the input to another.
• Test environments can be easily replicated as hardware and software components are identified and planned.
• Test phases are planned with specific risks in mind so as to ensure that the test coverage is not only adequate but also effective.
• Meetings are recorded so that risks can be managed, decisions tracked and issues escalated.

 

Such documentation trails result in the QA & test engineer becoming the 1st port of call during customer visits, demonstrations, technical queries and, for example, ISO audits. Thus the QA & test engineer documentation has to be highly planned, organised, detailed and reviewed in order to achieve all of the above benefits.

How can this documentation help Validation?

 

To answer this software engineering testing needs to be briefly examined.

 

 

 

 

The nature of software engineering is to break problems into modular designs, which are implemented as solutions. The modularised solutions are coupled together to form larger solutions and again until the complete system is delivered. The testing strategy will apply tests at each of the above stages. Small, distinct and independent, technical tests are designed to verify the small, modularised solutions – both positively and negatively. Different technical test techniques are deployed at different stages of the solution delivery, where the effectiveness of identifying a defect is greatest. A subsection of these tests are coupled to form larger test flows to challenge and verify the larger solutions. As the solution grows, so does the type and scope of test verification. As the complete solution is reflective of the user requirements, they are also mirrored in the user acceptance tests.  In the software engineering world, the user requirements are used to create the User Acceptance Test Specification.

 

Depending on the particular industry, this is also termed the Customer Acceptance Test Specification, or the Factory Acceptance Test Specification, or the Validation Test Specification (IQ/OQ and PQ). The scope of the tests performed by the QA & Test engineer and the Validation tester are the same. The documentation and results produced by the QA & Test engineer are of a very high quality that can be an aide to, or a substitute to much of the documentation and results produced by validation. The work performed by a QA & Test engineer can be used to reduce the work load of the Validation engineer.  With the documented history of the technical testing performed at different stages of the solution delivery, the Validation engineer can reduce the scope of test execution to focus on high risk areas and allow for a regression of others.

 

The benefit to Validation is the leverage of independent expertise, a faster Validation cycle, no high priority issues, less documentation and a faster delivery of the compliant, business critical computerised system.

 

EmpowermentQE can provide expertise to perform this role within GaMP5 Category 4 and Category 5 computerised system projects. EmpowermentQE can provide an additional audit function  of your next 3rd P. supplier audit to identify what activities you can rely on for Least Burdensome Approach. By using ISO based audit approachEmpowermentQE can quickly identify what gaps in the supplier’s approach need to be covered by you. The team  can help you mitigate risks with suppliers by devising processes that will improve their quality  activities and we can introduce additional activities that the  Validation team may need to deploy to overcome any quality gaps.