There are many ways to deal with this. But before that, remember that there are no 'rules' in Kanban -- it is just what your team decides. For example, you say you cannot move the card back because the WIP is full. Well, if your team creates a policy that you can override the WIP when a defect is found, then thats your team policy and now you can move it back :) (just make the policy explicit so that everyone understands and agrees to it)
Now the options
- I mentioned one option above - move the card back. You can agree on a team policy that defects can override the limits in upstream lanes
- Another option is to mark the card blocked and leave it in the QA lane. If you look at the board right to left, then the first action is for team members to swarm & resolve the block in QA before continuing with the existing work
- Third option is to mark the card blocked, and create a new card (maybe in a different colour) to track the impediment.
- The new card can move through the same lanes,
- or it could jump certain lanes (analysis may not be needed for example),
- or you can create a swimlane just for the impediments to flow, maybe with columns Not Started->In Progress->Done. If you create a separate swimlane, you can use that to track any impediment, not just defects.
Which option you choose depends on your situation.
If you choose to block the card in the QA lane, then the card will be occupying one spot in your WIP limit. So while the block exists, you may have a tester free. If the team is cross-functional, that person could perhaps help out upstream in the system.
If you prefer not to block up the WIP in QA (ie, have the testers continue testing other cards at full WIP), then Option 1 might be for you, as it frees up the QA lane.
If you have a tight cross functional team, swarming might be the best option. The card gets blocked, tester & dev pair up, the defect is fixed, and it moves on. Shortest lead time. If you have handoffs, then Option 3 gives you more visibility.
The important thing here is to implement one of the options and then keep taking steps to improve the system. Don't be content to just say, okay we can now handle defects on our kanban board, and leave it at that.
For example, if you have handoffs and implement Option 3 to get visibility into the time taken to fix bugs, then look at that and ask: How can we shorten this feedback loop? Can we bring testing & development into closer collaboration? If you see a lot of defect cards generated at the QA lane, then ask: Why are we generating these defects, and how can we fix it? Should we implement acceptance tests up front? .. and so on.