Working with fixed budgets, or by project, is a common practice in the IT world that I too endure as a consultant. However, from my point of view and experience, an R&D software project with a fixed project is a missed opportunity to create a great result with great value and, moreover, it can compromise quality. In this article, I’m going to explain why.
The Project Management Triangle is well known in software project management theory as a way to represent the constraints a project may have. On its corners, time, scope and budget (or schedule, scope and cost) shape the boundaries of the project, and quality is a by-product of the combination of these.
It is generally known as a best practice to have automated tests for your web application, which not always is an easy nor cost-affordable task. I have recently used BugBuster, a SaaS testing platform that makes the task easy by providing a solution that does exploratory testing in a smart way.
Some of the most interesting features of BugBuster are:
- Smart exploration: it discovers actions and walks through the application trying combinations that may lead to corner cases that weren’t covered by regular test cases.
- Time-insensitive: BugBuster waits for stable states between actions, so that dealing with AJAX features is as easy as chaining events. Say goodbye to random waits in your test code.
- Signup forms and validation emails: BugBuster can receive automated emails and check whether your signup or other email-based forms succeed or fail.
- Nearly-zero setup effort: it is a SaaS platform, they put the infrastructure at your service; you only have to write the test cases.
- And many others.
In this post I will show how easy it is to test a web application with BugBuster- whether in production, staging or development environments, it can also access your local and private environments thanks to a SSH tunnel. If you want to try it yourself, you can start by creating an account here if you haven’t already, and log in to the BugBuster application at app.bugbuster.com. To illustrate the example, I will test my own blog website.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
The results, splitting a batch of one million array inserts into ten parallel workers, is quite amazing:
It took 1039 milliseconds to run without web workers It took 391 milliseconds to run with web workers
So in this simple example, using web workers increased processing speed around three times. Yet another reason to consider them in heavyweight client-side processing tasks!