by Pawel Brodzinski on March 12, 2010
The project reached its final phase. It sucked as always. Everything should be ready by Friday afternoon but it looked like the whole weekend at work was the new plan for a group of people. Megan the Eager was among people who volunteered to stay late on Friday. She stayed late at night cleaning the mess in the project, she came back on Sunday to finish what had to be finished and finally on Monday it was all done.
Megan was proud of herself. She felt completely exhausted because of working overtime all the weekend but she felt she was among few people who rescued the project. At the same time she expected her engagement to be appreciated in some way.
What she got was some not even decent bonus money counted in some magic way which wasn’t revealed to her. The money was paid much later than she was told it would be. She neither heard “thanks” from her bosses nor was her effort acknowledged in front of the team. Megan felt like her bosses thought it was her duty to work crazy hours to save the project.
Actually that was exactly what she heard from her manager a month later.
Failure
It was a double failure. Not only project was failed in a first place which led to crazy rescue plan instead of proper work organization to finish on time but also the manager failed as a leader.
Appreciate the team
It’s damn manager’s duty to appreciate extraordinary work of their team. This is one of things they’re paid for. People don’t work their asses off to save the project just because their manager wants them to. They do it because they want and feel capable to help. However team sprit has to be sustained or it fades away. When the next project needs a rescue plan Megan will be heading home. She was taught it isn’t worth the effort.
When team fails manager fails too
Even when a manager is a kind of super-hero he won’t be able to do the project alone. Most likely he no longer has appropriate skill anymore. That’s why he has team after all. However, when team fails that’s a manager’s failure too. When team fails but could have succeeded under better management that’s a double fail for a manager. It would take just a few simple steps to bring the project back on track and complete it as planned.
And killing spirit of people like Megan should be punished in some way. She won’t work for current managers forever after all.
Read other project management failure stories.
by Pawel Brodzinski on March 10, 2010
The other day we were discussing different techniques aimed at improving code quality. Continuous integration, static code analysis, unit testing with or without applying test-driven development, code review – we’ve went through them all. At some point I sensed someone could feel that once they employ all this fine practices their code will be ready to ship as soon as it is all green after build on a build server. I just had to counter strike:
“I’m not going to ship any code, no matter how many quality-improving techniques we use, unless some human tester puts their hands on it and blesses it as good. Not even a chance.”
I’ve seen the situation quite a number of times: a team of developers who are all into the best engineering practices, but unfortunately at the same time sharing a belief this is enough to build top-notch applications. I have a bad news for you: if the answer for a question about quality assurance team is “we don’t need one” I scream and run away. And don’t buy any of your apps.
It just isn’t possible to build quality code with no manual testing at all. You may build something and throw it against your client hoping they will do the testing for you. Sometimes you can even get away with this approach. Be warned though – you’re going to fail hard way soon. The next customer may not like the idea of doing beta-tests for you, actually most of them won’t, and then you’re screwed.
Manual and automatic testing is fundamentally different. With automated testing, no matter if we’re talking about unit, stress, regression, integration or end-to-end tests, you go through predefined tracks. You had to create the test in the first place so it does exactly what you told it to do.
On the other hand humans pretty often had their own minds which they happen to use in unpredictable ways. They may for example make up some test scenarios on the fly or they may sense a subtle scent of a big scary bug hiding around and follow their instinct to hunt it down. Every now and then they will abandon beaten tracks to do something unexpected, i.e. find a bug which would be missed otherwise.
Note: I don’t say what kind of procedure you should follow in manual testing. Personally I strongly believe in value of exploratory testing, but any good tester will do the job, no matter what your manual testing procedure look like.
Actually this post was triggered by recent discussion between a few bloggers including Lisa Crispin, James Shore, Ron Jeffries, George Dinwiddie and Gojko Adzic. The discussion, while interesting and definitely worth to read, is a bit too academic for me. My approach is that there is no universal set of techniques which yields indisputably best results. While I like James arguments why they dropped acceptance testing and support his affection for exploratory testing I share Lisa point that even in stable environment our “best” approach will evolve and so would techniques we employ.
You may exchange acceptance testing with exploratory testing and that’s perfectly fine. As long as some fellow human put their hand on the code you want your users to touch with mine that I’m good with that. I don’t care much which approach you choose or how you call it. It is way more important who does the job. Experienced quality engineer with no plan at all will do way better job than poor or inexperienced tester with the best plan.
Just remember if you happen to skip the manual testing at all I’m afraid your app may be good only for machines as only machines tested it.