Resolved To Test

A discussion on a group I belong to on LinkedIn got me thinking about bug/defect tracking and the different systems I’ve used for it over the years along with the relative successes or failures of these systems.

Tracking bugs is a core need in software development. Bugs can be generated by the development team (all disciplines within the team), by customers, by product support, etc. This insures bugs that are found are followed, even if not fixed, and metrics from bug tracking help determine things like when a version of the product is ready to release, when a QFE or patch may be needed, etc.

For such a simple task, bug tracking can quickly become a complex and sometimes frustrating chore and this is often due to one or more of the following:

• Tracking More Than Bugs
  This tends to lead to field creep – an explosion in the fields in the bug form – in order to accommodate things like specifications, work items, customer issues, etc.
• Tracking Every Available Piece of Information
  Without a basic agreement on what information MUST be in a bug report, the tendency is to track every piece of available information so nothing is missed. This is another contributor to the issue of field creep.
• Lots of Required Fields
  If fields are made “required” when they are not always applicable, people will put junk in them to get past the requirement. At the point this starts to happen, the usefulness of that field’s information disappears. The same thing happens when the list of required fields is large – people will put anything in just to be done with the bug report.
• Field Overlap
  If there is more than one place to put the same exact same piece of information, users will begin to make mistakes, omit that information, or enter contradictory information.
• Lack of User Training and Documentation
  Users of the bug system should be trained in the way its implemented and used and what is required of them along with a good idea of the process used to address bugs and the bug lifecycle in use in their company. When the first solution to lack of compliance is to set up the bug tracking system to enforce rules, it can cause worse behavior because the users still don’t know the rules, instead they work at getting around the automatic enforcement.
• Shared Bug Tracking
  Sharing bug tracking among multiple projects, sometimes throughout a company, can lead to huge bug forms with a lot of redundancy or fields that are meaningless to all but one project.
• No Central System Control
  Lack of a single person or core v-team that is responsible for managing the bug tracking system can lead to both having no one in charge of fixing issues that inevitably arise, but also to people just randomly adding fields or field contents without a master plan or vision.
• Off the Shelf Configuration
  Using a bug tracking solution off the shelf, without reviewing it and possibly customizing it for the product, the development process and the needs of the team is akin to the square peg, round hole problem.
• Bug Tracking not Periodically Reviewed
  Using the same bug tracking solution and setup over and over without reviewing it periodically to insure it’s still applicable and optimized for the needs of the company, team and product can eventually erode its usability and usefulness.

These are the potential red flags from my own list and years of managing bug databases and bug tracking systems. I’m sure there are more and you can leave those in comments.

I was reading a blog post on uTest.com by James Whittaker called Thoughts on the Future of Software Testing and one thing that really jumped out at me from it is the issue of mentoring in Software Testing.

I’ve had the benefit of several very good mentors and, in turn, have mentored other testers over the course of my thirteen years in software testing. I know James has put out a call to testers to take mentoring seriously and I’d like to second that but also offer a short list of does and don’ts from my own experience:

• DON’T wait for someone else to break the ice. If you have another tester your respect and would like to learn from, go ahead and ask if they can spend a little time teaching and mentoring you. If you see a promising tester you think you can help, ask them if they’d like you to mentor them. The worst thing that can happen is that they turn you down.
• DON’T treat a mentor/mentee relationship as if it were a marriage for life. Even informal or short term mentoring relationships can have considerable value without having to sign up for a long-term or potentially unsustainable relationship.
• DO set expectations on both sides. Part of a good mentor/mentee relationship is having a clear and upfront agreement on expectations from both mentor and mentee. Lack of this typically leads to disappointment, resentment and a failure of the relationship.
• DO keep an open mind. If you go into a mentoring relationship, you won’t get much out of it if you aren’t open to other ways of doing things or the learning opportunities you may encounter.
• DON’T limit yourself to only other testers as mentors or mentees. Learning from other disciplines and teaching test theory and techniques to other disciples can be valuable as well.

Mentoring can be a great help to any professional, and testers in particular.

There’s a site/service called Grouply that is purported to help you manage all your Yahoo groups in a centralized place. Sounds good, right? Especially if you have a lot of group memberships.

But rumors abound about Grouply and how it operates. Some reports are that when you sign up for it, it changes all your membership emails to be username@grouply.com and then any mail in the groups you subscribe to are indexed and resourced by Grouply. This means that anyone else on those groups has, without their permission, had their assumed privacy removed.

Now, everyone should realize that there is no real privacy on the web. None. And the memory of the web is pretty darned infinite. But we’ll ignore the fact that illusions of privacy are just that.

But my most basic issue with Grouply is very simple – it requires you to disclose your Yahoo username and password to a third party service. At that point, you’ve lost all control. You have no idea what, how or when the third party will use that information. You certainly have no control over it.

So the basic security advice applies. Never give out your username and password.

Here’s a mantra everyone, especially every tester, should learn and repeat regularly….

ALL TRUST IS MISPLACED

Users are warned constantly to never open files from someone they don’t know but they really need to be even more pessimistic than that. A lot more pessimistic. Just because something comes from the account of someone you know or recognize does not mean it’s actually from that person or that they know it’s being sent.

Chuck and I became aware of this variant when he received an instant message from a former co-worker he’d not talked to in many months. The text of the message said “Is this YOU?” and it contained a link that, at first glance, appeared like it might be an image of some sort due to a ViewImage word in the link. When he clicked on it, it wanted to either run or save an MS-DOS application. Needless to say, he didn’t allow it to do either.

Instead we passed the information on to an antivirus group.

Sure enough, it was a new variant of Win32/Pushbot called Win32/Pushbot.BE – at least that’s what one vendor calls it. Naming of viruses and variants, especially if they are not a single type only tends to be more than a little inconsistent across vendors.

Now if Chuck had been a little less suspicious, he’d have likely fallen for that bit of social engineering. It played on people’s desire to see whether someone who knows them found a picture of them and what that picture might be. Because it’s someone they at least know well enough to add to their messenger list. It goes back to a mix of trust and human curiousity.

If he’d allowed the file to run, it would have spread by sending itself to all the members of his friends list as well.

In case you DID fall victim to this worm, you can see how to remove it on Microsoft’s Malware Protection Center entry.

My name is Maura van der Linden and I’ve been a software test engineer for about a decade. I tend to specialize in test theory and security testing and I talked my husband, Chuck, into this blog as a way to tell more than just each other about testing, the trials and tribulations of testing and even some real test content!

We’ll see how it goes!