Functional Testing - Testing Software From a Functional Point of View

Functional testing - the first, basic level of 'Testing' that is expected out of every Software Quality Assurance Professional. And even though it is being conceived as somewhat of a 'technical weakness' in many circles, functional testing is the core of all testing domain. The primary objective being, as the name indicates, is to provide quality assurance of the software from a functionality point of view. What you see/view on the screen, you need to 'test' it. It could be a Java API or it could be a.net web service. You need to validate what the interface is supposed to provide you. Often you will not be told a lot about the business requirements, and yet you are expected to come up with a very good 'tested' software product.

There are several steps which are needed before 'functional' testing can be completed. First of all, before you begin any testing you have to come up with a 'test plan'. A test plan is like a formal document which contains the steps and the procedure undertaken by the Software Testing team in order to fully test the project. Once the plan is approved the team will proceed with the test route. And it always starts with functional/manual testing. All of the requirements need to be understood before you can start testing, and that is very important. In my five years of experience I have seen many projects that were over budgeted and failed to get the expected response out of the clients due to this very reason, that the exact requirements were not understood properly by the testing staff. If there is confusion/lack of understand related to business requirements, the business flow will not be properly understood and that will lead to problems. As the client will expect the business flow to be tested before being delivered to the end-user. That said, the requirements are subject to change and they have to be managed by the project manager.

Once the requirements are understood (and it is an ongoing process), the testing team can begin with their 'test scenarios' a process by which test scenarios are identified and noted down. In this case it is pertinent to mention that one requirement or business case can point to one or more than one scenario. For the scenario, it is almost a requirement that there is an input (or more than one) and an output (at least one). Once the scenarios are finalized, the testing team can proceed with the test case part. Once the test cases are written down in document form (they can be written in MS word document, or it can be entered in a test tracking tool like Mercury's Test Director or JIRA), they result in defects or suggestions/improvements. These defects are prioritized and worked upon and eventually it leads to regression testing, where the test engineer has to re-test the defects again to verify the fixes.

The stability of the application at hand is the most important aim of all this testing activity. As the application is stabilized, it becomes easier for the client to make good out of it. Thereafter the requirements change and accordingly the application has to be customized to satisfy the changes requested. The other testing forms, such as automation, integration, compatibility and so forth are all a result of the functional testing cycle. If the application has not been properly tested in the functional phase it is very unlikely to be automated.

To conclude, functional testing is the core of all testing forms, and it's a vital part of any software project. Be it an ERP or eCommerce website or any other software project.