Wednesday, December 14, 2016

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?
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.

2 comments:

  1. Thank you for posting these notes! And hello! I'm T.J. Maher, a new co-organizer for the newly rebranded Ministry of Testing: Boston Meetup .

    I've explored a bit about the Ministry of Testing after first hearing Rosie Sherry's interview with TestTalks.com. I love the Software Testing Club blogs, contributing a few articles here and there. And I love the Testing Feeds! I really feel connected to the software testing community as a whole, keeping up with them. And I really love the wonderful ideas Ministry of Testing has, such as #30DaysOfTesting!

    When you talk about a "Lean Coffee", is it like this? https://www.retrium.com/resources/techniques/lean-coffee

    ... if so, this is an idea I may want to steal! ... What is the maximum size you have for your groups?

    Pleasure virtually meeting you!

    -T.J. Maher
    http://www.tjmaher.com/

    ReplyDelete
  2. Hi TJ,

    Yeah, that's the kind of thing. We typically have one hour total - the meeting is before work in the morning - and so the setup timings are more compressed.

    We also timebox the discussions at 8 minutes followed by a vote to continue or not. If we choose to carry on then a further 4 minutes, vote, 2 minutes.

    See e.g. http://agilecoffee.com/leancoffee/

    We typically try to keep groups to around six people, so we run several groups at each meetup.

    Hope that's helpful.

    ReplyDelete