Simply Testable helps those who create websites introduce fundamental automated frontend testing into their standard development, testing and support processes. We do this by offering one-click full-site testing that covers all the basic aspects that make websites work.
The service is used daily by people all over the world and saves many hours each day by automating testing that would otherwise be carried out by hand.
We're still growing, learning and improving. I've faced challenges, disasters and heroic victories as well as a fair amount of very hard work.
My current challenge is to translate a successful service into a profitable product. This is something I'm still trying to figure out and I constantly find myself having to investigate and learn about sales and marketing.
Here is a story of what we do, how we got to where we are, the challenges we faced along the way and where we go from here. If you find this interesting, you should follow us on Twitter and try out the public demo to see what we can do for you.
The structure behind a website is created in HTML. A website is then made pretty with CSS and is brought alive with JavaScript. A website also links to other websites, making the web what it is.
HTML, CSS and JavaScript are the fundamental underpinnings of websites, and the links between websites make the web a wonderful inter-connected collection of information.
We help people who build websites by letting them easily run a series of tests on the above fundamental aspects of a website. We help people discover invalid HTML, invalid CSS, inefficient or poorly-written JavaScript and broken or faulty links.
And we really help by offering the ability to run all such tests across all the pages of a website with just one click of a button.
My background is as a web developer and I've professionally built many websites at a range of companies.
Some companies didn't have dedicated test teams. I build websites and I tested what I built. As a quick aside: employ one tester per four to six developers, you'll reduce the time take to build sites and you'll significantly increase the quality of what is produced.
The last company at which I work didn't have any testers. They also didn't have many other supporting aspects that contribute towards high-quality work such as code revision control, continuous integration or automated basic testing.
After introducing version control and continuous integration, I introduced some basic automated testing into the continuous integration process.
Rather than manually test various fundamental underpinnings of my work, which would take a long time, which would take focus away making me less productive and which would be less thorough, I let the automated testing system do that for me.
When finished with a small section of work, I would commit the code changes and get on with whatever was next on my list. I could later check the automated test results and correct things as needed.
The automated testing system I had haphazardly pulled together was crude, basic and temperamental but worked more often than not and helped more than it hindered.
When made redundant as the company moved focus away from web development, I put my time, savings and effort into building simple automated web testing tools that either didn't already exist or which were awkward to use at scale.
As it stands today, Simply Testable lets you run a range of tests against websites of any size. Various factors, many of which are beyond our control, may result in a test taking a long time. But eventually your test will finish.
This sounds easy but it isn't. The web is temperamental and error-prone. Websites can be so poorly built and their faults so extreme that they break the tools that are used to test them.
And when you grow to a certain size and start processing enough data, the systems you thought could handle the work start to fall apart.
The web is not reliable. Some bits of data that you request go missing in transit. Web servers are happy one minute, overloaded, slow and sad the next.
Websites can be poorly-built and broken in ways that I would not have previously thought possible. The vast majority of websites are only minimally faulty in ways that don't really matter, but a small minority are broken in ways I try not to think about.
When using the unreliable web to retrieve websites that can be amazingly creative in their total disregard for coding rules, something is going to break. When you need to be able to test everything, you need to be able to cope with all the broken that the world can throw at you.
I've spent many hours figuring out how to retrieve web pages reliably, examining astonishing broken HTML to figure out how to test it and investigating why our broken link checker fails for some specific links only.
When operating at scale, otherwise infrequent occurrences of particularly bad websites are encountered often. Each and every time a single web page test inexplicably fails, the system is fixed to cope with whatever oddity was the root cause, slowly expanding the number of websites that can be tested to where we are today where everything works and it looks really easy.
Our first production server was cheap. It was a budget offering that for many uses would have been just fine. It was cheap because it used consumer-grade hardware instead of server-grade hardware. It was basically made of the same bits and pieces you expect to find in a standard office desktop computer, although with a lot more of those bits and pieces so as to cope with all the work it had to do.
Consumer-grade hardware is essentially the same as server-grade hardware but differs in quality, much like a space shuttle is essentially a oddly-shaped plane with a more fancy engine but which has to cope with more extreme conditions than your average passenger jet.
And much like a passenger jet cruising slowly around in space, we were not prepared for what would happen when you try to take that jet through the Earth's atmosphere and land. The passenger jet would fall apart and melt. So did our production server.
Backups? Well, "system backups" was featured somewhere towards the bottom of a long list of things that could be looked at once everything was actually working more often than not. I was aware that consumer-grade hard disks were much more likely to fail than server-grade alternatives but, I thought, maybe that gives me one year of good use instead of five to ten years.
Three months. Three months of use in the production server and the hard disks died. There were two hard disks, each holding the same copy of everything. If one failed it could be replaced without any data loss. But only after three months of use, both hard disks failed at the same time.
Did I mention we had no backups? We lost all user accounts, all test data, all everything.
I acquired a new production server, set everything up again from scratch and tried again.
These days our production server contains high-quality server-grade hardware with various redundant bits and pieces should any one single piece fail. It costs a heck of a lot more but is at least two hecks more reliable. Backups are taken daily and we run through restoring from backups monthly just to be sure that the backups are of any use should we need them.
I didn't previously know a great deal about server configuration. I would build websites and web-based software, pop it on a server and let it do whatever it did. I didn't need to look at how the server was configured to let the software do whatever it did.
Until I did need to know.
Not long after the service was initially launched back in October 2012, we ran into significant problems trying to handle all the people who wanted to use the service.
I tested, examined and checked all of the software I had written and had made improvements where I could to iron out any performance issues. I, with a background in software development, had reached the limit of what I knew and that was not enough to deal with the capacity issues.
I ventured into territory unknown to me and investigated what could be done to improve the performance of the web server being used and the underlying database server, both of which were performance bottlenecks.
I gave a talk at a Cardiff-based monthly developer meetup covering what I had learned (look for the video titled "3 Non-code Production Performance Improvements for Developers") and how it helped and later wrote a blog post covering the same.
In short, I had managed to bring a struggling service back to life by tweaking things in the background. I had to learn a great deal about what went on in the background to make this happen.
I started by saying that Simply Testable is a service used daily by many people all over the world. The service provides value by saving hours of time in testing websites.
My current challenge is to translate the value that the service offers into revenue. I'm having to learn a great deal about sales and marketing. I'm having to deal with situations with which I was not initially entirely comfortable, such as emailing people out of the blue, showing them what I can do for them and hoping they'll try it out and, with some luck, pay for it.
You can help by following us on Twitter, trying out the public demo to see what we can do for you and telling your web design friends to give us a go!