Demystifying Quality Assurance Processes as pertains to IBM i Systems and Infrastructure

Yvonne Enselman

All components of an IT ecosystem need testing and validation. Any professional, or student in MIS, knows this, of course. What is harder is determining how to approach a given modification and the testing needed in a pragmatic fashion. There is a process that can be applied to most initiatives that consist of planning, analysis of the context, definition of tasks, estimation of effort, and risk mitigation.

When we address what needs to be delivered in a pragmatic sense, the priorities are easy to see. Once we start into a project we can get lost in complexity, engineering principles, etc. In order to make QA/Testing accessible, scalable, and reusable, it is best to drill down the process into checklists for procedures. Every organization has someone who knows what they need the system to do – from an admin who gets how to connect the ports, to the AP person who can process a check before we say “deposit”, to an EDI coordinator who knows the JIT threshold. Determining the best way to test usually involves understanding the actual job we need to accomplish and taking the time to break into steps where failure can be determined.

“How much testing is enough?”

This question has a million answers. The correct one is when the risks have been identified, migrated, and relevant decisions are communicated to decision-makers. We determine this by planning the testing effort. Start with – what can this break, the worst-case scenario. Move into what is the modification likely to break to prioritize and is there anything unlikely that would destroy the business if we don’t test it completely.  Do we have any test cases from a previous project we can adapt and reuse? What are our testing resources? Is there anything going on with the business that can impact UAT? Should we refresh data? Is there a given point in time the data in production would be ideal for this testing and we should take a snapshot to save for this effort? Where are we in a testing maturity model and where would the organization want us to be for this specific task; are these aligned? What is the risk tolerance of our company? Are we hyper averse to risk and that is keeping us from handling routine maintenance as needed exposing us to worse issues?

Once we have planned let’s review the context.

Testing needs to account for operational concerns of the system overall and admin concerns, the actual project under development, and the business process it needs to support. Every project will weigh these factors differently but everything needs to account for all of them.

The System

On the IBM i there are so many components that can be addressed within the system settings and therefore be done for all development of that type. All of the functional testing areas can be addressed systemically, spending time to understand all the system values and how they can assist is usually well invested. Even if you aren’t managing this area of QA via system values, the configuration should be evaluated for all major projects.


Every single thing we do in IT is to enhance business. For testing, organizations look to what we are trying improve and write a wish list. Then they become realistic and move what can’t be accomplished into another phase. This technique allows us to create the testing plan matching the requirements long before we get bogged down in development and revision and lose sight of what we need in scope creep.

The Project

Finally, there is the project itself. Usually, it is the first QA priority, as it is where everyone is focused. Fair enough. However, you can test one thing upside and down and still fail if you don’t take the system configuration and settings and overall process into consideration.

We can’t evaluate the process without taking the amount of time, resources, and budget into consideration. This is where project management/testing management really needs to communicate with the decision-makers. I have never been in a situation where stakeholders said I told them a concern too early. Although this can be difficult as no one wants to feel they are a roadblock or a naysayer. However, we all know addressing issues early saves a lot of money. The above paragraph will give a team leader a lot of talking points to document and support their reasons if they need to raise a flag. A one on one meeting about predicted problems can be nerve-wracking but really does reap dividends. And if you wouldn’t be willing to have a conversation about exposure at a high level the project may not have enough analysis in place for full success.

Demystifying the QA establishment for projects and the procedures needed to test organizational processes can be daunting. We all care so deeply about how our system supports the organization. Boiling all modifications into core deliverables and from there into a checklist makes things far simpler.

View more from this month:

Leave a Reply

Your email address will not be published. Required fields are marked *