The other day I was working on an interface I didn't like. It was taking a large amount of the user's data, bulk uploading it, and choking if it wasn't formatted correctly. When that happened, the user's choices were either to give up, or to go through all their data and try to find the mistake. So I asked if I could change it. I asked my backend teammates and I asked my product owner and they all said that sounded good, but I didn't think they had a clear idea of what I intended to do. So I built it and I showed one of our QA people. He said it looked good, and I realized I should have just done that to begin with.
Not every company has QA people, and I think that's a shame. And some companies have QA people they don't take full advantage of, which is even worse. Next time I decide to take liberties with the design or requirements I've been given, I'm just going to skip asking permission and see what QA thinks. Here is why.
- QA eats the dogfood. Developers may talk about eating the dogfood, but entering "ndsjkfdksbafbdbfhjkbdkbkjfbd..." into a text box until you get the character counter to read -1 is not the same as actually writing a 500-character paragraph with, like, apostrophes. Product owners may talk about eating the dogfood, but that typically only happens at the demo, and then any revelations about the product get buried under the notes from the debate about who failed to upgrade the demo machine from IE6 and why that text is green when it's supposed to be teal. QA, by contrast, does nothing but eat your dogfood. They swim in a big old pit of dogfood, Scrooge McDuck style. No one is in a better position to tell you when your dogfood starts to taste like dogshit.
- QA does not want to read your 1000-page novel about tennis. QA doesn't care if you're using custom events or callbacks, they don't care if you write all your CSS on one line or do it the annoying way. They just want your shit to work. They are unlikely to sit there while you go on and on about your elegant fucking solution to some dumb edge case problem only .5% of the users are ever going to experience. I've found that having QA around does a lot to cut down on pointless refactoring and developer fapping in general.
- A firm no is better than a squishy yes. If your solution sucks, good lord, let's hope someone tells you before you go and do something stupid like write a blog post about it. Or ship it. Product owners, in my experience, go to a lot of meetings. You can show your product owner something and they'll respond immediately and love it. Then the product rolls out the door and your squeakiest power user fires off an angry email and you're staying at work all night removing all that drag and drop crap you added that everyone in the head office said was so cool three days before. What our heroine doesn't know is that the product owner saw her email, took a quick look at the site in the dev environment, and got as far as not seeing any glaring problems before getting yanked into another meeting. QA folks tend to not be in meetings all day. As mentioned above, they tend to be looking at your site all day. And QA folks very rarely sign off on anything without giving it a thorough review. I know from experience as I've tried to trick them and it has never once worked.
- QA does not have a fuzzy definition of done. Speaking of trying to trick QA.. I have often been guilty of telling QA that the request is right there in Firebug and therefore it is working. QA does not care about any of that. They are not impressed by your claims that you will fix that part "later" and they probably know that when you say something is "just a CSS issue" it's going to take three times as long to figure out as if it were a Javascript issue. Like duh, right? That's what they're supposed to. But I've had a lot of really cool solutions that fell apart on me because of some intractable "CSS issue" or minor edge case that I didn't think was worth worrying about. Having something ready for QA forces you to be certain it will actually work.
- It's good to have QA on your side. Project owners may spend a disproportionate amount of time talking to developers, but I think that's cause developers are needy. I suspect the people on the team they trust most are the QA folks. Product owners being harried and not-at-their-desks by nature, your precious solution runs the risk of being shot down after a split-second decision. Unless QA's got your back. If QA's signed off, your PO can probably trust that whatever crazy-ass thing you dreamed up is not breaking stuff or endangering deadlines and is much less likely to tell you to roll it back just because they don't have time to deal with it. Also, when QA tells me something I did is cool, I feel like the queen of awesome, cause those guys are hard as hell to impress.
Maybe everyone else had already thought of this stuff, but I had not. While asking the "decision makers" makes sense in the scheme of how a company is supposed to work, QA tends to have more influence over whether the decisions made by the decision makers stick. And if you sit right next to them, like I do, they're a hell of a lot easier to track down. I intend to become better at taking advantage of that.