Mixing
How to prove the manager we need a a new QA hire in the team? [duplicate]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
0
down vote
favorite
This question already has an answer here:
How To Build A Business Case For Hiring New People?
4 answers
Just like many teams we used to have a manual QA member. After a while he transferred to developer's position. We don't have any automated functional or unit testing. What we do have is so-called bug-session. The whole point is to bring the entire team together for manual testing. It does help to share the knowledge about the expected behavior but I don't feel it's enough because people don't take it seriously.
To improve the situation I suggested the boss contracting an outsource person part-time to minimize the expenses. The new person can simply take care of the issues pending for QA.
Manager says he doesn't see the value in bringing new QA because any of engineers can do manual testing. He asks me to prove we need a new person on board. How do I do this? What are the business advantages for having QA member in the team?
team teamwork team-role hiring
edited Mar 5 '15 at 21:10
sevensevens
6,20321531
asked Mar 5 '15 at 19:10
etual
20718
marked as duplicate by gnat, IDrinkandIKnowThings, Chris E, yochannah, Jim G. Mar 15 '15 at 21:28
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
suggest improvements |Â
up vote
0
down vote
favorite
This question already has an answer here:
How To Build A Business Case For Hiring New People?
4 answers
Just like many teams we used to have a manual QA member. After a while he transferred to developer's position. We don't have any automated functional or unit testing. What we do have is so-called bug-session. The whole point is to bring the entire team together for manual testing. It does help to share the knowledge about the expected behavior but I don't feel it's enough because people don't take it seriously.
To improve the situation I suggested the boss contracting an outsource person part-time to minimize the expenses. The new person can simply take care of the issues pending for QA.
Manager says he doesn't see the value in bringing new QA because any of engineers can do manual testing. He asks me to prove we need a new person on board. How do I do this? What are the business advantages for having QA member in the team?
team teamwork team-role hiring
edited Mar 5 '15 at 21:10
sevensevens
6,20321531
asked Mar 5 '15 at 19:10
etual
20718
marked as duplicate by gnat, IDrinkandIKnowThings, Chris E, yochannah, Jim G. Mar 15 '15 at 21:28
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
You may want to add some more information on the type of application you are developing to get some more specific advice. In general, prepare for a tough battle if you want to increase the importance of quality. QA is often seen as overrated by management since 'after all, they hired competent people and competent people shouldn't make too many mistakes right'? To change their mind, you will need to make them see that bugs are not always caused by incompetence.
– Cronax
Mar 10 '15 at 10:58
Given QA is considered important, I would suggest you discuss with the team which kind of QA they would take seriously. Perhaps give some suggestions.Then take that result to the boss.
– Thorbjørn Ravn Andersen
Oct 21 '16 at 15:51
suggest improvements |Â
up vote
0
down vote
favorite
up vote
0
down vote
favorite
This question already has an answer here:
How To Build A Business Case For Hiring New People?
4 answers
Just like many teams we used to have a manual QA member. After a while he transferred to developer's position. We don't have any automated functional or unit testing. What we do have is so-called bug-session. The whole point is to bring the entire team together for manual testing. It does help to share the knowledge about the expected behavior but I don't feel it's enough because people don't take it seriously.
To improve the situation I suggested the boss contracting an outsource person part-time to minimize the expenses. The new person can simply take care of the issues pending for QA.
Manager says he doesn't see the value in bringing new QA because any of engineers can do manual testing. He asks me to prove we need a new person on board. How do I do this? What are the business advantages for having QA member in the team?
team teamwork team-role hiring
edited Mar 5 '15 at 21:10
sevensevens
6,20321531
asked Mar 5 '15 at 19:10
etual
20718
This question already has an answer here:
How To Build A Business Case For Hiring New People?
4 answers
Just like many teams we used to have a manual QA member. After a while he transferred to developer's position. We don't have any automated functional or unit testing. What we do have is so-called bug-session. The whole point is to bring the entire team together for manual testing. It does help to share the knowledge about the expected behavior but I don't feel it's enough because people don't take it seriously.
To improve the situation I suggested the boss contracting an outsource person part-time to minimize the expenses. The new person can simply take care of the issues pending for QA.
Manager says he doesn't see the value in bringing new QA because any of engineers can do manual testing. He asks me to prove we need a new person on board. How do I do this? What are the business advantages for having QA member in the team?
This question already has an answer here:
How To Build A Business Case For Hiring New People?
4 answers
team teamwork team-role hiring
edited Mar 5 '15 at 21:10
sevensevens
6,20321531
asked Mar 5 '15 at 19:10
etual
20718
edited Mar 5 '15 at 21:10
sevensevens
6,20321531
edited Mar 5 '15 at 21:10
sevensevens
6,20321531
edited Mar 5 '15 at 21:10
sevensevens
6,20321531
6,20321531
asked Mar 5 '15 at 19:10
etual
20718
asked Mar 5 '15 at 19:10
etual
20718
asked Mar 5 '15 at 19:10
etual
20718
20718
marked as duplicate by gnat, IDrinkandIKnowThings, Chris E, yochannah, Jim G. Mar 15 '15 at 21:28
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
marked as duplicate by gnat, IDrinkandIKnowThings, Chris E, yochannah, Jim G. Mar 15 '15 at 21:28
This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.
You may want to add some more information on the type of application you are developing to get some more specific advice. In general, prepare for a tough battle if you want to increase the importance of quality. QA is often seen as overrated by management since 'after all, they hired competent people and competent people shouldn't make too many mistakes right'? To change their mind, you will need to make them see that bugs are not always caused by incompetence.
– Cronax
Mar 10 '15 at 10:58
Given QA is considered important, I would suggest you discuss with the team which kind of QA they would take seriously. Perhaps give some suggestions.Then take that result to the boss.
– Thorbjørn Ravn Andersen
Oct 21 '16 at 15:51
suggest improvements |Â
You may want to add some more information on the type of application you are developing to get some more specific advice. In general, prepare for a tough battle if you want to increase the importance of quality. QA is often seen as overrated by management since 'after all, they hired competent people and competent people shouldn't make too many mistakes right'? To change their mind, you will need to make them see that bugs are not always caused by incompetence.
– Cronax
Mar 10 '15 at 10:58
Given QA is considered important, I would suggest you discuss with the team which kind of QA they would take seriously. Perhaps give some suggestions.Then take that result to the boss.
– Thorbjørn Ravn Andersen
Oct 21 '16 at 15:51
You may want to add some more information on the type of application you are developing to get some more specific advice. In general, prepare for a tough battle if you want to increase the importance of quality. QA is often seen as overrated by management since 'after all, they hired competent people and competent people shouldn't make too many mistakes right'? To change their mind, you will need to make them see that bugs are not always caused by incompetence.
– Cronax
Mar 10 '15 at 10:58
You may want to add some more information on the type of application you are developing to get some more specific advice. In general, prepare for a tough battle if you want to increase the importance of quality. QA is often seen as overrated by management since 'after all, they hired competent people and competent people shouldn't make too many mistakes right'? To change their mind, you will need to make them see that bugs are not always caused by incompetence.
– Cronax
Mar 10 '15 at 10:58
Given QA is considered important, I would suggest you discuss with the team which kind of QA they would take seriously. Perhaps give some suggestions.Then take that result to the boss.
– Thorbjørn Ravn Andersen
Oct 21 '16 at 15:51
Given QA is considered important, I would suggest you discuss with the team which kind of QA they would take seriously. Perhaps give some suggestions.Then take that result to the boss.
– Thorbjørn Ravn Andersen
Oct 21 '16 at 15:51
suggest improvements |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Dedicated QA
Well this is kind of the "gotcha" here. Typically when I make a case for proper QA it fighting to demonstrated dedicating XX hours to QA per sprint. Usually you can put together the math based on other's research to figure out what is going to be a pretty good balance between time invested and bugs squashed.
Making this time a person
Most of the time those hours can be committed by engineers and actually work well enough. A dedicated QA person is more efficient, but if your need isn't enough to justify it then engineers time will do.
For you to sell your boss on a dedicated QA person you really need to demonstrate you need enough QA time to cover a fulltime position. Outsourcing a part time QA time is a REALLY hard sell, and in my experience one that typically hurts more than helps.
Making the most of QA time
So you have your entire dev team drop what they are doing and do manual QA... This... is bad. If you can dedicate a bunch of time to manually test everything you should be able to commit time to making proper unit and integration tests! Usually the cut best bang for your buck is 15% to 20% of your dev time dedicated to cleaning up old code, bug fixes, and non-production projects such as building out tests, database clean up, optimization, etc. (The crap that needs doing that doesn't directly make money)
As a developer good TDD can be invaluable and save you HOURS of debugging issues. You can reliably count on each part of your code doing it's job, and in the event something breaks you have a test that says what broke and where it broke, even before you spin up the UI to see that it broke. This takes your necessary QA time WAY down. Now instead of "testing all the things" you are really just making sure the UI is in good order... (Which actually works against you getting a QA person, unless you just dump building out automated testing on this person... which isn't ideal, but WAY better then no automation)
Summary
A dedicated QA person is a hard sale and you need to show your boss all the engineer's time dedicated to testing would go further in the hands of a QA person...
But that's really not your problem... You need to automate your testing to just reduce your QA time entirely.
answered Mar 5 '15 at 19:34
RualStorge
9,5372231
Thank you, calculation may work. And, automation is another hard sale!
– etual
Mar 5 '15 at 20:06
@etual it is. It's very hard to explain time spent now saves time later. That said figure out how long it takes to test something manually, how often you have to test it manually, and how long it would take to write an automated test for it. Numbers are the easiest way to sell anything. For me, to be honest I didn't give my employer a choice, I just started writing tests saying "I work faster this way" (But to be fair, I get away with a lot more than most of my peers)
– RualStorge
Mar 5 '15 at 21:15
Lack of automated tests also add cost and risk to the maintenance cycle. If a maintenance programmer later tries to change method X but there are no automated tests, then he will most likely have to add some tests at that point to avoid breaking something, and it's probably going to take more resources to do that during the maintenance cycle.
– Brandin
Mar 6 '15 at 13:21
suggest improvements |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Dedicated QA
Well this is kind of the "gotcha" here. Typically when I make a case for proper QA it fighting to demonstrated dedicating XX hours to QA per sprint. Usually you can put together the math based on other's research to figure out what is going to be a pretty good balance between time invested and bugs squashed.
Making this time a person
Most of the time those hours can be committed by engineers and actually work well enough. A dedicated QA person is more efficient, but if your need isn't enough to justify it then engineers time will do.
For you to sell your boss on a dedicated QA person you really need to demonstrate you need enough QA time to cover a fulltime position. Outsourcing a part time QA time is a REALLY hard sell, and in my experience one that typically hurts more than helps.
Making the most of QA time
So you have your entire dev team drop what they are doing and do manual QA... This... is bad. If you can dedicate a bunch of time to manually test everything you should be able to commit time to making proper unit and integration tests! Usually the cut best bang for your buck is 15% to 20% of your dev time dedicated to cleaning up old code, bug fixes, and non-production projects such as building out tests, database clean up, optimization, etc. (The crap that needs doing that doesn't directly make money)
As a developer good TDD can be invaluable and save you HOURS of debugging issues. You can reliably count on each part of your code doing it's job, and in the event something breaks you have a test that says what broke and where it broke, even before you spin up the UI to see that it broke. This takes your necessary QA time WAY down. Now instead of "testing all the things" you are really just making sure the UI is in good order... (Which actually works against you getting a QA person, unless you just dump building out automated testing on this person... which isn't ideal, but WAY better then no automation)
Summary
A dedicated QA person is a hard sale and you need to show your boss all the engineer's time dedicated to testing would go further in the hands of a QA person...
But that's really not your problem... You need to automate your testing to just reduce your QA time entirely.
answered Mar 5 '15 at 19:34
RualStorge
9,5372231
Thank you, calculation may work. And, automation is another hard sale!
– etual
Mar 5 '15 at 20:06
@etual it is. It's very hard to explain time spent now saves time later. That said figure out how long it takes to test something manually, how often you have to test it manually, and how long it would take to write an automated test for it. Numbers are the easiest way to sell anything. For me, to be honest I didn't give my employer a choice, I just started writing tests saying "I work faster this way" (But to be fair, I get away with a lot more than most of my peers)
– RualStorge
Mar 5 '15 at 21:15
Lack of automated tests also add cost and risk to the maintenance cycle. If a maintenance programmer later tries to change method X but there are no automated tests, then he will most likely have to add some tests at that point to avoid breaking something, and it's probably going to take more resources to do that during the maintenance cycle.
– Brandin
Mar 6 '15 at 13:21
suggest improvements |Â
up vote
1
down vote
accepted
Dedicated QA
Well this is kind of the "gotcha" here. Typically when I make a case for proper QA it fighting to demonstrated dedicating XX hours to QA per sprint. Usually you can put together the math based on other's research to figure out what is going to be a pretty good balance between time invested and bugs squashed.
Making this time a person
Most of the time those hours can be committed by engineers and actually work well enough. A dedicated QA person is more efficient, but if your need isn't enough to justify it then engineers time will do.
For you to sell your boss on a dedicated QA person you really need to demonstrate you need enough QA time to cover a fulltime position. Outsourcing a part time QA time is a REALLY hard sell, and in my experience one that typically hurts more than helps.
Making the most of QA time
So you have your entire dev team drop what they are doing and do manual QA... This... is bad. If you can dedicate a bunch of time to manually test everything you should be able to commit time to making proper unit and integration tests! Usually the cut best bang for your buck is 15% to 20% of your dev time dedicated to cleaning up old code, bug fixes, and non-production projects such as building out tests, database clean up, optimization, etc. (The crap that needs doing that doesn't directly make money)
As a developer good TDD can be invaluable and save you HOURS of debugging issues. You can reliably count on each part of your code doing it's job, and in the event something breaks you have a test that says what broke and where it broke, even before you spin up the UI to see that it broke. This takes your necessary QA time WAY down. Now instead of "testing all the things" you are really just making sure the UI is in good order... (Which actually works against you getting a QA person, unless you just dump building out automated testing on this person... which isn't ideal, but WAY better then no automation)
Summary
A dedicated QA person is a hard sale and you need to show your boss all the engineer's time dedicated to testing would go further in the hands of a QA person...
But that's really not your problem... You need to automate your testing to just reduce your QA time entirely.
answered Mar 5 '15 at 19:34
RualStorge
9,5372231
Thank you, calculation may work. And, automation is another hard sale!
– etual
Mar 5 '15 at 20:06
@etual it is. It's very hard to explain time spent now saves time later. That said figure out how long it takes to test something manually, how often you have to test it manually, and how long it would take to write an automated test for it. Numbers are the easiest way to sell anything. For me, to be honest I didn't give my employer a choice, I just started writing tests saying "I work faster this way" (But to be fair, I get away with a lot more than most of my peers)
– RualStorge
Mar 5 '15 at 21:15
Lack of automated tests also add cost and risk to the maintenance cycle. If a maintenance programmer later tries to change method X but there are no automated tests, then he will most likely have to add some tests at that point to avoid breaking something, and it's probably going to take more resources to do that during the maintenance cycle.
– Brandin
Mar 6 '15 at 13:21
suggest improvements |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Dedicated QA
Well this is kind of the "gotcha" here. Typically when I make a case for proper QA it fighting to demonstrated dedicating XX hours to QA per sprint. Usually you can put together the math based on other's research to figure out what is going to be a pretty good balance between time invested and bugs squashed.
Making this time a person
Most of the time those hours can be committed by engineers and actually work well enough. A dedicated QA person is more efficient, but if your need isn't enough to justify it then engineers time will do.
For you to sell your boss on a dedicated QA person you really need to demonstrate you need enough QA time to cover a fulltime position. Outsourcing a part time QA time is a REALLY hard sell, and in my experience one that typically hurts more than helps.
Making the most of QA time
So you have your entire dev team drop what they are doing and do manual QA... This... is bad. If you can dedicate a bunch of time to manually test everything you should be able to commit time to making proper unit and integration tests! Usually the cut best bang for your buck is 15% to 20% of your dev time dedicated to cleaning up old code, bug fixes, and non-production projects such as building out tests, database clean up, optimization, etc. (The crap that needs doing that doesn't directly make money)
As a developer good TDD can be invaluable and save you HOURS of debugging issues. You can reliably count on each part of your code doing it's job, and in the event something breaks you have a test that says what broke and where it broke, even before you spin up the UI to see that it broke. This takes your necessary QA time WAY down. Now instead of "testing all the things" you are really just making sure the UI is in good order... (Which actually works against you getting a QA person, unless you just dump building out automated testing on this person... which isn't ideal, but WAY better then no automation)
Summary
A dedicated QA person is a hard sale and you need to show your boss all the engineer's time dedicated to testing would go further in the hands of a QA person...
But that's really not your problem... You need to automate your testing to just reduce your QA time entirely.
answered Mar 5 '15 at 19:34
RualStorge
9,5372231
Dedicated QA
Well this is kind of the "gotcha" here. Typically when I make a case for proper QA it fighting to demonstrated dedicating XX hours to QA per sprint. Usually you can put together the math based on other's research to figure out what is going to be a pretty good balance between time invested and bugs squashed.
Making this time a person
Most of the time those hours can be committed by engineers and actually work well enough. A dedicated QA person is more efficient, but if your need isn't enough to justify it then engineers time will do.
For you to sell your boss on a dedicated QA person you really need to demonstrate you need enough QA time to cover a fulltime position. Outsourcing a part time QA time is a REALLY hard sell, and in my experience one that typically hurts more than helps.
Making the most of QA time
So you have your entire dev team drop what they are doing and do manual QA... This... is bad. If you can dedicate a bunch of time to manually test everything you should be able to commit time to making proper unit and integration tests! Usually the cut best bang for your buck is 15% to 20% of your dev time dedicated to cleaning up old code, bug fixes, and non-production projects such as building out tests, database clean up, optimization, etc. (The crap that needs doing that doesn't directly make money)
As a developer good TDD can be invaluable and save you HOURS of debugging issues. You can reliably count on each part of your code doing it's job, and in the event something breaks you have a test that says what broke and where it broke, even before you spin up the UI to see that it broke. This takes your necessary QA time WAY down. Now instead of "testing all the things" you are really just making sure the UI is in good order... (Which actually works against you getting a QA person, unless you just dump building out automated testing on this person... which isn't ideal, but WAY better then no automation)
Summary
A dedicated QA person is a hard sale and you need to show your boss all the engineer's time dedicated to testing would go further in the hands of a QA person...
But that's really not your problem... You need to automate your testing to just reduce your QA time entirely.
answered Mar 5 '15 at 19:34
RualStorge
9,5372231
answered Mar 5 '15 at 19:34
RualStorge
9,5372231
answered Mar 5 '15 at 19:34
RualStorge
9,5372231
answered Mar 5 '15 at 19:34
RualStorge
9,5372231
9,5372231
Thank you, calculation may work. And, automation is another hard sale!
– etual
Mar 5 '15 at 20:06
@etual it is. It's very hard to explain time spent now saves time later. That said figure out how long it takes to test something manually, how often you have to test it manually, and how long it would take to write an automated test for it. Numbers are the easiest way to sell anything. For me, to be honest I didn't give my employer a choice, I just started writing tests saying "I work faster this way" (But to be fair, I get away with a lot more than most of my peers)
– RualStorge
Mar 5 '15 at 21:15
Lack of automated tests also add cost and risk to the maintenance cycle. If a maintenance programmer later tries to change method X but there are no automated tests, then he will most likely have to add some tests at that point to avoid breaking something, and it's probably going to take more resources to do that during the maintenance cycle.
– Brandin
Mar 6 '15 at 13:21
suggest improvements |Â
Thank you, calculation may work. And, automation is another hard sale!
– etual
Mar 5 '15 at 20:06
@etual it is. It's very hard to explain time spent now saves time later. That said figure out how long it takes to test something manually, how often you have to test it manually, and how long it would take to write an automated test for it. Numbers are the easiest way to sell anything. For me, to be honest I didn't give my employer a choice, I just started writing tests saying "I work faster this way" (But to be fair, I get away with a lot more than most of my peers)
– RualStorge
Mar 5 '15 at 21:15
Lack of automated tests also add cost and risk to the maintenance cycle. If a maintenance programmer later tries to change method X but there are no automated tests, then he will most likely have to add some tests at that point to avoid breaking something, and it's probably going to take more resources to do that during the maintenance cycle.
– Brandin
Mar 6 '15 at 13:21
Thank you, calculation may work. And, automation is another hard sale!
– etual
Mar 5 '15 at 20:06
Thank you, calculation may work. And, automation is another hard sale!
– etual
Mar 5 '15 at 20:06
@etual it is. It's very hard to explain time spent now saves time later. That said figure out how long it takes to test something manually, how often you have to test it manually, and how long it would take to write an automated test for it. Numbers are the easiest way to sell anything. For me, to be honest I didn't give my employer a choice, I just started writing tests saying "I work faster this way" (But to be fair, I get away with a lot more than most of my peers)
– RualStorge
Mar 5 '15 at 21:15
@etual it is. It's very hard to explain time spent now saves time later. That said figure out how long it takes to test something manually, how often you have to test it manually, and how long it would take to write an automated test for it. Numbers are the easiest way to sell anything. For me, to be honest I didn't give my employer a choice, I just started writing tests saying "I work faster this way" (But to be fair, I get away with a lot more than most of my peers)
– RualStorge
Mar 5 '15 at 21:15
Lack of automated tests also add cost and risk to the maintenance cycle. If a maintenance programmer later tries to change method X but there are no automated tests, then he will most likely have to add some tests at that point to avoid breaking something, and it's probably going to take more resources to do that during the maintenance cycle.
– Brandin
Mar 6 '15 at 13:21
Lack of automated tests also add cost and risk to the maintenance cycle. If a maintenance programmer later tries to change method X but there are no automated tests, then he will most likely have to add some tests at that point to avoid breaking something, and it's probably going to take more resources to do that during the maintenance cycle.
– Brandin
Mar 6 '15 at 13:21
suggest improvements |Â
You may want to add some more information on the type of application you are developing to get some more specific advice. In general, prepare for a tough battle if you want to increase the importance of quality. QA is often seen as overrated by management since 'after all, they hired competent people and competent people shouldn't make too many mistakes right'? To change their mind, you will need to make them see that bugs are not always caused by incompetence.
– Cronax
Mar 10 '15 at 10:58
Given QA is considered important, I would suggest you discuss with the team which kind of QA they would take seriously. Perhaps give some suggestions.Then take that result to the boss.
– Thorbjørn Ravn Andersen
Oct 21 '16 at 15:51