Pruebas de desarrollador vs.Pruebas en equipo de control de calidad: ¿cuál es la división correcta del trabajo?[cerrado]

Question

Mientras intento abogar por más pruebas de desarrolladores, encuentro el argumento "¿No es ese trabajo de QA?" se usa mucho.En mi opinión, no tiene sentido darle al equipo de control de calidad todas las responsabilidades de prueba, pero al mismo tiempo Spolsky y otros dicen que no se debería utilizar a los desarrolladores de $100 por hora para hacer algo que un evaluador de $30 por hora podría estar haciendo. .¿Cuáles son las experiencias de otras personas en una empresa con un equipo de control de calidad dedicado?¿Dónde debería trazarse la división del trabajo?

Aclaración:Me refiero al control de calidad como equipo de validación y verificación.Los desarrolladores no deberían realizar la validación (pruebas centradas en el cliente), pero ¿dónde está el punto de división de verificación (pruebas funcionales)?

Answer 1

Es la diferencia entre las pruebas de "caja negra" (donde se sabe qué se supone que debe hacer el código, pero no cómo funciona) y las pruebas de "caja blanca" (donde saber cómo funciona determina cómo se prueba).Las pruebas de "caja negra" es en lo que la mayoría de la gente piensa cuando se habla de Garantía de Calidad.

Trabajo para una empresa donde el equipo de control de calidad también son desarrolladores de software.(Eso reduce el campo mucho si quiere adivinar la empresa). Conozco la opinión de Joel y mi experiencia me lleva a estar parcialmente en desacuerdo:Por la misma razón que un hacker de "sombrero blanco" es más eficaz para encontrar agujeros de seguridad, ciertos tipos de errores son encontrados más eficazmente por los evaluadores de caja blanca que saben cómo escribir código (y, por lo tanto, cuáles son los errores más comunes, por ejemplo, en la gestión de recursos). problemas como pérdidas de memoria).

Además, dado que los desarrolladores orientados al control de calidad son parte del proceso desde la fase de diseño inicial, en teoría pueden ayudar a impulsar un código de mayor calidad durante todo el proceso.Idealmente, por cada desarrollador que trabaja en el proyecto con un enfoque mental en la funcionalidad, tenga un desarrollador opuesto con un enfoque mental en descifrar el código (y así mejorarlo).

Visto desde esa perspectiva, se trata menos de utilizar desarrolladores como evaluadores que de una especie de programación en pares desconectada en la que un desarrollador tiene énfasis en controlar la calidad.

Por otro lado, muchas pruebas (como la funcionalidad básica de la interfaz de usuario) francamente no necesitan ese tipo de habilidad.Ahí es donde Joel tiene razón.

Para muchas empresas, podría ver un sistema en el que los equipos de programación intercambian tareas de revisión y prueba de código para el código de los demás.Los miembros del equipo de Business Logic, por ejemplo, podrían realizar un recorrido ocasional probando y revisando el código para el equipo de UI, y viceversa.De esa manera, no "desperdiciará" el talento de los desarrolladores en pruebas de tiempo completo, pero obtendrá las ventajas de exponer el código a (con suerte) escrutinio y castigo de expertos.Luego, un equipo de control de calidad más tradicional puede encargarse de las pruebas de "caja negra".

Answer 2

Cuando sea apropiado, los equipos de control de calidad deben poder realizar pruebas de seguridad, regresión, usabilidad, rendimiento, estrés, instalación/actualización y no los desarrolladores.

Los desarrolladores deben realizar pruebas unitarias con cobertura de código para el código que se escribe como objetivo mínimo.

En el medio, todavía quedan bastantes pruebas por hacer.

• prueba de ruta de código completo
• Pruebas de componentes
• Pruebas de integración (de componentes)
• Pruebas del sistema (integración)
• etc.

La responsabilidad de estos aspectos se mezcla entre el control de calidad y el desarrollo, basándose en algún acuerdo mutuo sobre lo que tiene más sentido.Algunas pruebas de componentes solo se pueden realizar mediante pruebas unitarias, otras se prueban "suficientemente" durante las pruebas de integración, etc.

