Velocity was too high
Ministry of Testing
Last updated
Was this helpful?
Ministry of Testing
Last updated
Was this helpful?
Case Study: After some testing advice..... or advice in general... so i have been a one person testing team since our junior was let go, with a 7 person dev team throwing stuff towards me.... At the start i came in with good intentions, making BDD test cases for the requirements..... then as time came along it came clear velocity was too high to maintain this.... (i was working 12-14 hour days or more). So at this point, i informed i was falling back to exploratory testing only and a cursory "check it works" mentality.... Today i get a "show the new developer where the test repository's are"..... how do i handle this situation when frankly I've killed myself just keeping our heads above water? Do i stop trying to keep velocity and expose the bottle neck and go back to manual test cases...? So confused
Recommendation 1:
Yea in my last place the sprint retro's never happened. There is nothing stopping you from taking control of it and making them happen. You might find that the rest of the team will appreciate it. Consider using a 3 C's board https://leancentre.co.uk/product/3-c-concern-cause-countermeasure-problem-solving-dry-wipe-board/ getting people engaged is not easy..but you start to try to fix the way you work!leancentre.co.uk3 C Concern Cause Countermeasure Problem Solving Dry Wipe Board | The Lean CentreThe Lean Centre exists to provide you with everything you need to set-up and run a lean production facility, within a few clicks of a mouse! We are the only company in the UK to supply everything for the lean manufacturing facility. From Continuous Improvement Posters and Lean Training DVDs, to 5S Red Tags and Kaizen Supermarket racking.
-- Brian MacRoberts
Recommendation 2:
I understand the desire to keep chipping away and not be seen as the obstruction but the test isn't really the source of the bottleneck - it's on the team as a whole and sounds like it has more to do with the sprint planning, a misguided notion of what a good velocity is, WiP levels and why they're needed to preserve quality, and team responsibility for workflow. Whilst I applaud your dedication it might be time to let the cracks show so that the team can be aware and take responsibility?
-- Anonymous
Recommendation 3:
I have been the sole tester for what started out as a 2 person dev team. Now the size is 7 dev with just me as QA. I have brought up the point of increasing work load time and again and asked people to pause and consider but (not surprisingly) they havent given it much thought. The difference is, at least they acknowledge that there will be delays and there isnt much (very little tbh) doc/TCs/TPs etc. All the knowledge kind of lives and dies with me. Not a fan of this but I dont seem to have the choice. I worked 14-16 hrs in my last job which nearly killed me so i made it a point to not repeat it ever. One way i try to consider/contain the sprint velocity is to advocate for including test efforts in stories and make sure(or at least remind them) that a story/sprint is not complete unless it passes (for the lack of a better word atm) the testing criteria. One way might also be to revisit the definition of done.
-- Barkha
Recommendation 4:
In one of my old teams a definition of done for dev was that the developer had to do a demo to the tester (me) to demonstrate that the ACs were met. If the demo failed then it was easy for the dev to crack on with debugging/fixing, if it passed that then freed me up to do more in depth testing around those areas. The devs also added DoDs around making sure all unit tests were complete and passing, as well as their work being code reviewed before they demoed to me. It's not easy trying to get the change to take place and stick so don't be hard on yourself if it feels like you're wading through treacle!
-- Anonymous
Recommendation 5:
Damn, gut feeling is they are doing both agile and BDD completely wrong.I like being part of three five developer teams and products in parallel, four gets a bit much for me at times, two gives me time to experiment and study or perhaps help them on broadening their automation coverage, so about 1 to 10 is my personal preference.I'd really rather not do the basics of a developers job for them and that includes basic automation coverage all levels in the stack, I'm their to catch the things they naturally miss not to tick box they have a basic understanding of the sprint deliverable.Because they are missing the point of BDD and Agile its almost worth you stepping out completely, its not your main job to change the development process but you can flag it.BDD scenario's are done as a team, as a tester you are a guide and often a light to help them get it right.1 to 7 empowers you to focus on testing as long as the developers take ownership of the basic verification and happy path stuff.
Take a step back with the team, define a testing mission that works for you, explain the gaps that leaves for the team and then as a team try and find a way to cover those gaps.
-- Andy K
Recommendation 6:
I'm on a very lean team, where I'm the QA lead and there are no dedicated testers. We have three developers now, and that is down from five. Everybody is too busy all the time. Here's one reason we are still able to produce good results: everybody has to test. When the release candidate is ready for UI testing, I assign each developer to test something they didn't code, and we also pull in our UX staff member to test. At our Go/No Go meeting the afternoon before a release, everybody on the team has to vote whether they are confident about the test results. It is never all on me.If you can get devs involved in UI testing, even for just a day, it might help everybody to understand the enormity of the task, and what is involved in the process.
-- Deb Collins
Recommendation 7:
It's really tough when you feel like you've ended up in a no win situation so I completely empathise! Story sizing/refinement done as a team can be a really useful tool as it's an opportunity to highlight/surface complexities across dev & test that may be hidden or unconsidered. Do you do team stand ups to discuss the work on the board? If not I'd highly recommend getting one going. I find that talking about the tickets in play from right to left (rather than going to the individual to talk about what they've done yesterday/what they're doing today) can also be a handy way of highlighting those grey areas where it's beneficial for the team to pitch in, be aware so they can slow down, or just be mindful of what's possible that day. It's a good way of drawing attention to areas the team might not directly think about such as testing, releases, or A/B experiments as they can easily end up on the periphery
-- Anonymous
Recommendation 8:
I feel for you, been there and have the t-shirt. Not sure how you are doing your sprints and coming up your backlog sizing but I would suggest you revisit that with with the entire team. Use your test charters as examples for the new dev. Maybe at the next retro bring up the subject of testing and suggest that developers should get involved in this-how you communicate that is key though. Have a chat with the scrum master-if you have one!....And working 12 hrs a day is not defining good.
-- Brian MacRoberts
Reference:
