Inspection Story

🔍 Catching Issues Early

In software development, every product follows a structured Continuous Integration and Continuous Deployment (CICD) pipeline. From initial problem definition to final deployment, code moves through multiple stages, ensuring quality and reliability.

📌 Where do most issues originate?

If we look at the CICD pipeline, three critical areas often determine a project's success or failure:

• ✅ Problem Definition:

  • Are we solving the right problem?
  • Are we missing key details that could cause misunderstandings later?

• ✅ Requirements Analysis:

  • Are the requirements clear, complete, and unambiguous?
  • Do they properly define what the system should do?

• ✅ Local Development:

  • Is the design structured properly?
  • Does the source code follow best practices and avoid early defects?

These three areas—Problem, Requirements, and Local Development—are where inspection plays a key role. By analyzing requirements, reviewing design, and inspecting source code, we can catch defects early, preventing costly errors later in the pipeline.

🛠 Why is Inspection Important?

Unlike testing, which focuses on running the software, inspection is a structured review process that helps detect issues before execution. It applies to:

🔹 Requirements Inspection: Ensure clarity and consistency.
🔹 Design Inspection: Review architecture, logic, and flow.
🔹 Code Inspection: Find syntax issues, bad practices, and logical errors.

By focusing on these areas, we reduce the risk of defects propagating through the CICD pipeline, ensuring a strong foundation for development.

---

❗ The Problem: Prehistoric Traffic Chaos!

The Stone Age people have just invented their very first stone car—a groundbreaking achievement! 🚗💨 However, there’s a problem… they are terrible drivers! 🦴💥

Before they take their rocky wheels onto the prehistoric roads, they need a way to train safely, avoid disasters, and master the art of driving. Without proper preparation, the roads will be filled with crashes, confusion, and runaway stone cars.

The Tribe Chiefs (the Clients) quickly identified this gap—they saw the chaos coming and realized it was time to evolve. To ensure a safer future, they decided to find a structured solution to train new drivers before they hit the road.

---

🪨 The Rock of Requirements

The Tribe Chiefs gathered around the legendary Rock of Requirements to write their statement. This was more than just a stone! It was the foundation of every great idea. 🏗️ Whenever the tribe had a new concept or invention, they would engrave it into the sacred rock, believing that once written, their ideas will be closer to became reality.
But things did not go as planned…

---

❌ Bad Requirements

❗ Issue #1: Confusing Requirements

The requirements:
“A cool simulation of a vehicle that can do stuff like steer, ‘go wrummm,’ and be safe.”

It was total gibberish! The requirements were:

• vague
• ambiguous
• open to interpretation
• without clear definitions

❗ Issue #2: Superficial Developers

The tribe decided to hire a group of overselling monkey developers 🐒💼. These so-called "experts" never questioned the requirements—! They just took them for granted and immediately started the next steps!

• No requirement validation before development.
• The developers never challenged unclear requirements.
• Assumptions were made without proper discussions or clarifications.

---

❌ Bad Design

After receiving the poorly written requirements, the overselling monkey developers swung into action. But there was a slight problem...

They completely misunderstood what the tribe actually wanted!

Instead of designing a car simulator for the prehistoric roads, they somehow concluded that the tribe needed a submarine simulator. 🌊🚢

• The requirements simply said:

“A cool simulation of a vehicle that can do stuff like steer, ‘go wrummm,’ and be safe.”

• The monkeys thought:

  • “Steer?” → Submarines steer! ✅
  • “Go wrummm?” → Submarines make noise! ✅
  • “Be safe?” → Submarines are built to survive underwater! ✅

• Conclusion? - They proudly designed a submarine. 🏆🐒

• No Requirement Validation

• Over-Engineering the Wrong Problem

---

❌ Bad Code

The monkey developers took their flawed design and blindly coded it.

• No validation, just assumptions.
• No testing, just "if it compiles, ship it!"
• No integration, just dumping components on a stick 🪵 and handing it off.

---

❌ Bad Product

