Understanding a client’s expectations and needs is a large part of what we do here at Envoc. Offering custom solutions and providing solid, professional service depends on the entire team crafting each project with care. For the testing team at Envoc, internalizing the needs of a client helps drive our efforts and provides the vital context we need to make the call of whether or not we have succeeded in creating something of value.
For those of us in the software quality assurance role, it is important to have a good grasp on a project’s acceptance criteria and technical expectations to ensure that our testing is productive, directed, and uncovers the nasty little experiences we’d rather spare the user. In the increasingly mechanical world of automated testing and planning, where does the human element fit into ensuring the quality of our products? Beyond the obvious answer of “Well, somebody’s got to make those tests…”, consider the following scenario: You’ve just sat down with your team and the client to showcase new features for a project that you’ve spent time testing. As the application fires up and the client sits across the table, fingers crossed, ready to be wowed, the first evidence of your testing efforts is shown. The client company’s logo in the corner of the application is proudly displayed with the word “Widget” in “Bob’s Widget Company” no longer pluralized. On the next screen, the developer running the demo clicks the small magnifying glass icon next to a search field to initiate a search for a specific widget. Lastly, the dimensions for the widget have listings in metric equivalents. The rest of the demo goes well and the client is amazed. These examples may seem quaint, but they illustrate a few of the things that can happen when you allow an element of personality into the testing process and connect with the product and client in a few different ways.
The first example is the simplest, getting the client’s logo right on the project and other documentation. It might seem obvious, but little things like these demonstrate that you and your team are engaged and interested in the client’s business. You’ve reviewed the client’s correspondence and make them feel secure that they are heard and listened to. In the negative case, such a simple slip up like spelling in a logo can have long lasting consequences. Depending on the client, they may feel slighted or even outraged. They’ve spent so long building their brand and business, and now the people they are trusting to improve their business with custom software products can’t be bothered to get the logo right.
…little things like these demonstrate that you and your team are engaged and interested in the client’s business.
The second example is a bit more personal. In the example above, the reason that something as simple as being able to click an icon to initiate a search is so important is because that client expects it. Let’s say that you’ve worked with a client previously and one of their peeves is that they expect that anywhere there’s a search box with an icon, it should be clickable. By knowing this and taking it with you into other projects for that client, you’ve connected with them on a personal level and learned likes and dislikes that aren’t technically bugs. Connecting with a client in this way and taking the time to learn these things speaks worlds about your team and goes a long way to improve the overall quality of the product and establish a relationship of trust with the client.
The third example, realizing that dimensions on widgets should also be listed in their metric equivalents, is an example of connecting with the client on a professional level. You’ve learned that the client’s business has many participants that rely on those metric equivalents heavily, so being able to see them at a glance is very convenient. Connecting in this way involves learning the ins and outs of the client’s business, such as jargon, certain technical details, and even how and why the business operates. You should never contend to know as much or more than the client (they are experts in their field and you’re an expert in yours), but a healthy understanding of their world can increase your knowledge of how to properly test an application and how and why certain expectations are established.
In all of the above examples, the tester has connected with the client and placed themselves in their shoes as they are using the product. They are striving for user emulation, that is, the ability to place yourself into the end user’s position as you are using the program and relying on the combined personal and professional knowledge to establish expectations and look for ways that the program varies from this. This type of testing goes hand in hand with functional testing. If you are going through a workflow that makes you pull your hair out, how will the client feel when they have to do it dozens of times a day? It may very well be completely solid and functional, but it doesn’t live up to the client’s expectations. By assuring that a product does fulfill your client’s total needs, you become an advocate for the product. You’ve placed yourself into the client’s own world and stand with them, not apart from them.
Every member of a good team will do this, but as a tester with the unique responsibility of controlling what the client will see in the end, your knowledge driven suggestions and change requests will play their part to ensure that at the end of the day you have a better product, better quality, and a better relationship with the client than when you first started.
