Dear Developers,
I just wanted to let you know that despite common belief, QA is not your enemy! I know - some days it may seem that way. Admittedly, sometimes I do feel giddy when I find a particularly good bug, but it's just what I do — it's nothing personal.
However, I think we need to have a chat. I have a bone (or three) to pick with you.
Over the last decade (cough, or more) I have worked with several types of engineers. I will say point blank that the most difficult person to work with is the developer who thinks only the tester owns the quality, and is known as The Hotshot. (See "The Seven Types of Software Engineers" if you need to know what kind of engineer you are). Most of this letter is dedicated to The Hotshot.
To the other engineers with whom I've had the absolute pleasure of working with (many of you fall under the category of 'The Great One' in the aforementioned link), those of you who stay up with me testing, see value in QA, and work with me to define tests up front — you may skip this (or read on to see my life with other engineers).
To those of you who like to just kick a feature over to QA and proclaim yourself finished... please read on.
The team owns quality. Period. Not just the QA on your scrum team. When you were late delivering your code, and I asked for help in testing because we had the same deadline to meet (and five weeks less time of testing to do it in than planned), you said your time was not worth the company's money because your salary was higher than mine. (Sidebar — How could you know that? And yes, that has in fact been said to me).
Since you would not help me, I spent weeks working past midnight. I found a lot of bugs, which leads me to my next point.
Your code is not perfect. Even the best engineers I have worked with are not impeccable. And the more you act like your code is perfect, the more I will set out to prove you wrong. Do you know that we look at which developers worked on which features, and see how many bugs have been reported? We do this for a couple of reasons: (1) to identify areas that are complex or buggy, and spend our resources there, or (2) to see if an engineer is constantly submitting buggy code, and we'll spend more time testing what that engineer touches. Don't make us do the latter. We don't like it. If you work with us on building a unit-testing culture, we can try to avoid that! I know which developers I need to do more testing for, and I know which ones I can trust. Be one I can trust.
Remember when we first started the project? I wrote up the tests I believed had to pass, and went through unit, integration, and acceptance tests line by line with you? Did you write any tests for your code? I promise you I did not do this for my health. I did this to help you develop code that is solid. (Build until those tests pass, then check it in.) But what actually happened after that effort? My team ended up running all of those tests manually. Long after we should have. And the code broke. A lot. Yes, some of this is on me. I should have had a better system in place to ensure you were writing the tests we agreed to. Mea Culpa. I'll be fixing that next sprint.
On the bright side, your lack of writing unit and integration tests and sending me buggy code has given me a bit of job security!
Phew! It feels good to get all that off my chest.
There’s more, but I don't want to scare you away. I don't hate you. In fact, I really love working with you, even during the challenging times. We can fix this and make a great team. As we march on towards Continuous Delivery, we are going to have to, or we will both fail.
While I may not be your dev manager, I know all things. I am the Eye of Sauron. (Ok, not really, but I do need to know what you are doing, when it will be done, and any issues you run into, because it all impacts my team). While you may be focused on a single user story, I am right there with you, but I'm also 30,000 feet up looking at the broad landscape of how that story fits into the overall epic and the release as a whole. I know obscure places I may need to test based on anything you are building, and I will tell you ahead of time that I'll be checking them. Before you submit your code, run the test we agreed needs to pass, and don't consider work complete until it passes. Simple, right?
Understanding quality and the testing culture is key to us working better together.
In Jerry Maguire, Ron Tidwell told Jerry, "Do Your Job!" Let's be a team. I'll help you do your job (delivering good code), if you help me do mine, and own quality too. I know it can be done. It must be done. Help me help you.
Cheers, Ashley
Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.
T: @aahunsberger
