I was a bit disappointed that I never saw a response to my questions on the Atlassian blog posts in order to gain a bit more context. However I do realize the comment ping pong can go on and on.
I read quite a few blog posts this week, but nothing really got me really thinking. I did come across a tweet that was interesting by Michael Kelly. He tweeted "There is nothing more depressing to me then logging bug after bug after bug. Feels like a waste, but it's clearly needed. Sad."
I recently experienced a situation where we had to stop testing for a similar reason. Two many defects were being found in one specific section of a website. It was not the highest risk section so we felt the value of the testing although important was not the best use of the time available.
Mike's tweet made me wonder about when is it appropriate to stop testing if there are too many defects. If this occurred in a single session, I might recommend the team spend another iteration before the next test session is scheduled. Another angle is that I might call a test dojo where the team is all in a room testing together. Perhaps we can find and fix as we go. Developers typically take a lot of pride in their work, so they will be responsive to rapidly fixing things or openly admit they need more time or assistance.
I believe I also read a tweet from Lisa Crispin that illustrated a paired story deliver approach. I like the approach but the paradigm may not always work. In the case of finding two bugs it might be a great time for a tester to offer to pair.
To many bugs from my point of view is most likely hurried work. I guess it could be due to poor design, lack of functional detail, or something else that was poorly communicated. Regardless of the cause I would recommend that testers find the most professional and collaborative way to adjust the situation.
I agree with Michael that it can be a huge time sink having to document a large volume of bugs. Personally I would rather see them get fixed than create an object in some system that now needs to be managed to resolution.
I guess find the bug nest early and get creative on a rapid solution.
Happy Testing!
I recently experienced a situation where we had to stop testing for a similar reason. Two many defects were being found in one specific section of a website. It was not the highest risk section so we felt the value of the testing although important was not the best use of the time available.
Mike's tweet made me wonder about when is it appropriate to stop testing if there are too many defects. If this occurred in a single session, I might recommend the team spend another iteration before the next test session is scheduled. Another angle is that I might call a test dojo where the team is all in a room testing together. Perhaps we can find and fix as we go. Developers typically take a lot of pride in their work, so they will be responsive to rapidly fixing things or openly admit they need more time or assistance.
I believe I also read a tweet from Lisa Crispin that illustrated a paired story deliver approach. I like the approach but the paradigm may not always work. In the case of finding two bugs it might be a great time for a tester to offer to pair.
To many bugs from my point of view is most likely hurried work. I guess it could be due to poor design, lack of functional detail, or something else that was poorly communicated. Regardless of the cause I would recommend that testers find the most professional and collaborative way to adjust the situation.
I agree with Michael that it can be a huge time sink having to document a large volume of bugs. Personally I would rather see them get fixed than create an object in some system that now needs to be managed to resolution.
I guess find the bug nest early and get creative on a rapid solution.
Happy Testing!
No comments:
Post a Comment