Blog

Cambridge Lean Coffee (Hiccupps)

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

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!