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. But, just as happens in real life, after a while their language didn’t seem so foreign.
In the beginning I appeared at such meetings by chance (all meetings were held near my workplace), but it soon became clear that my presence at the general meetings was quite useful for the project. Being a part of these meetings introduced me to every single detail and often proved valuable in developing the testing strategy. Moreover, I informed team members how the code or some part of it was going to be tested, which helped to proactively prevent defects.
These communication rules are pretty clear and simple. However, it is rare that these seemingly obvious steps are executed when the team is distributed across different floors, much less different cities and countries.
All too often, IT project participants forget that developers and testers have the same goal: to deliver quality software. No matter how talented the participants of the project may be, it is unlikely to run smoothly if they refuse to work as if they are not on the same team, striving for the same result. Providing a common goal helps establish a team environment and clear lines of communication. Everyone will benefit—software developers, testers, managers, customers, and the company as a whole.