Incident processes in QA/DEV/TEST environments?

[joshinplano]

Does anyone here use their IM process and tool(s) for their DEV/TEST/QA environments?

Some of our Managers and Project Teams are wanting to use our Incident process and tool to start tracking problems in those environments. There has been a lot of downtime in those environments recently, and they believe that using IM will help remediate issues. They want to track both project/release related Incidents, as well as environmental Incidents.

The underlying problem is that if a release is pushed into those environments and something is wrong, a defect is opened in our defect tracking system. The project teams are not responding to those defects quickly, and so the environment sits dormant because the problem is not remediated.

I have tried to explain that, while it could make sense to monitor and use IM for environment related incidents (i.e. server down, etc.) it does not make sense to log defects in use our IM process or tool to track those.

I believe they should follow a process such as:

- Open defect in defect tracking tool
- Project Team analyzes issue and determines if its projected/release related or environment related
- If its project/release related they keep in their defect tracking tool
- If its environment related they open an IM in our IM tool

Any thoughts/input?

[Diarmid]

It has to be horses for courses. If the Incident Management tool has the quality required in the non-live environments, then it has to be worth looking at how to do it, especially if it also means they can ditch an inferior tool or even if they can integrate to their other tools.

The issue is largely about maintaining the correct management in place in each environment. I would suggest that they should not use your process but they could use your procedures, although they should probably modify them to meet their own management requirements.

Two approaches seem feasible, but they do depend on the capability of your IM tool and possibly on its licence restrictions.

One is to use a separate instance of the software and let them run it themselves.

the other is to use very clear cut categories/classifications or whatever to distinguish the different systems and have the service desk staff work with both environments.

If the same staff are servicing the live and non-live environments and systems then it makes sense to manage them all together in one system. After all today's development is tomorrow's live system and if it ends up late because it was not given the support priority it deserved. It is perfectly possible that a fix in test is more urgent than some live incidents and if this is true you need a system that manages it that way.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718

[Timo]

Aren't all these SW dev methodologies supposed to address areas like issues, incidents, etc? I bet you will find something that will suit your needs if you look in detail into whatever methodology is used by the dev team.

[rpmason]

I looked at Josh's post and he didn't say anything about it being about software development. Even so, he very well might be describing SW dev.

Our data center has hundreds of pre-production environments on several platforms (mainframe, open systems, windows). We provide the infrastructure and (mostly) commercial-off-the-shelf applications. Our customers use the applications or develop their custom software on our infrastructure.

Josh, we use the same tool for all environments. The Environment field helps to keep it all straight. It's not unusual for a device or a service to be associated with several environments, so we assume the "highest" environment for priority and risk purposes. As always, your mileage may vary.
_________________
Ruth Mason
USA

[Ghulam]

One problem faced in an organization i was at was that the help desk was helpless once an application went live - they just didn't know enough about it because of inadequate release management and insufficient understanding of the application. agreeing on the correct classifications and having (and using) agreed distinction between the configuration status of an application, i.e. acquired, development, in test, under QA, under uer acceptance testing, could go a long way in improving the help desks ability to support the application once it goes live. this does require quite a bit of organizational maturity though. the objectives of live environment upport personnel can be different from project personel and project environment users. this could be especially useful if known errors and resolutions during pre-produciton phase of the application are well documented in the the help dewsk tool.

[Brian1]

I would suggest looking at the way you do business today and based on that analysis determine the best course of action for your company. I have consulted at organizations where the user community was heavily involved in development therefore it made sense to call the SD and log incidents there. I have also seen organizations where IM and CM did not apply to pre-production and it was managed under a development methodology. And I have seen companies do nothing in the DEV/QA/TEST world. Really comes down to what your organization is willing to spend and the value proposition they get from the additional investment. FYI, if your developers are not doing this today be prepared for the battle cuz "they no like!".

[Timo]

Ooh, another Canadian

[Diarmid]

Just to elaborate on what Brian1 said. Irrespective of how you handle dev incidents in the applications, it is a very good idea to fully manage the dev infrastructure whether it is the same groups that manage the live or not. Infrastructure being used to develop apps is live because you need its capacity and availability in order to perform the development to time.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718