Early 2022, as a result of some events, I came to realization that I should take a deep dive in agile development methodology to have a better overall understanding, be able to call right decisions and navigate discussions to a reasonable direction on a daily basis at the office.
My next move was to find a trustworthy source and I ended up reading “Bridging the Communication Gap” by Gojko Adzic.
Disclaimer: The followings are solely based on my thoughts and reflections from the book. It does not covers how an acceptance test is implemented.
Constructive feedback and further discussion of the topic is welcome! 👾
Communication inside a team (especially between different players of a team) plays a vital role in the development. Talking about software pieces, a product shipped in an intangible form makes it even more challenging when it comes to establish a common understanding about the business needs and functional requirements.
Developers might share a different perspective and naturally lay more focus on technical parts compared to a product owner or a business analyst. Moreover, the jargon and terminology they use may differ, even though they all try to communicate and exchange ideas over the same subject.
So how can we ensure that business people translate the requirements clearly to developer and developers build applications which satisfy the business’s needs?
Gojko Adzic proposes integration of agile testing in the development cycle. But what the heck is agile testing??
In a nutshell, agile testing encourages the participation of different team members (developer, product owner, business analyst, and tester) in a specification workshop. Goal is to create a shared understanding among everybody in the team and define the requirements of what needs to be developed.
Agile testing utilizes concrete real world examples to flesh out ideas and discover hidden layers in progress. Cognitive diversity is the cornerstone of these specification workshops. Otherwise, if the group consists of people from the same background whole idea generation process might swarm around in a very narrow region.
Alright, but how does it differ from unit test?
- Unit test concerns more with technical / functional aspects. For instance, if a function is working properly or how a function behaves when it encounters with an edge case.
- Acceptance test concerns more with general business logic. It provides specifications for required functionalities.
Andy Dassing describes this plainly. Unit tests “will ensure the code is built right”, and acceptance tests “insure right code is built”.
When writing acceptance tests, there might be some points where you wonder what is the best approach. One useful tip is to avoid using mock objects.
In unit testing mock objects can be very handy and eliminate dependencies, on the contrast using mock objects in an acceptance test can leave some parts uncovered.
To sum up, acceptance test lays down the foundation for a common understanding with discussions over concrete examples describing the business needs to crystalize the requirements by involving everybody in the team to this process.
Although, acceptance testing gather everybody on the same page, Gojko suggests it is neither a silver bullet nor it offers 100% guarantee for successful product development. Every organization considering to adapt this methodology should adjust this approach in respect to their current constraints and working environment, rather than following the instructions blindfoldedly.
That being said, starting with small team consisting of an avid group of people seems to yield better results than a hard switch.
Maybe it all starts with listening .. 👀
