My first job out of college was teaching software applications like MS Access, FoxPro, and Act!. Back then, in the late 90's, demand for these types of classes was much higher than it is today. This, I believe, is because today's software users are more sophisticated. Most have already been exposed to some flavor of word processing, spreadsheet, or email applications. Many can even teach themselves software or look online for answers.
After accepting the above, it's not too great a leap to also accept that modern software users are aware that software is not perfect. They have experienced application hangs and strange system errors and many users learn to avoid these bugs or recover via a reboot or similar.
If the above is true, why can't all bug lists be public? The culture of my dev team prefers to keep the bug list hidden because they believe users will have trust issues if we admit to known production bugs. I disagree. In fact, if properly facilitated, I think a public bug list can actually build user trust. Users are smart enough to see the value in having their software earlier, even at the expense of known bugs.
What do you think?
My opinions do not reflect those of my employer.
Subscribe to posts
RSS
Popular Posts
-
After attempting to use Microsoft Test Manager 2010 for an iteration, we quickly decided not to use it. Here is why. About 3 years ago we f...
-
Data warehouse (DW) testing is a far cry from functional testing. As testers, we need to let the team know if the DW dimension, fact, and b...
-
I recently read about 15 resumes for tester positions on my team. None of them told us anything about how well the candidate can test. Here...
-
Want your bug reports to be clear? Don’t tell us about the bug in the repro steps. If your bug reports include Repro Steps and Results se...
-
When someone walks up to your desk and asks, “How’s the testing going?”, a good answer depends on remembering to tell that person the right ...
Labels
- Teamwork (86)
- bugs (81)
- process (66)
- software testing career (49)
- automation (45)
- writing tests (38)
- Personal Excellence (37)
- Managing Testing (33)
- questions (31)
- language (29)
- testing metaphor (23)
- Tools (19)
- STPCon (10)
- heuristics (10)
- Test Cases (9)
- test blogs (9)
- CAST (8)
- Presentations (8)
- Test This (8)
- metrics (8)
- Rapid Software Testing (7)
- Silliness (7)
- Data Warehouse Testing (6)
- Kanban (6)
- STARwest (6)
- Testing Conferences (6)
- Agile (4)
- Bug Report Attributes (4)
- Don't Test It (4)
- Stareast (4)
- documentation (4)
- Failure Story (3)
- Lightning Talks (3)
- Testing Related Ideas (3)
- You're A Tester (3)
- Performance Testing (2)
- Podcast (2)
- ATDD (1)
- BDD (1)
- HATDD (1)
- Meetups (1)
Who am I?
- Eric Jacobson
- Atlanta, Georgia, United States
- My typical day: get up, maybe hit the gym, drop my kids off at daycare, listen to a podcast or public radio, do not drink coffee (I kicked it), test software or help others test it, break for lunch and a Euro-board game, try to improve the way we test, walk the dog and kids, enjoy a meal with Melissa, an IPA, and a movie/TV show, look forward to a weekend of hanging out with my daughter Josie, son Haakon, and perhaps a woodworking or woodturning project.
My other passion is woodturning.
Test blogs I try to read
I think our users aren't too bright, and would mistake common bugs that can be fixed with an unstable product, if a product is indeed stable but we have 1-200 bugs that are mostly low priority, it sends the wrong message to our users.
Eric,
One reason for keeping bug lists private might be fear of litigation/lawsuit from end users? I'm not sure how the law works in respect to that.
I also agree with what desertfox mentioned.
Adam
I have to disagree with desertfox and Adam and agree with Eric.
I believe it's better for users to know that Dev are aware of the bugs and in turn working on resolving them.
Take for example the scenario that desertfox mentioned, if there are 1-200 low priority bugs then users are going to notice them and wonder why they weren't discovered by Dev/Test and this will cause mistrust and lose of confidence, if Dev is upfront and say 'Yes we are aware of these and they will get fixed and if you notice anything else please let us know and we'll sort those out too' it builds a good relationship.
As for what Adam has mentioned surely a bug which could lead to a lawsuit is exactly what you need to let the world know about?!
Not letting users know is what would lead to the lawsuit. If they are aware then the responsibility is with them.
Are you advocating the bug lists be made available to only the users of the application or the public (whether or not a member of the public is a user of the application)?
I think that once Development and Testing are finished with their work and the application has been deployed/ distributed to the users, selected known bugs can be provided for viewing by the users.
Making all known bugs visible to each user might de-motivate a user (especially if the number of bugs is large). It can give rise to unrealistic expectations (a user might expect prompt resolution of any bug while being unaware of the constraints being faced by the development team).
Inder P Singh,
Great question. It forces us to think about a variety of software types (e.g., shrink-wrap vs. custom).
I think the bug list should be available to the general public whether they have a login or not. Again, I believe it shows more integrity for the app to make the bug list public, even in an extreme case where there may be 1000 open bugs.
Look, if the stakeholders decide to go live with 1000 bugs, they obviously assume there is enough working functionality to provide value to someone who matters. The quality of the software will speak for itself.
I think as years go by, more users will agree with me.
Eric, I posted a link to this post on sqaforums: http://www.sqaforums.com/showflat.php?Cat=0&Number=510106&an=0&page=0#Post510106
Thought you might be interested in reading the responses.