Not a bug tracker, but ...
A real IT person always likes to cook porridge from an ax. And if this porridge also turns out tasty to feed colleagues, then it turns out generally great.
On duty, I constantly have to deal with various installations of bug and issue trackers (hereinafter referred to as bug trackers), and there are quite a few non-standard solutions among them. I had to unfold something myself, I “peeped” at clients, but it would be useful to share observations.
')
I have already spoken about this topic at the SQADays conference, but for those who are lazy to watch 18 minutes of video, everything will be briefly described in the article.
So, why do we need to use a bug tracker in a non-standard way? There are two reasons for this:
The examples that follow will be taken from real life. But the successful implementation of anyone, does not mean that everything will go smoothly. Do not forget to think, try and consult with older comrades.
Well, I will immediately apologize that often the emphasis will be on using JIRA (you can throw a tomato at me), because I use this system on a daily basis, but other bug trackers have not been forgotten - almost everything described below can be done with their help.
The most frequent, not quite standard, application of the bug tracker, which I had to observe, was to use it as a HelpDesk in the technical support service.
Of the advantages of such an application, it is possible to note the convenience of linking calls to HelpDesk and the bugs introduced by them (integration with HelpDesks becomes prettier every day, but there is no ideal), and there is no need to learn technical support to work with two systems. But you need to understand that such a system will be a little less convenient than a separate HelpDesk, and if you have to work with a large number of calls, most of which are decided by the support service on your own, it is better to look at a separate HelpDesk system.
Get to the point. How can such a system be configured?
First, you need to provide the ability to receive email requests . Fortunately, many bug trackers are able to create applications from emails:
Using these plug-ins / processors allows you to parse letters, save the subject of the letter in the subject line of the created application, attach attachments from the letter to the application, bind the response messages to the corresponding applications.
But even if you do not plan to deploy HelpDesk, try using the creation and commenting of applications via email in their daily work. Some find it very convenient.
Next you need to ensure acceptance of applications through the web . Usually in a bug tracker you can:
For JIRA, the Issue Collector plugin is worth mentioning. It allows you to set up convenient feedback forms for posting on your site.
Unfortunately, the plugin is still damp and not in all cases can work reliably.
The presence of a support service usually implies the presence of an SLA ( Service Level Agreement ), according to which you must solve incidents for a specific time. And to eradicate forgetfulness administrators, with the filing of the manual, set up all sorts of reminders:
Coordination, phasing, applications, multi-level hierarchy of employees, what could be better ... for automation? In fact, the automation of some bureaucratic aspects of the organization, if it does not help make them simpler, then it does so more transparently.
I have seen bug trackers with which they made the coordination of equipment purchases, tracking the project budget, working with documents, etc.
The basis of such customization is usually the creation of its Workflow - the life cycle of the application. Those. what conditions the application has and what transitions can be between them. In addition, by configuring access rights, individual transitions can be allowed only for specially trained responsible comrades.
It helps to create your workflow in the daily routine of the developer. For example, new intermediate states can be introduced for tasks like “in testing” or “customer accepts”.
Using your workflow is usually inextricably with the creation of so-called custom fields and new types of applications. Custom fields can assist in storing any additional information:
New types of applications (for example, “document approval”, “procurement”, “design” or “testing”) make it possible not only to make the work process more visual, but also to link a separate Workflow to each type of application. So if for the task “development” it makes sense to enter the state “testing” in the life cycle, then for the task “design” this may not be necessary.
A bug tracker is not only a valuable tool, but usually an email notification system embedded in it. And these notifications can be used as a benefit to create mailing lists within the organization. The recipe is simple:
You should definitely take care of monitoring resources, if the same servers are often used simultaneously for different stress tests, or two employees are simultaneously trying to take the same iPad on a business trip for demonstration.
It is difficult to raise the conscience of colleagues with the help of a bug tracker, but it is possible to raise the level of organization. Recipe:
Naturally, no one can forbid a person to take away a resource and “not to be noted in the system”, but with the help of a kind word and a convenient tool one can do more than with the help of one kind word.
A fairly common function of voting for the implementation of certain applications can also be used for your own benefit. If you have asked the question “where to go for a corporate event” or “what to present to the director for his birthday”, then you can safely use the bug tracker (make sure only that the director does not use it :). Recipe:
JIRA and Bugzilla have a built-in voting feature. For Redmine there is a plugin .
There are fans to use the bug tracker as a system for storing a set of regression tests that must be performed manually on each regular version of the product. I myself am not a fan of this method, but once people use it, then there is something in it. Recipe:
Advantages of this solution: it is very convenient to refer to applications / bugs in the bug tracker from tests, you cannot close the version in which there are “unclosed” tests. In general, it may not be as convenient as a specialized test management system.
In addition to the ability to customize bug trackers (and all previous recipes are essentially customized), it is often possible to extend the functionality of the bug tracker programmatically.
All major bug trackers have remote access interfaces that can be used for some kind of automation. For example, automatically post requests for some events or from external systems.
Who does not want to bother with programming, can use command line clients for automation:
To incite holivar I will say that JIRA is the most developed client :)
Well, if you don’t want to do anything yourself , then you should look for ready-made plugins for your bug tracker:
Again, here is JIRA ahead of the rest. Mainly due to the ecosystem for plug-in developers, which, with an adequate level of training, makes it very cool to customize JIRA's behavior and add all sorts of “usefulness” and “whistles”.
A couple of thoughts that I wanted to convey to listeners on SQADays and to readers on Habré:
And in the comments I will be glad to see some non-standard uses of bug trackers that came across to Habrozhiteli.
Thank!
On duty, I constantly have to deal with various installations of bug and issue trackers (hereinafter referred to as bug trackers), and there are quite a few non-standard solutions among them. I had to unfold something myself, I “peeped” at clients, but it would be useful to share observations.
')
I have already spoken about this topic at the SQADays conference, but for those who are lazy to watch 18 minutes of video, everything will be briefly described in the article.
Meaning?
So, why do we need to use a bug tracker in a non-standard way? There are two reasons for this:
- Banal savings. Although usually ordinary employees are not used to asking such a question, it still has a place to be.
- Attempts to use non-standard tools of this or that tool (even unsuccessful ones) make it possible to study this tool better and use it more effectively for everyday tasks.
Disclaimer
The examples that follow will be taken from real life. But the successful implementation of anyone, does not mean that everything will go smoothly. Do not forget to think, try and consult with older comrades.
Well, I will immediately apologize that often the emphasis will be on using JIRA (you can throw a tomato at me), because I use this system on a daily basis, but other bug trackers have not been forgotten - almost everything described below can be done with their help.
Go!
HelpDesk
The most frequent, not quite standard, application of the bug tracker, which I had to observe, was to use it as a HelpDesk in the technical support service.
Of the advantages of such an application, it is possible to note the convenience of linking calls to HelpDesk and the bugs introduced by them (integration with HelpDesks becomes prettier every day, but there is no ideal), and there is no need to learn technical support to work with two systems. But you need to understand that such a system will be a little less convenient than a separate HelpDesk, and if you have to work with a large number of calls, most of which are decided by the support service on your own, it is better to look at a separate HelpDesk system.
Get to the point. How can such a system be configured?
First, you need to provide the ability to receive email requests . Fortunately, many bug trackers are able to create applications from emails:
- For JIRA, these are the existing Mail Handlers and the wonderful Jira Enterprise Mail Handler plugin (which, starting with JIRA 5, has become paid).
- For Mantis - EmailReporting Plugin
- For Bugzilla script email_in.pl
Using these plug-ins / processors allows you to parse letters, save the subject of the letter in the subject line of the created application, attach attachments from the letter to the application, bind the response messages to the corresponding applications.
But even if you do not plan to deploy HelpDesk, try using the creation and commenting of applications via email in their daily work. Some find it very convenient.
Next you need to ensure acceptance of applications through the web . Usually in a bug tracker you can:
- Strongly cut the rights of clients, so that they only saw their applications and could not delve into your internal kitchen.
- Open a self-registration if you have a boxed product or service sold freely and new customers may appear at any time.
- Enable the possibility of anonymous creation of applications, without registering users. Especially useful if you have a commercial bug tracker, the license cost of which depends on the number of users in the system.
For JIRA, the Issue Collector plugin is worth mentioning. It allows you to set up convenient feedback forms for posting on your site.
Unfortunately, the plugin is still damp and not in all cases can work reliably.
The presence of a support service usually implies the presence of an SLA ( Service Level Agreement ), according to which you must solve incidents for a specific time. And to eradicate forgetfulness administrators, with the filing of the manual, set up all sorts of reminders:
- For JIRA, you can apply a relatively simple solution based on a periodically triggered service and a Jelly script, which will do all the rough work. Well, if there is enough knowledge, the service can be written in Java and have non-trivial logic.
- In bugzilla there is a whinning function.
- And for Mantis, there are also plugins and scripts.
Bureaucracy
Coordination, phasing, applications, multi-level hierarchy of employees, what could be better ... for automation? In fact, the automation of some bureaucratic aspects of the organization, if it does not help make them simpler, then it does so more transparently.
I have seen bug trackers with which they made the coordination of equipment purchases, tracking the project budget, working with documents, etc.
The basis of such customization is usually the creation of its Workflow - the life cycle of the application. Those. what conditions the application has and what transitions can be between them. In addition, by configuring access rights, individual transitions can be allowed only for specially trained responsible comrades.
- JIRA even has two Workflow editors - convenient and beautiful :) With version 5.0, beautiful graphics became the main one, but you can get to the old editor. And the workflow, cited above, from JIRA was copied.
- Bugzilla initially had a fixed application life cycle, but from version 3.2 it can be "tweaked"
- In Mantis, you need to dig a little in the code.
- And in Redmine everything is done in the form of a tablet.
It helps to create your workflow in the daily routine of the developer. For example, new intermediate states can be introduced for tasks like “in testing” or “customer accepts”.
Using your workflow is usually inextricably with the creation of so-called custom fields and new types of applications. Custom fields can assist in storing any additional information:
- The client for whom the feature is done
- Tester who tests it
- Intermediate period when the demo should be held within the team
New types of applications (for example, “document approval”, “procurement”, “design” or “testing”) make it possible not only to make the work process more visual, but also to link a separate Workflow to each type of application. So if for the task “development” it makes sense to enter the state “testing” in the life cycle, then for the task “design” this may not be necessary.
Mailing Lists
A bug tracker is not only a valuable tool, but usually an email notification system embedded in it. And these notifications can be used as a benefit to create mailing lists within the organization. The recipe is simple:
- Create a separate project "for mailings"
- Inside the project we start one application for each topic of mailings. For example, "Schedule of the dining room" or "Attention to the office of motorists."
- Depending on the degree of bureaucracy, certain people / groups either forcibly fit into the list of recipients of notifications, or may themselves become watchers (those who receive notification of the application) on their own.
- When you add a new comment to the application, its text is sent to the right people.
Resource sharing
You should definitely take care of monitoring resources, if the same servers are often used simultaneously for different stress tests, or two employees are simultaneously trying to take the same iPad on a business trip for demonstration.
It is difficult to raise the conscience of colleagues with the help of a bug tracker, but it is possible to raise the level of organization. Recipe:
- For each resource that can be used at the same time by only one employee (server, car, demonstration iPad), one request is received. For example, "Employment server LOAD-02."
- A simple workflow is configured from the “free” and “busy” states.
- When a person transfers an application from the state “free” to “busy”, this means that he has taken the resource for himself. In this case, the application is automatically assigned to it, so that anyone can see who has the resource now. It is useful to set up mail notifications.
- The right to reverse the transition is usually only the one who took the resource or the administrator.
- Here you can also attach a reminder (see above about SLA), which after a couple of days will clarify whether this resource is still needed.
Naturally, no one can forbid a person to take away a resource and “not to be noted in the system”, but with the help of a kind word and a convenient tool one can do more than with the help of one kind word.
Voting
A fairly common function of voting for the implementation of certain applications can also be used for your own benefit. If you have asked the question “where to go for a corporate event” or “what to present to the director for his birthday”, then you can safely use the bug tracker (make sure only that the director does not use it :). Recipe:
- A draft is being created for voting.
- Each new vote creates a draft version.
- Application-variants are created and assigned to this dummy version.
- People vote
- When the time expires, the applications are closed (so that you cannot vote anymore)
- And builds a report on the version with the sorting of applications by descending votes
JIRA and Bugzilla have a built-in voting feature. For Redmine there is a plugin .
Test management
There are fans to use the bug tracker as a system for storing a set of regression tests that must be performed manually on each regular version of the product. I myself am not a fan of this method, but once people use it, then there is something in it. Recipe:
- Creates a new type of application "Test".
- For this type of application, custom fields “Execution steps” and “Expected result” are added (it is possible in one field, but the testing classics are indignant).
- A subtask “Test execution” is created, which will have the states “Test failed”, “Test passed”, “Test failed” and “Test cannot be executed”.
- If the test is planned to be conducted on the XY version, then a subtask is created in it, which is assigned to this version.
- After testing, the subtask is transferred to the desired state.
- Then you can build all sorts of reports on the subtasks “Running a test” in order to understand the light of the project.
Advantages of this solution: it is very convenient to refer to applications / bugs in the bug tracker from tests, you cannot close the version in which there are “unclosed” tests. In general, it may not be as convenient as a specialized test management system.
Technical expansion options
In addition to the ability to customize bug trackers (and all previous recipes are essentially customized), it is often possible to extend the functionality of the bug tracker programmatically.
All major bug trackers have remote access interfaces that can be used for some kind of automation. For example, automatically post requests for some events or from external systems.
- JIRA: REST, SOAP, XML / JSON-RPC
- Mantis: MantisConnect SOAP
- Redmine: REST
- Bugzulla: XML / JSON -RPC
Who does not want to bother with programming, can use command line clients for automation:
To incite holivar I will say that JIRA is the most developed client :)
Well, if you don’t want to do anything yourself , then you should look for ready-made plugins for your bug tracker:
- JIRA: more than 400 plug-ins (including paid ones) are written in Java
- Redmine: more than 230 plugins written in Ruby
- Trac: about 50 plugins in Python
- Mantis: just over 25 PHP plugins
Again, here is JIRA ahead of the rest. Mainly due to the ecosystem for plug-in developers, which, with an adequate level of training, makes it very cool to customize JIRA's behavior and add all sorts of “usefulness” and “whistles”.
Results
A couple of thoughts that I wanted to convey to listeners on SQADays and to readers on Habré:
- Know almost everything that your bug tracker can do (read “any tool”).
- Learn to administer and program, or make friends with colleagues who know how to do it. Their help is useful.
And in the comments I will be glad to see some non-standard uses of bug trackers that came across to Habrozhiteli.
Thank!
Source: https://habr.com/ru/post/144122/
All Articles