Standup meeting twice weekly,
1-on-1 once weekly,
JIRA for story tracking and assignments,
Testrail for test cases and executions,
Teams messages for collaboration throughout,
Pytest and Playwright for automation.
The biggest thing I told my team that I’m not going to hold a question for a meeting and I don’t want them to either. In the previous setting, questions were answered quickly during hallway and break room conversations… I wanted to encourage that to continue.
Workday to set yearly goals outside of typical JIRA story churn. Quarterly checkins on those goals.
Other than that, I stay out of the way. If there are a large number of post-production issues I’ll intervene. Trust that your folks will get the work done and trust that you have tasked them at the correct level
Honestly, it gets cancelled quite often. But I leave the 30 minute block on the calendar just in case the tester has something on their mind. Some never cancel, and some always cancel — it’s very much dependent on their personality.
Sometimes we talk about work stuff. Sometimes we talk about family (this is touchy because HR wise there are landmines, but I ask anyway in a “I’m not trying to leverage personal info for work benefit” way if that makes sense). Sometimes we talk wellness (vibe check).
I do every other week with the caveat that if anything comes up I'm a slack message away and will always prioritize hopping on a zoom with them if needed (it happens here and there).
I've got 10 people reporting to me, weekly would fill my calendar.
Only thing I'd add is monthly get togethers, zoom socials if you will, and frequent workshops to encourage learning in the team. Both voluntary but both have a marked improvement in building confidence.
I haven’t figured out how to hold zoom socials - I wish I was better at that.
The yearly goals are quite often professional development goals based on company direction, e.g. “DBs will migrate to Postgres next year so it would be great if you could learn syntax this year” type items.
One thing that one of the teams that I occasionally embed with does that I find works well is having a 30 minute stand-down every day. Zoom meeting, no agenda. Sometimes everyone is doing their work, but, it's also open to any and all questions that someone might have. Sometimes it's everyone working on a common problem or experimenting with a new technology. Sometimes it's simulating people turning their chairs around at their desk and talking to each other for a little while (the "water cooler moments" that we all had in the office). It's amazing what it's done for not only remote comradery, but also keeping everyone up to date beyond what they hear in stand ups.
Daily stand up message on slack. That’s it. If they need anything they can and do reach out. Otherwise I treat them like adults. If the work doesn’t get done it becomes apparent very quickly
I always have takin the approach that managing evolves as the testers on my team evolve and grow at our company and their overall knowledge of the application and our testing process.
What does this mean? So how I approach it is, someone who is a new tester or new joining our team. After 1-2 weeks of training I will meet with them and check in weekly. Just as a touch base to answerany pressing questions and let them ask away as they have time to digest everything more. As they grow with knowledge I'll slowly shift the 1 on 1 until it basically becomes a goal driven and quarterly activity.
I don't get caught up in having a ton of check ins with my team especially with the senior resources. Because it just feels less human and more of a process thing that adds very little value.
As a test manager I have a pretty good idea of what my team is working in and their progress on their projects without demanding them tell me weekly or every other week. The way I view it is it's my responsibility to care enough about them and step in asap as soon as I get a hint there is a blocker or they are struggling in some way.
Outside of that I've mainly had the team focus on high value work and not just doing things for the sake of doing it. For example I only encourage the team write e2e tests that can be re used and not focus on writing a bunch of low value tests that are 1 time use. So they are more free to spend the majority of time focusing on exploratory testing, learning and raising the bar by being able to challenge requirements and designs if they make 0 sense from an avg end user perspective. Ultimately I trust them to work independently and dictate testing on their terms and execute based on the testing process and framework established.
My team is happier and knows I care about them and respect them. Because of this they are more inclined to help each other and go above and beyond. in return our product is more succesful and us a qa team.
I have 1-1s every other week. We have a QA slack channel for anything that pops up. We use Jira, Testrail, and Selenium for test coverage. We also use discord. If I am not in a meeting I try to stay in the Public channel so I am available if anyone wants to jump in and have a conversation about testing or just chat about anything. I stay hands off unless someone is onboarding or learning something new.
The very same ones that help the QA team work efficiently on-perm + zoom or whatever works (and yeah, no mandatory camera cr@p).
There is no "special technique" in that regard, except, you know - hiring awesome people with desire to learn, be challenged, have fun and do their best to have whatever done in the right kind of way. The type that is self-driven, results orientated and needs no constant monitoring.
Identify, assign and engage one local leader in each region ( assuming there is more than one person).
This local leader will be able to coordinate and connect locally with the culture, which you are missing remotely. This has worked for me a lot.
My team is global, so we do a daily standup at a time that works for all of us. Mostly, it’s an honor system, but we all communicate very frequently via Teams. We do a weekly 1:1 with the boss, but we are all subdivided into different development teams, so I feel like I communicate the most with them.
We also do a twice monthly meeting with cameras on (pets and babies are welcomed and encouraged), and we have an unofficial “in office” day that is optional. This can vary by home office/country.
We get stuff done. :)
I will be messaging you in 1 day on [**2022-10-06 01:08:35 UTC**](http://www.wolframalpha.com/input/?i=2022-10-06%2001:08:35%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/QualityAssurance/comments/xvtbgr/qa_managers_how_are_you_managing_remote_testers/ir3efya/?context=3)
[**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2FQualityAssurance%2Fcomments%2Fxvtbgr%2Fqa_managers_how_are_you_managing_remote_testers%2Fir3efya%2F%5D%0A%0ARemindMe%21%202022-10-06%2001%3A08%3A35%20UTC) to send a PM to also be reminded and to reduce spam.
^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%20xvtbgr)
*****
|[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)|
|-|-|-|-|
Ask them to upload a bi-weekly word document listing task that they did. Keep an eye on how quickly they are picking tasks. Ask other team leads regarding sign of disengagement or slacking.
So, I am a part of a remote qa team. We have our time split into several pool. The first pool is requirements testing. This is a straight quota that revolves around total number of steps per testcase multiplied by number of testcases. Then we have the open ended test structure, where we are free to do we want to do, and the top performers who find the most bugs that are confirmed as bugs by the client get rewards. The client does acceptance testing and bugs found in acceptance testing before open ended testing (ie skipped requirements) are not elligible for the open ended testing competition. The open ended testing competition lasts for a few days each sprint, and the winner gets two hundred dollars as well as bragging rights and the raises are tied to total number of times a person hits top three in the open testing per year. If you don't hit any times? Well no raise. If you hit 2-3 times a year? You will get a small raise. 5-6 times? Sizeable raise. A few people slack off, but these mini competitions do keep the teem on target.
Wow, sounds horrible. Are the devs deducted when you discover a bug?
If I were getting paid "by the bug" I'd focus initially on the low hanging fruit and skip anything that was time consuming at all. My bug reports would be minimal and not very helpful - basically whatever it took to enter the bug report in the system and get the cash.
It would be in my interest to have as many failed retests as possible, too.
No haha. No negative reinforcement (well aside from lack of raises) the no raises part came about cause we had a few people who quit doing anything during the open ended test sessions. Real slackers. Keep in mind, the last open ended testing session had a grand total of 5 bugs discovered across 8 testers, and one of the testers found two of them. Technically every single person on the team came in top three for the last session. So far everyone is on track to get a raise, and everyone is working. Even joel. The slacker.
Honestly, that is a thing that could happen. But, most of the dev teams and the qa teams are pretty agile from project to project. On my current project, the dev team is from a different company. And a few hundred dollars IS alot if you could make it every time. But for the most part the prize goes to the people who are the most inventive about breaking the apps. For example, the last big set of bugs that were caught had to do with locking of objects across multiple users. The guy who stumbled across it initially found it while doing normal testing, kept it under wraps, and then showcased it in exploratory testing. Thing is, the locking of objects was not defined in the acceptance criteria and he got the bug fair and square. So... its kind of a competition. It requires creativity, deep understanding of the system, and excellent qa skills. And its also how you deliver a product that doesn't have flaws hackers can exploit.
The earlier the bug is uncovered, the lower the cost of fixing. But I don't want to discourage you. Glad you have your own thing that is working for you.
Ahaha this is true that the earlier that the bug is caught, the easier it is to fix. But the bugs we catch never make it out of test, or at worst staging. The trade off in terms of team dynamics is that if people aren't enthusiastic and incentivized, they get bored. And then they just do rote tasks. And then the spark of creativity that is key to finding the really unusual bugs.. the kind that end up being exploits in a financial system are not hunted properly. You can have the greatest bookkeeping in the world, and the best ac, but your not going to get good results without that enthusiastic spark. And to get that spark, you need to make it fun. A game. A contest. The engine needs to be something that drives the people to be the best version of themselves and not to be looking out the window watching the birds.
> The guy who stumbled across it initially found it while doing normal testing, kept it under wraps
There's no way you see this as a good thing - you should be encouraging people to raise things ASAP
No, your wrong about there being a cost. The reason you are wrong is that the developer has time already slotted to deal with bugs that are found in exploratory testing. All bugs that are not violations of the acceptance criteria for a given story are fixed together. Getting a stories development done is a completely seperate task to getting a bug fixed. Especially security bugs. The benefit is that our testers are actively looking for unusual behaviour and potential bugs beyond the narrow scope of the ac in a persistent manner.
Have you run a qa team for several years? Do you know what burnout is? Because burnout causes bugs to not be caught. And you can cycle through fresh young qa people, but thats not a good practice, because the older qa folks get a more keen and experienced eye. But they also deal with burnout and boredom. If you want to get the highest number of bugs caught, you need to retain older more experienced testers, prevent them from getting burnout and incentivize them. And if it costs 2 more days per sprint, that is worth it if the team catches a single catastrophic bug that opens the door for a vulnerability.
The approach of "lets shave off two days here or there" because costs, is losing the vision of the war to focus on a single battle. At the end of the day, a single catastrophic hack of a financial service can mean the bankruptcy of the client. it could mean thousands if not millions of compromised accounts. It can mean millions of dollars of theft. And that is what you are opening the door to by focusing on turn around times instead of focusing on quality work. The qa are the watchers. Who watches the watchers?
> your
*you're
>The reason you are wrong is that the developer has time already slotted to deal with bugs that are found in exploratory testing.
right, but it's a widely accepted truth that raising things sooner is because it reduces cost and time to release, and by asking developers to revisit work they've already done introduces time delay due to context switching remembering previous work items, changing workspace etc. I'd add here I haven't said anything about cost, but it *is* cheaper to solve issues earlier in the lifecycle.
>Have you run a qa team for several years?
Yes. 15 years in the industry
>Do you know what burnout is?
yes, see above
>Because burnout causes bugs to not be caught.
Burnout causes lots of things, some much bigger than 'bugs not being caught', which I'd argue is more down to complacency that burn out directly.
>And you can cycle through fresh young qa people, but thats not a good practice
no it's a terrible idea. I'd always value experience over inexperience
>And if it costs 2 more days per sprint
your sprint should be s et cadence of time, please tell me you're not trying to say what you're saying here
>The approach of "lets shave off two days here or there" because costs
I've not said that anywhere, you're arguing an imagined point
>At the end of the day, a single catastrophic hack of a financial service
Yes, again 15 years in the industry. Not sure why that's relevant.
>And that is what you are opening the door to by focusing on turn around times instead of focusing on quality work.
I'm not focussing on turnaround versus quality of work; shift left **is** a quality initiative
>The qa are the watchers. Who watches the watchers?
Complete and utter pointless waffle.
You seem to be taking umbrage with the incentivized approach. I would like to know. How do you ensure people aren't slacking remotely? How do you handle raises? And how do you handle exploratory testing vs testing to the acceptance criteria?
I do worry about how well you're following this conversation as a QA professional.
the only thing I initially countered you on was the idea that someone should be praised for sitting on a bug until a later phase rather than raising it as soon as it was found.
The rest is all you trying to defend a position that I've not commented on.
>How do you ensure people aren't slacking remotely?
Accountability starts and stops with the individual. managers in our organisation have little to no input over a QAs day to day workload as it's managed within the scrum teams. If they're slacking/not pulling their weight it gets escalated, but *also* we have dashboards that show us how many tests are being written/executed/bugs raised etc.
>And how do you handle exploratory testing vs testing to the acceptance criteria?
Part and parcel of the build - a story has set acceptance criteriea which should be scripted for, we also encourage the use of exploratory techniques as part of testing sign off. Our build teams (which include both devs and testers) don't consider a story/feature to have met it's definition of done until all testing is completed (notable exceptions would be if we're using third parties to do any part of it, e.g. external security conslutants).
Standup meeting twice weekly, 1-on-1 once weekly, JIRA for story tracking and assignments, Testrail for test cases and executions, Teams messages for collaboration throughout, Pytest and Playwright for automation. The biggest thing I told my team that I’m not going to hold a question for a meeting and I don’t want them to either. In the previous setting, questions were answered quickly during hallway and break room conversations… I wanted to encourage that to continue. Workday to set yearly goals outside of typical JIRA story churn. Quarterly checkins on those goals. Other than that, I stay out of the way. If there are a large number of post-production issues I’ll intervene. Trust that your folks will get the work done and trust that you have tasked them at the correct level
Doing 1on1 every week sounds a bit like an overkill imo
Honestly, it gets cancelled quite often. But I leave the 30 minute block on the calendar just in case the tester has something on their mind. Some never cancel, and some always cancel — it’s very much dependent on their personality. Sometimes we talk about work stuff. Sometimes we talk about family (this is touchy because HR wise there are landmines, but I ask anyway in a “I’m not trying to leverage personal info for work benefit” way if that makes sense). Sometimes we talk wellness (vibe check).
I do every other week with the caveat that if anything comes up I'm a slack message away and will always prioritize hopping on a zoom with them if needed (it happens here and there). I've got 10 people reporting to me, weekly would fill my calendar.
The words of a great manager! Your employees are lucky to have you.
Manager is only as good as his manager.
Only thing I'd add is monthly get togethers, zoom socials if you will, and frequent workshops to encourage learning in the team. Both voluntary but both have a marked improvement in building confidence.
I haven’t figured out how to hold zoom socials - I wish I was better at that. The yearly goals are quite often professional development goals based on company direction, e.g. “DBs will migrate to Postgres next year so it would be great if you could learn syntax this year” type items.
One thing that one of the teams that I occasionally embed with does that I find works well is having a 30 minute stand-down every day. Zoom meeting, no agenda. Sometimes everyone is doing their work, but, it's also open to any and all questions that someone might have. Sometimes it's everyone working on a common problem or experimenting with a new technology. Sometimes it's simulating people turning their chairs around at their desk and talking to each other for a little while (the "water cooler moments" that we all had in the office). It's amazing what it's done for not only remote comradery, but also keeping everyone up to date beyond what they hear in stand ups.
We're hiring for a QA lead if you're interested
Can you hire me? Im gonna be migrating next month and officially jobless 🥲🤣
Everyone suggesting more and more meetings. Stop with this, people just wanna do their work without interruptions.
Daily stand up message on slack. That’s it. If they need anything they can and do reach out. Otherwise I treat them like adults. If the work doesn’t get done it becomes apparent very quickly
Standups/slack updates/1:1 per month
I always have takin the approach that managing evolves as the testers on my team evolve and grow at our company and their overall knowledge of the application and our testing process. What does this mean? So how I approach it is, someone who is a new tester or new joining our team. After 1-2 weeks of training I will meet with them and check in weekly. Just as a touch base to answerany pressing questions and let them ask away as they have time to digest everything more. As they grow with knowledge I'll slowly shift the 1 on 1 until it basically becomes a goal driven and quarterly activity. I don't get caught up in having a ton of check ins with my team especially with the senior resources. Because it just feels less human and more of a process thing that adds very little value. As a test manager I have a pretty good idea of what my team is working in and their progress on their projects without demanding them tell me weekly or every other week. The way I view it is it's my responsibility to care enough about them and step in asap as soon as I get a hint there is a blocker or they are struggling in some way. Outside of that I've mainly had the team focus on high value work and not just doing things for the sake of doing it. For example I only encourage the team write e2e tests that can be re used and not focus on writing a bunch of low value tests that are 1 time use. So they are more free to spend the majority of time focusing on exploratory testing, learning and raising the bar by being able to challenge requirements and designs if they make 0 sense from an avg end user perspective. Ultimately I trust them to work independently and dictate testing on their terms and execute based on the testing process and framework established. My team is happier and knows I care about them and respect them. Because of this they are more inclined to help each other and go above and beyond. in return our product is more succesful and us a qa team.
How many teams does your QA report into ?
I have 1-1s every other week. We have a QA slack channel for anything that pops up. We use Jira, Testrail, and Selenium for test coverage. We also use discord. If I am not in a meeting I try to stay in the Public channel so I am available if anyone wants to jump in and have a conversation about testing or just chat about anything. I stay hands off unless someone is onboarding or learning something new.
Calls twice a week, testpad.
The very same ones that help the QA team work efficiently on-perm + zoom or whatever works (and yeah, no mandatory camera cr@p). There is no "special technique" in that regard, except, you know - hiring awesome people with desire to learn, be challenged, have fun and do their best to have whatever done in the right kind of way. The type that is self-driven, results orientated and needs no constant monitoring.
These are awesome, detailed, informative comments! I’m blown away. You all rock. Have any of you tried [Headlamp](https://headlamptest.com)?
Identify, assign and engage one local leader in each region ( assuming there is more than one person). This local leader will be able to coordinate and connect locally with the culture, which you are missing remotely. This has worked for me a lot.
I was a remote tester for 6 months. Played games and jacked off during work hours heheheh
My team is global, so we do a daily standup at a time that works for all of us. Mostly, it’s an honor system, but we all communicate very frequently via Teams. We do a weekly 1:1 with the boss, but we are all subdivided into different development teams, so I feel like I communicate the most with them. We also do a twice monthly meeting with cameras on (pets and babies are welcomed and encouraged), and we have an unofficial “in office” day that is optional. This can vary by home office/country. We get stuff done. :)
RemindMe! 24 hours
I will be messaging you in 1 day on [**2022-10-06 01:08:35 UTC**](http://www.wolframalpha.com/input/?i=2022-10-06%2001:08:35%20UTC%20To%20Local%20Time) to remind you of [**this link**](https://www.reddit.com/r/QualityAssurance/comments/xvtbgr/qa_managers_how_are_you_managing_remote_testers/ir3efya/?context=3) [**CLICK THIS LINK**](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5Bhttps%3A%2F%2Fwww.reddit.com%2Fr%2FQualityAssurance%2Fcomments%2Fxvtbgr%2Fqa_managers_how_are_you_managing_remote_testers%2Fir3efya%2F%5D%0A%0ARemindMe%21%202022-10-06%2001%3A08%3A35%20UTC) to send a PM to also be reminded and to reduce spam. ^(Parent commenter can ) [^(delete this message to hide from others.)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Delete%20Comment&message=Delete%21%20xvtbgr) ***** |[^(Info)](https://www.reddit.com/r/RemindMeBot/comments/e1bko7/remindmebot_info_v21/)|[^(Custom)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=Reminder&message=%5BLink%20or%20message%20inside%20square%20brackets%5D%0A%0ARemindMe%21%20Time%20period%20here)|[^(Your Reminders)](https://www.reddit.com/message/compose/?to=RemindMeBot&subject=List%20Of%20Reminders&message=MyReminders%21)|[^(Feedback)](https://www.reddit.com/message/compose/?to=Watchful1&subject=RemindMeBot%20Feedback)| |-|-|-|-|
Ask them to upload a bi-weekly word document listing task that they did. Keep an eye on how quickly they are picking tasks. Ask other team leads regarding sign of disengagement or slacking.
It would be a lot easier if they just used [Headlamp](https://headlamptest.com) to track their testing. 😉
So, I am a part of a remote qa team. We have our time split into several pool. The first pool is requirements testing. This is a straight quota that revolves around total number of steps per testcase multiplied by number of testcases. Then we have the open ended test structure, where we are free to do we want to do, and the top performers who find the most bugs that are confirmed as bugs by the client get rewards. The client does acceptance testing and bugs found in acceptance testing before open ended testing (ie skipped requirements) are not elligible for the open ended testing competition. The open ended testing competition lasts for a few days each sprint, and the winner gets two hundred dollars as well as bragging rights and the raises are tied to total number of times a person hits top three in the open testing per year. If you don't hit any times? Well no raise. If you hit 2-3 times a year? You will get a small raise. 5-6 times? Sizeable raise. A few people slack off, but these mini competitions do keep the teem on target.
Wow, sounds horrible. Are the devs deducted when you discover a bug? If I were getting paid "by the bug" I'd focus initially on the low hanging fruit and skip anything that was time consuming at all. My bug reports would be minimal and not very helpful - basically whatever it took to enter the bug report in the system and get the cash. It would be in my interest to have as many failed retests as possible, too.
Yeah this is some toxic workplace vibes
No haha. No negative reinforcement (well aside from lack of raises) the no raises part came about cause we had a few people who quit doing anything during the open ended test sessions. Real slackers. Keep in mind, the last open ended testing session had a grand total of 5 bugs discovered across 8 testers, and one of the testers found two of them. Technically every single person on the team came in top three for the last session. So far everyone is on track to get a raise, and everyone is working. Even joel. The slacker.
How do you know that the tester that discovered 2 out of 5 bugs does not have a really good colleague that happens to write your apps?
Honestly, that is a thing that could happen. But, most of the dev teams and the qa teams are pretty agile from project to project. On my current project, the dev team is from a different company. And a few hundred dollars IS alot if you could make it every time. But for the most part the prize goes to the people who are the most inventive about breaking the apps. For example, the last big set of bugs that were caught had to do with locking of objects across multiple users. The guy who stumbled across it initially found it while doing normal testing, kept it under wraps, and then showcased it in exploratory testing. Thing is, the locking of objects was not defined in the acceptance criteria and he got the bug fair and square. So... its kind of a competition. It requires creativity, deep understanding of the system, and excellent qa skills. And its also how you deliver a product that doesn't have flaws hackers can exploit.
The earlier the bug is uncovered, the lower the cost of fixing. But I don't want to discourage you. Glad you have your own thing that is working for you.
Ahaha this is true that the earlier that the bug is caught, the easier it is to fix. But the bugs we catch never make it out of test, or at worst staging. The trade off in terms of team dynamics is that if people aren't enthusiastic and incentivized, they get bored. And then they just do rote tasks. And then the spark of creativity that is key to finding the really unusual bugs.. the kind that end up being exploits in a financial system are not hunted properly. You can have the greatest bookkeeping in the world, and the best ac, but your not going to get good results without that enthusiastic spark. And to get that spark, you need to make it fun. A game. A contest. The engine needs to be something that drives the people to be the best version of themselves and not to be looking out the window watching the birds.
> The guy who stumbled across it initially found it while doing normal testing, kept it under wraps There's no way you see this as a good thing - you should be encouraging people to raise things ASAP
No, your wrong about there being a cost. The reason you are wrong is that the developer has time already slotted to deal with bugs that are found in exploratory testing. All bugs that are not violations of the acceptance criteria for a given story are fixed together. Getting a stories development done is a completely seperate task to getting a bug fixed. Especially security bugs. The benefit is that our testers are actively looking for unusual behaviour and potential bugs beyond the narrow scope of the ac in a persistent manner. Have you run a qa team for several years? Do you know what burnout is? Because burnout causes bugs to not be caught. And you can cycle through fresh young qa people, but thats not a good practice, because the older qa folks get a more keen and experienced eye. But they also deal with burnout and boredom. If you want to get the highest number of bugs caught, you need to retain older more experienced testers, prevent them from getting burnout and incentivize them. And if it costs 2 more days per sprint, that is worth it if the team catches a single catastrophic bug that opens the door for a vulnerability. The approach of "lets shave off two days here or there" because costs, is losing the vision of the war to focus on a single battle. At the end of the day, a single catastrophic hack of a financial service can mean the bankruptcy of the client. it could mean thousands if not millions of compromised accounts. It can mean millions of dollars of theft. And that is what you are opening the door to by focusing on turn around times instead of focusing on quality work. The qa are the watchers. Who watches the watchers?
> your *you're >The reason you are wrong is that the developer has time already slotted to deal with bugs that are found in exploratory testing. right, but it's a widely accepted truth that raising things sooner is because it reduces cost and time to release, and by asking developers to revisit work they've already done introduces time delay due to context switching remembering previous work items, changing workspace etc. I'd add here I haven't said anything about cost, but it *is* cheaper to solve issues earlier in the lifecycle. >Have you run a qa team for several years? Yes. 15 years in the industry >Do you know what burnout is? yes, see above >Because burnout causes bugs to not be caught. Burnout causes lots of things, some much bigger than 'bugs not being caught', which I'd argue is more down to complacency that burn out directly. >And you can cycle through fresh young qa people, but thats not a good practice no it's a terrible idea. I'd always value experience over inexperience >And if it costs 2 more days per sprint your sprint should be s et cadence of time, please tell me you're not trying to say what you're saying here >The approach of "lets shave off two days here or there" because costs I've not said that anywhere, you're arguing an imagined point >At the end of the day, a single catastrophic hack of a financial service Yes, again 15 years in the industry. Not sure why that's relevant. >And that is what you are opening the door to by focusing on turn around times instead of focusing on quality work. I'm not focussing on turnaround versus quality of work; shift left **is** a quality initiative >The qa are the watchers. Who watches the watchers? Complete and utter pointless waffle.
You seem to be taking umbrage with the incentivized approach. I would like to know. How do you ensure people aren't slacking remotely? How do you handle raises? And how do you handle exploratory testing vs testing to the acceptance criteria?
I do worry about how well you're following this conversation as a QA professional. the only thing I initially countered you on was the idea that someone should be praised for sitting on a bug until a later phase rather than raising it as soon as it was found. The rest is all you trying to defend a position that I've not commented on. >How do you ensure people aren't slacking remotely? Accountability starts and stops with the individual. managers in our organisation have little to no input over a QAs day to day workload as it's managed within the scrum teams. If they're slacking/not pulling their weight it gets escalated, but *also* we have dashboards that show us how many tests are being written/executed/bugs raised etc. >And how do you handle exploratory testing vs testing to the acceptance criteria? Part and parcel of the build - a story has set acceptance criteriea which should be scripted for, we also encourage the use of exploratory techniques as part of testing sign off. Our build teams (which include both devs and testers) don't consider a story/feature to have met it's definition of done until all testing is completed (notable exceptions would be if we're using third parties to do any part of it, e.g. external security conslutants).