Functional testing can consist of many components: unit testing, smoke testing, sanity testing, integration testing, interface testing, system testing, regression testing, and user acceptance testing (UAT).
The ‘early days’: the waterfall approach
Back in the early 90s when I first started testing (when most companies used the waterfall approach), the job of the System Tester was to solely find defects in a system, which back then was predominantly a Windows desktop application, and we used the Technical Specification Document. As part of the System Development Lifecycle (SDLC), testing fell between the Development and Implementation phases. It consisted of mainly System Testing followed by UAT (who used the User Requirements Document), but these two tasks very often merged into the same phase, due to time constraints.
Test phase and its importance
Being the last phase before the system went live, you would have thought that it should have been the most important and given the necessary time required to get the job done properly. However, often this was not the case. If any other phase overran, the test phase was the one that suffered. The project deadline still had to be met, so testing was often crammed in at the end with late nights and weekends being worked to get as much testing done before the deadline. It was also, ultimately, where the blame stopped. If defects were found in the system once it had gone ‘live’, it was the customer’s usual response to ask “why was this not found during testing?”
So, what has changed – agile vs. waterfall?
The role has now expanded vastly and includes the responsibility of deciding if the product is ‘fit for purpose’, and now we have to consider both the technical and business requirements when testing.
Nowadays, although the main function of testing hasn't changed, the role of a System Tester has, along with what we test. We're not known as System Testers so much today – now we are Quality Assurance (QA) Testers. The ‘waterfall’ approach has been overtaken by the ‘agile’ approach, and QA is involved a lot earlier in the SDLC.
The role has now expanded vastly and includes the responsibility of deciding if the product is ‘fit for purpose’, and now we have to consider both the technical and business requirements when testing, as the UAT phase has become more of a process for businesses to accept deliverables, as opposed to testing against requirements.
Benefits of QA being involved early in the SDLC
The agile approach enables the QA Tester to be involved in the project at the early stages rather than at the end. It has an overall effect on quality improvement, and risk is reduced because feedback can be provided early on. This will then lead to customers being happy because changes/fixes can be made whilst still developing, rather than at the end of the project when it can be too late and change requests and warranty/support agreements have to be written and charged to the customer.
From the moment requirements have been decided, a QA Tester can start to think about how the product can be tested, before a single line of code has been written. Test plans are drawn up, followed by specific test conditions, which result in test scripts.
These scripts are then a tester's Bible. They can be run manually or turned into automated tests and regression test suites. These days, it's not just a Windows desktop application - the age of the Internet has meant that web testing is more and more common, hence the QA role expanding.
Which devices is the website going on – desktop/laptop, tablet, mobile?
Which browsers does it need to support – is it running MAC, Windows, Android, iOS, and so on?
Gone are the days of ‘single platform’ testing. Now, it helps if a QA Tester is a developer too, as we write SQL queries and perform table lookups, XML/SOAP executions, write automated scripts in Visual Basic, Python, and so on.
Now, the capabilities and responsibilities of a QA Tester are huge, and luckily for me, Ridgeway understands the benefits of having a dedicated QA role within their development team. This will certainly go a long way to ensuring that products delivered by them are fit for purpose’ and as bug free as possible, before the client gets to perform their own testing – User Acceptance Testing (UAT).