Communication
Bad Communication->Most developers and testers only communicate through bugs. One reason is Testers are frequently afraid of going to their developer for questions. Testers are even told sometimes not to bother their developer since the dev is really busy. IF the tester is blocked, they should not let anything get in their way of doing their job. Testers time is just as valuable as the Developers. If a tester is told not to bother the dev, then the tester should schedule office hours with the developer where they come in with a list of questions they need answered. (sorry got off track... but i feel its important to say this because i hate it when testers act like the victim)
TEAM work
Back to qualities of a great developer...
- Great developers frequently discuss issues/designs with their testers.
- They kept them up to date about changes coming up.
- They tell their tester, area's of concern, area's the tester should focus on.
- They understand the more the tester understands the feature, the better they could test it.
- The great developers always included the tester on emails and meetings that discussed their features.
- Great Developers do NOT take bugs in there area personally
- Great Developers know they need great testers to challenge them. They know you can't ship a product with out them.
Why communication/team work sometimes fails...
Sometimes testers might not be included because they can be a distraction. They will start breaking the feature where the purpose was to design it. The tester needs to just be reminded of this fact... and everything will be ok. Don't just not invite the tester because they just break everyones idea... just tell them what you need from them before the meeting is started and it will go smoothly.
Here is a list of things I have seen great developers do:
- writes simple well designed code - oh how nice it is to do white box testing on a feature that has a simple design!
- rewrites crap! Code might not have started off as crap, but as the bugs were being checked in, the code became patchy hard to follow, alot of exceptions to the rules added all over the place. The great developers, will stop, and revisit the area and refactor/clean it up!
- Comment their code
- Design a flow chart of how it might go and let the tester loose on it.
- THEY NEVER do hacks (or very rarely). They will write code to fix the problem the right way even if it takes them alot longer. They understand that putting hacky code in, still have to go through testing which will find alot of bugs around it, and eventually they will have to go back and do the right fix, which will again have to be tested... (so the dev that tried to save 1 day of work or 1 week of work, actually caused more work on themselves and all other people involved.
- I am curious - what is the life span for a hack? how long on average does it actually stay in the code? What ever the answer - short or long half life... you can't win... it always comes back to bite you in the butt... in sooo many ways!
- Almost forgot - making the feature testable!!!! YAHOO!! this can be done by providing hooks for automation, providing some extra UI. If a feature is a black box, put a light bulb in it... light it up! The area will get stabilized faster, and both you and the tester can move on to the next feature!!
Hi Lana,
ReplyDeleteNice post, I wanted to also introduce you to a QA model I am promoting. Take a look and if interested you could use as well
Cheers
Oops!!
ReplyDeleteMissed the url
www.budgetqa.com