By Jonathan Watts
I try to pretend I am not a geek, but with fifteen cameras (film and digital), three android devices and a lifetime subscription to Sci-Fi Magazine, I haven’t been able to convince anyone. I am also a test engineer at Red Gate, a smallish software company based in Cambridge UK. For the last eight years, I have tried to ensure Red Gate’s software does what it should quickly, easily and efficiently. I am also responsible for stopping the software doing what it shouldn’t. So no pressure there, then.
I never planned to become a tester. When I left university, I got a summer job as a software auditor at a well-known photocopier manufacturer. At first, my role was to check the changes software developers were making to the copiers’ embedded software and make sure they were in line with the design specifications. As the summer progressed, I became involved in writing test plans and cases, reviewing requirements documents, building test environments, and finding bugs in the software. Before I knew it, I had been there 18 months and I was a software tester – and enjoying it.
I joined Red Gate in July 2004 and – I am afraid this is going to sound trite, but – I have loved every minute of it. I won’t bore you with the details, you can look at our company pages on the Red Gate website for some of the reasons why Red Gate’s such an awesome place to work.
Testing at Red Gate
Red Gate’s motto is “ingeniously simple tools”. This means we examine complex tasks and build tools to make it as easy for our users to complete these tasks. It is great hearing customer stories about a tool you have worked on solving problems for them.
We work in small cross-functional teams of developers, testers, user experience experts and technical authors, usually with a product owner and a project manager overseeing things. Everyone in the team is responsible for the design, functionality, quality and usability of the product. The entire team is involved from the very start of a project, helping design what we build. This means testing isn’t just an afterthought tacked on at the end of the project – testing happens throughout a project’s lifecycle.
The team research what our users are like, what problems they have, and how they use tools to solve them. As testers we try very hard to be domain experts, knowing as much about the problems our users want to solve as they do, and do a lot of exploratory testing aimed at trying to find out how the software actually behaves (rather than how we think it does). We also build test environments and create test data which allow us to test our tools in realistic scenarios.
Admittedly, some parts of manual testing can be repetitive, boring, error-prone or don’t need a human to decide whether the test case passes. Therefore, the other large part of a tester’s role involves writing software to automate testing. Many of our projects have automated test suites which execute more a month’s worth of manual testing in a matter of hours, so testers can quickly get comprehensive feedback about the quality of testing. In turn, this allows a team to confidently release new features and bug fixes within hours of the change going into the code.
New adventures in OLAP
I have been fortunate to work on some of Red Gate’s best-known products, including SQL Compare, SQL Data Compare and SQL Backup – all tools traditionally used by developers and DBAs using Microsoft SQL Server on OLTP-type projects. Now I am in a new team developing a SSAS comparison tool, venturing into the OLAP and business intelligence jungle for the first time. I spent my first day installing SSAS 2008 and 2012 (multi-dimensional and tabular), getting acquainted with BIDS and SQL Data Manager, running through those ubiquitous AdventureWorks examples, and reading all the BI blogs I can find.
Though we do talk to Red Gate’s own BI developers, everyone in the SSAS Compare team is new to the business intelligence world, and one of our major priorities is learning more about the BI community. We hope SSAS Compare will be the first of a number of tools Red Gate will develop for business intelligence professionals.
We will be going on trips to visit users, and running user experience sessions, to learn how BI developers use our tools. So if you work in BI and want to influence the design of tools aimed at solving real problems you face on a daily basis, let us know.