Get Back in the Game with these Post Summer Tips and Stories!

Written by PRAKASH SODHANI for Software Test and Performance Magazine - www.stpmag.com

In a surprising number of the organizations I have worked in, software testing was considered a luxury. "If you have time, you might do some testing," I might hear. Or else, "whatever can be done in the stipulated time is good enough" might have been the directive. From what I've seen, many large companies no longer employ domain experts for software testing, but instead now favor computer programmers who are willing to test. I believe this is a mistake. Testers rely not only on domain and technical expertise but also on people skills, which are useful for working through requirements and test cases with analysts and users. Rare indeed is the developer equipped to handle such potentially volatile situations as these.

I once read an article by Harry Robinson, a test architect in Microsoft's Engineering Excellence Group. In "Bumper Stickers for Testers," Robinson said the things we testers frequently say about our work reflect the pride we have in our profession. That article got me thinking about the times I've been happy when someone appreciated my work, as well as times when I've been frustrated. There have been remarks that have made me furious, and others that are so absurd as to be laughable.

All that thinking led me to this article, which is a compilation of comments I've heard over the years, many that are reiterated nearly every day. If you haven't heard some of these things yourself-from coworkers, developers, team leaders or managers-then you haven't been a software tester very long.

1) " There's nothing wrong with my code. Check with the other developer."

Often you will work with more than one developer. If you're lucky, at least one will have done some unit testing before tossing the code to the QA team. But even when they do, they often forget to test their code's integration. Sure, features might work as expected in isolation, but when you try to test end to end, you start seeing issues. One developer refers you to the other and thus starts the vicious cycle.

Even more frustrating is that once the flaw is tracked back to the first developer, he politely says, "My bad. I forgot to do one thing. I'll fix it and let you know".

ADVICE: Ask the developer if they've done their unit and integration testing.

2) " Can you show me the defect?"

Applications differ in complexity, and some take longer to test. One complex application I recall testing had multiple paths to be tested completely. I found that somewhere around the last step, I wasn't seeing the expected result when using one particular set of data. I tried with another set, just to see if I could reproduce the result, but it turned out to be happening only for the first set of data. I opened a defect, assigned it to the developer and proceeded to test other functionalities.

After a few minutes, an e-mail from the developer popped up asking me to come to his desk to reproduce the issue. I generally wouldn't mind doing this, but why did I even bother documenting all the "reproduce steps" and attachments in the defect's description? Visiting the developer sidetracked me from what I was doing and wasted both our time.

ADVICE: Ask the developer to try to reproduce the issue using your documented steps and to contact the tester only if something other than the issue arises.

3) " This shouldn't take much time to test."

Have you ever told a developer that a particular feature shouldn't take more than a couple of hours to write code for? Probably not. But developers certainly know how long something should take to test, don't they?

It amazes me how people with multiple years of experience in the industry still don't understand that testing might not be their domain. Suggestions about how to test are one thing, but to state that such-and-such a feature shouldn't take a lot of time to test is like saying "I know this feature works. You just confirm it." Depending on the issues involved, even a simple "Login" might take more than a few minutes.

There is no way I can say "it will be done in one hour." It all depends on a tester, how deeply they test and whether unforeseen circumstances arise. But when you know that people around you will become angry if you take more time than they think you need, your tendency might be not to test at all or not to test deeply, or thoroughly, enough.

ADVICE: When possible, don't agree to arbitrary testing timetables. If asked for an estimate, take your initial guess and triple it.

4) " This was working yesterday, and I haven't changed anything."

You have a list of test cases you want to execute before the deadline. You finish the list and go home assuming that everything is done. Your plan for the next day is to perform a last-minute smoke test and then send the "Testing Complete" message to all the stakeholders.

But that plan falls apart when you discover that your primary test cases are no longer working. You tense up-many of the other test cases depend on the result of your primaries. The developer, as expected, claims that nothing has changed since last night.

You frantically begin running all the test cases again to see if others have the same issue. Several hours later, you get an e-mail from a developer that a build was deployed the night before, and that since it was "not expected to affect anything," only developers were notified. The result was unnecessary frustration, anxiety and wasted time.

ADVICE: Insist that the test and/or QA departments be on the notification list for all new builds.

5) " Why test it that way? That's not realistic."

