#CaucusGate #CaucusMonday or #CaucusFail, or whatever you want to call it, all point to the fundamental issue, lack of proper testing.
For those who missed the headlines earlier this week, an app used to aggregate and communicate precinct caucus results for the 2020 Iowa Democratic Caucus failed miserable, resulting in near chaos. What should have been a foundational moment in the start of the 2020 Presidential Race resulted in a breakdown of epic political proportions.
If the app is at fault, as many have accused, it points to a not uncommon issue in development lifecycles, TESTING!
Testing and Reporting as part of a project usually occur at the tail end of a development lifecycles. When a project is delayed or has missed milestones, it’s often an area a Project Manager or Lead will try to reduce or trim. Don’t do it. If anything, you’ll likely need more time, given whatever was the cause of the delay may mean updates to testing plans, regression, etc. which takes TIME.
Here are important steps which every technology project or sprint should include; not just the function, but enough time to complete:
- Code Review. Any code developed internal or external should be separately reviewed by a different developer. While the code language is common, syntax and structure can vary wildly. This will ensure a second set of eyes, at a minimum, and potential code efficiencies as a bonus. If possible, daily code review should occur.
- Regression. Whenever new code is introduced, in addition to reviewing any code conflicts, a regression of your primary features and functions of the site/app/tool should occur. Can you still add items to your cart? Place an order? Sign-up for email? Etc.? Depending on your sprint cycles, this is usually a weekly or biweekly task, but can find issues introduced by developers early on.
- Quality Assurance (QA). The work horses of a project and a vital step toward a positive customer experience. QA teams should be involved from the VERY beginning to write the proper test cases, identify what can be automated vs. manually checked, as well as understanding what should and should NOT change. Each sprint cycle should have an adequate amount of time for QA, and QA should be adequately resourced to the time allotted to complete the work.
- Business Unit Acceptance Testing (BUAT). Most of the teams above are in the tech world, but it’s the end user who will interact with your code, sometimes all day long. Ensure the user team has a chance to review the experience. If possible, have a stakeholder in all the sessions to identify points of collision or friction for their use. BUAT should be completed with ample time to test, retest, and test again (i.e. more than once) AFTER QA has certified the work.
- Beta Testing. This might have been the fault of the Iowa Caucus. Essentially, they could have held a beta test where all the participants completed the steps in a Production world submitting their counts (albeit sample for the purposes of beta), to shake out any issues before Go Live. Think of it as a soft open for a restaurant. This might have happened with a handful of people, but taking the app to scale will shake out any server or system issues BEFORE the final product needs to go live or be in end user hands. This should occur after BUAT (sometimes during), should be a Production level environment, and is vital to sniff out any final issues.
- Smoke Testing. Similar to Regression, this should occur after a build or tool goes live. Ideally with a war room of testers, developers, server and network engineers, etc. The size of the team can vary based on the scale and scope of work, as can the length of the war room. I’ve had war rooms as short as 30 minutes and as long as a week, depending on needs. The important part is to get everyone into the room, monitor customer relations, social channels, etc., to identify any major issues as quickly as possible. Taking code to full scale will undoubtedly shake out a few missed scenarios, or error states, etc.
- Rollback Plan. And test it. I’ve been involved in MANY projects that when we sit down to discuss launch plan, the discussion of roll-back as a contingency, is dismissed. Every project should have a roll-back plan for business continuity. That roll-back plan should be tested, periodically, to ensure the steps, procedures, efforts that need to be completed – either again or in reverse – can be done so with the right teams and permissions. Roll-back testing should occur at least twice a year, or after any major systems or software updates.
Testing is a challenge. Developers don’t like to hear about things that aren’t working. Stakeholders don’t want to hear about delays or missed scenarios. Leadership doesn’t want to hear about missed milestones, project cost overruns, etc. However, ensuring a project is properly tested end-to-end throughout the lifecycle can help ensure a near-seamless positive experience for your consumer.
deBeck Solutions offers support for developing, evaluating or completing QA testing plans. We’d love to learn how we can help your organization deliver even better results for your users.
Reach out! Let’s get started.