Breaking news! Automation development is software development. Yeah, it’s true. Even if we are using a drag-and-drop or record-and-playback interface to create that automation, somewhere, in the stack, under the hood or behind the curtain, there is code sequenced by our actions. We must start treating our automation initiatives as software development initiatives, lest we end up in a quagmire of unsustainability and early project death.
One beneficial tactic used in software development is to have a different team member look for issues and risks in newly written or modified code; we call this a code inspection or code review. Much as a proofreader or editor will provide feedback on a book or article, code inspectors review and analyze areas of the code that may benefit from rework, such as supportability, readability, extensibility, and issues or risks of issues.
In this session, Paul Grizzaffi explains why we should do code inspections for our automation software, how these investigations for automation can differ from those for product software, and real-life issues found during these reviews.