Quality is a result of good processes. To ensure quality, you must budget time for quality discussions and quality testing. During envisioning and requirements gathering, you must identify essential qualities and put them on the roadmap. The focus of agile and lean should not be to just go faster, but also to experiment, learn, and get rid of waste. You must engineer for quality by architecting for quality and then testing for it. You also must determine when quality can be tested and delivered.
Target Audience: Architects, Developers, QA, Managers
Prerequisites: Understanding of Testing, QA, and quality attributes is helpful
For quality, much depends on whose eyes you're looking through. The developer has a different and sometimes competing perspective with the user, as do the engineer and the artist. So, who are your system's stakeholders? They are not just users, but also executives, sponsors, developers, database administrators, business process experts, and corporate compliance. The traditional system development lifecycle includes phases from initiation to disposition.
Where does system quality fit in? The requirements analysis and integration-and-test phases were typically when a team considered quality. Testing for functionality and testing for quality measure different aspects of a system, and often testing and QA occur right before launch, positioning QA as a QC gatekeeper. That's better than not doing anything, but it's not the most effective use of QA. Agile approaches carry certain design values. Among them are design simplicity, communication, continuous improvement, teamwork, trust, satisfying stakeholder needs, and building quality software. Myths about agile approaches include the following: System qualities can easily be added into the evolutionary architecture and design; we can easily adapt to new requirements; we can change the system fast; and we don't need to worry about performance, scalability, security, or usability until the functionality is working.