diff --git a/docs/quality-maturity-model/key-components/06-development-effectiveness/_3.md b/docs/quality-maturity-model/key-components/06-development-effectiveness/_3.md index 8b2d4ee..037f991 100644 --- a/docs/quality-maturity-model/key-components/06-development-effectiveness/_3.md +++ b/docs/quality-maturity-model/key-components/06-development-effectiveness/_3.md @@ -1,9 +1,9 @@ ### Description -- Software development practices are well-defined and documented, aligned at the Tribe level, in a consistent format (the [Quality Strategy](./../../../quality-strategy/01-getting-started.md)), and are consistently followed by all squads. +- Software development practices are well-defined and documented, aligned at the Tribe level, in a consistent format (the [Quality Strategy](/docs/quality-strategy/understanding-quality-strategy)), and are consistently followed by all squads. - **Continuous Integration (CI)** is set up to ensure code quality isn't compromised with new changes. - The **new code** is backed by Unit and Integration tests, which are consistently updated and maintained. -- A [shift-left](../../../quality-strategy/04-how-it-works.md#shift-left) approach is regularly employed, leading to early defect identification and remediation. +- A [shift-left](../../../quality-strategy/05-how-it-works.md#shift-left) approach is regularly employed, leading to early defect identification and remediation. - **Test Coverage** is measured and optimized per test level (unit, integration, system). - Every time a change is made, an **automated build** and test process (unit, property, integration, system) is executed. Failures are investigated and fixed proactively. - Builds are not left broken. diff --git a/docs/quality-maturity-model/key-components/06-development-effectiveness/_4.md b/docs/quality-maturity-model/key-components/06-development-effectiveness/_4.md index fd8a0c9..c7fd80e 100644 --- a/docs/quality-maturity-model/key-components/06-development-effectiveness/_4.md +++ b/docs/quality-maturity-model/key-components/06-development-effectiveness/_4.md @@ -1,7 +1,7 @@ ### Description - **Quality (Assurance = QA) is not just seen as a phase but as an integrated part of the development process.** -- Developers actively own the quality assurance process. [shift-left](../../../quality-strategy/04-how-it-works.md#shift-left) becomes a common practice. +- Developers actively own the quality assurance process. Shift-left becomes a common practice. - Automated tests cover both new and existing code comprehensively. - **Build** metrics gathered, made visible, and acted on. - Core **metrics\*\*** are consistently monitored and tracked throughout the entire SDLC. diff --git a/docs/quality-maturity-model/key-components/07-quality-control-effectiveness/_1.md b/docs/quality-maturity-model/key-components/07-quality-control-effectiveness/_1.md index 72f820e..9c4bc5c 100644 --- a/docs/quality-maturity-model/key-components/07-quality-control-effectiveness/_1.md +++ b/docs/quality-maturity-model/key-components/07-quality-control-effectiveness/_1.md @@ -1,6 +1,6 @@ ### Description -- Test engineers have minimal awareness and alignment with the tribe's Quality and Test [Strategy](../../../quality-strategy/01-getting-started.md). +- Test engineers have minimal awareness and alignment with the tribe's [Quality and Test Strategy](../../../quality-strategy/resources/02-quality-strategy-template.md). - The teams have minimal engagement with the system level **automation framework**, primarily using it as provided without active maintenance. - Ad-hoc system-level testing is performed, often manually, without a structured strategy or prioritization. - There is no, or limited, **visibility** on testing assumptions, limitations, risks, and results. diff --git a/docs/quality-strategy/01-getting-started.md b/docs/quality-strategy/01-getting-started.md deleted file mode 100644 index 831ed55..0000000 --- a/docs/quality-strategy/01-getting-started.md +++ /dev/null @@ -1,31 +0,0 @@ -# Getting started - -## Audience - -:::info - -Software quality must be visible to promote a quality mindset that improves everyone's individual choices, ultimately minimizing complexity, risk, waste, and suffering. - -::: - -The main audience for this document is anybody involved in the software development life cycle (SDLC) in any capacity, including project, product, delivery, engineering, management, and stakeholder roles. - -Readers are not expected to be experts in software development in order to understand it, but such expertise is required to implement its recommended practices and guidelines. - -**Note**: you're encouraged to provide feedback on the quality strategy tool at any time, especially as you implement it within your own team/project. Having input from a variety of teams will be particularly helpful to refine and revise the strategy. - -## Introduction - -:::info - -The **quality strategy** is a holistic plan outlining the project’s approach to build in and validate quality throughout the software development life cycle (SDLC). The strategy involves both a forward and backward-looking perspective, allowing projects and organizations to aim for optimal outcomes while also ensuring that all necessary checks are in place before releasing the new functionalities. - -::: - -**The Quality Strategy is about envisioning success and paving the way to achieve it.** - -Strategy illustration - -The quality strategy tool is designed to foster a structured and proactive approach to quality in software development projects. It ensures that every phase of the product's development adheres to high-quality standards, leaving no detail unconsidered, thereby improving both the efficiency and outcomes of all projects. - -The benefit of applying a quality strategy is that a team (or group of collaborating teams) creates easy and clear guidance for everybody involved, about which activities to apply to achieve built-in quality in fit-for-purpose systems. diff --git a/docs/quality-strategy/01-intro-quality-strategy.md b/docs/quality-strategy/01-intro-quality-strategy.md new file mode 100644 index 0000000..38bbbed --- /dev/null +++ b/docs/quality-strategy/01-intro-quality-strategy.md @@ -0,0 +1,50 @@ +--- +title: Understanding Quality Strategy +metaTitle: Understanding Quality Strategy +slug: /quality-strategy/understanding-quality-strategy +--- + +Imagine you're setting off on a road trip. You wouldn't just hop in the car and start driving, would you? You'd probably +plan your route, pack your bags, and make sure your car is in good shape. + +Building software is a lot like that road trip. A Quality Strategy is your roadmap, your preparation, and your vehicle +maintenance all rolled into one. It helps you navigate the journey, ensuring you reach your destination – a fantastic product that people love. + +But before you even start packing, you need to know where you're headed: **where are you going?** Every software journey +begins with a clear understanding of the destination. This could be a meticulously detailed formal specification, perhaps +born from rigorous academic research like Cardano, or driven by specific business needs and market demands. This vision +is the North Star of your journey, the "**why**" that fuels your software's creation. + +Now, with your destination in mind, here's how a Quality Strategy paves the way for a successful journey: + +1. **Know your destination:** Before you start, you need to know where you're going. What kind of software are you building? What problem does it solve? Who is it for? + +2. **Assemble your crew and gear:** Just like a road trip needs a skilled driver and reliable navigator, your software project needs a talented team with clearly defined roles. Gather your crew, ensure everyone understands their responsibilities, and equip them with the right tools and knowledge. Think of this as packing a well-organized suitcase with everything you need for a successful adventure. + +3. **Fine-tune your vehicle:** A well-maintained car is crucial for a smooth ride. Similarly, your development process needs to be in top shape. This means: + + * **Sturdy chassis:** A car needs a strong chassis to withstand the bumps and turns of the road. Similarly, your software needs a solid architecture and design to ensure stability, scalability, and maintainability. This involves making thoughtful decisions about how different components interact, how data flows through the system, and how the software will adapt to future needs. + + * **Powerful engine:** Think of your codebase as a powerful engine that drives your software. To ensure it runs smoothly and efficiently, establish clear coding standards and a well-defined development process. This acts as a detailed manual for everyone, both newcomers and seasoned veterans, ensuring consistency, maintainability, and easy onboarding for new team members. It's like having a finely-tuned engine that purrs like a kitten and can handle any terrain, with everyone knowing exactly how to operate it. + + * **Responsive brakes:** Think of your brakes as a combination of preventative maintenance and quick reflexes. Implement efficient testing practices, with a strong emphasis on preventing bugs in the first place. This includes things like code reviews, static code analysis, and automated tests at every stage of development. And just like a car with excellent brakes can stop on a dime, Continuous Integration (CI) allows you to quickly identify and address any issues that do arise, keeping your development journey on track. + + * **Secure doors and windows:** Protecting your passengers and valuables is paramount on a road trip. Likewise, security should be a top priority in your software development process. This means implementing measures to protect sensitive data, prevent unauthorized access, and defend against potential threats. + + * **Aerodynamic design:** A streamlined car cuts through the air with ease, maximizing fuel efficiency and speed. Similarly, your software needs to be performant, responding quickly to user requests and using resources efficiently. This involves optimizing code, minimizing bottlenecks, and ensuring your software can handle the demands of its users. + + * **Accurate GPS:** Use a reliable tracking system to monitor your progress, identify potential roadblocks, and keep everyone informed. This is your GPS for the software development journey, ensuring you never lose sight of your destination. + +4. **Enjoy the ride:** Building software should be fun! But it's also important to stay focused on your destination and make sure you're on the right track. Regularly check your map (the product specifications) and adjust your course if needed. Don't get distracted by scenic detours that don't contribute to your final goal. + +5. **Arrive in style:** Don't just roll into your destination with a dusty, beat-up car!Deliver your software with a grand entrance! Make sure it's well-documented, user-friendly, and meets the needs of your users. Think of it as arriving at your destination in a polished, gleaming car that turns heads and makes a lasting impression. + +6. **Reflect and learn:** The journey doesn't end when you reach your destination. Gather feedback from your passengers (users), reflect on what went well and what could be improved, and use that knowledge to make your next software adventure even better. Every road trip teaches you something new! + + +To help you chart your course, we offer a **[Quality Strategy Template](https://input-output-hk.github.io/quality-engineering/docs/quality-strategy/resources/quality-strategy-template/)**. +It's a blank canvas, a starting point for you to fill in with your own specific goals, processes, and quality checks. It's your unique story to tell, your personalized roadmap to success. + +So, before you start your next software adventure, ask yourself: **What's my Quality Strategy? Where am I going, and how will I get there? How will we build quality software efficiently and effectively?** + +![What is your quality strategy?](/img/quality-strategy/what-is-your-quality-strategy.png) diff --git a/docs/quality-strategy/02-overview.md b/docs/quality-strategy/02-overview.md index 11be0b7..643bddb 100644 --- a/docs/quality-strategy/02-overview.md +++ b/docs/quality-strategy/02-overview.md @@ -1,50 +1,24 @@ -# Overview +--- +title: Overview +metaTitle: Overview +--- -:::info - -The quality strategy presents a **path to building better software**, streamlining decision-making, optimizing resource use, fostering better teamwork, and ultimately **delivering more value** to users. It brings a common language, visibility, clarity, and efficiency to IO’s software development process. - -::: - -The quality strategy proactively combines quality assurance and strategic thinking throughout the entire SDLC, ensuring that challenges are anticipated and overcome, leading to products that consistently meet business needs and user expectations. - -Emphasizing continuous improvement and adaptability, the strategy ensures the delivery of robust, **value-driven software outcomes** while maintaining a clear, efficient path toward the end goal, thereby enhancing customer value and organizational efficacy. - -The benefit of applying a quality strategy is that a team (or group of collaborating teams) creates easy and clear guidance for everybody involved, about which activities to apply to achieve built-in quality in fit-for-purpose systems. - -This guidance will have different focuses. Some quality measures are linked to individual user stories, while other quality measures apply to features or epics and the quality engineering strategy will also contain generic quality measures that the team always applies. - -Apart from the choice of quality measures, the stage in which a quality measure is applied also matters, especially when multiple teams are involved. In that case, the quality measures are also linked to the relevant fundamental development activity (for preventive and corrective quality measures) and to test varieties (for static and dynamic quality measures). - -The quality strategy serves as a **multifaceted tool** for the entire organization, enhancing product quality and refining the software development processes. It can be utilized for guidance, fostering transparency and trust, and educational purposes: - -- **Guidance**: its primary focus is to support teams and projects in incorporating quality-oriented practices throughout the entire software development life cycle. It offers clear directions, (best) practices, and recommendations to ensure built-in quality, enabling teams to make informed decisions and effectively navigate the development process. - -- **Transparency/Trust**: by emphasizing alignment and transparency within the organization, the tool fosters an environment of trust. It enables teams to share information, collaborate effectively, and build trust among team members and stakeholders. This transparency fosters better communication, decision-making, and problem-solving, ultimately leading to reliable software and customer satisfaction. - -- **Educational**: It promotes a better understanding of the software development process. It equips and aligns individuals, and the entire organization with the knowledge and skills necessary to implement quality-driven approaches, fostering continuous learning and improvement within the organization. - -Each project has complete **autonomy** to establish their unique approach and methodology to achieve this objective. - -The quality strategy does not prescribe how to implement each practice. The **focus is on the outcomes of the practices** rather than on the tools, techniques, and mechanisms to do so. This means that the quality strategy can be used by any team or project, regardless of size or sophistication. It can also be used for any type of software development, regardless of technology, platform, programming language, or operating environment. +## Introduction :::info -Quality is more an act of prevention than it is detection. **Quality is a development issue, not a testing issue**. +The quality strategy presents **a path to building better software**, streamlining decision-making, optimizing resource use, fostering better teamwork, and ultimately **delivering more value to users**. +It brings a common language, visibility, clarity, and efficiency to IO’s software development process. ::: -Not all practices are applicable to all use cases; teams and projects should adopt a **risk-based approach** to determine what practices are relevant, appropriate, and effective to mitigate the threats to their software development practices. - -**It’s essential to take time on a regular basis, not only to design the quality strategy but also to review it**. Analyze what the current context is, see the progress it’s making, where the team stands, and where it can aspire to go. Then you may plan to achieve the goal. - -Most aspects of quality should be addressed multiple times within an SDLC, but in general, the earlier in the SDLC that quality is planned and addressed, the less effort and cost are ultimately required to achieve the same level of quality. This principle, known as shifting left, is critically important regardless of the SDLC model. Shifting left minimizes any technical debt that would require remediating early quality flaws late in development or after the software is in production. Shifting left also results in software with stronger quality, security, and resiliency. +**The Quality Strategy is about envisioning success and paving the way to achieve it.** -:::tip +Strategy illustration -Testing can never be said to be "complete", and a core skill in testing is the justified management of conflicting demands; **without a strategy, these judgments will be inconsistent to the point of failure**. +The quality strategy tool is designed to foster a structured and proactive approach to quality in software development projects. It ensures that every phase of the product's development adheres to high-quality standards, leaving no detail unconsidered, thereby improving both the efficiency and outcomes of all projects. -::: +The benefit of applying a quality strategy is that a team (or group of collaborating teams) creates easy and clear guidance for everybody involved, about which activities to apply to achieve built-in quality in fit-for-purpose systems. ## Objectives diff --git a/docs/quality-strategy/03-background.md b/docs/quality-strategy/03-background.md deleted file mode 100644 index bffe911..0000000 --- a/docs/quality-strategy/03-background.md +++ /dev/null @@ -1,61 +0,0 @@ -# Background - -## The cost of poor software quality - -Poor software quality drains resources and erodes trust. - -### Direct costs - -- Rework & bug fixes -- Testing & verification -- Support & maintenance -- Wasted resources - -### Indirect costs - -- Lost revenue -- Reputation/brand damage -- Legal liabilities -- Opportunity costs - -### Long-term impact - -- Increased maintenance costs -- Reduced software lifespan -- Reduced competitive edge - -The true cost of poor software is not just in dollars, but in **lost trust and opportunities**. - -Cost of poor software - -## The complexity of software engineering - -### Mastering complexity with collaboration & strategy - -Software engineering is a complex dance of art and science. It's not just about code. It thrives on unique skills, expertise, backgrounds, and **collaboration**, guided by a clear **strategy**. In combination, it **minimizes risks and shapes success**, turning expertise into successful solutions. - -### Beyond code: delivering value - -In this field, **success** is about delivering **real value** to users and creating **sustainable income streams**. - -IO's here to create impactful products that resonate with users' needs, delivering solutions that enhance lives and drive the business forward. - -Targets illustration - -## Strategy & quality - -Strategy in software development refers to a high-level plan targeting long-term goals, aligning with the organization's vision, and balancing technical and business aspects to efficiently create valuable software that meets user needs. - -Quality in software products is a comprehensive measure of how well the software aligns with the intended design, satisfies user needs, and remains resilient against various challenges or changes. It's not just about being bug-free; it's about delivering value, ensuring safety, and providing a positive user experience. - -![What is your quality strategy?](/img/quality-strategy/what-is-your-quality-strategy.png) - -## Quality: the foundation of IO's work - -Every line of code, every process, every release, has quality at its core. - -- Quality: the core value driving our success -- Guiding every SDLC phase -- Evidence-based (data-driven) approach -- Quality as standard practice, ingrained in every task -- Commitment to delivering value-focused, user-centric products diff --git a/docs/quality-strategy/04-how-it-works.md b/docs/quality-strategy/05-how-it-works.md similarity index 86% rename from docs/quality-strategy/04-how-it-works.md rename to docs/quality-strategy/05-how-it-works.md index f76e1a8..b7e8a16 100644 --- a/docs/quality-strategy/04-how-it-works.md +++ b/docs/quality-strategy/05-how-it-works.md @@ -1,8 +1,9 @@ -# How it works +--- +title: How it works +metaTitle: How it works +--- -## Getting started - -This section provides instructions on how to develop and use quality strategies effectively, ensuring that your project teams are aligned and equipped to deliver high-quality products. +This section provides guidance on how to develop and use quality strategies effectively, ensuring that the project teams are aligned and equipped to deliver high-quality products. The quality strategy tool is designed to foster a structured and proactive approach to quality in software development projects. It ensures that every phase of your product development adheres to high-quality standards, leaving _no detail unconsidered_, thereby improving both the efficiency and outcomes of your projects @@ -10,7 +11,7 @@ The quality strategy tool is designed to foster a structured and proactive appro #### 1. Familiarize yourself with the Quality Strategy tool -Explore the Quality Strategy Overview and Templates, as understanding these resources will help you grasp the goals, principles, and essential components of this approach. This foundational knowledge is crucial for effectively implementing the strategy throughout the SDLC and maximizing its impact on final products. +Explore the Quality Strategy info and templates, as understanding these resources will help you grasp the goals, principles, and essential components of this approach. This foundational knowledge is crucial for effectively implementing the strategy throughout the SDLC and maximizing its impact on final products. #### 2. Develop a product-level quality strategy @@ -18,7 +19,7 @@ Once familiarized with the general approach, develop a specific **quality strate The purpose here is to capture and consolidate all the existing actions and processes your team or organization has in place to plan, assure (create & validate), and control (verify) the quality of the software products. -- **Use the template**: use the Quality Strategy Template provided as a framework to structure your product’s quality strategy. This template will help ensure that all relevant actions, practices, approaches, tools, and responsibilities are considered and clearly defined. +- **Use the template**: use the [Quality Strategy Template](https://input-output-hk.github.io/quality-engineering/docs/quality-strategy/resources/quality-strategy-template/) provided as a framework to structure your product’s quality strategy. This template will help ensure that all relevant actions, practices, approaches, tools, and responsibilities are considered and clearly defined. - **Timely development**: aim to create the quality strategies during the planning phase, ideally before the start of the architecture or implementation phases. This collaborative approach promotes a unified vision and facilitates consistent implementation of the quality strategy across different areas of the project. - **Review and understanding**: Ensure the quality strategy at the product level is well-understood and reviewed by all team members. This collaborative approach promotes a unified vision and facilitates consistent implementation of the quality strategy across different segments of the project. - **Collaboration and insights**: collaborate with other teams and projects to leverage knowledge and experience. Share insights and best practices to further improve your quality strategies. diff --git a/docs/quality-strategy/resources/01-faqs.md b/docs/quality-strategy/resources/01-faqs.md index dd88484..0b6370e 100644 --- a/docs/quality-strategy/resources/01-faqs.md +++ b/docs/quality-strategy/resources/01-faqs.md @@ -10,15 +10,15 @@ The following conversation is: ![Example conversation](/img/quality-strategy/conversation.png) -### How do you prevent it? +**How do you prevent it?** You write down - before you start - what “finishing Thing A” actually is, and you don’t start building Thing A until there’s agreement on that from the relevant parties. -### So what is a ‘Quality Strategy/DoD’? +**So what is a ‘Quality Strategy/DoD’?** It’s the minimum you need to write down up front to achieve the goal of never having this Terrible Conversation again. -### So a ‘Quality Strategy/DoD’ is only a term for a really skeleton type of document, then? +**So a ‘Quality Strategy/DoD’ is only a term for a skeleton type of document, then?** Let’s not be too dogmatic about it. If you start adding detailed Acceptance Criteria to your doc, it’s still a ‘Quality Strategy/DoD’, as long as it can prevent this Terrible Conversation. @@ -28,10 +28,10 @@ Let’s not be too dogmatic about it. If you start adding detailed Acceptance Cr Writing enables better structuring of thoughts. Writing doesn’t just clarify your existing ideas; it generates more of them. -A quality strategy enhances transparency, clarity, and confidence regarding the project's strategy, approaches, current status, and potential risks. It also provides a comprehensive view of the product or feature vision, a clear definition of success, and the metrics used to evaluate success. - ::: +A quality strategy enhances transparency, clarity, and confidence regarding the project's strategy, approaches, current status, and potential risks. It also provides a comprehensive view of the product or feature vision, a clear definition of success, and the metrics used to evaluate success. + A quality strategy is essential for several reasons: - **Visioning and achieving success**: a quality strategy is crucial for defining a clear vision of success and detailing the steps to achieve it. diff --git a/src/pages/index.tsx b/src/pages/index.tsx index c42d036..c88608a 100644 --- a/src/pages/index.tsx +++ b/src/pages/index.tsx @@ -17,7 +17,7 @@ const features = [ description: 'A comprehensive tool that guides our projects through the process of envisioning and achieving success.', image: './img/qs-icon.png', - href: '/docs/quality-strategy/getting-started', + href: 'docs/quality-strategy/understanding-quality-strategy', }, { title: 'Knowledge Hub',