A good tester comes up with a variety of scenarios to break the application under test-to think of potential situations before hearing from the user. Some test cases might sound improbable, but whoever thought someone would mistake a computer's CD tray for a drink holder?
One application I was working on had a simple "Login" page that threw an exception when I entered special characters in the user name field. When I told the developer, he asked, "Who in the world would put special characters in the user name field?" Under normal circumstances, no one. But someone might do it by mistake, I said, and we need the application to handle it gracefully.

ADVICE: Conduct your tests based on what is possible, not what is probable. Given enough time, if something can happen, it will happen.

6) " Test it this way, with this test data."

In one of the companies where I worked, there was very little documentation. To learn what and how to test, I was expected to track down and speak with the subject-matter experts to get the information I needed to get started.

Eventually, I found myself testing a database application, but again, there was no schema or documentation to write queries against.

I had to ask a developer, who told me he would send me the SQL queries and data that I would need for my testing.

That's right. I was told to use what the developer sent me, and to say that "everything looked good." Not surprisingly, the testing finished on time and everyone was happy.

ADVICE: Sometimes you just have to do the best you can with the hand you're dealt.

7) " It works on my machine. Something must be wrong with yours."

Surely we've all been in this situation: Something works on your computer, but when you try to reproduce it on someone else's, you can't. Here's an example: While performing some function testing, I saw a bug and opened a defect. After some time, the defect was sent back to me as "unable to reproduce," but I was still able to produce the issue.

Instead of going back and forth through the defect tracker, I went to the developer's desk to discuss it. He showed me what he was doing, and at first he seemed right. He told me to check if I was doing it right on my machine. Then I realized that the developer was verifying the bug on the "development" environment rather than on the "test" configuration. I pointed that out, and sure enough, he was now able to reproduce the issue.

ADVICE: Don't assume that the developer has read your defect documentation completely, pulled all the right levers and set all the right switches. Sometimes developers overlook the basics, just like we mere mortals do.

8) " I know that scenario doesn't work, but how's the application overall?"

Test cases and defects usually have priorities attached to them. Higher-priority defects get more attention and generally must be fixed before the product is deployed. It's one thing when a test case is assigned as high-priority by the QA team. It's another when it's done by a developer.

I once found myself testing an application that sent an e-mail to support personnel when a customer ticket was opened by the sales team. The app worked fine when a valid e-mail address was entered or when an e-mail address was selected from an address book. But I didn't know how the application was supposed to behave if the address book was ignored or if an invalid e-mail address was entered manually. The developer didn't know either and asserted that people would always use the address book feature.

So even though I knew that at least one use case wasn't settled, I was asked if everything was alright to move to production. I was told that this test case had a low priority.

ADVICE: Every defect should be documented, regardless of priority. That way, a fix can be on someone's "To Do" list and that part of the application (as well as the tester's backside) is covered.

9) " Try to reproduce the issue multiple times before you open a defect. If it only happens once or twice, I can't do anything about it."

Developers occasionally get irritated, and sometimes they let you know it. In one such situation, I was new to a project and my only source of help was one of the developers. I thought e-mail was not the best avenue for questions, so I tried using instant messaging instead. After two or three sessions with the developer, I received an e-mail from the project manager directing me to go through him with questions. I got the message.

Later on during that same project, I found some issues that I wasn't able to reproduce consistently; the defects might appear twice in five tries. When I mentioned this to the developer, he said it was probably a one-off thing and suggested that I focus on other issues.

ADVICE: Document the issues and move on. Prioritizing defects is not generally the tester's job, so it's probably best not to waste time forcing an issue.

10) " Sorry; I forgot to deploy my code in that last build. You'll have to wait before testing."

This is a classic that I have seen quite often: You start testing after a new build and an e-mail appears telling you to stop testing for one reason or another.

ADVICE: You can change only the things that are within your control. If stop orders are a part of your environment, changing your attitude toward them might help reduce the frustration they cause. Rather than viewing time before the order as wasted, look forward to receiving a better build that might contain fewer defects.

Here are some more:

11) Don't worry about this. Try the other scenarios.

12) I know I delivered the code late for testing, but everything looks good to me. When can I move my code to production?

13) I tested this functionality during development. It looks good.

14) There's no documentation for this functionality. Let me tell you exactly what you need to focus on.

TEST AUTOMATION QUOTES
(To view the rest of this article, please go to www.stpcollaborative.com)