Intro

This is the first of a series of posts relating to Quality Assurance, automation testing and automation engineers. But if this is not your discipline, don’t worry! You too can enjoy this series as you may find it to be both refreshing and educational from a professional, business, and technical perspective.Just a quick note, the term “automation” or “automation testing” can mean many things to different people or companies. If you don’t clarify what you mean, then people make assumptions. It’s like telling your family or friends that you’re in IT. You want to be specific, but they have probably already made the assumption that your monitor looks like the Matrix with the green characters coming down the screen. The alternative is to default to the “I do computers” explanation since, apparently, everyone knows what “doing computers” entails. For the purpose and scope of this series, automation testing refers to UI/UX (user interface/user experience) functional and regression testing primarily with a programmatic approach, although many principles in this series can still be applied to GUI (graphical user interface) approaches if that’s your thing.

Domain Knowledge

Now, this may seem like a no-brainer but it should still be stated. It is possible to manage a project, develop features of the application, or mark issues as complete through testing and still not be intimate with its business rules, workflows, and overall character. Your level of knowledge becomes extremely evident when conducting client demos, writing acceptance criteria for user stories, or simply communicating with teammates about the project. This is an important responsibility that is shared among everyone on the team. Not being intimate with the application, especially in a collaborative environment, is just as frustrating to the team as having a roommate that consistently “forgets” to take out the trash. Everyone in the house can smell it. If they don’t, they will soon. And everyone knows that it’s your week to take it out. Don’t be that guy.  Be responsible. Be accountable. Know the application.What are the main features of the application, you ask? Well, like we discussed, you should already know this, especially if part of your job description is to also perform manual testing.  All of the features have to go through you anyway before they are considered to be done, right? ...Right? And as you’re doing this throughout the development lifecycle, you are gaining domain knowledge! Having this knowledge goes a long way and it promotes at least three different qualities within the automation tester (not in any particular order):

   
1. Professional equity and ownership of the application - The bearer of the domain knowledge should view their work as a continual investment into the life of the application and into the relationships built between teammates, project managers, and clients. Generally speaking, greater investment leads to greater influence in a collaborative environment for decision making.  In addition, since writing test scripts almost always requires you to go through the steps manually in the application (we’ll address this in a later post), you as an automation tester can easily become a subject matter expert. This unlocks the door for you to potentially drive demos with clients, lead training sessions with end users, and assist co-workers with on-boarding. It is at this point that you can tell people to put some “respek” on your name. This continual investment as a subject matter expert should prompt even automation engineers to cross their arms in white long-sleeve shirts with a sense of ownership over both the application and the testing scripts.
   
2. Well crafted and more targeted automation scripts - Having a great understanding of the character of the application means that you also know the happy and not-so-happy paths in addition to the peculiarities and quirks of certain pages or workflows. This knowledge is extremely helpful for automation testing as it provides a clear path for how the test scripts should be written and a clear identification of what the target or goal is. If you need to provide an email address on one particular form, will you need to assert its persistence four pages later? Are there any dependencies that need to be present before the actual test can run such as account registration or a full shopping cart?  You see, without knowing the application, you’re writing tests in the dark which costs time and helps no one.
   
3. Greater empathy and integrity in testing - Empathy is at the heart of what we do here at Smashing Boxes, even with automation testing. We cannot be empathetic if we are not intimate with the domain knowledge of our clients’ applications. While part of our success is based on writing stable and maintainable test scripts, the larger success is based on providing greater assurance of integrity and reliability of applications to clients and greater value and satisfaction to the end users. We want all of our clients to succeed in their endeavors. With that said, we can write the best automation test scripts anyone has ever seen. But if we overlook the priorities and concerns of our clients, then we have failed in our work. Our clients are serious about their projects. And our team at Smashing Boxes are seriously empathetic, even in our automation testing.

Key Takeaways

   
• Be responsible. Be accountable. Know the application.
   
• Greater investment leads to greater influence in a collaborative environment for decision making.
   
• Without knowing the application, you’re writing tests in the dark which costs time and helps no one.
   
• You cannot be empathetic if you are not intimate with the domain knowledge of your clients’ applications.

Up next in the driver.get() series! - QA Automation and Value.Darrin Whitley is a QA Automation Engineer at Smashing Boxes, providing functional and regression, manual and automation testing support in Java/Kotlin.