Quality Assurance vs. Quality Control in Scrum

Quality in software development is not just a nice-to-have; it is a fundamental pillar that underpins the success and reputation of any software endeavour. From ensuring customer satisfaction and loyalty to reducing costly defects and maintenance efforts, the pursuit of quality remains a core objective for every software development team.

In pursuit of this goal, two crucial approaches come into play—Quality Assurance (QA) and Quality Control (QC). Although often used interchangeably, they represent distinct aspects in achieving the common objective of excellence in software development. In this blog post, we will explore the differences between QA and QC in the context of Scrum and shed light on how they complement each other in creating exceptional software products.

Quality Assurance (QA) in Scrum

Quality Assurance in Scrum revolves around prevention-focused activities. It aims to embed quality into the development process from the very beginning. QA starts during the early stages of product development and continues throughout the project’s lifecycle. Here are some key characteristics of QA in Scrum

  • Defining and adhering to standards: QA establishes clear and agreed-upon standards for development, testing, and documentation. These standards serve as guidelines that the team follows to ensure consistency and quality.
  • Process improvement: QA involves continuous process improvement efforts to identify inefficiencies, bottlenecks, and potential areas of improvement in the development process. Regular retrospectives play a vital role in this aspect.
  • Training and skill development: QA emphasizes skill development and training for team members to enhance their abilities and ensure they possess the necessary expertise to deliver high-quality products.
  • Early defect prevention: QA activities focus on identifying and addressing potential defects as early as possible in the development lifecycle. This helps in avoiding costly rework and increases overall productivity.

QA can be summarized as Process-Oriented, Prevention over Detection and Documentation and Training.

While the primary focus of the Scrum Master is to facilitate the Scrum process and remove impediments, they also contribute significantly to the overall quality of the software product through their involvement in process improvement and fostering a culture of continuous improvement. Here’s how the Scrum Master plays a role in quality assurance. The Scrum Master encourages the team to adopt a quality-centric mindset. They promote the understanding that quality is everyone’s responsibility and not just the concern of the Quality Assurance or Testing team. The Scrum Master emphasizes that delivering high-quality software is crucial for long-term success.

The scrum masters involvement in retrospectives, advocating for Definition of Done, and removing impediments contributes to the overall quality of the software product and the team’s ability to continuously deliver value to customers.

Quality Control (QC) in Scrum

Quality Control in Scrum, on the other hand, centres around detection-focused activities. It involves verifying that the deliverables meet the predefined standards and requirements. QC activities occur at various stages of the development process, with the primary goal of identifying and fixing defects. Here are some key aspects of QC in Scrum:

  • Testing and validation: QC encompasses various testing practices, including functional testing, integration testing, regression testing, and user acceptance testing. These tests are designed to verify that the product meets the desired functionality and quality standards.
  • Defect identification and management: QC involves actively searching for defects, tracking them, and collaborating with the development team to resolve issues promptly.
  • Review processes: Peer reviews, code reviews, and design reviews are part of QC efforts to ensure that the developed product aligns with the established quality criteria.

QC can be summarized as product-oriented, defect identification and correction as well as validation and verification.

Es wurde kein Alt-Text für dieses Bild angegeben.

Balancing QA and QC in Scrum

Both Quality Assurance and Quality Control are integral to maintaining a high standard of software quality. To achieve software excellence in a Scrum environment, it’s essential to strike the right balance between these two approaches.

QA and QC should be viewed as complementary rather than competing forces. Implementing robust QA practices reduces the likelihood of defects, thereby reducing the amount of time and effort spent on QC activities. Conversely, effective QC practices provide valuable feedback to the development team and contribute to continuous improvement efforts in QA.

Establish valuable QA and QC

Actions for Valuable Quality Assurance (QA)

  • Define Clear Quality Standards: Establish and document clear quality standards, including coding guidelines, design principles, and testing criteria. This ensures that everyone on the team understands and follows a common set of quality guidelines.
  • Implement Code Reviews: Encourage regular code reviews among team members to promote collaboration and identify potential issues early in the development process. Code reviews help catch bugs, improve code readability, and maintain consistent coding practices.
  • Conduct Regular Knowledge Sharing Sessions: Organize knowledge sharing sessions where team members can present best practices, lessons learned, and new techniques. This fosters a culture of continuous learning and ensures that the team stays updated on the latest developments in the industry.
  • Invest in Test Automation: Develop and maintain a suite of automated tests, including unit tests, integration tests, and end-to-end tests. Test automation improves test coverage, identifies regressions, and allows faster feedback on code changes.
  • Prioritize Test-Driven Development (TDD): Encourage the adoption of Test-Driven Development, where developers write tests before implementing the code. TDD helps in focusing on requirements and ensures that test cases are closely tied to the desired functionality.
  • Implement Continuous Integration and Continuous Deployment (CI/CD): Implement CI/CD pipelines to automatically build, test, and deploy code changes. This minimizes integration issues and accelerates the delivery of features to end-users.

