Cambridge Lean Coffee (Hiccupps)

On December 15, 2016, in Syndicated, by Association for Software Testing

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?
Edit: Katrina Clokie followed up on this question in The Testing Pendulum: Finding balance in exploration.

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.
Edit: Me and Anders Dinsen followed up this question in What We Found Not Looking for Bugs.

Comments are closed.

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!