Can we analyze the work efficiency of developers and testers by JIRA? if Yes How to do that?
Like how many bugs a tester found in a release per hour
How many bugs produced by developer in a task
Something like this might help you:
issuetype = Bug and reporter = xyz and created > -1w
But this only gets you bugs reporter by the user in the last X duration. It is not exactly a report though. You can maybe create a filter like the below and use it in 2D filter gadget to see a report for all users.
issuetype = Bug and created > -1w
Duration can be changed as you wish!
I would be careful to rate the efficiency and quality of developers and testers on the number of issues they create or resolve.
In our company, something like that is forbidden. We have an agreement with our work council to not get such numbers from Jira.
I know, this was not your question, but maybe it is some food for thought ;-)
I must agree with Thomas-S here - counting bugs found per hour is a broken model of productivity measurement, in the same way as measuring a coders output by lines of code. I can turn out tens of thousands of lines of code and produce absolutely nothing of any use. Equally, I can log ten bugs an hour in the software I'm looking at currently, but whether they're valid, fixable or even useful reports is a totally different story.
What do you mean by work efficiency? Is someone that analyzes the problem, covers edge cases and writes testcases less efficient of someone that does less than that but handles a couple more issues more efficient? How do you measure the cost of issues that repeat because the process to test that issue is not included into the release process?
I agree with your comments but even then I'll say that there is a relation between no of bugs in a release and total work hours. Let me explain here:
Developer's Efficiency Measurement:
1. A task is assigned to a developer which includes a simple contact form and time was 6 hours.
2. Developer completes the task in 8 hours and sent it to tester
3. Tester found 4 issues in this work for example 1) Spells of labels were not correct 2) Email form has missing check of email validation 3) alignment of page not matching with design 4) Focus is not on 1st field
So It can show a picture of developer's efficiency In following way:
We will list the tasks assigned to developer in last month, Time in hours and no.of issues in that task
Tester Efficiency Measurement:
1. A task is assigned to a tester which includes a simple contact form testing and time was 2 hours.
2. Tester completes the test cycle with NO ISSUE in 2 hours and sent it to Team Lead for Review
3. Now Team Lead/QA Manager found 4 issues in this work for example 1) Spells of labels were not correct 2) Email form has missing check of email validation 3) alignment of page not matching with design 4) Focus is not on 1st field
So It can show a picture of Tester's efficiency In following way:
We will list the tasks assigned to Tester in last month, Time in hours and no.of issues He missed in that task,
So here the question will be how to find that which issues were missed by tester that can be in either way
a) There should be option to find bugs which are assigned after approval of tester
b) QA Manager separately note down those issues in sign off.
I was debating responding since the response is off topic from Jira, but I promise to bring it back to Jira.
In my opinion you are measuring the wrong thing and you have setup an adversarial environment. You want bugs to be found during the development/qa cycle. You do not want to penalize in any way because bugs are found. We have our QA team members paired up with developers from day one. The QA member learns about the system and works on designing and implementing tests right from the beginning. The QA member assists in setting up environments. The QA member also assists in giving additional testcases. What is your team doing to avoid issues in the future?. How well have they documented their testcases/behaviors such that other people can continue their efforts. How well have they understood what is being developed. These are not things to be measured but a mindset on what is important.
You want measures that are analytical not subjective such as code coverage, performance, error injection and detection to prove the code is doing what it needs to. In most cases, the normal path will work. It is the error recovery that matters. Yes, more complex interactions requires positive testing. You can write testcases all day long but if they test the same thing those tests are useless.
What matters is the work produced. Does your review teams agree the work was done?
You have put your emphasis on the development process where the emphasis should be on your customer expyerience. Put that minset into your development/QA members and you will have a better product.
Jira should be the glue combining your various tools together. You want your QA/Development members to see Jira as the place to store their knowledge. You do not want them to see Jira as a negative because they will avoid putting their information there. You want to make your vaious reviews a positive experience and Jira is the place they go to start any process.
Dear Norman, my view is that you are pioneering a line of thought that was badly needed in the Atlassian ecosystem. You are bringing to software development a sociotechnical perspective that got a lot of attention in the business organizational scenario, but that I hadn t seen yet in the sw development environment. I d like to encourage that more of this perspective come out here, so that people who work on cultural change and change management can participate effectively and enrich our learning together. Your observations are all about working with joy and appreciation for each other, in a virtuous cycle that can take place and make development more rewarding.
Thank you for the complement. I have instituted this process at various different companies since 1983. You are correct though that I needed to start from the business side since there is a cost and the benefit does not show until farther down the transition cycle.
Every team in the world is unique, and so Atlassian believes that each and every team's best way of working needs to be molded to their unique circumstances – ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot