TL;DR
The focus on representing automation as a separate step is a bit of a red herring, although that doesn't mean the automation problems aren't real. What you're dealing with is really an X/Y problem caused by a lack of smooth process flow.
The solution is to review your entire process for waste, friction, and unnecessary steps. You then need to revamp your processes, tooling, queue management, and working agreements to bring your overall process into as close to a state of continuous flow as possible.
Automation Isn't Inherently a Separate Activity or Status
How should I account for automated steps in Kanban board?
You shouldn't have to, because in most cases the automation is irrelevant to the status or activity. For example, a "testing" or "QA" step isn't really dependent on whether the testing is manual or automated. That isn't to say you can't sub-divide or add additional columns, but you should certainly ask yourself and the team whether doing so adds meaningful value.
Furthermore, your manual review and verification steps sound like anti-patterns to me. Continuous integration should be just that: routine and frequent (ideally continuous) integration into a common branch to test for regressions or conflicts. When possible, code reviews should really be automated by linters and style guides, and "verification" should really be automated unit, functional, and regression testing using a TDD/BDD framework that ensures the code increment meets the Definition of Done. Anything else is really just inserting manual steps into something you appear to consider automated, which seems like a process smell to me.
"Test First" Should Be a First-Class Principle
You also mention that after "Done" you have another group or team writing tests post facto. That's another anti-pattern. Currently, the received wisdom within the agile community is that you should be writing the tests first so that:
- You are codifying the Definition of Done for a feature, fix, or improvement before you create the actual change.
- You have executable tests and documentation, which ensures that your testing is automatable and that your documentation doesn't fall out of step with the product you're developing.
- Validation that new or modified code can be successfully integrated with the existing code base or a new deliverable increment can be successfully automated.
Optimize Your Test Pyramid
[A]uto-tests/unit-tests are running to ensure that nothing is broken. This step can take a while (4-8 hours per change).
While a long-running regression suite before deploying to production might be worth doing, continuous integration best practices rely on fast feedback loops. If your CI is that slow, it dramatically reduces the value of the feedback loop, and provides a huge disincentive for doing truly-continuous integration.
Slow tests are generally a process smell that indicate that you are testing too much of the wrong things, or that you aren't really testing at the right level of granularity. There are many different representations of the test pyramid, and numerous views about how to optimize the testing pyramid for any given domain, but they all basically say similar things about the wide base of the pyramid: most of your tests should be isolated unit tests that run fast so that you can optimize validated learning about the specific change(s) under test.
I suspect that your team is doing some or all of the following:
- too much integration or UI testing, or some other form of end-to-end testing, rather than isolated unit testing
- writing poor tests that are testing the wrong things, or that have unreasonable overhead
- testing things that should be assumed to be valid such as core language constructs rather than your application's logic or behavior (e.g. if you're testing that
2 + 2 = 4 you're testing the language or compiler, not your application)
- not ensuring that developers are testing code locally before committing things to the current integration branch
- writing non-performant tests, like generating complex or heavy-weight objects rather than stubbing or mocking expensive activities unrelated to the current test
From a project management perspective, these are largely engineering concerns that are out of scope except insofar as they impact cost, schedule, and quality. However, a process that isn't serving its intended purpose is a project management concern, and so you should definitely address the failure of your "CI" (the quotes are deliberate) to be timely and effective for your team.
Your Process Steps Need Better Integration
While inspecting individual components to ensure they meet specifications is important, a disjointed process that doesn't actually build a cohesive increment is inherently broken. If you're building a car, you need to ensure that the axles, doors, or engine parts on the assembly line all meet the correct tolerances so that they can be put together. However, the real measure of success isn't whether a specific part is within tolerance; the goal is to ensure that all the parts can come together to deliver a working car.
Software-related work items moving through a Kanban process are really the same thing as the car metaphor. What's important isn't just the individual steps. What truly matters is the integrated unit or cohesive increment of work that comes out at the other end. Somehow, your current process has lost sight of that, and your current queues, gates, states, and statuses aren't working smoothly together to ensure a properly-delivered increment.
You should work with your team and with your organization to inspect-and-adapt the process to provide a more continuous flow. Part of that discussion is developing working agreements about what to do with work items that don't meet specifications or the Definition of Done. Within a single cycle, moving them back a step or returning them to the starting input queue may be appropriate; if defects aren't found until after delivery then the work unit should either be discarded or placed into the appropriate input queue as net-new work with the appropriate metadata such as urgency or priority.