Without inspection and testing, the clients got:

• A submarine simulator when they actually required a car simulator 🏜️🚢
• A useless, time-consuming, expensive, broken mess!
• A bad product.

---

✅ Good Requirements

Structured Dev Team

Realizing their past mistakes, the tribe hires professional Stone++ development team to fix the mess:

• Buga 🛠️ – Developer
• Bambucea 🔍 – Tester

Inspecting the Requirements

Using their Requirements Phase Defects Checklist, they carefully review the original requirement:

Original Requirement:
"We want a cool simulation of a vehicle that can do stuff like steer, ‘go wrummm,’ be safe."

📜 RequirementsPhaseDefectsChecklist.pdf: Potential issues

Code	Defect Description
D_01	Requirements are incomplete.
D_02	Requirements are missing.
D_03	Requirements are incorrect.
D_04	Initialization of the system state has not been considered.
D_05	The functions have not been defined adequately.
D_06	The user needs are inadequately stated.
D_07	Comments

📜 ReviewForm.doc: Identified Issues

Crt. No.	Checked Item	Issue	Suggestion
1	D_01 – Incomplete	"Vehicle" is vague	Specify CAR
2	D_05 – Functions not defined	"Go wrummm" unclear	Define acceleration
3	D_06 – User needs unclear	"Be safe" is ambiguous	Add seat-belt requirement

Refined Requirements

With clear, testable requirements, they discussed these points with the clients before proceeding further, and they refined the requirements together:

"A simulation of a CAR that:

• Allows steering
• Can accelerate
• Has a seat-belt

---

✅ Good Design

After fixing the requirements, the Stone++ development team moves on to design. However, they discover a major flaw—the previous team designed a submarine instead of a car! 🛑🤦

📜 DesignPhaseDefectsChecklist.pdf: Potential issues

Code	Defect Description
D_01	Is the overall architecture clear and structured?
D_02	Does the design cover all requirements?
D_03	Is error handling properly planned?
D_04	Have classic design patterns been considered?
D_05	Are class names/descriptions meaningful?
D_06	Can the architecture handle likely changes?
D_07	Comments

📜 ReviewForm.doc: Identified Issues

Crt. No.	Checked Item	Issue	Suggestion
1	D_02 – Missing coverage	Design is for a submarine, not a car	Redo design for a car
2	D_05 – Poor naming	Components named like "Periscope"	Use car-related terminology
3	D_06 – No flexibility	Hardcoded underwater mechanics	Make modular for different vehicles

Refined Design

With a clear architecture and proper structure, the team finally designs a car simulator, ensuring it follows the actual requirements.

---

✅ Good Code

With a proper design in place, the Stone++ team (Buga & Bambucea) start pair programming inside Buga’s Stone PC. They find a mess of submarine code—uncompilable, full of logic errors, and completely unusable! 🚨🐒

📜 CodingPhaseDefectsChecklist.pdf: Potential Issues

Code	Defect Description
D_01	Decision logic or sequencing is erroneous
D_02	Branching is incorrect
D_03	Undefined loop terminations
D_04	Input/output format errors
D_05	Subprogram calls are violated
D_06	Confusing use of parameters
D_07	Comments

📜 ReviewForm.doc: Identified Issues

Crt. No.	Checked Item	Issue	Suggestion
1	D_01 – Bad logic	Wheels turning like propellers	Fix movement logic for land travel
2	D_02 – Wrong branching	"If underwater, reduce speed" condition	Remove submarine logic
3	D_06 – Confusing parameters	"Depth" used instead of "Speed"	Rename variables properly

Refactored Code

The team modifies and refactors the code, removing submarine logic, fixing errors, and making it functional for a car simulator. Now, it compiles, runs properly, and meets the original requirements! 🚀

---

✅ Good Product

Unlike the monkey developers, Buga & Bambucea didn’t rush to hand over the product. They knew that more rigorous testing was crucial before release.

• 🛠 Extensive testing to ensure functionality
• 🔄 Fixing last-minute defects