Functional Testing simply put, testing a system’s functions (functionalities) per defined specifications has traditionally been a very important component of software quality control and assurance. Even before the days of independent testing, when testing was done by the same team that developed the code, functional testing has been a core focus area of people who were responsible for the product’s quality. Functional testing is often very large in its scope and potential that it continues to be done in a variety of ways – be it manual or automated, scripted or exploratory, as part of a core test pass as well as a regression test effort. If it has been so deep rooted in the testing history, you may ask what has changed over the years that we now need special consideration. As with any discipline, process or technique, the evolution of functional testing also has to be looked at from a past, present and future angles to ensure we are geared to align our testing efforts with the needs of the day. So, let’s look at functional testing from these 3 buckets of the past, present and future.
Past – As stated, over the years, testing for a product’s functionality was largely based on the defined system or functional specifications. These documents were the base for the tester to define his tests, map his test coverage on, and build his test entry and exit criteria. Functional testing was given more emphasis than non-functional test areas such as performance, security, usability etc. Globalization testing that included both internationalization and localization tests were also in part mapped to a functional test effort and were done sequentially after core functional testing in English was completed. The tester was more of a black box tester taking on functional verification in ensuring the system was built accordingly to define specifications, rather than validation
Present – When I say present, I talk about the last few years – say a timeline of about the last 3-5 years. This is a time when so much has happened in the software world – right from technology evolutions in the mobile, cloud, social computing spaces, to changes in development methodologies – a more active adoption of Agile, to more progress and acceptance of open source tools and technologies. The tester has been seeing and partaking in a lot of change including a new facelift to his role. The detailed system or design specifications that they used in the past are no longer prevalent. High level user specifications is what they have now and they understand that system functions need to be robust yet dynamic to accommodate changing user needs. So, while they are complex in nature they are also simultaneously light weight and modular. The tester has moved into a role where he does more system validation than in the past and then verification. This saves a lot of his time and effort in the verification test cycle, also giving more time for the equally important non-functional test areas such as performance, security and usability. These have become inevitable given how the applications are now accessed across a range of devices and platforms making them more vulnerable to these non- functional issues. Test automation, especially for functional tests are being closely looked at to understand what the return on investment is, and is being carefully chosen and done, rather than being looked at as pure numbers. Also, domain knowledge that lets the tester take on functional testing with an improved understanding of the domain’s workflows have become increasingly important
Future – The trends that we are seeing at the present will likely continue into the future years as well. These are all positive changes in the functional testing space that the testers should feel happy about. As more organizations take on Test Driven Development (TDD), where tests are designed upfront even before source code is written, these would largely continue to be functional tests that form part of the TDD suites. Functional testing will thus give the tester the required breakthrough to completely drive the product’s validation and verification rather than being blocked by dependencies on the team (including system understanding) that may have earlier impacted their productivity. More end users may also be brought in to partake in functional testing along with the core test team. Optimizing the large functional test suite along with the regression test suite to determine what tests to run on what locales and what devices will become core in differentiating an effective test team from a not so effective one. The future is all about scale and complexity to be able to make end user’s experience very rich yet simple. If so, functional testing which is a core element in this whole 9 yards, will have to be optimized and geared to continue to be central to the application yet not overwhelming in a tester’s drive to deliver a quality product to the end user. To this effect, the tester will have to see how to delegate portions of functional testing (be it a sanity suite or a regression suite) to other members such as developers and build engineers such that together the entire team is able to achieve the required functional coverage they desire.
Functional testing has and will continue to outlive the test of time. It is however in our hands as testers to see how to shape this in the coming years in the best interest of the quality of the product / application under test and the overall team’s productivity and morale standpoints.