Courses from iDIA Computing
This day is for the entire team--product specifiers, programmers, testers. It introduces everyone to the basics of BDD. It highlights the need for discussion of system requirements from a variety of viewpoints (e.g., the Three Amigos), and offers some techniques to facilitate the discussions. From these discussions, we will identify the essential examples required to feel confident that the system is meeting functional requirements.
This one-day workshop will teach you expert-level techniques for discovering the essential elements of the system you are building and for expressing those elements in a manner that supports both maintainable test automation and durable documentation.
This is an active, participatory workshop, not a PowerPoint lecture. Be prepared to walk away with enough experience to change the way you work.
Each attendee will get a workbook containing both exercises to be done in class, and reference material to take home. Lunch will be provided. Let us know of any dietary restrictions when signing up for the course.
Of all the Agile engineering practices, Test Driven Development (TDD) seems to be the one that draws the most interest, but also the most misconceptions. Having unit tests is not a reliable indicator that TDD is being followed. Nor is a suite of unit tests the primary goal of TDD (though it's a great secondary goal).
TDD done right gives you code that doesn't paint your developers into a corner. You get reliable, modular code that does what the developer thinks it does, and can be easily extended and modified for new requirements in the future.
Your CFO will appreciate that TDD done right costs less than adding unit tests after writing the code. Instead of adding onto the development cycle, TDD done right piggy-backs on the time that developers already spend thinking about how to write the code. It just asks them to think in a little bit different way than they're accustomed.
Agile Estimation & Delivery (2 days)
Once upon a time, we wrote what we wanted in excruciating detail and called it a requirements document. We handed that document to a software development team for implementation, and then we waited. And waited. And when we finally got the software back, sometimes we recognized in it some of what we requested, and sometimes we still wanted what we had requested. And we asked for changes, repeating the process.
In this course we'll explore the ways to gain more control over the finished product using less painstaking work.
A course just for you
We can also design a course tailor-made for the needs of your organization.
Email contact me via phone or other methods.)to for details on scheduling a course at your company, or in a location of your choosing. (Or