Let’s talk about the importance of Why and what it represents. The Merriam-Webster dictionary defines Why as “the cause, reason, or purpose for which.” Asking Why gets at the cause of the problem. The Test Automation Engineer (TAE) already knows the effect. The automation produced a failure. Something did not go according to plan. So, let’s focus on the cause.
Ultimately, this sums up what it is to be a TAE. Determining the cause of a failure offers so much valuable information to the organization. Not asking Why will harm the organization over time. TAEs are charged with digging deeper, figuring out what went wrong, and asking questions. They must ask Why.
TAEs develop and run test automation. That is a simple enough statement but does not sum up the possibilities of that role. We test software to ensure that the product going into production helps customers to do the job of the business, whatever that may be. The business suffers if the software is not usable.
All too often, due to misunderstanding, environmental, or other factors, TAEs are relegated to the simplest form of test automation. This step in the system development life cycle can be viewed as just another obstacle on the way to production. TAEs create the tests, execute them, and then report the passes and failures. A role that has so much potential quickly is reduced to limited responsibility and involvement. The reasons are numerous and vary with each IT department. The rationale can range from complicated to simple. It could be due to a bad relationship between testers and developers, lack of management support, or simply not enough time built in at the beginning for testing. By asking Why, the TAE opens themself up to learning on many levels they may not have realized.
First, the test case can be reviewed and explored. Each step outlined in the test case has meaning and, in some cases, required data. Now the TAE can explore the application to see how it reacts to various inputs. As the TAE digs deeper, he or she learns more about the screens that are included in this test case and how they are meant to be used. At the end of this exercise, the TAE puts together a high-level picture of the business process.
Now is a great time for the TAE to reach out to a business analyst (BA) or other contacts they have in the business units. Through these conversations a TAE learns how the business users interact with the software to do their jobs. The TAE can see how software defects affect daily activities, and even if there is a workaround, how that hinders the business users from completing their jobs. The entire exercise has increased the TAE’s business knowledge and made them a better test developer.
The time and effort spent also familiarizes the TAE with the test suite and its numerous test cases. Some suites are small and concise while others contain hundreds of test cases. Understanding what functionality the suite covers is invaluable information for the team they support, and enhances the credibility of testing generally, and the TAE specifically. For example, the TAE acquires the necessary knowledge to answer questions about regression cycle coverage in conversations with team members.
Up to this point, the TAE has reviewed application screens and learned how the business units interact with those screens. Now the TAE can turn toward more technical items, such as investigating why the page works the way it does. The TAE already knows what the business user wants to do on that screen; now, why does it work the way it does? The TAE can dive into the objects on the page, and see what tags and IDs are being used. He or she can speak with the developers about style and evaluate the HTML that will be referenced in the test automation.
Time spent with the developers builds rapport and even can help solve the relationship issue mentioned earlier. By talking together and asking Why the TAE demonstrates interest and has the opportunity to explain why the coding of a table, for example, is better for the test automation in one coding style versus another.
Simply by asking Why, a TAE is seizing the opportunity created by a failed test case. Failure gives the TAE a tremendous chance to investigate and, more importantly, learn. It gives him or her the opportunity to be taught how things work by hearing from business users about the screens they use and processes they follow, talking to members of the agile or project team to learn more about the design of the screens in question, and talking to the developers to see how they coded the screens and built the applications. Every conversation that starts with asking Why puts the entire picture together for the TAE.
The power of Why is too important to skip over. Go ask Why and learn.
