¿Crees en las pruebas de software Mitos?

Mito 1: las pruebas son demasiado caras

Realidad : Hay un dicho, paga menos por las pruebas durante el desarrollo del software o paga más por el mantenimiento o la corrección posterior. Las pruebas tempranas ahorran tiempo y costos en muchos aspectos, sin embargo, reducir el costo sin pruebas puede resultar en un diseño incorrecto de una aplicación de software que inutiliza el producto.

Mito 2: Las pruebas consumen mucho tiempo

Realidad : durante las fases de SDLC, las pruebas nunca son un proceso lento. Sin embargo, diagnosticar y corregir los errores identificados durante las pruebas adecuadas es una actividad productiva que requiere mucho tiempo.

Mito 3: solo se prueban productos completamente desarrollados

Realidad : Sin duda, las pruebas dependen del código fuente, pero la revisión de los requisitos y el desarrollo de casos de prueba es independiente del código desarrollado. Sin embargo, el enfoque iterativo o incremental como modelo de ciclo de vida de desarrollo puede reducir la dependencia de las pruebas en el software completamente desarrollado.

Mito 4: la prueba completa es posible

Realidad : se convierte en un problema cuando un cliente o evaluador piensa que la prueba completa es posible. Es posible que todas las rutas hayan sido probadas por el equipo, pero la realización de pruebas completas nunca es posible. Puede haber algunos escenarios que nunca son ejecutados por el equipo de prueba o el cliente durante el ciclo de vida de desarrollo de software y pueden ejecutarse una vez que se ha implementado el proyecto.

Mito 5: un software probado no tiene errores

Realidad : Este es un mito muy común en el que creen los clientes, los gerentes de proyecto y el equipo de gestión. Nadie puede afirmar con absoluta certeza que una aplicación de software está 100% libre de errores, incluso si un probador con excelentes habilidades de prueba ha probado solicitud.

Mito 6: los defectos perdidos se deben a los evaluadores

Realidad : no es un enfoque correcto culpar a los probadores de errores que permanecen en la aplicación incluso después de que se hayan realizado las pruebas. Este mito se relaciona con el tiempo, el costo y los requisitos que cambian las restricciones. Sin embargo, la estrategia de prueba también puede hacer que el equipo de prueba omita errores.

Mito 7: los evaluadores son responsables de la calidad del producto

Realidad : es una interpretación errónea muy común que solo los evaluadores o el equipo de evaluación deben ser responsables de la calidad del producto. Las responsabilidades de los evaluadores incluyen la identificación de errores para las partes interesadas y luego es su decisión si corregirán el error o lanzarán el software. Lanzar el software en ese momento ejerce más presión sobre los probadores, ya que se los culpará de cualquier error.

Mito 8: La automatización de pruebas debe usarse siempre que sea posible para reducir el tiempo

Realidad : Sí, es cierto que Test Automation reduce el tiempo de prueba, pero no es posible iniciar la automatización de prueba en ningún momento durante el desarrollo del software. El autómata de prueba debe iniciarse cuando el software se ha probado manualmente y es estable hasta cierto punto. Además, la automatización de pruebas nunca se puede usar si los requisitos siguen cambiando.

Mito 9: cualquiera puede probar una aplicación de software

Realidad : las personas ajenas a la industria de TI piensan e incluso creen que cualquiera puede probar un software y probar no es un trabajo creativo. Sin embargo, los evaluadores saben muy bien que esto es un mito. Pensando en escenarios alternativos, tratar de bloquear un software con la intención de explorar posibles errores no es posible para la persona que lo desarrolló.

Mito 10: la única tarea de un probador es encontrar errores

Realidad : encontrar errores en un software es tarea de los probadores, pero al mismo tiempo, son expertos en el dominio del software en particular. Los desarrolladores solo son responsables del componente o área específica que se les asigna, pero los evaluadores entienden el funcionamiento general del software, cuáles son las dependencias y los impactos de un módulo en otro módulo.

  1. MITO : Control de calidad = Pruebas. HECHO : Las pruebas son solo un componente del control de calidad del software. El control de calidad incluye otras actividades como las revisiones.
  2. MITO : El objetivo de las pruebas es garantizar un producto 100% libre de defectos. HECHO : El objetivo de las pruebas es descubrir tantos defectos como sea posible mientras se garantiza que el software cumpla con los requisitos. Identificar y deshacerse de todos los defectos es imposible.
  3. MITO : La prueba es fácil. HECHO : Las pruebas pueden ser difíciles y desafiantes (a veces, incluso más que la codificación).
  4. MITO : cualquiera puede probar. HECHO : Las pruebas son una disciplina rigurosa y requieren muchos tipos de habilidades.
  5. MITO : No hay creatividad en las pruebas. HECHO : La creatividad se puede aplicar al formular enfoques de prueba, al diseñar pruebas e incluso al ejecutar pruebas.
  6. MITO : Las pruebas automatizadas eliminan la necesidad de pruebas manuales. HECHO : 100% de automatización de prueba no se puede lograr. Las pruebas manuales, hasta cierto nivel, siempre son necesarias.
  7. MITO : cuando un defecto se desliza, es culpa de los probadores. HECHO : La calidad es responsabilidad de todos los miembros / partes interesadas, incluidos los desarrolladores, de un proyecto.

