Una definición común de un error de software es una falta de coincidencia entre el programa y su especificación. En otras palabras, podemos decir, un error de software está presente en un programa cuando el programa no hace lo que su usuario final espera.
Categorías de los errores de software:
- Errores de interfaz de usuario, tales como errores de salida o mensajes incorrectos de usuario.
- Errores de función
- Defectos de hardware
- Versión del programa incorrecta
- Requisitos de los errores
- Errores de diseño
- Errores de documentación
- Errores de Arquitectura
- Errores del módulo de interfaz
- Errores de rendimiento
- Límites relacionados con errores
- Los errores lógicos tales como errores de cálculo, errores basados en estado de comportamiento, errores de comunicación, errores de estructura del programa, tales como errores de flujo de control.
La mayoría de los programadores son bastante arrogante acerca del control de la calidad del software. Ellos escriben un código, ejecutan a través de algunas pruebas bastante evidentes(test unit) el flujo básico y si todo sale bien se pasa a desarrollo. Si bien este enfoque puede funcionar bien para programas pequeños, personales, pero no en el desarrollo de software profesional.
Las modernas prácticas de ingeniería de software incluyen un considerable esfuerzo dirigido hacia la garantía de calidad del software y pruebas. La idea, por supuesto, es para producir un software de alto con la probabilidad de satisfacer las necesidades del cliente.
Hay dos formas de administrar el software libre de errores:
- Prevención de la introducción de errores en el primer lugar.
- La identificación de los errores que acechan en el código del programa, los buscan y destruyen.
Obviamente, el primer método es superior. Una gran parte de la calidad del software viene de hacer un buen trabajo en la definición de los requisitos para el sistema que estamos construyendo y diseñando una solución de software que satisfaga esas necesidades. Las pruebas se centra en la detección de los errores que se arrastran en a pesar de sus mejores esfuerzos para mantenerlos fuera.
Clasificación de los defectos/bug
Hay varias maneras en las que podemos clasificar. A continuación se presentan algunas de las clasificaciones:
Severity Wise:
- Mayor: Un defecto, lo que provocará una falla del producto observable o salida de los requisitos.
- Menor: Un defecto que no se producirá un error en la ejecución del producto.
- Fatal: Un defecto que hará que el sistema se bloquee o cierre abrupto o efectuar otras aplicaciones.
Work product wise:
- SSD: Un defecto de documento Estudio del Sistema
- DFC: Un defecto de un documento de especificación funcional
- ADS: Un defecto de Documento de Diseño Arquitectónico
- DDS: Un defecto de un documento de diseño detallado
- Código fuente: Un defecto de código fuente
- Plan de Pruebas / Casos de Prueba: Un defecto de plan de pruebas / Test Cases
- Documentación del usuario: Un defecto de los manuales de usuario, manuales de servicio
Tipo de errores Wise:
- Comentarios: comentarios inadecuados / no es correcta / errónea o faltante en el código fuente
- Computacional Error: cálculo incorrecto de las validaciones de negocio fórmulas / incorrecto en el código.
- Error de datos: datos de población incorrecto / actualización en la base de datos
- Database Error: Error en el esquema de base de datos / Diseño
- Diseño desapareció: Las características de diseño / aproximación frustrada / no documentado en el documento de diseño y por lo tanto no se corresponde con los requisitos
- Diseño óptimo inadecuada o substitución: Las características de diseño / enfoque requiere de insumos adicionales para que sea completeDesign características descritas no proporciona el mejor enfoque (enfoque óptimo) a la solución requerida
- En correcto diseño: Diseño incorrecto o inexacto
- Ambiguo Diseño: característica de diseño / enfoque no está claro para el revisor. También incluye el uso de palabras ambiguas o poco claras características de diseño.
- Condiciones de contorno Olvidadas: Las condiciones de contorno no se aborda / incorrecta
- Error de interfaz: interna o externa al error de aplicación de interfaz, el manejo incorrecto de paso de parámetros, alineación incorrecta, incorrectas / campos / objetos fuera de lugar, ONU amistosos ventana / pantalla posiciones
- Error lógico: la funcionalidad que falta o inadecuada o irrelevantes o ambiguas en el código fuente
- Mensaje de error: mensajes de error inadecuados / no es correcta / errónea o faltante en el código fuente
- Error de navegación: La navegación no codificado correctamente en el código fuente
- Error Performance: un error relacionado con el rendimiento / optimización del código
- Requisitos que faltan: implícitos / explícitos requisitos perdidas / no documentados durante la fase de requerimiento
- Requisitos inadecuados: Requisito necesita entradas adicionales para que se complete
- Requisitos incorrectas: requisitos erróneos o inexactos
- Requisitos ambiguas: Requisito no está claro para el revisor. También incluye el uso ambiguo de las palabras - por ejemplo, como, por ejemplo, puede ser, puede ser, alma, etc
- Secuenciación / tiempo de error: Error debido a la incorrecta / falta de consideración y tiempos de espera incorrecta / falta de secuenciación en el código fuente.
- Normas: Las normas no siguieron como el manejo de excepciones incorrecta, uso de E & D formatos y diseño de proyectos relacionados / requisitos / normas de codificación
- Error del sistema: Error de hardware y del sistema operativo relacionado, pérdida de memoria
- Plan de Prueba / Error casos: Inadecuado / incorrecto / ambiguo o duplicados o faltantes - Plan de Prueba / Test Cases y scripts de prueba, incorrecto / incompleto configuración de prueba
- Error tipográfico: Ortografía / Gramática error en los documentos / código fuente
- Error de declaración de variables: declaración incorrecta / uso de variables, error de coincidencia de tipos en el código fuente
Estado Wise:
- Abierto
- Cerrado
- Diferido
- Cancelado
Estas son las principales formas en que los defectos pueden ser clasificados.
Ciclo de vida de un error/bug
El flujo básico sigue siendo el mismo.
Ciclo Bug Life:
- El Tester encuentra un bug. Status -> Abrir
- El Tester escribe la descripción del fallo y autoriza el error. Stats -> Abrir
- El equipo de desarrollo principal revisar el defecto. Stats -> Abrir
- El defecto puede ser autorizado o no autorizado por el equipo de desarrollo. (Aquí el estado del defecto / fallo será abierta (para los defectos autorizados) y Rechazo (Para Defectos no autorizadas).
- Ahora, los errores autorizadas será arreglado o diferido por el equipo de desarrollo. Situación de los errores corregidos se ha corregido y Estado se aplazará para los bugs que ya ha diferido.
- Los bugs fijos se pasan de nuevo al equipo de pruebas (Aquí basado en la Clausura del Bug, el estado se hará tan cerrada o si el error persiste, que se volverá a levantar-y el estado se volverá a abrir- .
El ciclo anteriormente mencionado continúa hasta que todos los errores / defectos se fija en la aplicación.
Encontrar mas errores al hacer pruebas de software?
Algunos consejos útiles para encontrar más errores al hacer pruebas de software:
- Comprender toda la aplicación o módulo en profundidad antes de iniciar la prueba.
- Dar la tensión en los casos de pruebas funcionales que incluye el riesgo principal de la aplicación.
- Probar con un conjunto de datos, debe incluir los identificadores de los registros de la base de datos que se van a probar.
- Si no es primer ciclo de pruebas de software, utilizar la prueba anterior como patrón de datos para analizar el conjunto actual de pruebas.
- Lleve a cabo las mismas pruebas en entorno de prueba diferente. Descubre el modelo resultante y después compara tus resultados con los patrones.
- Haga algunas pruebas estándar como poner el signo "%" o "*" o etiquetas HTML en el cuadro de texto y luego ver los resultados en la ventana de resultados.
- Cuando estás cansado, se pueden hacer algunas pruebas automatizadas.
Aparte de estos consejos, una cosa importante es que usted debe estar pensando cada minuto en encontrar un error en el software.
Informe de errores
Después de completar la Prueba de Software, es una buena práctica para preparar un informe de error efectiva. La fijación de un error depende de la eficacia con la que informar de ello. A continuación se presentan algunos consejos para escribir un informe de error de software bueno:
- Si usted está haciendo pruebas de software y manual de informar de fallos sin que la ayuda de ningún instrumento, asigna un número único a cada informe de error. Esto le ayudará a identificar el registro de errores.
- Es evidente que hablar de los pasos para reproducir el error. No dé por sentado o saltar cualquier paso reproducirse.
- Sea específico y directo
Aparte de estos consejos, a continuación son algunas buenas prácticas:
- Reporte el problema inmediatamente
- Reproducir el bug Atleast una vez más antes de reportar
- Pruebe la aparición mismo error en otros módulos similares de la aplicación
- Lea el informe de errores antes de enviarlo o enviarlo.
- Nunca jamás criticar cualquier desarrollador o atacar a cualquier individuo
Plantilla para presentar el informe de errores.
Si usted está usando alguna herramienta de gestión de pruebas de software o cualquier otra herramienta de informe de errores como Bugzilla, la herramienta generará automáticamente el informe de error. Si usted no está usando cualquier herramienta, puede consultar la siguiente plantilla para el informe de errores de software:
- Nombre del Reportador:
- Email Id del Reportador:
- Versión o Build: < Versión o construir el producto >
- Módulo o componente: < mencionar aquí el nombre del módulo o componente de prueba >
- Plataforma / Sistema operativo:
- Tipo de error: < codificación error / error de diseño / sugerencia / UI / documentation / texto de error / error de hardware>
- Prioridad:
- Gravedad:
- Estado:
- Asignado a:
- Resumen:
- Descripción: < mencionar aquí los pasos para reproducir, resultado esperado y el resultado real>
Bueno con esto creo que queda entendido como se comporta un error dentro del ciclo del desarrollo de software.
Fuente:
No hay comentarios:
Publicar un comentario