To date I’ve spent a couple years now in the software development industry. First 2 years was as a tester and leading the QA department of a great little start-up, while in recent months I had made the move from QA tester to software developer.
During my time as a QA specialist I had to learn a lot of things fast. A few of these things included effective ways to test code, and effective ways to communicate the defects I found to the development team. The latter, I learnt, required a bit more care than the former.
I didn’t know this or fully understand it at first, but there are 2 very distinct mindsets between QA and developer. Not understanding can make both jobs on both sides of the fence incredibly frustrating. Testers, and this was myself admittedly, could easily become frustrated with code that they are given which is often buggy. We think to ourselves, is it really *that* hard to follow the most basic of requirements and give us something which works?
But that attitude, while arguably fair since developers are expected to have a level of responsibility and professionalism, can often be destructive between the QA and Developer relationships. I learnt that, as a tester, being able to manage this relationship is important, and that developers minds are different to QA minds. The biggest difference I find is..
Testers want to destroy. Developers wish to create.
If you look at both of these roles at a very basic level, you will see that their motives couldn’t be any more different. As a tester, it is your job to scrutinize, poke, and destroy. Not until you have done any of these things with successful results, you will feel unfulfilled in your role.
As a developer, on the other hand, it’s all about creation. Making something functional from nothing. To take what is often bare instructions and make something usable and interact-able. As a developer, if you are not able to make something which can be used and meets some level of the specified requirements, you won’t meet your role-fulfillment level.
In QA, sometimes it’s easy to forget about that creation and the pride that goes into it. As a tester we would, maybe unfairly so to a degree, just expect certain levels of quality consistently. We often forget the challenges that go into making something. From the planning, to the researching, to the development.. it can often be a lot of work. And often this process is pushed with deadlines. (of course these high-pressure deadlines can be addressed with better project management, but that’s a talk for another day)
I am not trying to defend developers who submit buggy code. And I am reminded of a well written piece from Robert Cecil Martin about being a ‘Professional Programmer’, which encourages one to be a more responsible developer. And while I believe all developers aspire to be ‘the Professional’ in their field, I think it’s safe to say achieving that status is an ongoing aspiration and challenge for most.
If there is one thing that is certain, is knowing that there is no such thing as ‘bug-less’ code. Bugs will *always* be found, if not by your users, then hopefully by your testers. And testers need to be able to communicate and manage these findings a bit more mindfully. Just as a Developer can, and should, be responsible in the quality of his code, the tester can apply the same level of professionalism with their reporting. And a good, midful report, whether a professional report for the end of a development cycle or just a casual bug ticket, can go a *long* way and can be far more appreciated by developers with the right tact.
There is actually an interesting psychology behind the QA-Developer relationship and you will see there is quite a bit of discussion around this on the web. While testers get a level of joy in finding bugs, which can result in a level of excitement or achievement, as a developer hearing a ‘Yes! Found one!‘ coming from the QA team can sink a couple hearts. Making bugs is not really part of the developers expectation, but finding bugs is definitely a big part of the testers role, so there will always exist an overlapping of success/defeat on both camps when the one side does a better job than the other.
There is various ways that testers can ‘break’ the news to developers when a new bug is found. The main idea is to not associate blame. Blame indicates a level of failure and if you want your developers to respond a bit more openly to your 10-step edge case defect that you found, knowing how to remove the negativity around finding a problem is a great skill to have.
From Tester to Developer. Managing Multiple Disciplines
Having been a tester, and now being a developer, you would think I would immediately be an unstoppable force. In a perfect world my code would be legendary, and the testers would love me because they would always know that my work would be thoroughly tested, just as they would have done themselves. But it hasn’t been like that. At least, not as my first few months as a developer.
You see, just as I had to learn a lot becoming a tester, adapting the mindset and understanding the principles, so have I been learning a lot as a developer, and understanding their mindset too. I am beginning to feel that pride of creating something new. I feel connected to it. Close to it. Proud of it. That I don’t *want* to break it, as I normally would have been required to. These two mindsets are now at odds with each other, and finding the balance has been a new challenge.
I wish I could say that my code has been perfect, and that the QA team does love me, but learning a new skill, such as development, will never be smooth and so I have made my handful of mistakes and committed a few breakers. And when a bug gets logged against me, I feel like I not only let the QA team down, but myself down too for not having put on my QA hat sooner or for longer. That I should have known better. But I need to learn to accept that managing two internal disciplines is not going to be easy, especially doing so while learning something new, and I just hope that as I become more comfortable in my developer role, that I can find equilibrium between both mindsets and be one step closer to a ‘Professional‘ in either or both fields.
Ultimately it’s always good to remember that no matter what side of the fence we are on, whether QA or Developer, we all have the same goal. And that is to deliver quality products and software we are proud of. We mustn’t forget what each side’s motivations are, and what their role is, and how both are necessary to achieve that end goal.
As a QA specialist or software developer, can you say you know what goes on in your developer’s head? Or if you’re a developer, do you see and feel that the QA team don’t want to work against you, but with you? Or if you have been or are both, what other insight and knowledge can you share for the other’s that are on each side?
So knowing what I do, do I think QA and Developer’s will ever reach that perfect harmonious relationship? I think Scott Adams had summed up this possibility quite aptly.. Till that day comes though!1