While I’m still trying to catch up from my break from the internet during June and most of July, I came across a TechCrunch article by MG Siegler, Playing Devil’s Advocate.

The answer, it seems, is that most of those people were likely too close to the projects to see what was right in front of them. They fell victim to group think, or worse, they started to rationalize their own bad projects.

Basically someone in your company, group, needs to be the one the is skeptical. But not just skeptical, skeptical to the point of cynicism. While this might seem counter productive, especially in small companies and startups, I believe this a good thing to have and a lot of companies avoid it.

Some of the main reasons I have heard is that someone that does this is not a team player. They are creating rifts within the company.

I don’t believe so. This person and/or people should be in QA. Quality Assurance is often overlooked by many companies, especially manual testers. Most companies try to automate test, or A/B test everything and there is nothing wrong with that. I myself have written and use automation scripts for personal projects and at work. I have pushed for some features to be A/B tested before finalizing them to get broad user feedback. Using many technologies is good for companies, but automated steps can’t bring up user experience, the quality of the product. As we’ve seen with recent software releases, it’s a very important issue.

At the end of the day, that’s what the article is talking about is companies need to stop shipping crappy products, products that are half thoughts and not fully fleshed out. MVPs, or minimal viable products are no longer acceptable. It’s “ship”, not “shit,” wrote Cat Noone, Co-founder & Chief Design Officer at Liberio.

A good quality engineer will be vocal about UI/UX. They will play an important role as protector of the company from shipping a bad product but advocate for the user. It’s not an easy job. You have to deal with knowing why something was done, but also understand the expectations of a typical user. There will never be bug-free updates. QA and project managers should have the last say when something is shipped. Usually it’s with no blockers (usually nasty bugs or crashes) and no bugs that impede the functionality of features in the application. After something is shipped, you go back to testing and pushing for bugs to be fixed. Usually having users report the same bugs is helpful to increase priority.

I have seen companies disregard QA and just ship product because of deadlines. I have seen companies consider QA input on product and it was better for it.
From experience, my role as a QA engineer was started with just testing, then evaluate, if the bugs that remained that impeded user functionality enough then I stopped the release. As I became more confident with what was being tested, I raised concerns, first by simple suggestions on how to make things seem from the user perspective. Ultimately, talking about workflows and the use of interactions, taking into consideration preexisting expectations, working closely with designers, product groups and at times even external groups.

QA should not be disregarded or a group that is sidelined. They are the people that care about the company and the user. They are literally the first users of the product and should be brutal about it.

It was a different perspective when talking to actual users about the product I helped ship. They talked so highly about features that I knew were half broken, or if you deviated a bit, can crash an entire embedded system. But to them, they enjoyed it. It worked as they hoped and intended. They cared for it. The yelling matches, the fights, the endless conversations with product managers and designers to make things better, chatting and compromising with developers all worth it, for the user.

I may know that the product is held together by shoestring and tape, but it works for a user and they love it. That’s why QA engineers work hard for. For the user. They are a real life version of Tron.