Software Testers Diary: Building Credibility in the Development Room

This is a guest posting by Carol Brands. Carol is a Software Tester at DNV GL Software. Originally from New Orleans, she is now based in Oregon and has lived there for about 13 years. Carol is also a volunteer at the Association for Software Testing.

It has been a few months, and I still have anxiety about being the only Software Tester in the development team room. There are 8 of them, and 1 of me. I’m worried that I won’t be able to prove my worth, or that I won’t be able to keep up. I’m concerned that this whole experiment will fail and I’ll only prove how useless testers are instead. I think more than I should, about ‘proving’ myself, especially as a non-coding tester.

Transition to The Team Room

Software Testers Diary: Building Credibility in the Development Room

When I was working in my own office, I didn’t really need to know much about how the program worked. In my new job, Software Testers are expected to know what the program is and isn’t supposed to do. Furthermore, the Testers are required to state why the current behavior didn’t meet expectations if there is a problem. Learning the technical details came naturally to me. I always enjoyed learning how things worked, so that I could do a better job of understanding the program and explaining what was going wrong.

Things are different working in the team room. Our development team has been working with a technology that’s relatively new to them, much less to me. We used to use relational databases and synchronization on our flagship client-server system. On our new projects, we’re using a document database, message queuing, and an event store to transmit and store data. Before I started working in the development room, I worried a lot more about ‘is it working’ or ‘is it not working’. Now that I’m here, it seems a lot more important to be able to fluently talk with developers about how things work.

Learning Experiences

Software Testers Diary: Building Credibility in the Development Room

One of my biggest focuses has been learning how to use the tools available to me to work through unexpected behaviors. I typically start by looking at the event log generated by the system. When I report a problem, the logs are the first thing the developers will ask for. I’ve also worked hard at paying attention to the other things the developers walk through when examining a problem. I’ve learned how to examine the document database and figure out which documents store data that will be displayed, and which ones are for data that’s used internally. I learned how to examine the message queue audit log to identify what messages have been sent, and what content and header information to expect in those messages. Finally, I’ve learned how to use the event-store to identify all the actions that have been taken against a particular object.

I didn’t know today was going to be the day that I proved my abilities with these new tools. It happened without even thinking about it. I found a good juicy bug, a result in the UI wasn’t what it was supposed to be, so I traced it as far as I could on my own. I called over the product owners who have been reviewing my work, in this case the Lead Developer and Architect. I showed them the problem in the UI, then I shared the error log that indicated the wrong messages had been received. I guided them to the bad results that I found in the database, then I showed them what was in the message queue audit log. I examined the message headers to get more clues about what had gone wrong, and traced the messages in the event-store. I overheard the Architect tell the Lead Developer, “Wow, you see her fly through these tools? She knows what she’s doing with this stuff.” with the Lead Developer responding “Yeah, this is impressive.” Something about that conversation happening right in front of me gave me a huge boost of confidence. By the time we were done, it was obvious they knew I had found something good, and they were really impressed.

I moved through the tools quickly because I had spent hours figuring it all out before showing them; I don’t know if they knew that. Even so, being able to find problems and chase them deeper than the UI feels like a remarkable feat. Something that a useful tester would do. I might keep pushing myself to do even better, because I’ll always want to prove myself, but I’m feeling a lot less worried about whether I’m useful today.

In This Article:

Try a 30-day trial of TestRail today!

Share this article

Other Blogs

Building a Modern QA Team With T-Shaped Testers
Agile, Books, General, Software Quality

Building a Modern QA Team With T-Shaped Testers

The role of QA is changing—fast. Agile workflows, DevOps, and CI/CD pipelines have raised the bar for what’s expected of software testers. Today, being a specialist in just one area isn’t enough. Teams need people who can wear multiple hats, jump into differen...
T shaped tester
Uncategorized, General, Software Quality, TestRail, Webinar

Competing in a Modern QA Job Market: Insights from the T-shaped Tester Webinar

The QA job market is evolving rapidly. The rise of Agile, DevOps, and shift left methodologies demands a new breed of tester—one who combines deep expertise in specific areas with broad knowledge across various domains. This shift has paved the way for the con...
Key Factors to Consider When Selecting the Right Test Case Management Tool
General, Software Quality, TestRail

Choosing the Right Test Case Management Tool: Key Factors

Understanding the need you have is often the first step in defining the method for managing test cases that will work for you and your team.