That's a great question and a topic of much debate in Kanban communities! However, there are two aspects to this - one, what is your actual engineering practice when a defect is found during development (as opposed to production defects) and two, what is the way you want to model that on your Kanban board.
A developer works on a feature - which may be modeled as a User Story or an Enhancement or a Change Request - and during its development lifecycle, issues or bugs may be found during various testing stages (unit, system, integration, etc.) as well as code reviews - and these issues may be captured/ reported as Defects or Bugs or Issues.
Without getting into your specific processes, there are broadly two methods of modeling this on a Kanban board that teams use.
The first one is, depending on the stage where an Issue or a Bug is reported, the User Story is moved back to the earliest Working stage (Design In-Progress or Dev in-Progress, for example) and reworked on to fix the Issue or Bug.
The second one is, where the User Story is 'blocked' wherever the issue or bug was reported and a new issue or a bug is created as card and taken up for work at the earliest stage it needs to be taken up in (including perhaps in a completely separate swim-lane with its own workflow for fixing such issues or bugs. In the picture below, cards with the red square represent blocked user stories - which are then linked to their associated defects.
The process typically favored is the second option, since it has the following advantages -
- It clearly highlights and visualizes the stories which are blocked due to defects being found in them.
- It specifically identifies and allows 'assignment' to 'failure-demand' - and enables analysis of this failure demand.
- It allows you to model a different workflow/ process for issues/ defect resolution if you wish, in a separate swim lane, which further helps the analysis of cycle time (resolution time), throughput and other metrics which might help you make SLA commitments to your customers.
- If your team is focused on implementing and following WIP limits, it puts pressure on developers to resolve and close open defects against their name since blocked items also occupy their WIP limit.
You do have to make sure that developers follow the process of linking (associating) stories to their defects/ issues (which a Kanban software would usually enable fairly easily) and also to unblock the user story when the defect is closed, so that the developer's WIP limit opens up for doing additional work.
There is a very nice blog post written by Kanban thought-leader Dr. Masa Maeda on this topic you might also be interested in looking at - http://blog.digite.com/how-to-handle-tickets-during-sprint-planning/
Hope this helps!