“Added a validation in the service codes to make sure either "DSP" or "Already in GE" is true for Accession.”
Do your devs write bug resolution comments? If not, ask for them. All bug tracking systems have a spot for devs to write notes about what they did to fix the bug. It’s tough to get devs to write their resolution but it’s well worth the pain.
When you verify fixed bugs you should be asking yourself what regression testing is necessary; what did this bug fix break? If you don’t know how the dev fixed it, you don’t really know what could have broken as a result. Sometimes, devs are cool enough to provide tips of where other bugs may be lurking…
“This problem is bigger than the shoot value hiding. In fact, the entire preCat is not reloading after a save which is hiding other bugs (UI refresh and service layer issues.)”
Some of my devs are terrible at writing resolution comments. Sometimes I have no idea what they did to fix it. My emotions tell me to Reopen the bug. But after listening to my brain, and asking the dev what they did, I usually discover an unexpected fix that still solves the problem. Dev comments would have been nice.
You may also discover your devs share some of your angst when dealing with scatterbrain stakeholders, as evident in comments I’ve recently seen such as the following:
“UI now allows multiple preCats and DSP check box, even though earlier requirements conflict with both of these.”
“Yet another requirements change. The need dsp check box has always been there. It was expressed that it should only be visible when there IS and accession, but I guess we are changing that.”
Poor dev guy. I feel your pain. I miss the good old pre-agile days too.
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 ...
Blog Archive
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
Want to encourage your developers to write more? Why don't you show them that you have enough respect to refer to them as "developers" or "engineers" or something more reasonable than "devs". Demonstrating that you care so little about them that you're not willing to use an entire word to refer to them is a great way to erode their trust in you and their interest in what you say.
amoore,
If you read more of my posts, you'll hopefully see that I respect my "engineers" and promote teamwork between them and testers. And that includes the tongue and cheek fun we have.
Sorry I touched a nerve.
I mainly put in a bug comment since it also helps me as a dev when someone asks a question about a bug so that I know what I did to fix it. Or sometimes just to vent.
If a side-effect of me writing a resolution comment is that it also helps a QA person then so be it.
P.S. - i disagree with amoore and don't consider the word "dev" derogatory, and haven't heard of it being associated as such just because it's used in a shortened form.
If everyone were that sensitive then the reverse and calling people "QA" would then be considered disrespectful vs. saying the entire word "quality analyst"?
I think it's just a matter of getting the point across as quickly as possible without unnecessary formalities (like using contractions).
Developers rarely leaved any resolution comments at my past projects. But the last dev team I worked with has this practice, and indeed it helps a lot.
It gives a clue to tester how to verify and regress certain bugfix and also gives better understanding of the inner structure of software you test.
So I'm all for it!
Christine