Testing is Rocket Science Not Brain Surgery

To Pull the Plug or Not? Who knew the life or death of a computer would depend on a tester

“To be, or not to be, that is the question:
Whether ’tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles
And by opposing end them.” – Shakespeare’s Hamlet

Does a company choose to start a fire to prove that their fire evacuation plan is valid; something most might consider an extreme measure? Should a tester look to use extreme methods to exercise a particular test case, say an application’s data will not be lost in the event of power failure for instance? As a firefighter must practice saving lives without putting lives in danger, a tester must attempt to simulate real world scenarios, but look to do so in a controlled environment. Recently I participated in a System Test effort for a client implementing a Citrix based deployment of a client server application. While my role during this effort was to serve strictly as a human test robot under the direction of the client and not that of a test analyst I decided to err on the side of caution and question the test script based on my intuition confirmed by the advice of my peers. This effort involved testing several system requirements related to disaster recovery. One step within the script I was assigned was for the human test robot; me, to unplug the power cord from the computer while it was powered on. Yes, you read it correctly, UNPLUG the power cord. The expected result I was instructed to observe was zero data loss, when really the more likely outcome would be a hard drive crash, which would definitely lead too loss of data, just not data in the AUT.

This situation put me in quite a quandary because of the client’s lack of understanding about the technology. Should I take this opportunity to educate the client that this was not a good approach to testing this feature or should I sit back, doe as I was told pull the plug and hope for the best? I solicited advice from my team and some of our most senior technical people and the responses varied from, “Don’t do it”, to, “It’s your job to make the client look good; therefore, you must do what they ask you to do”. My belief is that a tester should not do something that risks damaging hardware or the application regardless of the request, unless that is the context we are testing under, it has it’s place, just not while testing a COTS app running on Citrix and Oracle where network connection fault tolerance is a primary feature of all of the products mentioned. Instead a tester should seize the opportunity to educate their client, boss, or team lead. The goal is to persuade those persons to explore and evaluate other approaches that are less risky in order to satisfy the test case. We’ve got to learn to listen to our inner voice, back that up with the voices of trusted resources and stand firm to at the very least give the client the opportunity to do something better than they did before.. In order to persuade them, the tester must be able to effectively communicate the risk, articulate the alternate solutions and shape the inter-personal environment by soliciting ‘buy-in’ from the individual(s) capable of making decisions.

For most testers this means using the skill that we know best, written communication. Actually investigate the risks associated with performing the task. Interview individuals, search the internet, and draw upon your own experience. Next, document the most important risks in a memo or email. Factual evidence is your best argument to persuade those who don’t agree with you, stating your points succinctly with your supporting evidence is one way to achieve this.

Second, the tester MUST offer a viable alternative solution. We’ve all heard the adage that “You’re either part of the problem or part of the solution”. The goal is to educate your audience without offending your audience. Offer solutions that are appropriate to solving the problem with the least impact or effort first. The solutions should be well thought out and have the potential to effect change. Seize the opportunity but be humble and ask questions to gather knowledge about your audience as much as you did for your solution. Anticipate the possible objections to your solutions. Deal directly with these reasons for opposition not the person or person(s).

Lastly, after you have communicated the risks and proposed solutions, it is time to request feedback and get that all important ‘buy-in’ from the individual(s) capable of making decisions. This may be the most difficult part of the process. Your communication should call for action from your audience, asking them to select one of your proposed solutions for review. It’s never easy doing what you think is right and opposing a sea of troubles, but by educating your client, soliciting feedback and gaining buy-in you can end them, their troubles that is.