Wednesday, December 13, 2017

Cambridge Lean Coffee

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.

1 comment:

  1. That... is a lot of really good notes.
    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.