The ongoing influx of technologies and processes brings greater complexity and demands shorter testing cycles. An unprepared testing team can be seen as a roadblock to business agility and faster time-to-market.
Here are some of the reasons why functional testing can be particularly difficult for these IT initiatives.
Testing needs to take place earlier in the lifecycle, often in parallel with development. In many cases, both testers and developers participate in testing in an “all-handson-
deck” effort to keep an iteration on schedule. Testers need to get their job done even if they are given minimal documentation on an application, and they still must
communicate a comprehensive defect description to facilitate fast remediation. And they often need to test partial applications and features instead of a complete
final version. These challenges lead to a growing need to implement practices such as exploratory testing. After engaging with major stakeholders to understand the business
goals of an application and its use cases, testers should use their knowledge and skills, including creativity and critical thinking, to rapidly explore the application to
uncover defects. The main benefit of this type of testing is time-savings, both in performing the tests as well as in reduced test design and documentation efforts.
It is necessary to not only validate GUI and non-GUI services and components, but to visualize, validate, and report on an integrated test scenario of the business process that traverses the multiple layers of a composite application.
For example, how do you test a bank transaction that initiates a deposit, executes a database call, and sends a text to the customer while confirming back to the user
that the deposit was successful? Too many of these processes won’t reveal their functionality through the GUI and must be validated another way. And if the
service that sends a text to the customer is also used in a transaction that sends an overdraft notice, will there be additional defects that have gone unnoticed?
With all the test-case permutations needed to fully test a complex composite application, many organizations will employ test automation; however, there are inherent challenges. The work required to automate tests is often underestimated. Automation is software development, and it needs to be properly staffed as such with skilled resources for design, validation, and maintenance.
In addition, finding a toolset to accommodate all or most required testing scenarios can be difficult. Using specialized tools for different technologies or applications can result in higher tool costs, higher training costs, and can limit the ability to standardize
across the organization. In addition, there is the problem of test scripts changing owners over time—without proper documentation. Often these tests are run for
years without knowing why the tests are important or what requirements they satisfy.
Here are specific steps the functional testing team can follow to modernize:
- Start with design:
Although this step is often neglected, taking the time to carefully design the test
strategy pays off in terms of making tests more efficient and easier to maintain. We recommend using a framework—creating a model of the business process and building a library of reusable test components that can be assembled into flows.
- Increase and improve automation:
Although automation will never completely replace manual testing, finding areas to automate will help the QA organization o test more and test faster.
For example, let’s say there are three business processes to be validated: create order, delete order, and update order. Once the business processes are modeled, it’s easy to identify duplication; all three use the same login function. With a modular approach, the test component for the login function only needs to be created once, not three times, eliminating duplication of effort. If a change is made to the login function, it is only necessary to change the associated test component once, and all tests that use that component will be updated. This “test by composition” method can reduce test creation and test maintenance time and effort. And this greater efficiency is realized whether the tests themselves are automated or performed manually.
To get the most out of automation, it is important to pply it judiciously. Here are recommendations on what and when to automate:
Regression testing – Regression testing is a “baseline” test suite that is used in conjunction with manual testing but is easily automated. It is usually less about finding
bugs in a new release and more about making sure that the latest changes haven’t broken anything that was working previously. Use automation to create fastexecuting,
repeatable regression test suites that can be run 24 hours a day. Incorporating these automated regression tests into the build process can enable a “continuous build” practice that rapidly finds problems and keeps developers always working on a known,
The previous iteration – In iterative methods such as Agile, it can be difficult to automate and get results back within one iteration or sprint. There often isn’t
enough time, and the code may still be in flux. But, similar to regression testing, it is a good practice to manually test the current iteration and automate the testing of the previous iteration. This helps QA teams to test sooner and test faster, both of which are necessary for an Agile process.
More stable applications and components – It’s important to analyze the return on investment (ROI) for automation. The benefits of automation over
time should outweigh the costs of developing and maintaining the automation scripts