streamlined the Quality Strategy content

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.

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.

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.

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)

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
+<img className="default-sized-image" src={require("@site/static/img/quality-strategy/illustration-strategy.png").default} alt="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