Explaining Iowa caucus app fail: Why Elvis has left the building
A case when QA might have been a bosom friend
Last Monday, the USA was shocked by the Iowa caucuses’ incident with the app that has failed to fulfill its critical mission on a momentous day. Why could this have happened? How to assure it won’t reoccur again at the very crucial point? The a1qa experts provide technically-justified answers below.
With multiple examples of how the low-quality software ruined the relationships between customers and the product owners, QA (quality assurance) within digital transformation is not a buzzword, it is a must.
Software testing is an indispensable part of the SDLC. In a wish to save money or time, some companies neglect applying for timely QA or pitch on low-qualified specialists. In governmental, BFSI, and eHealth industries, data accuracy is one of the key points that has to be ensured with no compromises.
When speaking about critical events like on Monday in Iowa, QA should stand in the first place assuring that thousands of users can download the application, sign in to it, make the required actions (report the results) without any difficulties.
In fact, by now, the Nevada Democratic Party tries to avoid the caucus app to make the reporting process easier, even though before Monday’s events, they were expected to use the same technology.
Relying on in-house QA expertise, two reasons for app fail can be defined:
• The QA engineers didn’t ensure that the precincts should seamlessly report the results. The peculiarity is that it has to be not a one-time check. In reality, thousands of results were delivered.
• Besides, the developers also had to take into account that the reporting was multi-flow. In this case, it is an architecture issue that could have been avoided through careful requirements testing to ascertain the system requirements are logical and full.
Before moving to the testing processes, one has to cherry-pick the test approach. It helps define the test strategy showing, which test types are to be conducted to help achieve the business needs of the app.
Without proper test planning and incoherent strategy, there is no test approach that can be used for QA activities. It may consist of some chosen tests, but they may be not enough or may be not the ones required for the specific case.
In such a mission-critical situation (like the Monday’s), the steps that should be taken before the app goes live are to be strictly regulated:
1. Create an appropriate test strategy.
2. Delve into software specifics and choose the testing types that should be conducted.
Functional and performance testing could have helped avoid the chaos. Performance testing can identify whether the system will stand the expected load as well as define the maximum load when multiple users at the same time intend to work with the app. Functional testing could have helped ensure the users can sign in to the app, and the results can be reported accurately.
The implementation of shift-left approach at early SDLC stages makes the development journey more cost-effective and faster, as it is cheaper to fix the bottlenecks before they leak to production.
3. Correctly generate test data.
4. In the end, conduct UAT (user acceptance testing).
Bearing in mind that the application is a mobile one, the variety of mobile devices should be taken into account, and the software has to comply with the Developer Guides (for Android). In addition, the APK file has to be delivered to the Google market not independently, and one has to do it beforehand to let pass the check by Google. Therefore, we may assume that development deadlines were really tight.
Certainly, to create an actionable plan in this situation, one has to test the programming code and dig into software specifics, complexity, and business logic.
All in all, no matter what the app is like (is it a complex one or not), timely testing before a mission-critical event can help deliver high-quality software with no budget losses.