The Power Of Why

The Power Of Why

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.

  • Top articles, research, podcasts, webinars and more delivered to you monthly.

  • Leave a Comment
    Next Post

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    IoT & Automation
    Could the IoT Help End Hunger? Farmers Are Finding Out

    Internet of Things (IoT) gadgets are everywhere. Cars, buildings, roadways, airplanes, home appliances, and other items have tens of billions of sensors, processors, and internet-connected gadgets. IoT devices detect motion, regulate temperature, share and collect data, measure weather, and provide location information, power logistics, and medical research. They also enable self-driving vehicles, to name just

    5 MINUTES READ Continue Reading »
    IoT & Automation
    10 Biggest Opportunities for IoT Innovation in 2021

    IoT is a powerful economic driver. IoT Innovation is actively shaping businesses and consumer trends. Most of the technologies developed before and during the pandemic address the Internet of Things directly or indirectly. From healthcare and retail to automobile and manufacturing, IoT innovations are opening new avenues across industries.  It covers almost every segment of

    8 MINUTES READ Continue Reading »
    IoT & Automation
    10 Things to Consider When Starting an IoT Project

    One of the biggest issues companies face when starting an IoT project is deciding who should be responsible. Should it be the engineering team that is responsible for the core technicalities of the device, or should it be the product management team that is responsible for the end functionalities of the IoT product? Starting on

    8 MINUTES READ Continue Reading »