Las ilusiones en programas de pruebas de software

Posted by admin on February 16, 2013

En un ciclo de vida típico de software de desarrollo (SDLC) no es inusual para la fase de pruebas de software del proyecto para ser comprimido. En la última etapa en el ciclo de las escalas de tiempo para las pruebas de software tienden a reducirse ya que el equipo del proyecto trata de mantener el compromiso de cumplir la fecha de entrega.

Por lo general, el calendario de pruebas de software que se reduce debido a la reducción del tiempo de desarrollo significa la eliminación de cualquiera de las características o el aumento de la cantidad de desarrolladores. Ninguna de estas opciones parece muy atractiva. Uno de los medios una discusión incómoda con el cliente y los costos de otros medios mayores. Así que todas las decisiones difíciles de todo el ajuste de la fase de desarrollo son generalmente pospuesto y aplazó la llamada hasta que el producto entra en la fase de pruebas de software. En este punto las discusiones se hacen más interesante.

Las principales opciones en este punto incluyen la adición de más probadores de software, reduciendo la cantidad de pruebas de software o cambiar la fecha de entrega. Cambio de la fecha de entrega suele ser desestimado inicialmente como no es aceptable para el cliente. La adición de más probadores generalmente se desestimó ya que requiere un gasto adicional. Esto sólo deja reducir la cantidad de pruebas de software. Lo interesante a destacar aquí es que los dos primeros (fecha de entrega y más probadores) son cuantificables y visibles. Cambio de la fecha de entrega requiere de un acuerdo con el cliente y la adición de más probadores se incrementa los costos y los beneficios (reducción). Reducir la cantidad de pruebas de tiempo no es tan visible y es difícil de cuantificar. El único punto en el que se reduce la cantidad de pruebas de software se hace visible es que el producto se libera.

Por lo tanto, a menos que tengas un muy buen caso, olvídate de intentar convencer al equipo de proyecto que reduce la cantidad de pruebas de software es la solución equivocada. El equipo del proyecto es poco probable que escuche cuando las otras opciones son tan visibles y cuantificables. La opción para reducir la cantidad de pruebas de software es probable que sea seleccionado, y como resultado esto creará la ilusión de que el proyecto está en marcha. Pero es una ilusión que no puede mantenerse indefinidamente. Por lo general, esta ilusión se rompe justo después de que el producto software es liberado. El objetivo es romper esa ilusión antes de que se envíe el producto para que el cliente mantiene su fe en su capacidad de entregar un producto de calidad.

No sólo es realmente una estrategia a disposición del equipo de pruebas de que el combate a esta demanda para reducir el calendario de pruebas de software. Esta estrategia es la siguiente:

1. Inicialmente aceptar la reducción
No pierda su tiempo tratando de argumentar en contra de la reducción del tiempo de prueba a menos que usted tiene un caso muy fuerte, que usted sabe que puede ganar. Usted es mejor dirigir sus esfuerzos en tareas más constructivas y después de los próximos 3 pasos.

2. Implementar las mejores probadores que tienen en el proyecto
Probadores de software encontrar defectos Buenas buenas. Con los mejores probadores que tiene en el proyecto que tienen una mejor oportunidad de encontrar más defectos en un plazo más corto. Desde el punto de vista de los directores de proyectos esto se verá como si estuviera jugando a la pelota con sus requerimientos para reducir el tiempo de prueba. En realidad, usted va a utilizar sus mejores probadores para ayudarle a probar su caso. El caso está destinado a probar es que el producto no va a alcanzar el nivel requerido de calidad por el momento este producto de software está listo para enviar.

3. Prepare su evidencia
Este paso tiene que ver con convertir la prueba de algo que no se concretan en algo que es cuantificable. Iniciar el seguimiento de la tasa de defecto de encontrar (número y la severidad de los defectos en contra de la fecha) en un gráfico. Si los mejores probadores están haciendo el trabajo que se emplean para entonces este gráfico se va a mostrar un aumento gradual y constante aumento en la tasa de detección de defectos.

4. Utilice sus pruebas
Su tasa de detección de defectos debe ser utilizada como prueba para romper la ilusión de que el proyecto está en marcha. Si sus probadores siguen para encontrar defectos a un ritmo constante, con las prioridades de defectos importantes, entonces esto puede ser proyectado hacia adelante. Con las estimaciones proyectadas se puede demostrar que la aplicación de software no va a ser de calidad suficiente para liberar en la fecha acordada.

Esto no es una ciencia exacta en las pruebas de software, sino que le dará algo concreto para luchar contra su esquina con. Si se combina esto con la velocidad a la que el equipo de desarrollo son la fijación de los defectos que tiene un buen sistema de gran alcance de las estadísticas para trabajar con ellos. Usted podría incluso ir tan lejos como la estimación de los defectos graves que el número del producto de software es probable que se libera con.

Usted necesita comenzar a recoger esta evidencia tan pronto como sea posible y presente las pruebas que el equipo del proyecto tan pronto como se dispone de datos suficientes. Esta continuación, da a cada uno tres opciones tangibles para elegir, cambiar la fecha de entrega, añadir más recursos, al desarrollo y prueba) o la liberación de mala calidad.

Por supuesto, la opción de liberar a la mala calidad seguirá siendo alto en la lista de opciones aquí. Así que es posible que desee apoyar su defecto encontrar pruebas tasa con detalles sobre los tipos de defectos que puedan. Por ejemplo, si su equipo está encontrando defectos de alta prioridad, al igual que los problemas que bloquean un comunicado, sobre una base diaria entonces usted está en una posición más fuerte. En una posición de fuerza que son más capaces de contador de personas que utilizan las pruebas de soluciones de software de reducción como una opción creíble.

Es importante recordar que el objetivo no es ir en contra del equipo de desarrollo y proyectos de aquí. El objetivo es trabajar con ellos. Después de todo el equipo de pruebas de software tienen mucho que ganar de una versión de alta calidad, entregado a tiempo, tanto como cualquier otra persona.

El objetivo debe ser siempre para presentar la información tanto como sea posible para que todo el equipo (de prueba, desarrollo y proyectos) puede hacer la llamada correcta. La decisión correcta en el equilibrio de la fecha de lanzamiento, las características y la calidad se realiza mejor con todos los datos pertinentes. A veces, para el desprecio del equipo de pruebas, que la decisión correcta es dar a conocer a ligeramente por debajo de la calidad del par. Mientras que la llamada se realiza con las mejores intenciones y se basa en los datos correctos, entonces tiene una posibilidad mucho mayor de hacer las cosas bien.

Como siempre, al final, todo se reduce a conseguir el equilibrio de la fecha de entrega, características y derecho de calidad para el cliente.

Categories: Software

Comments are closed.