How do we go about testing a web app, portal or a plain website? This depends on the application, but generally each gets at least a fifth of project time dedicated solely to testing. There are three main processes to testing:
- Source Compiler Test
In the first case, code is usually run through a compiler which will show up any errors in the written code. This gives you very little information other than the code you have written can be converted by a compiler to the source (the source is a service or operating system that will process the machine code after compilation). To explain further this means the source service/operating system is willing to run the code without returning any errors. For us humans writing the code, the compiler gives us a more readable format to work in (usually for major software that tends to be American English). However just because a piece of code will run doesn’t mean it doesn’t contain any errors…or even makes any sense! This is where the next set of tests have to be applied. - Unit Testing
This is a way of actually testing the written code. This is usually written on “function assertions” (expected behaviours) which allow a developer (as much as is possible) to predict the ways the code may be compiled depending on the properties that are delivered from the user. This means trying to predict what a user could do and what the end result would be. - User Acceptance Testing (UAT)
This is usually considered the “final” testing to any application. We use human testers to run through the application pretending to be different kinds of users (for example, a customer) and trying their best not just to break the software but report back any problems with understanding the instructions given, or whether the flow and user interface works well in real life.
Post-Three Tier: Live Feedback
So the software is now live! This is where reports can start coming in from the actual customers using the application and can be the most taxing part of the testing. Unfortunately, the feedback you receive at this point is often written in frustration at rather than being constructive or helpful to fixing any problem. It often includes distracting facts about how the fault is affecting their business or life, which makes it harder to concentrate on fixing the problem. We are aware of this attitude as it happens in life – it’s like turning up to a gym but there’s a power cut and the machinery isn’t working (unless you like free weights). You spent time and effort to get to that gym. The gym owner will tell you the machinery is working fine – it’s just not powered up. Emotions kick in, arguments begin…but maybe all that’s needed needed is for someone to suggest checking the fusebox.
When any application becomes live you have to have a place where feedback can be given constructively. You need to be asking the right questions in clear language, as users are only experts in using (the clue is in the name!) not coding or testing. Any time you need to return to a customer to ask more questions just adds to the frustration. You can’t expect a customer using your software to know every step they took until they find a fault. You have to revert back to UAT based on feedback and try to recreate the fault to fully understand it to then be able to provide a patch (fix to the issue).