Aquí hay algunos mitos para ti:

Mito # 1 La prueba es aburrida

La mayoría de las personas que se dedican a las pruebas pueden decir que las pruebas son rutinarias. La razón de tales juicios radica en el hecho de que esas personas no tienen ninguna satisfacción con su trabajo. Acordemos que estar satisfecho con el trabajo de uno es uno de los principales factores para ser una persona exitosa. El mito dado, sobre las pruebas como una actividad aburrida y monótona, está cubierto en los medios de comunicación. De hecho, los evaluadores se enfrentan a muchos desafíos nuevos y emocionantes todos los días.

Mito # 2 La prueba es fácil

La prueba es una artesanía difícil de dominar, lo que sería difícil para una persona promedio. Según Patrick Coupland de Google: “Los evaluadores aman su trabajo y lo hacen bien”.

Mito # 3 Los probadores solo buscan errores

Sí, los evaluadores buscan errores en varios programas y aplicaciones, pero no es su única actividad. Es una mirada demasiado limitada al trabajo de los evaluadores como una profesión que lo subestima a los ojos de los usuarios. Los probadores son expertos en sistemas, aplicaciones o productos que prueban. A diferencia de los desarrolladores, que son responsables solo de una función o característica particular, los probadores son responsables del funcionamiento del sistema en su conjunto. Los probadores entienden la importancia del producto, el impacto del medio ambiente en su efectividad. Saben cómo usar un producto con el máximo impacto.

Aquí encontrará más 5 mitos sobre los servicios de SQA

Mito 1: es el error del equipo de prueba que se perdió el defecto.

Mito 2: Las pruebas son fáciles y cualquiera puede probar el software.

Mito 3: El equipo de prueba solo es responsable de garantizar la calidad.

Mito 4: Podemos probar todo y podemos tener un software 100% libre de errores después de la prueba.

Mito 5: La automatización de pruebas reemplazará a los probadores manuales y podemos automatizar todo.

Mito 6: los desarrolladores no necesitan tener que probar, hay control de calidad para detectar errores.

Mito 7: los probadores de software se pagan menos que los desarrolladores. No hay oportunidades de crecimiento si elijo las pruebas de software como mi carrera.

Consulte este artículo para obtener más detalles: 7 MITOS SOBRE LAS PRUEBAS DE SOFTWARE

More Interesting

Si un grupo de desarrolladores dice que puede completar un proyecto en 8 semanas, ¿cuál es el número de semanas más realista que debo esperar?

Tengo una idea para Windows. ¿Con quién puedo discutirlo?

¿Es el aprendizaje en profundidad de tecnologías particulares una pérdida de tiempo en ingeniería de software?

¿Cuál es el estado actual de la técnica con respecto al porcentaje de cobertura de código óptimo para las pruebas unitarias?

¿Qué herramientas utilizó Mark Zuckerberg para construir Facebook?

¿El modelo en cascada (ingeniería de software) es adecuado para proyectos cuyos requisitos cambian constantemente o no se especifican correctamente y por qué?

Cómo evaluar el esfuerzo de implementación y los costos en un nuevo proyecto de desarrollo de software

¿Cuál debería ser el proceso de control de calidad para bloqueos reportados para aplicaciones móviles?

¿Por qué y cómo usan los ingenieros eléctricos C ++?

¿Por qué los ejecutables producidos con compiladores que no sean C / C ++ son más lentos que los producidos con C / C ++?

¿Cuál es una buena manera de leer CLRS? Me encuentro perdiendo interés después de leer un par de páginas seguidas, probablemente debido a que el texto es demasiado formal.

¿Existe alguna correlación entre la capacidad del desarrollador y el eclipse vs vim?

¿Los programadores mediocres 1x ayudan a mantener bajo el salario de los programadores 10x?

Tengo 4.5 años de experiencia en desarrollo de software con .Net. ¿Qué es un consejo profesional?

¿Cómo convertirse en un ingeniero de software exitoso ahora? Estoy en la clase 10