A Tester among Developers: Life beyond the Code

By: Anastasia Kotsevich

Summary:
Tester Anastasia Kotsevich got the chance to work side by side with her company’s coders. This experience opened her eyes to some problems she wasn’t aware of before, and some solutions: designating a common team goal and opening clear lines of communication.

I have a question for testers: Have you ever tried working in the same room with coders? I expect the majority of responses would be no. It’s really no surprise, considering testing is most commonly performed in a separate location.

That’s why, when I was faced with an opportunity to work in that type of environment, I was hesitant. It wasn’t that I did not want to; if we’re being honest, I was afraid. I didn't have to move to another city or country, or even another building—I would only be going up to the floor above—but I expected to be like Alice in Wonderland, falling through a rabbit hole into the strange world of coders.

I halfway expected to see Supermen controlling computers with the power of thought and correcting defects like cracking nuts. I was very much afraid that they would find me silly—or, on the other end of the spectrum, very smart. I wasn’t sure which would be worse.

I entered what felt to me like a hostile environment; I thought they hated me from the get-go. I can’t say I much blamed them. After all, my job is to disrupt the coders’ quiet lives by finding bugs and issues with their code. Who would appreciate that?

The first item in my plan was to understand the project thoroughly in order to not ask stupid questions and annoy the coders with "under-bugs." However, this group of projects seemed extremely complicated, and the field—financial analysis—was quite unfamiliar to me. I decided to ask the developers for help.

Unfortunately, I did not get any assistance from the coders because they really weren’t any more familiar with the business logic than I. But making an effort to “speak their language” when asking for help made it easier to become part of the team. Looking back, I realize that was the moment we discovered the first rule of teamwork: Try to sort it out together! The earlier you understand this, the better quality code you will possess and the more effective tests will be later.

The second point of my initial plan was to provide a flawless description of defects. I was pretty confident that well-described defects wouldn’t be too annoying for programmers. That is why I wasn’t hesitant to share the first bug I found, clearly describing fields and algorithms, providing informative attachments, etc.

Imagine my surprise when my new colleagues started to ask questions regarding this “ideal” defect. At that moment, I made one of the most important breakthroughs: I learned that developers perceive defects quite differently from testers. While testers may think they know which field would be of the highest interest to coders, the truth is it differs from one developer to another. Each developer focuses on a different part of the defect, often unaware of the fields present in the description.

It would be unfair not to mention risks that can trap testers who work side by side with developers. For me, the description of the defects became the most serious risk. Sometimes, testers try to save their time and efforts by discussing defects directly rather than receiving detailed written reports. That said, as new developers and testers join the team, having clear descriptions is important to get them up to speed.

Initially, I even tried to adjust the testing strategy depending on the specific functions of the developer. Fundamentally, however, this is not correct, as sooner or later, it will lead to missed defects.

The first time I found myself in the epicenter of a developers meeting, I felt like I was in another country.

Full article...

Other Resource

... to read more articles, visit http://sqa.fyicenter.com/art/