This first level of the QA plan serves as a preliminary X-ray of the current state of the software. It is not yet about diving into sophisticated tools or complex automation; here we roll up our sleeves and observe the system carefully, exactly as it is.

The main objective is to identify the key problems that could be compromising the quality of the product, both functionally and structurally. In other words, we are after the obvious failures, behavioral inconsistencies, nonexistent or poorly applied QA processes, and improvement opportunities that are often hidden in plain sight.

What is done in this stage?

• Review of existing artifacts: the available documentation (if it exists) —requirements, user stories, acceptance criteria, etc.— is analyzed to verify its clarity, coherence, and completeness.

• Key interviews: discussions are held with the development team, product, and any involved roles to understand how the system is currently being tested (if it is being tested).

• Manual exploration of the system: an initial exploratory testing is conducted to identify obvious bugs, bottlenecks in the user experience, or critical errors.

• Evaluation of the QA process: if a QA process already exists, its maturity, test coverage, and how errors are managed are reviewed.

What is this phase for?

The Initial Diagnosis aims to establish a realistic and honest starting point, without embellishments. What is wrong? What can be improved right now? What is missing for the software to be reliable, maintainable, and scalable?

Furthermore, this diagnosis lays the groundwork for the later levels of the QA plan, which will be more technical, automated, and in-depth. But if we don't have a clear vision from the start, any subsequent effort can end up being just makeup over structural cracks.