How can you reduce risk when implementing agile development in your SDLC?
Jan: Tell us a little bit about your background. What led you here?
Phil: I’ve been involved in software development for almost 20 years, first as a product leader, but also as an engineering executive and a marketing executive. Starting out as a an enterprise software product manager in the pre-agile, pre-SaaS era, I learned the value of testing very, very early. Back in the dark ages, if you had bugs in your software, you had to send out a new CD-ROM to all your customers, and if they were enterprise customers, that meant that those bug fixes would not be applied for months, if ever. And someone who’d signed a five-million dollar check would blame you, not her company, for the problems. So the pressure was high to get it right!
Since then I’ve worked at two companies that specialized in creating online communities of people who in one way or another had questions or wanted to share their expertise. So one thing I love about test IO is that we have a great community of people who genuinely enjoy software testing, and we’ve figured out how to harness their abilities for everyone’s benefit.
I love companies like that!
Jan: Would you say it’s like Uber for software testing?
Phil: Yeah, I’d definitely say that to potential investors or the person I meet on the proverbial elevator.
I think that like Uber, we see that there are a lot of people who have the skills to help others, and what they lacked was a platform to connect them with people who were willing to pay. So we’re that platform, and we build technology to make that process of connecting people fast and friction-free.
What’s not like Uber is that the testers who work with us are professionals, and the difference between a good software tester and a novice is much wider than the difference between a good driver and a bad one (provided the bad one doesn’t harm you physically!). So we’re looking for great testers, and looking for ways to help testers improve.
Jan: What made you decide to join test IO?
Phil: A lot of things, but most importantly, I could have been the customer for test IO for most of my professional life, and I know that this is not a solved problem. In fact, in some ways the problem of how to test software effectively has gotten more challenging in the past 10 years.
Go back 10 years: IE 6 had finally been defeated in the browser wars, and you had a relatively standardized experience across major desktop browsers. The world we live in today is vastly more complex: there are two big mobile platforms, and Android has many variations. Apps are written natively and for mobile browsers, and responsive design is supposed to work on the web across a gamut of devices and form factors. And increasingly we have the Internet of Things, otherwise known as the Internet of Random S***.
So if you want a great -- or even an acceptable -- customer experience across all of this, you need a strategy that combines automation with rigorous real-world testing.
That, combined with the fact that there’s only going to be more software, makes test IO a great opportunity right now.
Jan: What has surprised you the most, that you didn’t see from the outside, or learn from the interview process?
Phil: Our marketing and our company ideology emphasize that we’re a SaaS platform and that test IO is an on-demand service. That means if you need a test, you log into our platform, click a few buttons, and the magic happens! You can make test IO part of your regular software development process and treat it like other utilities that you rely on: your automated tests, your deployment scripts, Heroku instances, whatever. And from the customer perspective, this is true, and it is quite magical.
But what the customer doesn’t see is all the work we do operationally, both with software and with human beings, to make sure those tests generate useful results for them. It starts with having great testers, but it doesn’t end there. There are several levels of computer- and human checks that make sure that the customer gets useful intelligence quickly.
So, what I didn’t quite understand is: this is a service, but it is not a commodity service.