This week of reading: Chapter 7: Acceptance Testing and Chapter 8: Testing Strategies from The Clean Coder by Robert C. Martin, covered importance of acceptance testing and the role of Quality Assurance (QA) in the designing, building and delivering of a successful product.
In chapter 7, Uncle Bob explained that there is often misinterpretation and miscommunication between the stakeholders and programmers. One remedy to clear this uncertainty between stakeholders and programmers is to use acceptance testing. Acceptance tests eliminates communication errors between programmers and stakeholders. As Uncle Bob stated, “They are completely unambiguous”. Acceptance tests clears up the communication between what the stakeholders wants and what the programs should deliver. These tests can also be looked as a perfect requirements document.
In chapter 8, Uncle Bob elaborates on the different testing strategies in order to strive for an attempt that QA should find no bugs or defects in the software/product. For this Uncle Bob suggests that first, development team in an organization have to count QA team as part of their team rather than treat them as their adversaries. Development team have to work closely with QA to arrange hierarchy of unit, component, integration, system and exploratory tests. These tests should be run as often as possible which will assure clean system with maximum feedback.
So far in the semester, we been constantly discussing and defining what do we mean when we say we are done? By reading these chapters, it cleared up what does ‘done’ means for a professional developer. Uncle Bob states, “Done means all code written, all tests pass, QA, and the stakeholders have accepted.” Normally, every person or team has their own meaning and definition of done, but when it comes to the business world we have to be on top of our game. We have to be responsible for not only ourselves, but we have to make sure that the team thrives too, and is successful in completion of the project. I believe, I can apply this strategy to our own team projects at university and in professional career that my team’s success is my success. In order to do this, I should be as transparent, positive and open as I can be with my team members. We should reach the ‘done’ part together, not individually.