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.
Processing
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:
- Accidental Deletes on External Storage: How Volume Protection can Prevent a Disaster
- Reviewing MIMIX IBM i Protection Reports
- Important Notice Regarding the Latest POWER9 Model G Firmware
- Making the Case to Keep Your IBM i
- iTech iTip Videos
- [ Webinar Series ] Sips & Tricks: Coffee with iTech
- [Podcast Episode] The Benefits, Features and Functions of External Storage
- Upcoming Events
- IBM i, FSP, and HMC release levels and PTFs (October 2020)
