“Coumn: Test Plan or boys adventure book”


How a childhood memory contributes to finding the correct answer and in which Derk-Jan argues that the form of our deliverable is less important than answering the relevant questions.

Derk-Jan de GroodIt’s  a Tuesday morning, the team leaders have gathered for their regular meeting. Today there is a new topic on the agenda: discussion of the generic test templates.

Generic templates development is a complex activity, which discussions are often rise sky high. It seems so simple. You start with the template that you always use, you pick a standard template from the internet or ask your colleagues if they have some lying around.  But then it starts to become difficult. Enough examples, an abundance of choices, but what is best for the organization.

I listen to the discussion getting agitated. One of the team leaders has made a proposal, but not everyone is equally enthusiastic. Within one of the other teams a different working method is used, and the proposed template does not fit. Another teamlead sight that the document becomes to thick. Suddenly six pairs of eyes are looking my way. “Derk-Jan, you know a lot of testing, what is a good test plan? Do you think that the definition of the test types should be in the test plan. Can we savely omit the section 3.4?  What is your opinion. “Eh … “ I do not have an answer ready. Logical because there is no clear answer. I try to get out of it with a “It depends”, but that answer is of course not accepted.

My experience is that templates are often developed from the methodology or as I mentioned earlier from the examples already in stock. This causes often difficult discussions about the content. Different teams have different approaches, products, suppliers and stakeholders. It is therefore logical that different teams different demands on their deliverables and thus their templates.

Suddenly I remember that in my youth I sometimes read old-fashioned boys adventure books. I mean those adventure books like they were written up to the fifties. Characteristic of these books is that each chapter starts with a brief introduction. For example, “Chapter 6, In which knight Bertrand makes an important discovery, loses his sword and must spent a night in prison.”

The generic template discussion can be solved by defining a simular introduction for each of the deliverables in the test process. By doing so, we set the objective of the deliverable in a central place. It triggers the reader to continue reading. Instead of chapters and sections, the discussion should focus on the why. Why do we make such a test plan? Do we want to force ourselves to think carefully about our test approach, Do we want to show the stakeholders that we take their concerns and risks seriously. Or do we write it only because we have to follow the procedure? Enough reasons to make a test plan, but what reason (s) are most important.

The content is derived from the goal we want to achieve with the document. If we takes thosd for a starting point, the template will migrate to a checklist that indicates what questions must have been answered after reading the document. In the example of the beforementioned test plan, this could be: “Is it clearly defined how stakeholder input has been incorporated into the test approach”, “Can the project manager determine which parts of the system are covered by tests and where risks are taken?”

If you get into a discussion about the template, diverse it to a discussion about the purpose of the deliverable. If you do it right, you’ll need to know your stakeholders and understand what issues are important to them. You will notice the different documents are interrelated and each document its own reason for being written. Once you have this clear, you will be able to create a balanced set of templates.
You might be reluctant to entering such a trajectory. I understand. But if you still want focus on the purpose of your deliverable. Please take Knight Bertrand as an example and write take a brief introduction on the title page of your next deliverable.

For more information:

Derk-Jan de Grood works as a testing expert at Valori. He advises organizations to organize and improve their testing activities. As product manager he is working on innovations in Valori services. In addition, he publishes and speaks with great enthusiasm on developments in the testing profession.

©Derk-Jan de Grood – Test & Product Manager – Valori

Derk-JandeGrood@valori.nl

http://www.valori.nl

 

Autor: qanewsblog

Sogeti es una compañía tecnológica perteneciente al Grupo Capgemini y especialista en: Testing y Calidad de Software; Soluciones Microsoft y High Tech Consulting. En Sogeti entendemos la importancia de obtener el máximo valor empresarial de sus sistemas de IT, por ello somos líderes mundiales en Testing & QA. Somos creadores de las metodologías estándar del mercado: TMap® (Test Management Approach) y TPI® (Test Process Improvement). ¡Nuestro compromiso es el Testing!

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s