Mundo Testing Control de calidad de software
Artículos relacionados
Todo desarrollo de productos de software independientemente de la metodología que se está implementando, es necesario que se incluya la fase de pruebas, la cual nos permitirá determinar si el producto a entregar cumple con la calidad especificada y esperada por el cliente. En la actualidad las personas que nos dedicamos a las pruebas de software (Testing), necesitamos de un Plan de Pruebas de Software, el cual tiene como propósito comunicar a todos los involucrados del proyecto los entregables, las características a ser o no ser probadas, los aspectos de criterios de aprobación y fallo, criterios de suspensión y reanudación, las necesidades ambientales, las capacitaciones requeridas para los integrantes del equipo de pruebas, los riesgos y el laboratorio de usabilidad.
El Plan de Pruebas de Software se puede aplicar a todo proyecto de software, se ajusta a las necesidades de cada empresa de software considerando el tamaño del proyecto, el tiempo, el costo, el ciclo de vida del software, los involucrados, que son algunos por mencionar. Cada empresa puede definir su propio Plan de Pruebas de Software basándose en las buenas prácticas y en la mejora continua.
Contenido
El Plan de Pruebas de Software lo integran las siguientes secciones
Identificador
El identificador del Plan de Pruebas nos sirve para nombrar a nuestro plan de pruebas en desarrollo, la característica de esta sección es que tiene que ser único, no puede ver más de un plan con el mismo identificador, el objetivo de esta sección es llevar un mejor control entre los diferentes planes.
Ejemplo: PLAN_001-(NOMBRE DEL PLAN).
Introducción
Es la sección inicial de nuestro Plan de Pruebas, cuyo propósito principal es informar el alcance de las pruebas para el proyecto en cuestión, dando una breve explicación o resumen de todas las secciones que integrara nuestro plan.
Objetivo
Corresponde a la finalidad genérica del Plan de Pruebas, no debe de señalar resultados concretos ni medibles con la utilización de indicadores. Se debe de especificar el propósito central del plan.
Estrategia
Corresponde al conjunto de decisiones sobre acciones y recursos a utilizar que permitirá alcanzar el objetivo general de nuestro plan.
Alcance
Corresponde a presentar y delimitar la totalidad del trabajo que es necesitado para dar por terminado nuestro plan de pruebas.
Propósito
Corresponde a la determinación firme de lo que se espera al momento de llevar a cabo la implementación de nuestro plan de pruebas.
Entregables
Documentación a entregar
En esta sección se listaran todos los documentos que se entregaran como parte de la ejecución del plan, especificando el nombre del documento, la persona quien entrega, la persona quien recibe, así como la fecha planeada y la fecha que fue la entrega para cada uno de los entregables. Para esta sección se recomienda el uso de una tabla cuyo formato del tipo de letra, color de la tabla sean entendibles para que los involucrados en el Plan, puedan identificar rápidamente las características de los entregables. Algunos de los documentos que debes de considerar entregar son: Casos de pruebas, Especificación del diseño de casos, Reporte de errores (defectos), Evidencias de las pruebas, Reportes emitidos por alguna herramienta de administración de las pruebas y cualquier otro documento de carácter importante que sea considerado para su entrega.
Características a ser probadas
En esta sección se listaran todas las características que serán probadas, para ello es importante que se realice juntas con interesados del proyecto, los cuales nos permitirán determinar qué características se van a probar en este plan. Algunas características que se pueden hablar en esta sección son: características de funcionalidad, interfaz gráfica, seguridad, etc. Es importante definirlas de manera clara y concisa para no tener malas interpretaciones de dichas características que serán probadas.
Características a no ser probadas
En esta sección se listaran todas las características que no serán probadas, estas características se determinan a través de juntas y de los requerimientos del proyecto, es importante que se justifique el por qué no serán probadas las características y el riesgo que estas pueden ocasionar al no ser probadas, con el propósito de informar a los involucrados y estén completamente de acuerdo. Algunas características que se pueden hablar en esta sección son: características de interfaz gráfica, seguridad, etc. Es importante definirlas de manera clara y concisa para no tener malas interpretaciones y si ocurre algún evento que afecte al proyecto no comenzar a repartir cumplas entre los equipos.
Criterios de aprobación y fallo
Son los criterios que serán considerados para dar por completado el Plan de Pruebas, por ejemplo: Porcentaje de la cobertura de las pruebas esperado, cierto porcentaje de casos exitosos, cobertura de todos los componentes, porcentaje de defectos corregidos, todo error debe de ir acompañado de un mensaje de validación, entre otros. Cuando un criterio de aprobación fue rechazado se toma acción para el criterio utilizando el criterio de fallo para dicho criterio. Todo criterio de aprobación lo debe de acompañar un criterio de fallo, el cual es la acción que se tomara en la implementación del plan, cuando se ejecuten las pruebas sobre el proyecto.
Criterios de suspensión y reanudación
En esta sección se establecen los criterios de suspensión los cuales establece claramente bajo qué condiciones se detienen un conjunto de casos de pruebas, por ejemplo en caso de existir defectos que impidan la ejecución de más casos de pruebas, cierto porcentaje de casos fallidos, o cualquier otro que se especifique. Los criterios de reanudación establece bajo qué criterios se reanudaran las pruebas, por ejemplo: cuando nos entreguen una nueva versión de pruebas, cuando nos realicen las configuraciones necesarias, etc. Es importante considerar que para cada criterio de suspensión debe contar su criterio de reanudación.
Tareas de las pruebas
En este apartado se describirán las tareas y cuando se van a ejecutar, el propósito es mantener una buena administración de las tareas integradas en este plan. Se recomienda establecer el nombre de la tarea, su descripción corta y precisa, fecha de inicio, fecha de fin, su duración, el responsable de cada tarea y el rol que la desempeñara. Para determinar la duración de las tareas es importe desarrollar un WBS (Estructura de Descomposición del Trabajo) en el cual se describen y se asignan las tareas de manera desglosada para obtener dicha duración, o también podemos pedir la opinión de los expertos para determinarla de manera más real.
Necesidades ambientales
En esta sección se especificaran las necesidades del ambiente de pruebas que son requeridas, con el propósito de poder ejecutar las pruebas al proyecto y así determinar la calidad del mismo. Estas necesidades de dividen en:
Hardware
En este apartado se especifican los equipos tecnológicos que son requeridos para poder llevar a cabo nuestras pruebas de software en el proyecto, las necesidades del hardware comienzan desde el análisis de requerimientos, diseños de pruebas, administración de pruebas, ejecución de pruebas y algún otro dispositivo necesario que es parte fundamental del proyecto, como pueden ser, impresoras, terminales bancarias, teléfonos, que son algunos ejemplos.
Debes de considerar que los equipos y/o dispositivos con los que no se cuentan, que tan requeridos son, para ello te debes de contestar las siguientes preguntas: ¿Es requerido el equipo y/o dispositivo?, ¿Urge la adquisición del equipo y/o dispositivo que es requerido?, con el objetivo de justificar porque es necesario la adquisición del equipo y/o dispositivo, de esta manera los involucrados en el proyecto podrán determinar que parte realiza la adquisición del hardware.
Planeación de costos
En esta sección es preciso tener en cuenta el costo de la implementación de las pruebas en el proyecto. El costo es uno de los indicadores más importantes a considerar en el plan, por lo tanto, mientras más eficiente sea esta labor, menos recursos se invertirán en la ejecución de las pruebas y, por consiguiente, menor será la cuantía de los gastos. Toma en cuenta los recursos humanos, costo de capacitaciones, cursos, insumos materiales; como puede ser papel, tinta etc. Es importante que clasifiques los tipos de recursos para una mejor organización y presentación de los mismos.
Sistemas Bajo Pruebas – SUT
El sistema bajo pruebas por sus siglas en inglés SUT (System Under Test), se refiere al sistema o modulo del sistema que está siendo probado para su funcionamiento correcto. Es importante considerar la distribución de los módulos en los cuales el proyecto se organizó y la integración de los mismos. El propósito de esta sección es tener bien claro cuáles son los módulos a probar, los requerimientos del proyecto por módulo y los casos de prueba para cada módulo.
Test-ware
En esta sección se especifican los artefactos que son requeridos para la ejecución del proceso de pruebas, se debe de considerar la configuración del ambiente de pruebas, los privilegios de los diferentes usuarios que van a interactuar con el sistema, los accesos a bases de datos, guías de pruebas, casos de prueba y la documentación especifica del proyecto.
Capacitaciones
En esta sección se deben de especificar las capacitaciones requeridas para los integrantes del equipo, el objetivo principal de esta sección es determinar a qué personas del equipo serán capacitadas. Se debe de considerar las capacitaciones de carácter autodidacta. Es importante considerar al instructor, las personas que recibirán la capacitación, así como los temas, las fechas de inicio y fin, la duración en horas y su costo.
Riesgos
En esta sección se especificaran los riesgos que pueden afectar directamente o indirectamente a los resultados de nuestras pruebas. Identificar y tener las acciones preventivas y correctivas de los riesgos anteriormente definidos, nos permiten tomar decisiones rápidas y eficientes, porque anteriormente ya se realizó el análisis de los riesgos y sus acciones a tomar. Es importante que al documentar los riesgos sea de manera organizada y entendible para todos los involucrados del proyecto. A continuación te comentare algunas secciones para la organización de los riesgos que son: Id Riesgo, Nombre, Descripción, Estado inicial, Consecuencias, Probabilidad de ocurrencia, impacto, prioridad, clasificación, síntomas, tolerancias, acciones preventivas y correctivas.
Laboratorio de usabilidad
En esta sección se especificaran las citas (juntas) requeridas en todo el proyecto, las citas se pueden tener de clasificación externa que son con el cliente o internas que son con los integrantes del equipo, es importante determinar las citas y su objetivos de cada una ya que pueden ser para presentación y validación de diseño de pruebas, como aclaraciones con las reglas de negocio, requerimientos, etc. Algunas opciones de definición son: cita, clasificación, descripción, duración, fecha y los usuarios.
Es importante dejar en claro que cada empresa dedicada a las pruebas de software puede tener diferentes secciones que conformen su Plan de Pruebas de Software, ya que cada empresa determina sus procesos, sus diseños y sus documentos de acuerdo a sus necesidades.
Plantilla Plan de Pruebas de Software
En el link de abajo, les comparto una plantilla del Plan de Pruebas de Software. Utiliza esta plantilla como un ejemplo de plan de pruebas de software.
Very good written post. It will be supportive to anybody who employess it, including me. Keep doing what you are doing – looking forward to more posts.
I’d like to find out more? I’d like to find out more details.
Esta sección del Plan de Pruebas contiene una lista de todos los requerimientos que serán probados. Cualquier requerimiento no incluido en esta lista estará fuera del alcance de las pruebas
holaz
penepenpenepene