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.
Image: https://flic.kr/p/51zjaK
Comments
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/
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.
Post a Comment