This month's Lean Coffee was hosted by us at Linguamatics. Here's some brief, aggregated comments and questions on topics covered by the group I was in.
Performance testing
- We have stress tests that take ages to run because they are testing a long time-out
- ... but we could test that functionality with a debug-only parameter.
- Should we do it that way, or only with production, user-visible functionality?
- It depends on the intent of the test, the risk you want to take, the value you want to extract.
- Do both? Maybe do the long-running one less often?
Driving change in a new company
- When you join a new company and see things you'd like to change, how do you do it without treading on anyone's toes?
- How about when some of the changes you want to make are in teams you have no access to, on other sites?
- Should I just get my head down and wait for a couple of years until I understand more?
- Try to develop face-to-face relationships.
- Find the key players.
- Build a consensus over time; exercise patience.
- Make changes incrementally so you don't alienate anyone.
- If you wait you'll waste good ideas.
- Don't be shy!
- There's no monopoly on good ideas.
- Can you do a proof-of-concept?
- Can you just squeeze a change in?
- You don't want to be a distraction, so take care.
- Organise a show-and-tell to put your ideas out there.
- Give feedback to other teams.
- Attend other team's meetings to see what's bothering them.
- Get some allies. Find people who agree with you.
- Find someone to give you historical context
- ... some of your ideas may have been had, or even tried and failed.
- As a manager, I want you to make some kind of business case to me
- ... what problem to do you see; who does it affect; how; what solution do you propose; what pros and cons does it have; what cost/benefit?
- Smaller changes will likely be approved more easily.
- Find small wins to build credibility.
When did theory win over practice?
- I've been reading a performance testing book which has given me ideas I can take into work on Monday and implement.
- I've been reading TDD with Python and it's changed how I write code
- ... and reinvigorated my interest in the testing pyramid.
- Rapid Software Testing provided me with structure around exploratory testing.
- ... I now spend my time in the software, not in planning.
- Sometimes theory hinders practice; I found that some tools recommended by RST just got in my way.
- I heard about mindmaps for planning testing at a conference.
- I've been influenced by Jerry Weinberg. His rule of three and definition of a problem help me step back and consider angles
- ... the theory directly influences the practice.
How many testers is the right number?
- That's a loaded question.
- It depends!
- The quality of the code matters; better code will need less testing
- ... but could the development team do more testing of their own?
- How do you know what the quality of the code is, in order to put the right number of testers on it?
- Previous experience; how many bugs were found in the past.
- But the number of bugs found is a function of how hard you look.
- Or how easy they are to find.
- Or what kinds of bugs you care to raise.
- You need enough testers to get the right quality out at the end (whenever that is).
- Our customers are our testers.
- Our internal customers are our testers.
- We have no testers
- ... we have very high expectations of our unit tests
- ... and our internal customers are very good at giving feedback
- ... in fact, our product provides a reporting interface for them.
- Microservices don't need so many testers, but perhaps the developers would benefit from a test coach.
- If the customers are happy, do you need to do much testing?
- Customers will work around issues without telling you about it.
- It's helpful to have a culture of reporting issues inside the company.
- I see a lot of holes in process as well as software.
- You don't need any testers if everyone is a tester.
Image: https://flic.kr/p/8GzX7H
Comments
The recurring theme and consensus level tells me that not only is the Cambridge community maturing, but probably also getting better at communicating risk to project stakeholders/players too.
Post a Comment