The V-Model, Simplified for Modern Quality Engineering

The V-model is often presented as an old lifecycle diagram, but the underlying idea remains useful: testing should be connected to the work products and decisions that shape the system.

A modern QA professional does not need to worship the model. They should understand what it teaches about early validation and traceable evidence.

The useful idea

On one side of the V, teams define business requirements, system requirements, architecture, and detailed design. On the other side, teams validate and verify the resulting software through acceptance, system, integration, and unit-level evidence.

The point is alignment. Acceptance testing should connect to business need. System testing should connect to system requirements. Integration testing should connect to architecture and interfaces. Unit testing should connect to detailed design.

How to use it today

Modern delivery is more iterative than the classic model suggests, but the mapping still helps. When a story is refined, ask what evidence will prove the business outcome. When an API is designed, ask how the contract will be tested. When architecture changes, ask how integration and failure behavior will be observed.

This is how the V-model becomes a thinking tool rather than a process constraint.

The quality lesson

Testing should not start when coding ends. Test thinking should begin when expectations are formed. That lesson is still current.

How to use this as a working habit

The practical value of this topic is in daily test design. Use it when reviewing a requirement, creating examples, selecting data, choosing boundaries, or explaining why a particular test matters.

Fundamentals are not junior concepts. Senior testers use them with more judgment: less ceremony where risk is low, more discipline where ambiguity, impact, or repeatability matter.

A useful habit is to ask what decision this concept supports. If the answer is unclear, the testing activity may need refinement. Good fundamentals should make the work sharper: clearer scope, better examples, stronger evidence, and more honest communication about what remains unknown.

Verification and Validation: Building the Product Right and the Right Product

Verification and validation are simple words that are often used loosely. The distinction matters because software can be built correctly against a specification and still fail the user.

Verification asks whether we built the product right. Validation asks whether we built the right product.

Verification

Verification compares the product, design, code, configuration, and tests against defined expectations. It includes reviews, static checks, unit tests, integration tests, system tests, and traceability against requirements.

Verification is essential because teams need evidence that the system conforms to what was agreed.

Validation

Validation looks at fitness for use. Can real users complete meaningful tasks? Does the workflow solve the problem? Are the assumptions still valid? Does performance, accessibility, and error handling support the user's context?

Validation often requires demos, exploratory testing, user feedback, acceptance testing, prototypes, analytics, or production learning.

Why QA needs both

A team that verifies without validating may deliver the wrong thing perfectly. A team that validates without verification may have a good idea implemented unreliably.

Strong quality engineering connects both forms of evidence so release decisions reflect conformance and usefulness.

How to use this as a working habit

The practical value of this topic is in daily test design. Use it when reviewing a requirement, creating examples, selecting data, choosing boundaries, or explaining why a particular test matters.

Fundamentals are not junior concepts. Senior testers use them with more judgment: less ceremony where risk is low, more discipline where ambiguity, impact, or repeatability matter.

A useful habit is to ask what decision this concept supports. If the answer is unclear, the testing activity may need refinement. Good fundamentals should make the work sharper: clearer scope, better examples, stronger evidence, and more honest communication about what remains unknown.

Project Management in an Agile World

This is from an article that i put together and was published in the September '09 issue of the Project Management Institute's magazine - available online at http://www.pmi.org.in/

Managing projects in the agile word requires the ability to balance stability with flexibility, order with chaos, planning with execution, optimization with exploration and control with speed while dealing with project unpredictability and dynamism by recognizing and constantly adapting to change.

In their whitepaper, "The New Product Development Game", Takeuchi and Nonaka, suggests that "the rules of the game in product development are changing.” Under the traditional approach, a product development process moved like a relay race, sequentially from one phase to the next: requirements, design, development and so on. Problems could occur at the points where one group passes the project to the next. A bottleneck in one phase can slow the development process.

Takeuchi and Nonaka discuss the "rugby approach" of dedicated, self-organizing teams, the members of which, like actual rugby scrum teams who work together to gain control of a ball and move it up the field, all work together to deliver product.” The new approach has characteristics such as – built-in instability, self-organizing project teams and overlapping development phases. These self-controlled & self-organizing teams require little direct project management as we know it.

Agile projects value working software, which is a profoundly different emphasis from traditional, projects. Traditionally, one would measure a project's progress by the percent complete of the functional milestones (analysis complete, documentation complete, code complete ...). In agile projects, however, working software is the ultimate quantification of project status. At the end of each short iteration, a working product is delivered and available for review.

While agile methodologies have gained popularity, the role of the project manager (PM) in many groups remains unclear. Traditionally, the project manager is typically “the outsider” who controls the teams progress and makes assignments. In the agile world, PMs are expected to - be part of the team and function from within the team's boundary itself while acting as a facilitator who collaborates with the team.

Being more specific, in the case of Scrum (a popular agile methodology which we follow in our group), it would be safe to state that the responsibilities of a traditional project manager have been distributed among the Scrum Master, the product owner and the team. In Scrum, the project team meets at a sprint planning meeting where the team itself plans and schedules its own work using a sprint backlog. The sprint backlog is a list of tasks to be tackled during the duration of a sprint (~4 weeks). The project manager generally plays the role of the scrum master who facilitates daily meetings of the team, understands any impediments and works to remove them. Skills needed for the role include – influencing, negotiation and facilitation, which are needed when dealing with the team that comprises representatives from various functional areas and in working across organizational hierarchies and divisions to resolve any impediments that the team is facing. The role of the scrum master can be viewed as a servant-leader who works to help the team become productive. The team decides what tasks to take up and estimates the time needed to complete the same. Team members derive metrics based on their daily activities and reports the same. Some of the responsibilities of the project manager in the agile world include the following.

Remove impediments: These could be administrative, requirements or technology challenges. Impediments are reported during the daily meetings by the team members. The project manager (acting as the scrum master) takes note of the issues, tries to remove them and reports back on status.

Facilitate sprint planning meetings: Before starting a sprint (iteration), the PM facilitates the planning meeting to get the team to decide & commit to tasks they will perform. Any dependencies between requirements could also be considered and a plan for the sprint is prepared.

Facilitate sprint retrospective meetings: Unlike the “lessons learnt” meetings that used to happen at the end of a project, retrospectives happen after each iteration and is facilitated by the project manager.

Facilitate, track and monitor estimation: The agile team makes the estimates while the project manager captures and tracks the estimates. The project manager's job focus is on leading the project rather than micro-manage the team's activities.

Handle reporting: The team generates most of the data in the course of their normal work. The project manager can take this input and present it in a way thats appropriate for different entities interested in this information.

Facilitating daily meetings: Running the daily meeting as per the rules and timelines, keeping the team focussed, facilitating status reporting by all members, capturing action items are part of the PM's profile.

The project manager in the agile world is called to lead. The PM has to keep the team on track, help resolve issues, have good inter-personal skills to handle any people issues within the team, communicate & negotiate with stakeholders and report on project status. The project manager represents the team to the world outside and is responsible for protecting the team from external influence and distractions.