Cambridge Lean Coffee

This month’s Lean Coffee was hosted by Cambridge Consultants. Here’s some brief, aggregated comments and questions  on topics covered by the group I was in.

How to get work in testing having been a developer for 25 years?

• The questioner is an experienced developer/consultant who consistently sees “poor quality” development.
• You don’t need a formal background; it’s possible to learn testing on the job.
• The job market seems to be about ‘technical testers’ these days, so a developer could be suited to it.
• Are you applying for roles and being rejected. (Not yet; this is a recent idea.)
• What do you mean by testing? (“Separation of concerns, loose coupling, SOLID, good requirements. Unit testing is just there for the taking … you just do it.”)
• They sound like full life-cycle or architectural ideas that might enable testing or reduce the need for it? (“Yes.”)
• Think about what motivates the person you’re pitching to. What do they care about? Ask what they’re worried about, the risks they perceive.
• Testing is a stigma for some people.
• Perhaps don’t try to sell testing, so much as the value that testing can bring.
• Testing for its own sake is tedious.
• What is the context that you’re trying to sell testing into?
• In some cases, testing might be the wrong thing to suggest. For example a startup might need to move fast to get to market.
• Remember that it doesn’t matter how valuable testing is to you, the key is how valuable it is to them.

Test Managers must have been testers.

• Are we talking about technical management or line management? (The questioner was more interested in line management.)
• Other things being equal, I’d rather have a good people manager than a tester as a manager.
• Testers will benefit from access to someone with technical knowledge, if not their manager.
• A good manager can give the value proposition from the company perspective. Someone focused on testing might not do that so well.
• A good line manager understands your needs and helps you through challenges in all areas (not just your discipline).
• A non-testing manager can offer a useful alternative perspective, force you to speak in plain language.
• A non-testing manager might not understand the value that you’ve given on projects (and does salary review, appraisal etc) but a good manager will ask relevant people for that feedback.
• What’s the best thing a manager has done/does for you?
• … (non-tester) pushed me to develop myself; in particular he saw that I could benefit from public speaking experience.
• … (non-tester) trusts me to get on with stuff – but asks me hard questions
• … (tester) supported me; gave me time to learn
• … (tester) defended me from company crap and allowed me to do good work that needed doing
• Can we differentiate people who see value in testing and in testers?
• Line management is about people not activities.

How detailed should exploratory testing be?

• The questioner has been accused of going “too deep” when testing, after finding bugs outside the mission scope.
• ET is about learning the product; about iterating, debriefing and focusing.
• Look at Explore It!
• Sometimes the mission is “I just want you to check the feature”.
• Sometimes people don’t want to hear about bugs because they might e.g. stop the product shipping.
• Sometimes people assume that “I found a bug” means “you must fix the bug I found”.
• Are there other things that you could have done that would have been more valuable?
• What did your accusers expect from you?

We can’t find all the bugs, so which ones shouldn’t we look for? How?

• Think about the cost to the organisation if an issue comes to light. What do the stakeholders care about?
• Quality is in the eye of the stakeholder.
• Don’t look for the bugs that the customer is likely to find.
• You shouldn’t look for the cases that aren’t important.
• Is that very practical advice? How do you know?
• Yes, it is practical advice, it can force you to think about or find out which are the important cases.
• … for example, performance is not important, so we won’t look for bugs there.
• … which isn’t to say we won’t find them in passing, of course.
• But testing is a way to uncover the things that are important.
• … ideally it will be a continual dialogue with stakeholders which focuses the investigation.
• If you’re not going to do anything with the information, then don’t look for it. There’s no value in reporting if no action will result.
• But sometimes the aggregation of bugs in an area is itself significant, e.g. one typo on a page vs 300 typos on every page.
• That’s an interesting negative (“shouldn’t”) because normally we focus on the things we are doing or should do.
• Isn’t the premise here questionable? Do testers really generally go out looking for specific bugs?
• Perhaps testers will be focusing more on the areas of potential risk and ways in which those risks might be exposed?
• But you might know of, say, a repeated anti-pattern within the development team that you would look for explicitly.