We are trying in our company discuss our processes. We are software development company.

We expect we have processes according ITIL to take a care for customer Incidents (Incident management, Problem, Change, function Service Desk).

Now we want to have similar processes for our development->testing->bugfixing, using same application to have same GUI and because we think there are things which may be the same for both support and development processes (like Incident from customer is leading to RFC, bug found by tester could lead to RFC also).

I found only picture (Figure 6.4 in chapter 6.7) in ITIL blue book (Service Delivery), that is explaining "The error cycle in the live and development environments".

The general question not answered by this picture: During the test of some internal build, the tester founds a bug. What he has to create? Is it Incident? Would it be something else? Or should we define a new object like "Bug"?

Incidents are usually coming from customers - over Service Desk. There should be probably different process for bugs found by testers (I do not expect, that they will create Incident, which will be handled the same way like Incident from customer).

Anyhow: later the bug is leading probably to Problem, Known Error (which would be known error in development known errors database, later if it is not fixed in release, then it would be also in the live known errors db), Request For Change.

The ITIL is not telling too much about this (only the picture and small chapter I already menitoned...

You're talking about Defect Management and it's not technically an Incident as the concept applies to production environments and in terms of impact to the business. I once had a customer who used a well known Service Desk application for Defect Management instead of Incident Management.

However, in terms of the Incident/Problem Management processes, you could apply them here but I would be reserved about logging defects or bugs in the same tool as my production Incidents and Problems. An alternative, perhaps, would be to copy the application/form/database and use that instead?

You're spot on with the bug leading to a Problem/Known Error. If you implemented live with bugs, these would be captured as Known Errors, with the appropriate workarounds should any issues arise.

You may also want to take a look at the ITIL Application Management book. I haven't read it but it looks as though it may contain topics that you are interested in.

Remember that an incident is anything "that is not part of the normal operation of the service and effects quality of service". This is very generic, but means that there can be different sub-types of Incidents -Request for service, system event, request for information (how to), development defects, etc.

You would just need to register the incident as a different type to be able to track the "development defect".

The Application Management book addresses more of the organizational change and management/control aspects of AppDev.

Internally, we use a Development Process, which is a bit based on RUP. Now, the organisation is investing in ITSM. If you look closely to the process models, nor Service Support, nor Service Delivery focusses on Application Development (except Change & Release management).

If you would break it down to Operational, Tactical and Strategical Processes, where would you put Application Development ?

Another aspect is I would prefer having Change Management in the lead of all changes to the infrastructure (incl. Applications), but if I would move Application Development into the Tactical Processes, this might generate a certain level of aggrevation into the Change Management Role.

Currently I am reading the book from ITIL - Application Management.
Seems to be focused on processes during application lifecycle, but on the first look there was not so much relations to Service Support and Service Delivery processes.

Even I would expect also (as bvanbrabant wrote) to have Change Mgmt. in the lead of all changes.

Also you can find some help to this issue in Prince2 book, so this book is focused in management Sw life cycle.

From my point of view a bug detected in a test enviroment should not be considered as an incident, and should be considered as a problem, because we have detected early and this bug cannot have the chance to create "real" incidents.