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.

Independent Testing in other words, testing that is officially done by a third party team that has not been engaged with the source code development, is a serious business. It is a discipline of its own under the larger umbrella of software testing with people who specialize in testing activities ranging from manual to automated, from functional to performance, from compatibility to internalization. A study by Ambysoft in 2013 talks about how Agile organizations claiming to be Agile were. In this study while evaluating the parameter of “validation and verification”, one of the checks done was to see whether an independent third party team was used for testing the software under development. While in several organizations there is a discussion of merging the developer and tester into a single role, especially with how Agile and nimble they need to be, the role of an independent tester is never going to go away, at least in the foreseeable future, given the value they bring in, to the quality of the product. We do continue to see organizations as large as Facebook not having a quality team of its own, but we also steadily continue to see newer organizations (e.g. WIKIMEDIA) christening the new role of a software tester.

While we continue to emphasize the prominence of the role in the future, despite mergers with that of the developer in certain groups and organizations, the tester has an important role to play in shaping his and the discipline’s future. He needs to the quality consultant and advocate not just in own team but also within the larger product team, has to be ready to take on bigger and better challenges (whether it is TDD, whether it is interfacing with end users, whether it is learning new test automation tool functionalities or whether it is understanding newer computing technologies). Such readiness of the tester and actual implementation on the ground are critical to give “independent testing”, its facelift into the future. Also, there will be situations where the tester will need to collaborate with the developer to a larger extent than he did in the past – whether it is pairing with him to understand the system internals, or taking on a paired development and testing effort. These are going to increasingly become inevitable in the future. In all of these situations, it is in the tester’s best interest that he has to step out of the development zone and mind set, to maintain his independence in the testing effort.

The scope of software testing is only going to rise, with technology becoming omnipresent in all disciplines – whether it is wearable computing that is slowly penetrating the market, or the ongoing aggressive software development in the mobile app world or end user centric web applications or enterprise world applications, to name some. Independent testing is a better understood and accepted term in the industry now than it was, a decade ago. While, there are some forces, including a questioning on the cost spent on independent testing, that will attempt to merge it with the product development effort, with the right focus from the test team and the other market forces (be it end user needs, competition, time to market etc.) at play, the world of independent testing will stand tall and high into the coming years, staying clear of all the distractions it may occasionally face.