Help them to help you
•
0 likes•407 views
This document discusses problems that occur when developers and testers do not work as a team and offers solutions to transform an adversarial "they" relationship into a collaborative "we" relationship. It identifies issues like developers not reporting all bugs, forgetting to inform testers of changes, and dismissing tester-filed bugs as trivial. The document recommends rewarding developers for bug reports, helping set up a testing environment, and emphasizing the customer perspective to improve collaboration.
More Related Content
Similar to Help them to help you
Similar to Help them to help you (20)
More from Tabăra de Testare
More from Tabăra de Testare (15)
Recently uploaded
Recently uploaded (20)
Help them to help you
- 1. Help them to help you How to help developers to feel comfortable while helping you in testing
- 2. Problems • “They” do not report bugs they find • “They” forget to inform testers about changes to be tested • “They” fight against testers filing “Trivial” bugs • Lack of a testing environment (testing in prod)
- 3. Biggest problem (in my opinion) • “They” • Get rid of “They” – transform to “We” • Make “Them” understand you are using “We” • Make “Them” switch to “We”
- 4. Problem (and solution?) • “They” do not report bugs they find • Better to file the bug before customers do • Help in filing the bugs • Respect “their” privacy, but reward “them” by letting “their” manager know
- 5. Problem (and solution?) • “They” forget to inform testers about changes to be tested
- 6. Problem (and solution?) • “They” fight against testers filing “Trivial” bugs • Perhaps “Trivial” for them is not Trivial to customers (important customers) • When “Trivial” issues prove to be “Critical” to customers, proceed with care
- 7. Problem (and solution?) • Lack of a testing environment (testing in prod) • Highlight the risk of testing in prod • Show examples of products where testing environment helped avoid angry customers • Help setting a test environment
Editor's Notes
- Them - developers
- How to make this happen: First, convince yourself that you and the developers have the same goal – to deploy “good quality” (will not get into details what “good quality means”) projects to production.Second, convince developers about this: - when you file bugs, be very careful not to sound personal – make the bug report as objective as you can. If you are adding subjective opinions make this clear (mark the subjective part). - with every occasion show them that you care about the product, not about what you think is good for the product – if you signaled an issue which was not solved, if customers complain about the same thing, do not say “I told you - if you have information which would help them, share it - if you can help with some tasks – like setting up test environments, do it - if you can help them fight against requirements they do not consider right, do it (in the case you are thinking the same about those requirements) - if they express a concern about the way the project is managed, try to expose the issue (if you feel the same). They could be “afraid” to expose their concerns, it should be easier for you, your management should be separate (in fact anyone should expose their issues with the management, but not everyone does it – NOTE: I am not pushing you to get fired, think before acting :D) - if you file “strange” bugs motivated by “possible customer complaint” and you are proven wrong, apologize for wasting their time .
- If customers find bugs we knew about, we should be able to tell them: “Yes, we know about this issue, we are working on it/we decided not to fix it”. This would improve the perception of quality for the customer (at least this is what I think – it is better to say that the issue was triaged instead of saying “We did not know about this”).Respect their privacy – some developers will not want to have their name associated with bug reports – it could make their work relationship with colleagues worse. Respect this and do not mention their name in the bug report. Make sure to ask them if they want their name mentioned or not.Reward them – if they are letting you know about issues/possible problems, let their manager know that they are interested in the quality – but do not mention exact issues unless needed.
- 1. Establish a “process” – as simple as setting a place for developers to write down the changes at the moment the submit the code – this way, when it is time to test it, you can look at the whole change log.
- If developers fight against filing “Trivial” bugs, you could add comments in the bug description stating that you are aware that this is “Trivial” but you would like to first see the customers opinionIf customers consider a “Trivial” bug as “Critical”, take care on how you handle the situation. You have to talk with developers to show them you were right, without saying “I told you so” . Make them understand that filing “Trivial” bugs does not harm them, it helps them (at least they can say that the bug was known and triaged).
- If developers do not have time to set up a test environment, do it yourself.