Hablad entre vosotros y averiguad qué es lo que cada uno hace más cómodo.Tomará algún tiempo, pero vale la pena.

Answer 3

Siempre debería haber algunas pruebas de desarrollador.Si un desarrollador está produciendo demasiados errores, entonces estará perdiendo el tiempo solucionándolos.Es importante que los desarrolladores no desarrollen la actitud de decir, bueno, si dejo un error, será detectado y tendré la oportunidad de solucionarlo.

Intentamos mantener un umbral para los errores producidos.Si se cruza este umbral durante las pruebas, el desarrollador es responsable de ello.Depende de usted decidir cuál es este umbral (para nosotros puede variar de un proyecto a otro).

Además, todas las pruebas unitarias las realizan los desarrolladores.

Answer 4

Solo he estado en la industria durante un año, pero según mi experiencia, los desarrolladores son responsables de las pruebas unitarias de sus funciones, mientras que el control de calidad es responsable de probar los escenarios.También se esperaría que el control de calidad probara cualquier condición límite.

Answer 5

Estoy pegando mi respuesta a una pregunta en nuestro foro interno.Si tienes una hora más o menos...Escuche la canción de Mary Poppendieck. Competir a base de Velocidad video. Recomendado

Nota (Por los evaluadores: me refiero al equipo de control de calidad)

Desarrollador/pruebas unitarias ________=_______ Pruebas de usabilidad y exploración pruebas

'==================================================================

Aceptación / Pruebas de clientes ___=_____ Pruebas de propiedad

Imagínese que es un cuadrado con cuatro cuadrantes.:)

La mitad izquierda debería estar automatizada.

• Las pruebas de desarrollador verifican que el código funcione como el codificador quería.Herramientas:NUnit/xUnit/cualquier herramienta casera
• Las pruebas de los clientes verifican que el código funcione como el cliente quería.Las pruebas deben ser muy fáciles de escribir y no deben requerir que el cliente aprenda .NET/Java.De lo contrario, el cliente no escribirá esas pruebas (aunque puede necesitar ayuda de un desarrollador).Fit, por ejemplo, utiliza tablas HTML que se pueden escribir en Word.Herramientas:Las herramientas de regresión de ajuste también se encuentran aquí.Grabación-reproducción.

La mitad derecha utiliza mejor el tiempo y el esfuerzo de los buenos evaluadores.p.ej.Ninguna prueba automatizada puede indicarle si el diálogo X es utilizable.Los humanos son mejores en esto que las máquinas.

• Usabilidad.Intente descomponer el sistema (capte escenarios de falla no controlados, ingrese valores nulos).Básicamente, detecta cosas que el desarrollador pasó por alto.
• Las pruebas de propiedad nuevamente requieren humanos.Aquí puede comprobar las propiedades exigidas por el cliente que requiere su sistema.p.ej.Rendimiento: ¿su cuadro de diálogo de búsqueda cumple con el tiempo de respuesta de 2 segundos?Seguridad: ¿alguien puede hackear este sistema?etc.Disponibilidad: ¿su sistema está en línea el 99,99 % del tiempo?

Los evaluadores no deberían perder tiempo ejecutando planes de prueba en la mitad izquierda.Es responsabilidad de los desarrolladores garantizar que el código funcione como el cliente y el desarrollador lo concibieron.De hecho, los probadores pueden ayudar al cliente a formular las pruebas de aceptación.

Answer 6

Las pruebas deben ser lo más automatizadas posible, lo que las convierte nuevamente en trabajo de desarrollo si los evaluadores escriben código que se agrega al conjunto de pruebas automatizadas.

Además, descubrí que realizamos mucho control de calidad en la revisión de código, ya que las personas sugerirán casos extremos y de esquina adicionales que desean agregar a las pruebas unitarias que se están revisando (junto con el código que prueban, por supuesto). .

Answer 7

