I am currently a graduate tester in a scrum team, and am about 1.5 years into my career as a tester.
In my company we have had quite a lot of discussion about whole team testing over the last few weeks. In general my scrum team are quite good at this, they consider the most appropriate automated tests to write and help with manual testing when required. We are not perfect however, and I am looking for new ideas and processes to further improve the quality of our work.
I feel like at the minute defects are discovered too late in the development process, and that we could shift left and discover these earlier. I also feel like sometimes not all team members understand our user stories when they pick them up, and that they become familiar with the stories while writing the code.
I’ve been doing some research into TDD, but what I have discovered is that would be a large change to how the developers work, and not something that I as a graduate tester can mandate. I’ve also read that to make TDD successful the developers need to pair with someone experienced in TDD, and I do not have anyone with such experience available.
So I would love to know if anyone has any other ideas that I might be able to bring to the scrum team? Sort of along the lines of TDD lite - if such a thing exists!
It sounds like the pain point you’re trying to address is around requirements and/or stories not being easily workable? I don’t think TDD itself would help much there, and in fact, could be a lot of effort that just reinforces bad implementations/requirement misses.
Definitely focus on shifting left, but I’d be looking into more process oriented things like:
How stories are written - maybe you need to add some sample input/output, acceptance criteria, context/background, etc. Lots of possibilities to try and build common understanding at this stage, but heavily dependent on what’s currently being missed. Remember to tweak and iterate - heavy handed process/templates are challenging to get buy in on, so instead focus on small changes
Improve the pointing of the stories - By the time people are playing planning poker, they’re hopefully on the same page and understanding before they point. Maybe pointing has become pro forma and it’s not helping people reach a common understanding of the story? It might be worth putting more time into pointing, encouraging people to clarify requirements, edge cases, acceptance criteria, definitions of done, etc before pointing. If you aren’t pointing, it might be worth exploring adding pointing to your ceremonies to help guide these discussions and keep everyone aligned.
Are your standups working? - have they just become pro forma Y/T/B instead of talking about actual issues, questions, etc? Figuring out ways to make them more productive, getting people to bubble up questions as “they become familiar with the stories while writing the code”, etc
Encourage pairing/mobbing - if there are nebulous stories, encouraging early collaboration on them, especially with a mix of experience, can help fill in some of these gaps
code review process - unclear what your review process looks like, but getting reviewers to focus on tests for new code might help
psychological safety - are people afraid to ask questions/clarify implementations? has the team put quantity of output ahead of quality of output or incentivized other behaviors that might be detracting from a culture of quality?
I think you might be right that some of our scrum ceremonies have become pro forma and we are not getting as much out of them as we could.
I also like the idea re: code reviews focussing more on the tests. I’ll have a chat with the developers to better understand their code review process at the minute and where they focus efforts.
Something that has really helped me with previous teams is holding testing discussions about new features.
Here’s a brief guide, feel free to follow up with questions
hold them when reqs/ user stories exist but before code is written
invite everyone who has been involved with the feature and who will be involved
prepare your list of questions and your assumptions
prepare notes on how you would test it
be specific and use examples. For example say, when I enter an invalid email address such as invalid@email I expect this error message to show (then refer them to the error message)
the goal isn’t to be right, the goal is to be explicit so people can correct you if you are wrong
ask people, is there anything I’m
Missing?
ask people do you have any ideas on how else we can test this
Hey @cdaveys great topic indeed and considerations. I certainly agree with what was suggested by @ernie.
While I’m no expert in processes here is my “2 cents” I can share what we’ve tried to consciously enforce and that being when picking up stories, ask the question "Are these stories/issues meeting our DoR (Definition of Ready)?
It might seem disconnected but the earlier stories are developed based on the agreed DoR the more we avoid having missed requirements or defects occurring later in the software. I think it’s easy to assume that as a development team we all understand the requirements and can pick it up and run with it immediately. Maybe a refresher of the WoW(Ways of Working) helps to bring it back in focus also.
It sounds like maybe only devs are reviewing code? This could be a growth opportunity for you (or other testers) to start learning to read code and related tests, and shifting the testing efforts left as well.
Coming from a point where TDD would be no option for the team I am working with. I am trying to advocate for clarity of requirements. In day-to-day work that means:
Asking during the story explanation, “the stupid question”, even if I know the answer, to let others know too
Using examples, like “So if we have this third option how would it look like on the pdf?”
If there is no description, lacks clarity in the requirement I might demand a 3 Amigo session (PO, dev, test)
Another thing, we are trying lately is to combine the wishes of around 10 different stakeholder types (internally, externally) we are using example mapping to discover the requirements. Reveal, where wishes match and find the differences of requirements that may sound identical.
Hi @cdaveys
TDD is always a great asset to invest in. As you wrote however it is not something you should just introduce and hope for the best. First of all it requires a lot of dicipline - so you really want your developers to want to use it instead of forcing them. Otherwise it will just not happen. If you don’t have someone in the team who can function as a mentor invest in the team by giving them the opportunity to gain the necessary knowledge. Maybe you have also have some small non critical software components where the new knowledge can be applied first.
You said also that the user stories are only fully understood - once ppl start to write the code. I am not sure if that is really a problem or just a fact as naturally ppl need to get a deeper understanding of a story once they start the actual coding🤔
Have you tried 3 Amigo Meetings? Those really helped us generate a common understanding of User Stories, possible impacts and testing before coding happens. This prevents bugs.
We are still working on shifting left and it’s not been easy. Our devs a really old school and don’t get the importance of testing and why they should be doing it as well. We created a Code Review checklist that includes testing. Currently working on deepening their understanding of testing through exploratory testing activities for the whole team.
Thanks for your response Andrea above suggested 3 amigo sessions as well. I don’t think I have ever been involved in a formal 3 amigos session after refinement/before writing code. In my experience my company seems to schedule these earlier, usually before a refinement when there is very little known about our requirements. The developer that eventually picks up the story likely would not have been involved - so this is a great idea to run a similar session with those completing the work if anything is unclear.
That being said, something in our refinement sessions must not be working correctly if everyone is not on the same page by the end of the session.
This is a very important observation, I’ve over 20 years experience and I still would not be going to bat to tell developers do their jobs with my tester hat on.
I sometimes change hats though, I’ve done development including TDD, good experience with code reviews and was a PM for a long time so with a different hat on I can guide people to consider some other practices but its only because I have done those roles personally that I feel okay to throw them out there.
I sometimes get a PM or a developer suggesting to me that I should write more test cases or follow a testing practice they spent ten minutes reading a blog on, as a suggestion its fine but I’d really not be keen if someone tries telling me how to do my job.
I view testing often as simply asking awesome questions to help guide the team and product forward.
Often these questions will be in relation to risk, if the tester is only involved later in the project those questions often get restricted to hands-on asking the product itself questions.
For me this is the biggest opportunity in shifting left, getting involved from the start of the project testing theories, ideas, business value assertions and discovering risks or future blockers that help guide the team. I am rarely full time at the start of a project but jumping in for some sessions and asking awesome questions can add a lot of testing value to any development approach.
say, when I enter an invalid email address such as invalid@email I expect this error message to show (then refer them to the error message)