1. No Test Cases: Your testers don’t have a fixed list of tests they have to execute, they are in the wild with lots of guess work.
2. Waiting for crisis: Unless there is a major visible failure, no one in your team cares about testing.
3. Isolation: Your testers start testing on their own and finish on their own when they feel like, and you have no report of which tests were passed, which were failed.
4. Delayed Releases: Releases are delayed many times because of last minute test failures.
5. Thinking too late: Not thinking about testing before you write your first line of code.
   
6. No track of time: You don’t even know how much time you need to put in testing in first place.
7. Complexity: Your app’s tests are so complex that you need to teach your testers how to test first, before they can actually start testing. Or even worse, you don’t want to hire testers because you know it’ll be too complex for anyone else.

Any of this sounds familiar? If yes, don’t be shy – we sucked at testing as much as you do (actually maybe more since you took time to read this post), before we decided we had to do something about it.

We’re building something very promising, a test case management system which will effectively work with you in solving all the problems listed above. If it looks worth to you, signup to our newsletter and we’ll inform you once we launch it. Even if you already use one, you’ll definitely find it faster, easier and leaner.

Update: Check out our new test case management app!

There are always a few books which are lying around me in a queue for months before I start reading them.

Today, I just started reading Sustainable Software Development, and the concept which I’ve been spreading from years popped up. (So I couldn’t obviously wait to blog this)

As you can see in the charts, working smart over working hard is much more beneficial in long-run even if it requires some extra time investment in beginning.

Not too long back my colleague asked community about how they handle their deployments and patches to the production server. We received quality response and various options – I learned many new things about how others were handling it. We are using Subversion for versioning our projects from last 3 years and were very happy to implement it. It reduced a lot of time in release cycle and all that hassle one has to go through, was simply gone.

But here comes the problem. The clients who are not willing to use such tools. Or are simply not giving you authorization to do so, or they are using shared hosting environment. I’ve seen this problem with my 5 out of 10 clients. They have a reason to stop you – they were never asked for this before from their previous development companies or whatsoever. Then, there are clients who say “Use ftp” when you ask them to send SSH access, this limits the productivity of the whole system and the project. However, I consider it as my call to make them aware of the things which can help them – and that is why I’m writing this post today.

So by this post, I actually want to highlight the advantages offered by any version control system over the regular FTP transfer for deployment – I’m sure this will help the buyers who don’t allow much control in hands of their web developers. Ok, here we go, these are some real BIG limitations you know you’ll face using FTP:

1. Initial setup is always easy, updating and bug fixes and applying patches is difficult using FTP. You spend 10x more time being careful for things that can be handled automatically.
2. You have to wait for the files to upload/download.
3. If something goes wrong, it’s really difficult to revert to “last stable” state.

And when you’re using Subversion or any other version control tool for that matter – All these issues are no more your concern, and you can focus on real development rather than finding files and stuff. Here are some advantages offered by a standard version control system:

1. To apply patches, you simply issue “svn up” command to the system (In case of subversion). It automatically updates the modified files.
2. In case there’s something wrong, you can go back to any old revision and have your site running as it was. Using Subversion’s advanced features and proper versioning; you can also define a “last stable” version and be safe all the times.
3. You don’t have to worry about latest back – everything is on a separate server with all revisions.

This is just a start – many things are eventually taken care of while using a version control. However, there are many other automated ways for this purpose, some people like using “rsync”, some rely on application servers and so.

I’m hoping that it’ll help buyers understand our offering better. Thanks for reading.

Abhimanyu Grover