If you don’t already have a thorough testing process which is incorporated into your budgeting for project estimates, I’d like to convince you why you need to! Testing can slip onto the last item on our lists as developers, for a number of reasons. Not least of which is that it’s not the most glamorous piece of the development process. It’s also tedious, and doesn’t feel very rewarding.
However, it is an invaluable piece of the project. And you need to budget for it as well. Once you’ve come up with your project estimate based on your best guess of how long it will take to accomplish all the features (including a little extra padding for the “oh crap” factor), then you want to take that number and slap an additional 20% to 30% on top of it for testing. It hurts to add that onto the budget, for you because you’re concerned the client won’t bite, and for the client because…well, they don’t want to pay for it.
So now that you’ve accounted for it in your budget and you’re talking to your client, they are now drilling down into your estimate and trying to isolate pieces of the budget that they might be able to remove. If they even start thinking about trying to cut the testing budget, you want to raise a huge red flag, wave your hands in the air, and do a little dance. You have to hold the line on this, and communicate to the client that testing is a critical and integral part of building a reliable, solid web app. Soon they will grow to trust your judgement.
One tool that I noticed recently which I’d like to point out, while we’re on this topic, is a company like Cenzic who you can actualy outsource your testing too. Now they are an enterprise-level solution, so you might not actually need that much fire power. But consider the possibility of outsourcing your testing. Testing is a skill in and of itself, and it can be difficult to put yourself in the mindset of a tester when you are a developer. Did I just say difficult? That is a massive understatement!
Popularity: 100% [?]
8 Responses
Mark Schmulen
April 2nd, 2008 at 10:40 am
1Great post on a very important point. I would actually say that for many projects that the testing and bug fixing time frame can double the development schedule. I know that is true for many projects i have worked on.
kalen_jordan
April 2nd, 2008 at 9:09 pm
2Hey Mark - yes, for more complex web apps I would not even be surprised by that kind of QA/testing time frame. It’s amazing how much these pieces can bit you in the hind parts if you’re not careful!
Video Summary for Saturday, April 5, 2008 by Programmer’s MInd
April 5th, 2008 at 3:26 pm
3[…] Testing Your Web Applications […]
Dave Stewart
April 9th, 2008 at 3:05 am
4> testing and bug fixing time frame can double the development schedule
I tried for years to ignore the facts about this one, but it’s absolutely true. I almost NEVER build in enough time for changes, bug fixing or such like and usually quote on the “perfect” project, but it’s just not practical to do that if you want some kind of a life outside of work!!!
kalen_jordan
April 10th, 2008 at 5:42 am
5Totally man! That’s exactly the kind of thing I’m trying to drill into some young developer’s skull out there. It’s *so* hard to learn on your own and *really* internalize. Testing is a friggin beast!!
Dave Stewart
April 11th, 2008 at 5:54 am
6So Kalen what do you know about “Unit Testing”? I’m aware of it, but I don’t know how to do it, and what I’d actually test.
Any insights, links, etc!?
kalen_jordan
April 11th, 2008 at 6:46 am
7Hey Dave, basically it boils down to setting up automated test cases to test various “low-level” features of your code and ensure that you’re not introducing regressions.
Unit testing is very different from functional testing in that most of the things you are testing are at a very granular level. It’s difficult to test higher level user interface issues.
But for example, you have a variable in your code that should be an integer. So you setup a test case to assert that that variable is an integer, and of course it passes. Now, two months down the line when you’re coding some other piece, you accidentally turn that into a string to accomplish something else but of course you don’t have the foggiest memory of why it needs to be an integer for some other piece of your code.
So you run your long list of unit tests you’ve accumulated and you get all green lights except for that one. So then you fix it.
Hope that makes a lil sense…I’m going to work on a full post on this topic for ya
Dave Stewart
April 11th, 2008 at 8:24 am
8Sounds good Kalen!
The only thing I don’t really get with unit tests, is that you need to think what might go wrong before you can write a test for it.
I find the reason stuff breaks is that I didn’t think of how something could be broken in the first place, and if I had, I may not have spent the time to rite a unit test I just would have spent the time making sure it had the right checks in there in the first place.
A tricky one huh!
RSS feed for comments on this post · TrackBack URI
Leave a reply
Nuggest of Wisdom
Let's Socialize
Visit our sponsors!
VIDEO: Week in Review
Week of Sat, April 5 in Review
Categories
Blogroll
Most Popular in March, 2008
Programmer’s Mind is proudly powered by WordPress - BloggingPro theme by: Design Disease