We’re Closing The Deal With Cision. Here’s What That Means
By Giles PalmerJun 1
We looked at over 20bn data points across 2021 to understand how we use emojis and emotional language to express ourselves online
Published July 18th 2014
Editor’s note: Interested in the Engineering team and what they get up to? They’ve got their own blog over at engineering.brandwatch.com. Head over there for insights into what makes them tick, what they’re working on and other developments behind the scenes.
Quality assurance. Why bother? This is a good question – and one I’ve heard a few times in my testing career.
Surely, the argument goes, developers run it before it goes live and if anything breaks, our customers will tell us, right?
Besides, we hire really talented developers – those testers just aren’t needed, are they?
That approach is so 1990s (a decade a large amount of the Brandwatch staff were born in!) and is something we at Brandwatch definitely don’t agree with.
We have made a big investment in QA as we believe quality is as important as functionality.
Well, there are many reasons, but for me, the most important are:
As someone who didn’t start life working in IT, I was on the other side of the coin as a user.
I remember having to use apps that just didn’t work well (even my early years as a tester I used a test tool that kept crashing!) so I know how frustrating it can be! Software is a tool that helps people do their jobs.
Customers pay for our service and in my mind are entitled to be able to “just use” the service.
They shouldn’t have to login back in every 10 minutes because the app freezes when they view a chart or when they try and export their data nothing happens. It should just work.
We are extremely proud of our product and like any proud parent we don’t want people to criticise it.
We want the experience to be a great one.
We want our customers to want to tell their customers about Brandwatch, and if the application has lots of bugs and is unreliable, we won’t stay in business that long.
QA isn’t just about finding what doesn’t work (the negative test).
It also has to make sure that a feature/product does what it should do (the positive test). This is as important as bug finding, and involves looking at the product through the customers eyes.
Does the navigation work – can you get to the area you want without jumping through too many hoops. Does it look nice or is it painful on the eyes?
Sure, we hire the best developers around, people that talk a language that, quite frankly, most of the time I have no clue about.
QA have a different perspective on the world – we look at a product not as a collection of JS, HTML, CSS and API calls for example, but as a whole – this means even though the code may be the best it can be, it doesn’t mean it works in a way that is good for the user.
Brandwatch is growing daily. We are rapidly becoming the tool of choice, and I like to think the effort that our QA team put in are a part of that. So for me, the bother is worth it.