First up on Day 1 was Bret Pettichord's keynote address. He spoke about Agile Testing. The question being answered was how agile methods redefine the role of QA for a project.
Traditional QA has mostly been about testing (finding bugs) and, in some companies, enforcing processes and methodologies. Agile methodologies however, view the role of QA as one of customer satisfaction. In order to fulfil this goal, the software is constantly exposed to a number of "reality checks". These checks are writing unit tests before coding, continuous integration, short release cycles to get customer feedback and continuous acceptance testing. These checks happen often during the course of the project.
The difference between agile QA is that in agile QA is a continuous process from start to end, whereas in traditional models QA is often seen as a phase at the end of the project (because of the framing of QA as testing/ process enforcing). Agile methods also say that everyone is involved in QA from developer to project manager to testing teams, while traditional models have a seperate QA team responsible for ensuring quality (does this mean that developers or managers are not responsible for ensuring quality? Is it okay if developers write sloppy code or managers rush through a project?).
To summarize, in agile teams, QA is everyones responsibility and continuous reality checks are done throughout the lifecycle to ensure that the customers are getting what they actually want.
No comments:
Post a Comment