Does the Agile Manifesto, ‘Implementation over Documentation’, refers to No Documentation? No, not at all!
However, in the competitive environment where speed is crucial, a number of teams have abandoned the test plans altogether. The plans have acquired a bad reputation of being time-killers. They are definitely hard to maintain, and nobody seems to read them at all once the project is signed-off, and even during the project, they seem to become obsolete half-way through.
Yet another challenge is these documents are rarely reviewed and are mostly copies of the previously created plans with no new insights or critical thinking involved.
But having said that, it is still difficult to answer that in the absence of a clear outline to follow, isn’t the project going to run into trouble?
This indicates that we definitely need to go retro but using a different approach, which is more in sync with the era of Agile, Scrum and Lean. A heavy thesis may have been outdated, but test plans have definitely not. Test plans with some amount of documentation are still required.
But let’s first understand what a test plan entails?
Test plans, as such, begin with a brainstorming session that is needed before execution. Behind the document goes a thought process that identifies and defines the scope, approach, resources and schedule of the intended test activities.
This exercise determines the type of tests that will be needed during the course of development by dividing the tasks according to the needs, goals, and test types, and accordingly clarifies how much automation and manual testing is going to be required.
But coming back to the current scenario, we need to do this in the light of the collaborative spirit of agile where things are more likely to be discussed and agreed upon at a daily standup meeting, ensuring that everyone is on the same page and things move quickly.
In such a scenario, the test plans must be skimmed for agility but are still needed to prevent the teams from getting too focused on low-level user stories ignoring the bigger picture. A test plan will assist the teams to lose the myopic view in order to get a real larger picture.
Also, communicating, collaborating and getting agreements on special test types that are particularly included or excluded should be documented for transparency and speed. We may keep this part lightweight, but cannot dismiss it altogether, for a sense of direction is required.
Besides, as agility has moved the process from few teams to multiple teams on one release, gaps are bound to happen along with communication breakdowns and integration issues, making it even more significant to have a test plan with project specifications to refer to.
Hence, the main tenet here is to keep the conversation moving around the test planning process and the right sequence of things in order to provide a clear path, and a basic test plan does just that.
In addition, the test plans are still in demand for compliance with the regulatory agencies or for internal groups during an audit, or for the contractual formalities requiring plans to be presented to the client.
In a nutshell, test plans cannot be done away with, however, they have to be factual, precise and short to be in sync with the agile environment, and should at least contain the agreed-upon team plans that are not bound to change very frequently along with the special test inclusions.
Moreover, if teams are not referring to this document time and again, or this document is not created at all, testing teams may end up with issues post release and may have no proper literature to refer back to. Hence, test plans are a living document rather than a dead one and hold significant value even in an agile framework.