DFT & Automation

In this smartbits video “Design for Testability& Automation” Girish Elchuri outlines how design for testability aids in test automation.
 The transcript of this video is outlined below.

There are three aspects to be looked at when we talk about test automation. The first one is running the test cases, the second, invoking the functionality that needs to be tested and the third, asserting the outcome tests as success or failure. We can talk about test automation only if we can automate all these three functions.

Test execution
Most of the time, running the test cases is perceived as automation, but ideally it has to invoke the other two as well. With reference to running the test cases, there are enough tools that can be used and invoked, but in case of invoking the functionality, a developer can make a big difference.

Backdoor invocation
Normally when a product is being developed, the product functionality is accessible only through GUI. Developers should also provide a backdoor to reach the functionality so that one can actually test the entire product functionality in a much more efficient way without having to invoke the GUI. This is how developers can help in terms of test automation.

Test outcome assessment
In the third aspect of asserting the outcome as success or failure, sometimes it is not clear whether it has succeeded or failed because of some small state changes that we do not know how to check. So a suggested way is to have extensive logs, these are also called as the structured logs. While logging we put debug messages, information messages and error messages. There is another category that needs to be added, these are called test messages. In a structured log with test messages, it becomes easy for us to go and check the log and ascertain whether a particular test case has passed or failed.

These are ways how a developer can help testability in test automation – by facilitating invocation and assistance in assertion of outcomes of test result.