Agile Testing: A Practical Guide for Testers and Agile Teams
As common as Agile project management is now in the software industry, the problems implementing it are just as common. For startups, this is not as much of a problem because the software was build with rapid, continuous deployments in mind and the teams are hired to be part of a pod structure from day one. For established companies with a wide range of legacy and new software to maintain and long term employees use to a traditional project development life cycle, the transition can be tremendous and fraught with obstacles.
Below are some of my highlights from the book
- Real life observations and commentary provided throughout this book highlight the practical nature of this book and illustrate the kind of issues that you can expect along this journey to Agile.
- Agile Testing Quadrants help to reinforce the test case tractability that is often overlooked in the rush to test like an Agile tester in a 2 week sprint. The complexities of testing cannot be overlooked or downplayed if you truly want to build a robust system. Sometimes in Agile projects, there can be a “good enough” or “good for now” mentality but this can often be hugely inefficient if you later have to go back and fix large sections of the product. Why not build it the best that it can be the first time? Using test quadrants helps to reinforce standards as to what is good enough by ensuring that you “kick the tires” of the product from all angles
- Independent QA Team was especially refreshing to see. In the spirit of team work, many agile teams can inadvertently water down the importance of testing skills by having other team members testing. While there is nothing wrong with supporting testing, it is critical to have testing expertise in the pod.