Abstract: Teams starting to become agile often get caught by the technical issues of software development. While stories may be completed initially, technical debt such as lack of cohesion, bad coupling, missing tests, and other issues slow things down. Test automation becomes harder and brittle for both internal units and external flows. Team members are not sure which of the techniques such as Behavior Driven Development, Acceptance Test Driven Development, Test Driven Development, Domain Driven Design, Design Patterns, Object Oriented Analysis/Design, or others will help them.
This session presents a holistic approach to discovering how these D’s relate to each other and how they can help you. We start by concentrating on the desired behavior and the context in which that behavior occurs. Next we explain how tests specify that the behavior is being implemented correctly and we recognize that all tests specify some behavior. We continue by illustrating how external behaviors that a user experiences are a combination of behaviors of the implementing components. We end up by showing how behavior of those components (microservices, classes, methods) can be specified in an implementation independent manner. Along the way, we’ll show how principles, such as separation of concerns and low coupling, apply in many aspects of development including defining behavior.
This interactive session is appropriate for anyone working on the creation of a software application – developers and testers. It’s aimed at newer agile teams, but any teams who are experiencing delivery issues may benefit.
Learning Outcomes: - Explain the different contexts of an application
- Identify what are external and internal behaviors and how to specify them
- Create a shared understanding of the behavior of business rules and domain terms
- Minimize the amount of redundancy in tests and code
Attachments:
