I know from past experience that Bugzilla takes security seriously. Furthermore, all such information needs to remain unexposed to the public at large. () Security is important to the system in that the labs are a shared environment among multiple customers and I need to ensure that customers can see only the information pertinent to their testing. Bugzilla is very strong in all of these areas. () I examined "true" IT ticketing systems and found them lacking in a number of ways: they were not FOSS, they lacked custom reporting, they lacked significant customization capabilities, they lacked the ability for users to store their own queries, they were not extensible, they did not provide rich graphical reports, and/or they were not easily upgraded / migrated to new systems or backed up in case of system failure. () Where a problem arises in hardware, capturing software-related information is usually of prime importance. Buzilla seemed a fine fit, though it lacked many of fields I need and had a number of fields I either don't need or wish were optional.
Bugzilla workflow customization software#
Thus, capturing the initial appearance of the problem in a domain-specific way is important even if the problem is often traced to software in the end. () Software defects will be a measurable portion (at least 50%) of the reported problems, but these defects may first, _to the tester_, appear to be problems in hardware. Over time, we can build a searchable database of problem manifestations and root causes that will reduce problem resolution and provide the data to drive lab investment decisions.īased on this, here is my reasoning in no particular order:
The goal is to capture problems seen by testers and drive to root cause solutions regardless of whether these are hardware or software solutions and regardless of how the problem manifested. Defects will just as often be software as hardware related.
Bugzilla workflow customization windows#
Within the labs, there is application software under test, embedded software under test, application and embedded test management software, custom hardware and wiring and of course a significant amount of core IT infrastructure (linux / windows servers, VME-based systems, routers and the like). The system is to support two software and hardware testing labs in different states in the US. The IT Ticket system I require is not "standard" IT ticketing though that is the best way to describe it. This is an excellent question and one in which I should have addressed in my initial post.
> Use the right tool for your needs as Bugzilla doesn't seem to fit * Can you please provide any other high-level advice or anecdotes regarding this approach or your experience in attempting something similar? * Can I set user/group security to operate against only my custom fields? It is important that access be restricted based solely as these fields, as Bugzilla's default fields are not really applicable to my problem domain. * Can all default fields (including Product and Component) be hidden and never used or must I use some of these fields? However, there are a few specifics on which I am unclear: Workflow is unlikely to change substantially and the existing tools for editing workflow seem adequate for my needs. My plan thus far is to edit the templates / create custom templates as necessary to hide most if not all of Bugzilla's fields on the appropriate pages using the typical hidden field mechanism and create custom fields that match my needs through the admin screens. I am hoping a customization expert can provide some top-level advice on what I am about to do. I have performed Bugzilla customization in the past, but haven't taken on anything this extensive. This will require me to add 10-15 custom fields, build custom reports and establish multiple security levels against these custom fields.
I am planning to customize Bugzilla to act as an IT ticketing system.
0 kommentar(er)