Mi postura general es que los evaluadores nunca deberían encontrar errores a nivel de unidad (incluidos los casos límite).Los errores que los evaluadores encuentren deben estar a nivel de componente, integración o sistema.Por supuesto, al principio los evaluadores pueden encontrar errores de "camino feliz" y otros errores simples, pero estas anomalías deben usarse para ayudar a los desarrolladores a mejorar.

Parte de su problema podría ser utilizar desarrolladores de $100 dólares por hora y probadores de $30 por hora :}.Pero independientemente del costo, creo que sabiendo que los errores encontrados anteriormente en el ciclo de desarrollo son inevitablemente más baratos, probablemente aún ahorraría dinero si los desarrolladores realizaran más pruebas.Si tiene un equipo de desarrollo bien pagado y probadores de piratería, probablemente encontrará muchos de los grandes problemas obvios, pero se perderá muchos de los errores más oscuros que volverán a atormentarlo más adelante.

Entonces, supongo que la respuesta a tu pregunta es que los evaluadores deben probar tanto como tú quieras.Puede despedir a todos sus evaluadores y hacer que los desarrolladores realicen todas las pruebas, o puede contratar un ejército de evaluadores y dejar que los desarrolladores verifiquen lo que quieran.

Answer 8

Hay 2 tipos de grupos qa, los que quieren mantener el status quo.Siempre lo hicimos así.Naturalmente, odian y se deshacen de aquellos que intentan hacer las cosas más eficientes y, por tanto, van más allá de su zona de confort.Eso me pasó más de una vez.Desafortunadamente, los gerentes de control de calidad son tan incompetentes como sus equipos de control de calidad.Entonces, un gerente de control de calidad que ha estado administrando durante los últimos 6 años eliminará cualquier automatización e introducirá muchos procesos solo para justificar su existencia. Es responsabilidad de la alta dirección reconocer eso.Hay gente algo técnica qa sabe de herramientas.Lamentablemente un lenguaje de programación no es una herramienta, sino una visión.Trabajar con esas personas realmente depende de cuánto estén dispuestos a aprender y de cuánto esté dispuesta la gerencia a correr el riesgo de cambiar las cosas.Las pruebas deben escribirse de la misma manera que el código principal se escribe con una estructura orientada a objetos fácil de mantener.Creo que los desarrolladores deberían revisar las pruebas de calidad.La mayoría de las veces descubrí que la automatización no prueba nada.Desafortunadamente, un trabajo se considera de clase baja, por lo que los desarrolladores no se molestan.Yo mismo tengo suerte cuando recibo el apoyo de un desarrollador influyente en un grupo, que está dispuesto a explicar mis esfuerzos a un gerente.Desafortunadamente, sólo funciona la mitad del tiempo.En mi humilde opinión, los evaluadores deberían informar al gerente de desarrollo.Y todo el equipo debe asumir la responsabilidad de lo que realmente prueban las pruebas de calidad.

Answer 9

A continuación, se muestran algunas formas en las que las pruebas para desarrolladores son la más eficiente y la más rentable:

• El desarrollador modifica una biblioteca compartida mientras trabaja en una función: el desarrollador tiene información sobre los posibles efectos secundarios que el control de calidad/validación no tiene
• El desarrollador no está seguro del rendimiento de la llamada a la biblioteca y escribe una prueba unitaria
• El desarrollador descubre una ruta de caso de uso no considerada en las especificaciones que el código debe admitir, escribe código, actualiza las especificaciones, escribe pruebas

Es discutible cuántas tareas de prueba debe realizar el desarrollador en el tercer ejemplo, pero sostengo que es más eficiente para el desarrollador porque todas las minucias relacionadas de muchas capas de documentación y código ya están en su memoria a corto plazo.Es posible que un evaluador no pueda alcanzar esta tormenta perfecta después del hecho.

¿Estamos hablando de control de calidad o validación?Pienso en el control de calidad en términos de listas de verificación de inspección, aplicación de estándares de código, pautas de interfaz de usuario, etc.Si hablamos de validación, no tiene sentido que los desarrolladores dediquen mucho tiempo a crear y ejecutar casos de prueba formales, pero los desarrolladores deben proporcionar todos los fundamentos y la documentación de diseño necesarios para crear buenas pruebas.