Bridging the Communication Gap: Specification by Example and Agile Acceptance Testingを読んだ
Listed below are essense of the book:
- Basically It's unrealistic to understand all details of specification instantly
- According to researches on US army, only 34% of commands are completely executed. Other commands are missed or misunderstood. Same things frequently happens on software development project. But if we understand the background of the commands, then the percentage should be raised.
- Creating black-box test cases on requirement phase is one of the best practices to avoid communication gaps between stakeholders. This is because requirements and black-box test have similer idea: how the system should work.
- As formality increases, tests and requirements become indistinguishable. At the limit, tests and requirements are equivalent
- Concrete realistic examples give us much better way to explain how things really work than requirements. Test scripts that are produced to verify the system are also examples of how system behaves. Examples, requirements and tests are essentially tied up together in a loop.
- A key lesson to take this and apply in software development is that understanding business reasons behind technical requests is crucial for buildng shared understanding of the domain. Original intent is one of the most important things that a customer or business analyst should pass on to the developers and testers.
- Understanding why something is required, instead of just blindly following instructions, is definitely one of the key factors for improving the chances of success in a software project. This is why it is crucial to communicate the reasons behind technical requests and business decisions. Don't be afraid of ask 'why' if you do not understand a requirement or if you find it strange
- idea of agile acceptance testing:
- Use real-world examples to build a shared understanding of the domain
- Select a set of these examples to be a specification and an acceptance test suite
- Automate the verification of acceptance tests
- Focus the software development effort on the acceptance tests
- Use the set of acceptance tests to facilitate the discussion about future change requests, effectively going back to step 1 for a new cycle of development
- Agile acceptance testing is derived from Test-Driven Development, not from User Acceptance Testing.
- Because all the stakeholders have different points of view, it is good to have discussion on business problems together. This helps us to find new opportunities.
- Just writing realistic examples as specification is not enough, because each stakeholders have different point of view and then communication gap will happen. This is why specification workshop is required.
- Process of creating examples is more important than examples itselves, because lots of discussions happen during the process, and then stakeholders reach common understanding on the speicifcation
- Use ubiquitous language. One major reason why communication gaps happen is that because business-side and tech-side use their own jargons
- Specification workshop can be used not only making common understanding but also finding out potential issues
- Software Developers usually have to implement 500+ pages of specification into source code. It means that if the specification include cunclear expreccion, then something important should be overlooked. That's why concrete example is required
- Agile acceptance testing can also be used as a metrics of software development progress. The more acceptance tests become green, the more the software provides values to cusotomers
- We should take care that acceptance test is are NOT dead or set in stone. They can be changed/updated as the time goes by
