Software testing: A basic primer

This is why I thought it would be ideal to share Quba’s first blog on Software Testing using a Dilbert comic on bug fixing and at the same time, to introduce myself in my new role as a Test Analyst at Quba.

Over the years, Quba has built a strong portfolio of web projects making many of our customers more than happy with the end products that they have received. As a web design agency we have had the chance to build, learn, relearn and develop software that is continuously getting better at meeting client expectations. To reach this level of sophistication, we have had to consistently deliver on quality. This is why we have invested in testing and ultimately, quality assurance.

Putting on my test analyst’s hat, I thought it would be a good idea to start off with a back to basics blog on software testing as a process.  

While we would like to think we have built a robust piece of software or application, we cannot leave it to chance that we have. More often than not, human errors can creep in during the build phase, resulting in a bad code and eventually a mismatch between the specification and the program. That’s when software testing makes its appearance.

Quite simply, software testing focuses on the functionality and viability of the product. It is done to ensure that the software achieves client specification requirements and more importantly is able to deliver in the real world scenario. Ultimately, the purpose behind doing it is to verify, validate and find.

Verification is when we confirm that the software meets all technical specifications laid out before in the specs document.

Validation of the software is when we confirm that the software is able to meet all business requirements. A business requirement could be while on a webpage, when a company stockist is chosen, their contact details appear with an input field where one can put in a post code or address to get directions to the stockist.

Finding a defect in a software is finding a variance between the expected and actual output when a certain input is made.

Testing, if done correctly takes the product one step forward to launching stage. If done incorrectly, it can devalue the software developing life cycle.

So, what steps do we take into begin testing?

In principle, software testing can be broken down into the following stages:-

Understanding the functional requirements of the program

Firstly, we need to develop a clear understanding of what needs to be tested. Obviously, the first point of call is to ensure that the product is functional at its core level i.e. the most critical parts important for business operations are functionally capable. Once this is achieved, there are a lot more aspects that can be delved into with regards to testing – technical design, regulatory requirements, hardware and system configurations and also corporate standards. For example, regulatory requirements of websites dictate that they follow W3C validation as well as The Data Protection Act 1998.

Test plan design

Writing down a test plan means we have a constant guidance at hand during the testing process. The test plan document is a framework surrounding the scope and activities within testing. It details the approach that will be used, the resources and toolkit that will be needed, and most importantly the schedule decided. It will also list individual tasks like who is responsible for what. In a way, the test plan is the holy grail of the process employed for a project. Inevitably, it also works as a communication tool amongst various stakeholders in the testing process in the way that it is informative of the steps ahead in the process. Any changes or revise in testing plans should be incorporated in the test plan design.

Test plan execution

Following the development of a test plan, testing begins in the development phase with smaller pieces of testing being done with the completion of each unit of the build. A more advanced set of testing takes over in the later stage with system and integration testing. This is then followed by business users taking over the testing responsibility through user acceptance testing. The final phase of test plan execution is completed with the product verification testing. The product to be tested is removed from the test environment for this testing to be run.

Test error logging

While logging bug errors, it’s important to put in more details than less. Some basic information in error logging that need including are – start-up configurations, initial state, the setup steps, test case steps, the expected results against the actual results and the error and warning messages received. On the other hand, there is no point in logging errors that are not actually errors, or even repetitive errors that can clog the logbook.

Test completion

While quality assurance is a never ending process, testing is finite. Ultimately, you would like to deliver quality to clients and assuring that quality is fundamental to the value proposition. This is why testing most often needs to go above and beyond the period of the product going live. Testing a live project has its own set of difficulties but doing it will aim to fool proof the product.

There are some activities that need to be completed to signify test closure. These would involve closing off any work items relating to the project, archiving the test artefacts like the test environment, script and plan for later review. Finally, a post project review may be undertaken so learnings can be made for future projects.