4 added 2 characters in body
source | link

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.

To me this is wrong KPI and there ishave been at least two discussions here why is so:

I, personally, sometimes report problems found in incomplete work, but I ask before reporting it formally. I ask whether it's because of incomplete work or just requirements are wrong and we need to discuss requirements or plan fixing it in the next sprints.

Joern Boegeholz suggested also to work in branches. This is great approach. However, you said you were working for two weeks on UI changes and it has not been finished. To me this demonstrates that perhaps your stories might be too long and you should try to work as a team on defining stories that are smaller and of finer granularity. That could be kind of compromise also between testers and developers: they could get things to test more frequently and you could focus on your work until it is complete. Finally, merging shorter branches might be less painful.

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.

To me this is wrong KPI and there is been at least two discussions here why is so:

I, personally, sometimes report problems found in incomplete work, but I ask before reporting it formally. I ask whether it's because of incomplete work or just requirements are wrong and we need to discuss requirements or plan fixing it in the next sprints.

Joern Boegeholz suggested also to work in branches. This is great approach. However, you said you were working for two weeks on UI changes and it has not been finished. To me this demonstrates that perhaps your stories might be too long and you should try to work as a team on defining stories that are smaller and of finer granularity. That could be kind of compromise also between testers and developers: they could get things to test more frequently and you could focus on your work until it is complete. Finally, merging shorter branches might be less painful.

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.

To me this is wrong KPI and there have been at least two discussions here why is so:

I, personally, sometimes report problems found in incomplete work, but I ask before reporting it formally. I ask whether it's because of incomplete work or just requirements are wrong and we need to discuss requirements or plan fixing it in the next sprints.

Joern Boegeholz suggested also to work in branches. This is great approach. However, you said you were working for two weeks on UI changes and it has not been finished. To me this demonstrates that perhaps your stories might be too long and you should try to work as a team on defining stories that are smaller and of finer granularity. That could be kind of compromise also between testers and developers: they could get things to test more frequently and you could focus on your work until it is complete. Finally, merging shorter branches might be less painful.

3 replaced http://sqa.stackexchange.com/ with https://sqa.stackexchange.com/
source | link

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.

To me this is wrong KPI and there is been at least two discussions here why is so:

I, personally, sometimes report problems found in incomplete work, but I ask before reporting it formally. I ask whether it's because of incomplete work or just requirements are wrong and we need to discuss requirements or plan fixing it in the next sprints.

Joern Boegeholz suggested also to work in branches. This is great approach. However, you said you were working for two weeks on UI changes and it has not been finished. To me this demonstrates that perhaps your stories might be too long and you should try to work as a team on defining stories that are smaller and of finer granularity. That could be kind of compromise also between testers and developers: they could get things to test more frequently and you could focus on your work until it is complete. Finally, merging shorter branches might be less painful.

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.

To me this is wrong KPI and there is been at least two discussions here why is so:

I, personally, sometimes report problems found in incomplete work, but I ask before reporting it formally. I ask whether it's because of incomplete work or just requirements are wrong and we need to discuss requirements or plan fixing it in the next sprints.

Joern Boegeholz suggested also to work in branches. This is great approach. However, you said you were working for two weeks on UI changes and it has not been finished. To me this demonstrates that perhaps your stories might be too long and you should try to work as a team on defining stories that are smaller and of finer granularity. That could be kind of compromise also between testers and developers: they could get things to test more frequently and you could focus on your work until it is complete. Finally, merging shorter branches might be less painful.

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.

To me this is wrong KPI and there is been at least two discussions here why is so:

I, personally, sometimes report problems found in incomplete work, but I ask before reporting it formally. I ask whether it's because of incomplete work or just requirements are wrong and we need to discuss requirements or plan fixing it in the next sprints.

Joern Boegeholz suggested also to work in branches. This is great approach. However, you said you were working for two weeks on UI changes and it has not been finished. To me this demonstrates that perhaps your stories might be too long and you should try to work as a team on defining stories that are smaller and of finer granularity. That could be kind of compromise also between testers and developers: they could get things to test more frequently and you could focus on your work until it is complete. Finally, merging shorter branches might be less painful.

2 added 568 characters in body
source | link

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.

To me this is wrong KPI and there is been at least two discussions here why is so:

I, personally, sometimes report problems found in incomplete work, but I ask before reporting it formally. I ask whether it's because of incomplete work or just requirements are wrong and we need to discuss requirements or plan fixing it in the next sprints.

Joern Boegeholz suggested also to work in branches. This is great approach. However, you said you were working for two weeks on UI changes and it has not been finished. To me this demonstrates that perhaps your stories might be too long and you should try to work as a team on defining stories that are smaller and of finer granularity. That could be kind of compromise also between testers and developers: they could get things to test more frequently and you could focus on your work until it is complete. Finally, merging shorter branches might be less painful.

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.

To me this is wrong KPI and there is been at least two discussions here why is so:

I, personally, sometimes report problems found in incomplete work, but I ask before reporting it formally. I ask whether it's because of incomplete work or just requirements are wrong and we need to discuss requirements or plan fixing it in the next sprints.

To me this is a perfect example of what happens when effectiveness of testers is assessed based on the wrong KPI, in this case, a number of bugs reported. In the end it will harm testers, developers, relationships between tester and developers and as a result product quality.

To me this is wrong KPI and there is been at least two discussions here why is so:

I, personally, sometimes report problems found in incomplete work, but I ask before reporting it formally. I ask whether it's because of incomplete work or just requirements are wrong and we need to discuss requirements or plan fixing it in the next sprints.

Joern Boegeholz suggested also to work in branches. This is great approach. However, you said you were working for two weeks on UI changes and it has not been finished. To me this demonstrates that perhaps your stories might be too long and you should try to work as a team on defining stories that are smaller and of finer granularity. That could be kind of compromise also between testers and developers: they could get things to test more frequently and you could focus on your work until it is complete. Finally, merging shorter branches might be less painful.

1
source | link