Essential Software Testing Tools Blog


Working with Programmers

November 28th, 2008 by William Echlin

The success of any development project isn’t dependent on just the skill of the testers. It isn’t dependent on just the skill of the programmers. The success of most projects is dependent to a large extent on the relationship that is built between the test team and the development team.

Years ago I worked for a test manager who thought it was healthy to have an abrasive relationship between the test and development teams. He believed that this friction resulted in a higher quality of the delivered product. He assumed it was acceptable to have loud shouting matches with the development manager. He frequently stormed out of meetings with the development manager.

I would sit there watching the relationship between the development manager and the test manger evolve, or rather deteriorate. I would think; if I had that sort of relationship with my counterpart in the development team the developer would never feel like fixing any of the bugs I described to him.

“If there is conflict between test and development then you’ve lost the ability to work constructively together for the benefit of the whole team.”

I’m not saying you shouldn’t disagree with developers (you should if you think there is a serious bug that they are not paying enough attention to). What I’m saying is that if you have a constitutive, positive relationship with your counterparts in the development team then you stand a much better chance of working together to do what is right to deliver the right product, to the required quality levels, within the specified time scales.

Software testing and development may be distinctly different aspects of any project but the ability to work together usually dictates the end result.

Don’t start down this slippery slope

October 18th, 2008 by William Echlin

With a couple of developers out on holiday last week I had a less senior developer come to me and ask if it is okay to release a build to the software test team without going though the formal build process. So the release would be a build compiled on his local machine with no formal release identifier and no release notes. His argument was that this would enable him to release to the test team earlier.

On the face of it this was quite a compelling argument because we were behind schedule on this project and the test team needed this release urgently for regression testing. I was tempted to take the bait and speed things up.

Experience has taught me though, that you’ve got to be slightly deluded if you think taking an informal release is going to speed things up over the long term.

Firstly, you open yourself up to lots of little issue to manage as you start to work with the release. What build number should you use when you raise a bug? Where should another developer get this build from when trying to recreate a bug? Whilst these issues may seem small on the surface they can take up an inordinate amount of accumulated time for your team to resolve. Each one small in isolation but over a period of days and weeks it soon builds up to a significant amount of time. Usually more time than it would have taken for the developer to create a formal release in the first place.

Secondly, and more importantly, once you’ve started down this road its very difficult to get back to the days where you had a well defined and adhered to build delivery process. Once you’ve started down this road every time things are slightly behind schedule the development team will assume that it is acceptable to repeat the informal release process. One informal release in the process can cause a problem but 2, 3 or more informal release is certainly going to get you unstuck.

So the first piece of advice is, what ever you do don’t accept an informal release from the development to test. No arguments, no discussion or any consideration. Just don’t take an informal release. The second piece of advice is that working with teams where the build process is automated makes even the idea of informal releases redundant.

Shopping for Clothes with your Girlfriend

February 25th, 2008 by William Echlin

Ever wondered why choosing a development framework is like shopping for clothes with your wife or girlfriend? “No”? Oh, well I’m going to tell you anyway!

A couple of months back, when the ball started rolling for work on version 7 of QaTraq we started looking at the various development frameworks available for Php. The options were quite simple. Only two real contenders were available; Symfony and Zend. Choosing between the two was, however, somewhat more complicated than just identifying them.

Right at the start, Adrian, our lead developer, suggested a combination between Symfony and Zend. The argument behind this was that we would get the flexibility of the Symfony framework and access to the great range of Zend modules and components. The fact that Symfony could utilize the Zend components meant that this was technically possible and would give us the best of both worlds. These reasons had not been thought through in detail at this point, but were probably based quite legitimately on instinct, intuition and years of experience.

In the name of best practice though, we went through a four week evaluation and prototyping period. We were attempting to select just one of the two options in the belief that choosing just one would simplify things for us. One day we’d be thinking Zend would best suit our needs, the next day we’d be extolling the benefits of having the flexibility of running with the Symfony solution. As our prototyping with both solutions went on for week after week so did our constantly changing opinion on which of the solutions was the best option to go with.

After about four weeks of constantly changing minds we had our final meeting to discuss which framework we were going to use to construct version 7 of QaTraq. We spent an hour changing our minds again as both solutions had very real pros and cons. That was until Adrian pointed out again that perhaps his initial suggestion combining both solutions, the approach suggested at the very start, was the way to go. One final prototype later and more web research, and we had made our decision.

So why did we spend 4 weeks changing our minds only to go back to the original suggestion? And how does this compare with buying clothes for your wife or girlfriend?

After 4 weeks we were back to square one with the original idea that should we go for Symfony and then use the Zend components we need where necessary. This is when it occurred to me that this evaluation is a lot like taking your wife or girlfriend shopping. First you take her in shop number 1, and she finds a really nice pair of trousers. She doesn’t buy them because she needs to see all the other shops before making a decision. So you visit what feels like hundreds more shops, see what feels like thousands more garments but 8 hours later you get taken back to buy the trousers in shop number one. So you’re left wondering why on earth we didn’t buy the trousers in the first shop in the first place.

Well I mentioned this analogy to the guys at which point Adrian spoke up and pointed out that this analogy wasn’t quite accurate. Adrian quickly pointed out that we hadn’t bought the best trousers from shop number one but rather we’d bought ALL the trousers just to be sure we’d got the best pair of trousers. I could see his point!

Regardless of how many pairs of trousers we’d decided to purchase the moral would seem to be that there is a lot to be said for trusting your first instincts. So we settled with a combination of Zend and Syfony, and we haven’t looked back since.

Imminent Release

July 19th, 2007 by William Echlin

There is always a buzz when it gets close to a new release, and this imminent release is no different. It is a strange mixture of nervousness and excitement. Nervousness because the credibility of the project depends on a quality release. Excitement because after months of hard work from the team you are eager to show people exactly what you’ve been doing in that time, and what new functionality it is that you’ve been working so hard to deliver.

Whilst this release will only be formally categorized as a minor release, due to the fact that no database changes are being incorporated (the database back end has been stable and reliable for some time now), there is no denying that we’ve added some major improvements to the user interface. Namely the inclusion of four new one-stop summary pages for the testing aspect covering; test-management, test-coordination, test-development and test-execution. Each of these four new summary pages providing users with a single point of focus delivering the critical information required for four crucial aspects of testing projects.

So as the nervousness becomes more acute over the next two weeks, and the excitement even more palatable, that new release really isn’t far off being available from our download page.

Regards

QaTraq Team

Copyright ©2009 - Traq Software Ltd - All Rights Reserved.