In this first part of a two part blog Gordon Baisley, a new contributor to the Start Up series, introduces himself and his company Quast. He then moves on share the first of three example of what starting the business has taught him about testing.
Introducing Quast and the Idea for this Blog
Just over a year ago I started a business called Quast – www.quast.uk.com. The name comes from QUality Assurance and Software Testing, and this is our focus. We are a QA and Testing Consultancy with four main offerings:
- Consultancy: Providing QA and Test consultants to companies
- QA-as-a-Service: Outsourcing or taking responsibility for specific QA or Test tasks on behalf of a customer’s business
- Resourcing: Acting as an agency to help companies find permanent or contract QA skills
- Software Vendor: Reselling software to underpin a company’s QA processes
In recent roles I’d been Director or Head of QA or Testing at large companies, so I wasn’t starting a business in a completely new area. I had led internal teams providing QA and Test services within a single company, and Quast offers the same services, but instead as an external supplier to many companies.
Nevertheless, however relevant my experience, I was very conscious that no new business is guaranteed success. Bis.gov (the Department for Business, Innovation and Skills) collected some stats that showed that 400,000 new businesses started in the UK in 2012. Encouraging, right? But they also tell you that over 50% of them weren’t around by 2015, which puts something of a different perspective on things. As I considered starting up, it was important for me to believe I’d benefit whether the company was around in two years or not. As father to a young family it would have been irresponsible for me to dive in if being one of the 50% that disappeared within 2 years would mean disaster. It was important for me to believe that if, having given it my best shot, it didn’t work out, then the effects would be at worst liveable with, but ideally they’d be positive.
The mantra that convinced me to go ahead was that the skills I’d gain running a business are invaluable professional development, and actually an acceleration of the personal development I’d have made inside a company. I convinced myself that, by facing the challenges and risks of setting up a company, that if I end up back in a large company I’d be much more capable, much more rounded, much more effective employee, and so would progress further in future because of the experience. I remain convinced of this today. Working in a large company, for all you work with other teams – looking to understand their responsibilities and decisions – just by nature of the other team’s existence they have the real accountability and so you never actually walk in their shoes. Starting a small business I’m the only person performing a number of the roles in the company. I truly am wearing other shoes as the buck stops with me. Through the experiences I’ve had starting a small company if I went back to a corporate role I’d now either do some things differently, having broadened my thinking, or increase the priority of some tasks I’d already recognised but not given enough focus.
For my first article for the Startup Series I thought it might be interesting to share three examples of how different roles I’ve performed have furthered my thinking as a QA Leader and would lead me to do things differently. With Quast itself a QA and Testing consultancy, I’ll look at how we’re adapting what we’re doing. And I will also give some examples of what I think I’d do differently back in a role in an in-house QA department.
Adventures in Architecture
As a start up we have a green field site. Thinking about some guidelines for building our architecture I came up with three targets: 1. Best of breed products; 2. Architectural Simplicity / Out of Box integration; and 3. Fit for Future. Thinking of my Test experience, these reflected a consciousness of 1. Not spending enough time on Requirement / Design up front and incurring costly change later. 2. The exponential increase in Test costs as Architecture gets very complex. 3. Recognising how difficult it is for companies to move between products.
The rules seemed sensible but in selecting a single application, it became clear to me these guidelines needed to adapt to current trends.
An early task was to select an Application Tracking System (ATS), the application that will be the core tool for our Resourcing business.
Looking for the best products, what I was really conscious of were the proliferation of offerings. Through the internet giving access to a global product set, cloud hosting making it easy to get up and running, and advances in Development Environments making it easier to get a credible product to market, the choice was bewildering. You could find great products specialising in every niche – In-house Perm, Recruitment Agency, Job Board recruitment or Social Recruiting.
Thinking about integration, the proliferation of choice meant there wasn’t the out-of-box interfaces I hoped for. I honed in on 4 preferred products and identified 3 main interfaces to other application we’d wanted. I found each preferred product had one out-of-box integration and two not there.
Finally, in terms of fit for future, I found it very difficult to separate the future Salesforce’s from the rest. It felt you could identify some companies, even previous leaders, that weren’t keeping up, but it was very difficult to identify who would thrive long term out of the many credible options remaining.
Ultimately, I selected a product that was Best Now for us as a specialist recruitment agency and that offered best integration with job boards (which seemed our first priority). I consciously avoided a U.S. product that in many ways was better but that didn’t yet have a U.K. template and so talked Resume, MM-DD-YY and $. This was work-aroundable, but at too much effort today. The initial guidelines I’d set myself were useful, but worded more for a time when architectural boundaries were less fluid – before Digital Transformation and IoT – and choice was more limited – before cloud services were commonplace.
With hindsight I’d re-state them as:
1. Best Fit to Core Requirements – this recognising that there’s so many great niche products that you need a laser focus on your core requirement, rather than buying big generalist tools that aren’t best at anything.
2. Easy to Integrate with (/Open API) – given the choice it seemed unrealistic now to rely on suppliers to provide all integration for you, making it easy for you to do so yourself is a close second.
3. Digitally Minded – as although you can’t pick the winners, you can identify those likely to fall behind by not keeping up.
Having acted as Enterprise Architect, I’ve made some changes at Quast and will change my emphasis in future Test roles.
At Quast, we’ve signed a new Software Partnership. The selection process above made me very conscious of the importance of Integration between systems – API Testing and the need for good Tooling to support that – in an ever proliferating, IoT world. We’ve signed a Partnership with Smartbear. Smartbear have made a real focus on the API: they own SOAP UI and Swagger (the most popular framework for RESTful API’s). They’ve really made Integration and API their focus and built a product set ready for an Internet of Things world. This feels a tool set that will be very relevant and valuable to our customers, and one that we want to keep up to date with for our own capability.
If I went back to leading a QA or Test function, the lesson would be to put more focus on enabling integration and integration testing. To give a specific idea… while Design and Development teams are doing a lot of work to publish Open API definitions to their customers, I don’t often see companies offer Test Environments and Test Data that would allow customers (internally or externally) to readily Test against a real version of the API or even more fully with the neighbouring system. Currently the onus tends to be on the customer to ask and arrange access to our environments, when I think we should make this part of a professional service. This links to a feeling that as an industry we haven’t put enough effort in to being sponsors of Service Virtualisation or other approaches to professionalise the provision of stubs or virtual services support . I believe it should be part of our process to update in line with our releases, a Test Environment and Test Data, ideally a real version of the neighbouring API and system with stubbing behind, but at least a stub based on the current interface definition, to readily allow customers to test their integration with you. This becomes a really sellable and differentiating offering showing that you are doing everything to make yourselves easy to connect with. I did see one really good example of this at Eircom (now Eir). They had a wholesale offering allowing other companies to sell telephony provided over their network. The interface to do this was called UG (Universal Gateway) and Eircom offered not just an interface definition but a live instance of UG, stubbed behind to represent back end systems, and a set of test cases and test data that defined the stub responses available. You can openly read this on their website: http://www.openeir.ie/support/Unified_gateway/ More of us should do this and it’s something I’d look to do in future.
Read Part Two here
About The Author
I’m Gordon Baisley; the Founder and CEO of Quast Ltd.
At Quast, our aim is to bring together the best pool of talent in QA and software testing, and make it available to our clients.
Read more at quast.uk.com
