Chapter 7:
This chapter is mainly based around the idea that communication is key and is necessary for a developer have, not just their ability to develop. It is very difficult to keep up with what you think the business side of developing would want and what they actually want or think you are doing. With that in mind, the programmers can only make what they Think is wanted from them, and so this process is filled with errors. It also talks about how not only developers, but also business have a problem with their premature precision. Both sides, business and developer usually want to know an estimate of what people are going to get and what you are supposed to deliver to give an exact estimate of how long the process should take, but this task is nearly impossible. Also the outcomes of a product usually end up being different from how it was planned on paper simply because it doesn’t always come out how you imagine or plan it to. What helps this ambiguity sometimes is acceptance tests. Acceptance tests are tests written in a collaboration of stakeholders and programmers in order to define when the requirement is done. This all helped me realize and look back at times that ambiguity could have led to some miscommunication in the group which effected a person to think that they were done with their work, when they were not. So using acceptance tests would help by making it all much more clear than before and help define the context of the problem in precision and communicate its context clearly.
Chapter 8:
This chapter teaches about the fact that writing unit and acceptance tests is good but not enough, what you really need is to have good testing strategies. Even though the company you work at might have its own QA group, you should not use them to find your bugs, your goal should be to eliminate any bugs that could be present in your code, before it even gets into QA hands. They should be working together with you and your team to try to make sure the high quality set for the system is actually reached. Now even though your goal is to try as hard as you can that no bugs should slip through, that is plain impossible and that is the whole reason the QA group is there, to help you catch the bugs you missed. I also learned that QA work with business and make automated acceptance tests that establish the true specifications and requirements document for the system. While the business updates and gives their requirements, the QA then turn that information into tests for the developers. This also showed me that the QA group is there to use testing to see the true behavior of the running system and report it back to the developers and business, not interpret the requirements.
CS Blog by Gautam 