Actions for Valuable Quality Control (QC)

  • Perform Comprehensive Testing: Conduct various testing activities such as functional testing, regression testing, performance testing, security testing, and user acceptance testing. Rigorous testing helps identify defects and ensures that the software meets user requirements.
  • Track and Manage Defects: Use a robust defect tracking system to document and manage identified issues. Prioritize defects based on their severity and impact, and ensure timely resolution.
  • Implement Exploratory Testing: Encourage exploratory testing, where testers explore the software with an open mindset to discover hidden defects and usability issues that might not be covered by scripted tests.
  • Engage in Bug Bashes or Bug Hunts: Organize bug bashes or bug hunts where the entire team collaboratively tests the software to find as many defects as possible within a specific timeframe. This can help identify critical issues and foster a sense of shared responsibility for quality.
  • Conduct Root Cause Analysis (RCA): Whenever a significant defect is discovered, perform a root cause analysis to understand the underlying reasons for the issue. Use the findings to prevent similar issues from recurring in the future.
  • Encourage User Feedback: Gather user feedback through surveys, user interviews, or usability testing. User feedback provides valuable insights into the software’s usability, functionality, and overall quality.
  • Incorporate Test Environment Management: Maintain well-configured and consistent test environments to ensure that testing accurately represents the production environment and avoids discrepancies.

In the context of Quality Control (QC) activities, the Scrum Master plays a critical role in facilitating and supporting the team’s efforts to ensure product quality. While the primary responsibility for QC lies with the Development Team, the Scrum Master helps create an environment conducive to effective QC practices and collaborates with the team to address any impediments that may hinder the quality control process.

Quality is negotiable

People in software development often say that quality is not negotiable. But this is not true.

Not negotiating is not discussing quality and you need to discuss the level of quality that is needed and how to achieve this level every day. If you do not discuss quality everybody does have its own perspective on it. The discussion needs to happen on all levels of a company. Take the sales department. Their job is to sell features, not quality. Look at customer support. They want less features to support, but more quality, as poor quality makes their live a mess. Developer themselves want quality for each new feature but face the problem to also need to provide quality for some old legacy features they do not own. This shows that company departments might have different requirements on quality. Hence quality is not only negotiable. You have to discuss and negotiate it every day.

Negotiate on company level

To have a common understanding of the level of quality you want to achieve, this quality topic needs to be addressed on a company level. The requirements to quality and the cost it has need to be transparent in every department. Sure, sales want to sell features. But if these features do not work properly, they will not sell a second feature to the same customer. The customer support wants to have features to work properly only, but no new features will make them lose work. Quality does have a cost and return of investment. This and the different needs of everybody should be communicated well to let management decide the proper company needs of quality assurance.

Es wurde kein Alt-Text für dieses Bild angegeben.

The testing pyramid often has its base at unit test level. But to work properly it needs support by a clear and well communicated quality requirement.

Negotiate on software developer team level

Developers need to know what they should deliver. If they are told “quality is not negotiable” developers need to do what ever it takes to prevent any bug. It might include refactoring old the old legacy code. This means that any new features might take an eternity to develop. If developer know what is expected, they can negotiate on how to achieve the expected level of quality within the team

In any software development team, the first step of negotiation should be the definition of done (DOD). The DOD defines what it needs for a feature to be finished. Which tasks should the team perform, and what checks need to be done. If this is not negotiated and therefore not known to anybody, the team will not be able to deliver a sustainable level of quality and each feature implemented might contain an expectation gap. A team DOD might contain something like the following:

  • all acceptance criteria are met.
  • new code is secured by an automatic test (unit test, integration test, UI test).
  • four-eye principle: Code has been reviewed and understood by at least one other developer (Code review or pair programming).
  • Code guidelines for the components (server, client, mobile…) are met.
  • No new linting or compiler warnings exist (depends on component type).

This example is part of the DOD of one of my teams and it shows the result of an intensive discussion between all members of the development team (product owner, software developer, quality experts). Having a DOD written down is needed, but the negotiation does not stop here. For each new feature product owner, software developer and quality experts need to discuss the quality or testing strategy. Which kind of automatic tested is needed? Which edge cases need to be tested? The discussion about the testing strategy does not only impact the proper quality of the product but also the speed of development for this and upcoming features. Additionally, the four eyes principle stated in the example DOD is nothing else than a negotiation about quality. At least two developers discuss for each feature if the unit tests are suitable, the coding guidelines are kept and if the overall code quality has been increased (boy-scout-rule). They might even discuss to remove an automatic test if it does not suite any meaningful test case but increase the effort of maintenance and the performance of the overall test run.

