E 2.4.1 Documento de entrega de Aplicación Versión: 0.1 Fecha: 11/08/11 Autor: Email: Antoni Bertran Bellido abertran@opentrends.net
Historial de cambios Versión Fecha Autor Cambios 0.1 11/08/11 Antoni Bertran Versión Inicial
Índice 1. Introducción... 1 2. Conceptos previos... 2 3. Tabla de Tareas Pruebas y Tests... 7
1. Introducción 1.1. Objetivos del documento El objetivo de este documento es el de comunicar, facilitar y recopilar una lista de tests y pruebas que deberán cumplimentar para cada Aplicación en el momento de hacer la entrega. De esta manera se podrá validar la calidad de la misma. 1.2. Propósito La metodología, políticas y procesos de desarrollo deben ser seguida por todos los componentes del equipo para asegurar una buena coordinación y alcanzar la calidad esperada en los entregables. Hay que recordar que una metodología, por buena que sea, resulta inútil si no es seguida por todos los componentes del equipo. En este caso, este punto reviste especial importancia dado el gran número de socios y de componentes del sistema. Por todo ello en este documento se muestra una lista de pruebas y tareas a realizar para poder entregar la aplicación. 1.3. A quién va dirigido Desarrolladores. Para conocer qué normativas deben seguir y qué herramientas tienen a su alcance para facilitar su tarea de gestión de la calidad. Testing o Revisores. Para conocer qué procedimientos pueden seguir para gestionar y controlar la calidad de los proyectos. 1
2. Conceptos previos 2.1. Conceptos Generales 2.1.1. Qué es el aseguramiento de la calidad? Aseguramiento de la Calidad se asegura que el proyecto se completará sobre la base de las especificaciones previamente acordadas, las normas y la funcionalidad requerida, sin defectos y los posibles problemas. Se vigila y trata de mejorar el proceso de desarrollo desde el principio del proyecto para asegurar esto. Está orientado a la "prevención". 2.1.2. Cuándo se debe empezar a las pruebas de control de calidad en un proyecto? Por qué? Control de calidad está involucrado en el proyecto desde el principio. Esto ayuda a los equipos de comunicación y entender los problemas y preocupaciones, también se da tiempo para configurar el entorno de pruebas y la configuración. Por otro lado, la prueba real se inicia después de los planes de prueba están escritas, revisadas y aprobadas sobre la base de la documentación de diseño. 2.1.3. Qué es el Software Testing? Las pruebas de software se orienta a "la detección". Es el examen de un sistema o una aplicación bajo condiciones controladas. Es intencionalmente, haciendo las cosas van mal cuando no deberían y las cosas suceden cuando no deberían hacerlo. 2.1.4. Qué es la calidad del software? La calidad del software es razonablemente libre de errores, entregado a tiempo y dentro del presupuesto, cumple con los requisitos y / o expectativas, y es fácil de mantener. 2.1.5. Qué es la verificación y validación de software? La verificación es la prevención de mecanismo para detectar posibles fallos antes de comenzar la prueba. Se trata de estudios, reuniones, documentos de evaluación, los planes, el código, inspecciones, etc validación de las especificaciones ocurre después de la verificación, y es la prueba real de encontrar defectos en contra de la funcionalidad o las especificaciones. 2.1.6. Qué es el Plan de Pruebas? Plan de prueba es un documento que describe los objetivos, alcance, enfoque, y el foco de un esfuerzo de pruebas de software. 2.1.7. Qué es el caso de prueba? Un caso de prueba es un documento que describe una entrada, una acción o evento y la respuesta esperada, para determinar si una característica de una aplicación funciona correctamente. Un caso de prueba debe contener los datos tales como identificador de casos de prueba, el nombre de caso de prueba, el objetivo, las condiciones de prueba / configuración, los requisitos de entrada de datos, medidas y resultados esperados. 2
2.1.8. Qué es buen software de codificación? Buen código es el código que funciona de acuerdo a los requisitos, libre de errores, de mantener legible, ampliable en el futuro y con facilidad. 2.1.9. Qué es un buen diseño? En un buen diseño, la estructura general es clara, comprensible, fácilmente modificable y mantenible. Funciona correctamente cuando se implementan y la funcionalidad se remonta a las necesidades del usuario y del cliente final. 2.1.10. Qué es un ingeniero de pruebas de bueno? Ingeniero de pruebas bueno tiene la capacidad de pensar lo impensable, fuerte deseo de calidad y atención al detalle. 2.1.11. Qué es el WalkThrough? WalkThrough es breve encuentro informal y para fines de evaluación. 2.1.12. Qué es el ciclo de vida del software? El ciclo de vida del software se inicia cuando una aplicación se concibió por primera vez y termina cuando ya no esté en uso. Incluye aspectos tales como el concepto inicial, análisis de requerimientos, diseño funcional, el diseño interno, la planificación de la documentación, la planificación de controles, la codificación, la preparación de documentos, integración, pruebas, mantenimiento, actualizaciones, nuevas pruebas, la eliminación gradual, y otros aspectos. 2.1.13. Qué es la Inspección de Software? El propósito de la inspección está tratando de encontrar defectos y problemas sobre todo en documentos como los planes de prueba, especificaciones, casos de prueba, codificación, etc Ayuda a encontrar los problemas e informar de ello, pero no para arreglarlo. Es uno de los métodos más rentables de la calidad del software. Muchas personas pueden unirse a las inspecciones, pero normalmente un moderador, un lector y un encargado de tomar notas son obligatorios. 2.1.14. Cuáles son los beneficios de las pruebas automatizadas? Es muy valioso para el largo plazo y sobre los proyectos en marcha. Puede automatizar todos o algunos de los ensayos que se debe ejecutar de vez en cuando en repetidas ocasiones o difíciles de probar manualmente. Se ahorra tiempo y esfuerzo, también hace pruebas de posible fuera de las horas de trabajo y las noches. Pueden ser utilizados por personas diferentes y muchas veces en el futuro. De esta manera, también estandarizar el proceso de prueba y puede confiar en los resultados. 2.2. Pruebas A continuación mostramos las diferentes pruebas o test que se proponen con una explicación detallando en que consisten 3
2.2.1. Unit testing Se trata de la prueba a más bajo nivel para probar las funciones específicas o módulos de código. Por lo general realizado por el programador y no por los testing, ya que requiere un conocimiento detallado del diseño del programa interno y el código. No siempre es fácil de hacer a menos que la aplicación tiene una arquitectura bien diseñada con código estricto, puede requerir el desarrollo de módulos piloto de pruebas. 2.2.2. Incremental integration testing Control continuo de una nueva funcionalidad añadida. Requiere que los diversos aspectos de la funcionalidad de una aplicación independiente que suficiente para trabajar por separado antes de todas las partes del programa se han completado, o que los pilotos de pruebas se desarrollarán según sea necesario. Hecho por programadores o por los testing. 2.2.3. Integration testing Ensayo de piezas combinadas de una aplicación para determinar si funcionan juntos correctamente. Puede ser cualquier tipo de aplicación que tiene varias aplicaciones independientes sub módulos. 2.2.4. Black box testing No es necesario conocer el diseño interno en detalle o tener un buen conocimiento sobre el código para esta prueba. Se basa principalmente en la funcionalidad y especificaciones, requisitos. 2.2.5. White box testing Esta prueba se basa en un conocimiento detallado del diseño interno y el código. Las pruebas se realizan para las declaraciones de código específico y estilos de codificación. 2.2.6. Functional testing Pruebas tipo Black Box, pone a prueba de los requisitos funcionales de una aplicación. Por lo general realizado por los testing de software, pero los programadores de software también debe comprobar si su código funciona antes de soltarlo. 2.2.7. System testing Las pruebas tipo Black Box se basan en las especificaciones de los requisitos generales. Cubre todas las partes de un sistema combinado. 2.2.8. End to End testing Es similar a las pruebas del sistema (System Testing). Implica la evaluación de un entorno de aplicación completa similar al uso del mundo real. Puede requerir la interacción con una base de datos, utilizando la red de comunicaciones, o interactuar con otros equipos, aplicaciones o sistemas. 2.2.9. Sanity testing or smoke testing Un esfuerzo inicial para determinar si una nueva versión SW está funcionando lo suficientemente bien como para comenzar una prueba de software. Por ejemplo, si el nuevo software se bloquea con frecuencia o corrompe las bases de datos, entonces no es una buena idea para comenzar a probar antes de todos estos problemas se resuelven en primer lugar. 4
2.2.10. Regression testing Se trata de volver a hacer las pruebas después de que el software se ha actualizado para corregir algunos problemas. El desafío podría ser la de determinar lo que necesita ser probado, y todas las interacciones de las funciones, especialmente cerca del final del ciclo de software. Las pruebas automatizadas pueden ser útiles para este tipo de pruebas. 2.2.11. Acceptance testing Esta es la prueba final hace en base a los acuerdos con el cliente. 2.2.12. Load / stress / performance testing Se tratan de pruebas de una aplicación bajo cargas pesadas. Tales como la simulación de una situación de tráfico muy pesado en una red de voz o datos, o un sitio web para determinar en qué punto el sistema de empezar a causar problemas o no. 2.2.13. Usability testing Las pruebas para determinar cómo de fácil es la aplicación. Depende del usuario final o cliente. Entrevistas a usuarios, encuestas, grabación de vídeo de las sesiones de usuario, y otras técnicas se pueden utilizar. Los programadores y testing por lo general no son apropiados como evaluadores de uso. 2.2.14. Install / Uninstall testing Prueba parcial, completa o actualizar de instalación / desinstalación de los procesos. 2.2.15. Recovery / failover testing Las pruebas para determinar qué tan bien un sistema se recupera de accidentes, fallas u otros problemas importantes. 2.2.16. Security testing Las pruebas para determinar qué tan bien el sistema se protege contra el acceso no autorizado interna o externa y el daño intencionado. Puede requerir técnicas sofisticadas. 2.2.17. Compatability testing Prueba lo bien que software lleva a cabo en diferentes ambientes. Particularmente de hardware, software, sistema operativo, etc entorno de red, igualmente incluye las pruebas de un sitio web en distintos navegadores y versiones de navegadores. 2.2.18. Exploratory testing A menudo se entiende una prueba creativa, ya que el software informal que no se basa en los planes de pruebas formales o casos de prueba implican, el encargado de hacer el test tieneque aprender cómo funciona el software cuando lo prueba. 2.2.19. Ad-hoc testing Al igual que en las pruebas de exploración, pero a menudo se entiende que los examinadores tienen una comprensión significativa del software antes de probarlo. 5
2.2.20. Context driven testing Pruebas impulsadas por una comprensión del medio ambiente, la cultura, y el uso previsto de software. Por ejemplo, el enfoque de las pruebas de vida de software críticas equipo médico sería completamente diferente a la de un juego de ordenador de bajo costo. 2.2.21. Comparison testing Comparación de las debilidades y fortalezas de software para productos de la competencia. 2.2.22. Alpha testing Prueba de una aplicación cuando el desarrollo está casi terminado. Cambios menores de diseño todavía pueden ser hechos como resultado de dicha prueba. Por lo general realizado por los usuarios finales o los demás, no por los programadores o los de testing. 2.2.23. Beta testing Pruebas de que el desarrollo y las pruebas son esencialmente completado y los bugs finales y los problemas hay que encontrar antes del lanzamiento final. Por lo general realizado por los usuarios finales o los demás, no por los programadores o los de testing. 2.2.24. Mutation testing Un método para determinar si un conjunto de datos de prueba o casos de prueba es útil, introduciendo deliberadamente varios cambios de código (defectos) y volver a probar con los datos de prueba original / casos para determinar si los defectos se detectan. La aplicación correcta requiere de grandes recursos computacionales. 6