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.
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.
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.
Building QA into your SDLC is key to delivering quality. Here are the mistakes to avoid when building quality throughout the SDLC.
Organizations need conceptual and QA has crucial strengths to effect that change. Here are three winning action plans to change your QA culture and integrate it with the rest of your SDLC.
DevOps implementation involves shifting the attitude of not only QA but all roles in a team. This takes a considerable amount of effort!