To achieve the right balance between working software and pace of development the whole company needs to be involved in the negotiation of quality. Quality is not an act. It’s a habit of negotiation.

Focusing on Quality Attributes for Superior Software Delivery

Agile software development is a methodology that emphasizes on iterative and incremental development, frequent inspection, and adaptation. It focuses on delivering working software frequently, responding to changes in requirements, and collaborating with the customer throughout the development process.

The main purpose of agile is delivering and exchange value with customers. Mostly value is associated with features. This is what customer will ask for and this is what customers will notice. Everything else such as reliability, maintainability, scalability, performance, security, and usability just needs to be build in. These aspects of software will only be notice if absent and a problem occurs. Therefore, we must make sure that the implementation of soft aspects is part of software development. However, developing software with agile methodology does not guarantee the quality of the software. Therefore, it is important to pay attention to quality attributes in agile software development. In this blog post, we will discuss how to achieve quality attributes in agile software development.

What are quality attributes?

Quality attributes are the non-functional requirements of a software system. They are the characteristics that define the quality of the software, such as reliability, maintainability, scalability, performance, security, and usability. These attributes are essential for the success of the software system, as they determine how well the software meets the needs of the users.


ISO/IEC 25000 is a standard that provides guidelines for software quality requirements and evaluation. It is also known as the Software Product Quality Requirements and Evaluation (SQuaRE) standard. The standard describes a framework for evaluating the quality of software products based on eight quality characteristics, which are:

  • Functionality: The degree to which the software satisfies specified requirements.
  • Reliability: The ability of the software to perform its required functions under stated conditions for a specified period.
  • Usability: The degree to which the software is easy to learn, understand, and use.
  • Efficiency: The degree to which the software performs its functions with appropriate speed and resource utilization.
  • Maintainability: The ability of the software to be modified or enhanced easily and effectively.
  • Portability: The ability of the software to be transferred from one environment to another.
  • Compatibility: The degree to which the software can operate with other software, hardware, and systems.
  • Security: The degree to which the software protects against unauthorized access, use, disclosure, disruption, modification, or destruction.
Es wurde kein Alt-Text für dieses Bild angegeben.

Developing software that meets the quality attributes outlined in ISO/IEC 25000 can be a challenging task, particularly when using an agile development approach. However, with careful planning, attention to detail, and a focus on quality throughout the development process, it is possible to achieve a high-quality software product that meets or exceeds the expectations of its users.

Here are some key steps to follow when developing software using an agile approach that meets the quality attributes outlined in ISO/IEC 25000:

Define and prioritize quality attributes: Before starting the development process, it’s essential to define and prioritize the quality attributes that are most important for the software product. This involves working closely with stakeholders to understand their needs and expectations, and using this information to determine which quality attributes are most critical.

Prioritising quality attributes especially involves deciding whether to develop another feature or spend time on security, reliability, etc.

Incorporate quality throughout the development process: One of the key principles of agile development is to prioritize quality throughout the development process. This means incorporating testing, code reviews, and other quality control measures into each stage of the development process, rather than treating it as an afterthought.

Use iterative development: Iterative development is a key part of the agile methodology, and it can be particularly useful when working to meet quality attributes. By breaking down the development process into smaller, manageable iterations, it becomes easier to focus on quality at each stage, identify and address issues quickly, and make improvements as needed.

Conduct frequent testing: Testing is a critical part of the development process when working to achieve high-quality software. Agile development emphasizes frequent testing, which allows for issues to be identified and addressed quickly, reducing the risk of defects, and ensuring that the software meets quality standards.

Embrace continuous integration and delivery: Continuous integration and delivery (CI/CD) is another key aspect of agile development, and it can be particularly useful when working to meet quality attributes. By automating the build, test, and deployment process, it becomes easier to identify and address issues quickly, reduce the risk of defects, and ensure that the software meets quality standards.

Monitor and measure quality: Once the software product is released, it’s essential to monitor and measure its quality to ensure that it continues to meet the standards outlined in ISO/IEC 25000. This involves collecting data on key quality metrics, analysing this data to identify areas where improvements can be made, and using this information to guide future development efforts.

In conclusion, developing software that meets the quality attributes outlined requires a concerted effort to prioritize quality throughout the development process. By working closely with stakeholders, incorporating quality control measures at each stage of the development process, and embracing the principles of agile development, it’s possible to achieve a high-quality software product that meets or exceeds the expectations of its users.