A tester among developers, or Alice in Wonderland
The article by Anastasia Kotsevisch was published on Stickyminds. You can also read it here.
Anastasia Kotsevich is a QA Team Lead at a1qa with 3 years of experience in Testing and Project management and more than 6 years of experience as an IT-coach. She used to manage the team of more than 10 people and specializes in projects with complex business logic, financial technical analysis in corporate ERP-systems. Anastasia is also a frequent speaker at international QA conferences and the local QA Academy.
I have a question for testers: Have you ever tried working in the same room with coders? I expect the majority of responses to be “no”. It’s really no surprise, considering testing is most commonly performed in a separate location.
That’s why, when I faced an opportunity to work such an environment, I was hesitant. I wanted to take on this task but, to be honest, I was afraid. I didn’t have to move to another city or country, or even another building — I just had to go one floor up — 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 contrary, very smart. I wasn’t sure which one is worse.
I felt that I entered a hostile environment; I thought they hated me from the get-go. I can’t say I blamed them. After all, my job was to disrupt coders’ quiet lives by finding bugs and issues in their code. Who would appreciate that?
The first point in my plan was to understand the project clearly in order to not ask stupid questions and annoy the coders with “under-bugs”. However, that group of projects seemed extremely complicated, and the field — financial analysis — was unfamiliar to me. I decided to ask the developers for help.
Unfortunately, I did not get any assistance from the coders because they 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 a part of the team.
Looking back, I realize that it was the moment we discovered the first rule of the teamwork: try to sort it out together! The earlier you understand this, the better code you will make up and the more effective tests you will get.
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 discovered one of the most important things: I learned that developers and testers perceived defects differently. While testers might think they knew what field would be of the highest interest to coders, they were wrong. Each developer focused on a different part of the defect, often unaware of the fields presented in the description.
Read the second part here.
