A couple of days ago, @redgate hosted Cambridge Lean Coffee. Notes from the group I was in are below.
How much is too much testing?
- The discussion started with a suggestion to Michael Bolton’s blog post ‘When Do We Stop a Test?‘
- One of them in the group raised that we should avoid measuring our testing in test cases.
- Many of us stop testing when the allocated budget is over.
- Depends …
- on the product – medical software may require more testing compared to testing a simple website.
- on risk, subject, impact, context etc.
- When we run out of ideas or have all the answers to the questions we had in mind before we started exploring.
- Questions such as ‘Can I finish testing?’, ‘Am I expected to finish testing?’ come up when someone asks ‘How much more testing remains?’
- Some people have code coverage as the yardstick.
Lessons learned in software testing
- We have to work with people
- Efficient communication is very important to bridge gap between Dev and Test
- Avoid blame games
- One of them in the group felt that occasionally Testers have to be gatekeepers of the product since the stakeholders are too keen to release.
- Looking at the product for a long time can make one blind to some of the bugs. So it may be wise to talk to the experts once in a while.
- Moving teams within the company can be useful. The way we see and interact with the product can vary. Fresh pair of eyes is always useful.
What strategies do you use to learn when you start at a new company?
- User guide/manual as a map to start exploring
- Request to shadow or pair with others
- Ask for induction meetings if they are not setup to know about different teams
- Find out about the proprietary tools used in the company
- Look at testcases if they exist
- Bug management system can be useful to find which are the risky areas of the product
- Ask a lot of questions
- maybe in the wiki and request people to contribute answers
- maybe in scheduled time slots
- to the domain experts
- Draw architecture diagram of the software, explain what you have understood and ask others to correct your understanding or fill in any gaps
- Mindmaps can surface any inconsistencies in the perceptions of different people which itself is interesting to explore
Legacy test automation framework
- The person who raised this
- was part of a Scrum team
- wanted to know how to best deal with improving legacy test automation framework where the team members were not fond of it.
- Discussion revolved around
- exporting a few tests at a time from the legacy framework to a new framework rather than a bulk move
- don’t be afraid to delete tests that haven’t been delivering value
- slow down now to speed up later
- migrate the tests related to stories worked on in a sprint as part of that sprint itself
- this can be part of Definition of Done
- new test framework should be a by-product from the various sprints if the time to work full time on the new test framework is unavailable.
- in the questioner’s Scrum team if there isn’t an improvements backlog, they could create one and add stories for working on the migration of tests from legacy to a new test framework. They can work towards reducing technical debt.