ISTQB – Fundamental Test Process in the Advanced Level

In a previous post I published the Fudamental Test Process from the ISTQB but for Foundation Level.
Now, in the Advanced Level, these activities are considered separately in order to provide additional refinement and optimization of the processes, better fit with the software development lifecycle, and to facilitate effective test monitoring and control. So, the new graph lokks like this one:

Next post: brief resume of each activity.
Enjoy! =)

ISTQB – Basics

This is the basic Testing Process defined by the ISTQB. You don’t know what ISTQB is? International Software Testing Qualification Board.

ISTQB Fundamental Test Process

After this, in next post, I will explain each one of them. =)

Análisis Mental Costo-Beneficio

¡Hola! Retomando mis viejos hábitos de bloguear, por lo que aca estoy de vuelta. Estoy trabajando muchísimo en un proyecto por lo que estos son días muy ajetreados para mí.

Hoy estuve leyendo la revista “Better Software”,ejemplar de mayo/junio 2012, y me encontré con un artículo muy interesante de Lee Copeland: “Vuelo controlado en terreno”.

En este artículo, él menciona un par de accidentes de aviación y los compara con proyectos de software. Realmente te hace pensar.

En el primer ejemplo, después de contar el accidente, él menciona:

“Cuando la situación se deterioró, tenían otra opción, podrían haber entrado en un compás de espera. A menudo, la espera de unos minutos puede permitir que las incertidumbres se aclaren. A veces tenemos que hacer eso con nuestro proyecto, esperar un momento hasta que la información adicional este disponible . En general, la ejecución de “el plan” no es más importante que el éxito de su organización. Siempre se puede hacer un análisis mental del costo-beneficio ”

Y luego se hace tres preguntas que realmente me llamaron la atención:

• ¿Cuál es el costo si se espera?
• ¿Cuál es el beneficio de la presión?
• ¿Cuál es el costo si falla?

Creo que estas preguntas abren nuestra mente y nos llevan a pensar en la evaluación de estos costos. Después de esta evaluación, y en base a cada una de las respuestas obtenidas, podemos revisar cuál es la mejor solución para nuestro proyecto en crisis. Realmente para pensar en este análisis mental costo-beneficio.

Se puede leer el artículo completo en la revista “Better Software” , Volumen 14, Número 3 • mayo / junio de 2012.

Hasta la próxima!

Pato 🙂

Mental Cost-Benefit Analysis

Hi! I am back. I am working very hard on a project so these are very busy days for me.

But today I have been reading the “Better Software” magazine, May/June 2012 issue, and I found a short but very interesting article from Lee Copeland: “Controlled Flight into Terrain”.

He mentions a couple of aircraft accidents and compare them with software projects. Really it makes you think.

From the first example, after he tells the story of the accident, he mentions:

“When the situation deteriorated, they had another option—they could have entered a holding pattern. Often just waiting a few minutes can allow uncertainties to clear. Sometimes we need to do that with our project, wait for a while until additional information becomes available. Generally, executing “the plan” is not more important than your organization’s success. You can always do a mental cost-benefit analysis”

And then he makes three questions that really called my attention:

• What’s the cost if you wait?
• What’s the benefit of pressing on?
• What’s the cost if you fail?

I believe these questions open our minds and leads us to think about evaluating these costs. After this evaluation, and based on each of the responses, we can review what the best solution would be if our project is on a crisis. Really to think about this mental cost-benefit analysis.

You can read the complete article in the “Best Software” magazine, Volume 14, Issue 3 • May/June 2012.

Until next time!

Pato 🙂

BDD – Lesson 1: Core principles

BDD, Behahior Driven Development, emerges from the combination of TDD, Test Driven Development, and ATDD, Acceptance Test Driven Development.

It encourages the use of a common and simple vocabulary (Ubiquitous Language) that seeks to narrow the gap between the Business and Technology.

It has three core principles:

• It is All Behaviour – Business and Technology should refer to the same system in the same way.
• Where is The Business Value – Any system should have an identified, verifiable value to the business.
• Enough Is Enough – Up-front analysis, design and planning all have a diminishing return

BDD consider that when using a very specific and common vocabulary you minimise miscommunication and  ensure that everyone – the business, developers, testers, analysts and managers – are not only on the same page but using the same words.

BDD aims to bridge the gap between the differing views of computer systems held by Business users and Technologists.

Test Automation Manifesto

I found something very interesting some time ago about Automation: Test Automation Manifesto

From Gerard Meszaros, Shaun Smith and Jennitta Andrea, they propose:

Automated tests should be:

• Concise—As simple as possible and no simpler.
• Self Checking—Test reports its own results; needs no human interpretation.
• Repeatable—Test can be run many times in a row without human intervention.
• Robust—Test produces same result now and forever. Tests are not affected by changes in the external environment.
• Sufficient—Tests verify all the requirements of the software being tested.
• Necessary—Everything in each test contributes to the specification of desired behavior.
• Clear—Every statement is easy to understand
• Efficient—Tests run in a reasonable amount of time.
• Specific—Each test failure points to a specific piece of broken functionality; unit test failures provide “defect triangulation”
• Independent—Each test can be run by itself or in a suite with an arbitrary set of other tests in any order.
• Maintainable – Tests should be easy to understand and modify and extend.
• Traceable—To and from the code it tests and to and from the requirements.

You can read a more detailed document from this PDF

 

 

BDD: First lesson coming soon!

Hi!

Did you have any chance to start reading about BDD? No? Ok, don’t worry! I will be starting soon to work in a serie of short lessons so you can understand what it is BDD. Initially, you should know that BDD is Behavior Driven Development, an Agile Software Development methodology.

You have different tools to start working using BDD, but the most important is Cucumber. And what is this? Coming soon! 🙂

BDD: Behavior Driven Development

Ok. Do you really want to involve the client team, Product owner, stakeholders, future users, in the development of their product? Yo have to try BDD. BDD is an agile software development technique that tries to reduce the gap in the communication between the technical team, programmers, architects, testers, and non technical, Product Owner, stakeholders, future users. It is oriented to work all together as a team, using a language that everyone can understand and this way, we can develop a product that really matters to the client.

From its author, Dan North:

“BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.”

If you want to continue reading more about this, you can go to http://behavior-driven.org/

Hey, take a look! 😉

Manifesto for Software Craftsmanship

Hey, you really have to read and sign this: “Manifesto for Software Craftsmanship“

Cucumber: a tool to make your testing easy and fun! :)

Hey! Do you want to read something interesting and to be on the wave? Ok, you have to read this.

Cucumber. What? Cucumber? I am not interested on a preparing a salad with Cucumber…..

Really, take a look and after reading, leave your comment. Make your testing easy and fun! 😉