Agile/Scrum and Traditional Waterfall-Quality Assurance
In traditional methodologies like waterfall, QA is primarily a function of the execution phase. If you ask the entire team if they know what is expected of them the answer would be “I don’t know that’s QA’s role” or you can try to convey to the team members that they are all part of QA and that they will have to work together to develop the end product to meet the standard of quality expected by the business/stakeholder. This is not a feature of the waterfall methodology that helps QA, putting QA in a specific silo and not throughout the development cycle is a recipe for disaster and unhappy stakeholders.
In Agile/Scrum, the framework is designed to utilize the entire team in the testing of the application. When you set up teams you are assigning quality assurance team members with developers. They will bounce off each other the kinds of unit tests that will need to be run before each iteration, working as a team the developer will have some ideas for testing his piece of the application and usually QA will come up with a few more tests that might not have been thought of, working as a TEAM. Test Driven Development (TDD) will complement QA by testing each unit until all units are tested together, using the commented code, automating when you can, and creating a code repository for ease of refactoring the team will build better, cheaper and faster products to market. You won’t have to convey that the team will have to work together (each in their own silo) but they will BE working together in teams to ensure communication across the many job roles. Now the developers will understand the requirements of the application and by focusing on tests first they can truly get a feel for what the applications are supposed to accomplish for the business/stakeholders.