Your project is finally on its last legs, User Acceptance Testing (or more commonly known as UAT). After months of development, your application is unleashed on a selected group of users. They are there to determine if the application that has been built meets all the necessary requirements and standards before the big go-live.
You are expecting good results because your developers tested their work before it was deployed to UAT, which is a good thing. The project is already under pressure due to rework, which needed to be done in the last couple of weeks. Go-live is in four days’ time, which should leave enough time for the small tweaks that you are expecting.
The next morning you find a list of over one hundred defects reported from the UAT sessions, along with an email stating the users’ furiousness and disappointment. You are completely flabbergasted. How can it be? You expected only a few teething issues, not a list setting the project back weeks.
You do the right thing by requesting an urgent meeting with your team to go through the list and a couple of hours later you call your unhappy users with the news that will make him even more unhappy. The project is delayed by an additional week.
The UAT findings were legitimate. There are a few low priority issues that could be fixed within hours but there is one requirement that was completely missed. The biggest issue being cross browser application styling inconsistencies, different screen resolutions, mobile devices and operating systems, none of which was taken into consideration to the extent the users expected.
Where did it all go wrong?
Simple, a lack of proper and integrated quality assurance process. We often underestimate the importance and the additional effort required for this.
Yes, software engineers can test their own work, and they should, but there are many factors to consider. Developers will always have a level of bias towards ensuring stuff works. And that reflects in their own testing – checking that things work, rather than checking that things don’t work as expected.
Some items are completely overlooked;
· Are the results according to the client’s requirements and standards?
· Does it look aesthetically pleasing?
· Can it be viewed on different devices, different browsers or according to different screen sizes?
· What are the results being used for, and is it future proof?
Sadly, due to budget constraints, quality assurance is at the front of the chopping queue, and this can line you up for disaster before a project even started.
Quality Assurance Processes
A Qualify Assurance (QA) specialist ensures that the client receives high quality project in line with all functional (the things we see in the product) and non-functional (the things we don’t see) are met. It further creates a layer of accountability between developers and the quality of the product. A QA specialist can also automate testing with the use of software like Selenium, an opensource testing application that functions much like macros, where iterative steps and actions are recorded and then “replayed” by the click of a button.
When should quality assurance become part of the software project cycle?
Even though testing is the fourth stage of the Software Development Life Cycle (SDLC) - after Requirements Gathering, Design, and Development - the planning for testing should start immediately after the requirements gathering phase. Functional and non-functional requirements are used to draft the test cases, so there is no need to wait until the fourth stage to start with your test planning. By then you should already have the test cases finalised so that the actual testing can start.
Follow these guidelines during your QA process to ensure your client gets what he/she asked for.
1. Create a test plan according to the BRS, as this forms part of the application requirement
2. Execute testing by means of a platform designed to assist in generating reports
3. Log all defects and change requests
4. Have feedback sessions with developers
5. Measure the change impact
6. Audit fixed items
7. Implement regression testing
8. Manage good relations
My conclusion is that even if there is no budget allocated towards quality assurance on a project, the addition of one, can save you a mountain of time on a project. Rather sacrifice requirements, than quality.
And we all know that time is money.
Niel Steyn
Operations Manager of Innovation & IoT