Prueba de desarrollador vs. prueba de equipo de QA: ¿cuál es la división de trabajo correcta?

Question

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

Aclaración: Quise QA como un 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 sabe lo que se supone que debe hacer el código, pero no cómo funciona) y las pruebas de "caja blanca" (saber cómo funciona cómo lo prueba) . La prueba de "caja negra" es en lo que piensa la mayoría de la gente cuando menciona la garantía de calidad.

Trabajo para una empresa donde el equipo de QA también es desarrollador de software. (Eso reduce el campo mucho si le interesa 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 efectivo para encontrar agujeros de seguridad, los verificadores de caja blanca encuentran ciertos tipos de errores de manera más efectiva que saben cómo escribir código (y, por lo tanto, cuáles son los errores más comunes, por ejemplo, problemas de administración de recursos como pérdidas de memoria).

Además, dado que los desarrolladores orientados a la GC son parte del proceso desde la fase de diseño inicial, teóricamente pueden ayudar a conducir un código de mayor calidad durante todo el proceso. Idealmente, para cada desarrollador que trabaje en el proyecto con un enfoque mental en la funcionalidad, usted tiene un desarrollador opuesto con un enfoque mental en romper el código (y hacerlo mejor).

Visto desde esa perspectiva, no se trata solo de utilizar desarrolladores para probadores, sino de una especie de programación de par desconectada en la que un desarrollador hace hincapié en controlar la calidad.

Por otro lado, muchas pruebas (como la funcionalidad básica de IU) francamente no necesitan ese tipo de habilidad. Ahí es donde Joel tiene un punto.

Para muchas empresas, podría ver un sistema en el que los equipos de programación se comprometan con la revisión del código y las tareas de prueba para el código de los demás. Los miembros del equipo de Business Logic, por ejemplo, podrían gastar ocasionalmente un código de prueba y revisión para el equipo de UI, y viceversa. De esta forma no estás "malgastando" talento de desarrollador en pruebas de tiempo completo, pero estás obteniendo las ventajas de exponer el código a (con suerte) el escrutinio y el castigo de expertos. Entonces, un equipo de control de calidad más tradicional puede tomar la prueba de "caja negra".

Answer 2

Siempre debe haber algunas pruebas de desarrollador. Si un desarrollador está produciendo demasiados errores, entonces él/ella está perdiendo el tiempo más tarde para corregir esos errores. Es importante que los desarrolladores no desarrollen una actitud que diga, "bueno, si dejo un error, será atrapado y tendré la oportunidad de arreglarlo".

Intentamos mantener un umbral para los errores producidos. Si este umbral se cruza durante la prueba, entonces 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 de unidad son realizadas por los desarrolladores.

Answer 3

Llevo solo un año en la industria, pero en mi experiencia los desarrolladores son responsables de probar sus funciones unitarias, mientras que QA es responsable de probar los escenarios. También se espera que QA pruebe cualquier condición de delimitación.

Answer 4

Estas son algunas formas en que las pruebas de desarrollador es el más eficiente/rentabilidad más alta:

• desarrollador modifica una biblioteca compartida mientras se trabaja en una característica - dev tiene una idea de los posibles efectos secundarios que la GC/validación no hacer
• desarrollador no está seguro de los resultados de la llamada a la librería y escribe una prueba de unidad
• desarrollador descubre camino del caso de uso no se considera dentro de las especificaciones que el código debe ser compatible, escribe el código, especificación de actualizaciones, escribe prueba

Es discutible la cantidad de tareas de prueba que debe realizar el desarrollador en el tercer ejemplo, pero considero 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 brevedad. memoria de término Esta tormenta perfecta puede no ser alcanzable por un probador después del hecho.

¿Estamos hablando de control de calidad o validación? Pienso en QA siguiendo las listas de verificación de inspección, aplicación de estándares de código, pautas de UI, etc. Si hablamos de validación, no tiene sentido que los desarrolladores dediquen mucho tiempo a la creación y ejecución de casos de prueba formales, pero los desarrolladores debe proporcionar toda la documentación de diseño y justificación necesaria para crear buenas pruebas.

Answer 5

Estoy pegando mi respuesta a una pregunta en nuestro foro interno. Si tiene una hora más o menos ... escuche el video de Mary Poppendieck Competing on the basis of Speed. Recomendado

Nota (por los probadores - Me refiero al equipo de control de calidad)

desarrollador/Unidad de prueba ________ = _______ Usabilidad prueba exploratoria & prueba

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

Acepta ce/Customer tests ___ = _____ Prueba de propiedades

Imagine que se trata de un cuadrado con cuatro cuadrantes. :)

La mitad izquierda debe ser automatizada.

• Las pruebas de desarrollador verifican que el código funciona como el codificador lo quería. Herramientas: NUnit/xUnit/lo que sea herramienta casera
• Las pruebas del cliente verifican que el código funciona como el cliente lo quería. Las pruebas deben ser muy fáciles de escribir, no deben requerir que el cliente aprenda .NET/Java. De lo contrario, el cliente no escribirá esas pruebas (aunque es posible que necesite ayuda de un desarrollador). Ajustar, por ejemplo, utiliza tablas HTML que se pueden escribir en Word. Herramientas: FIT Las herramientas de regresión también se encuentran aquí. Grabación-repetición

La mitad derecha mejor utiliza el tiempo & esfuerzo de buenos probadores. 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 romper el sistema, (capture escenarios de falla no controlada, ingrese valores nulos). Básicamente atrapa cosas que el desarrollador perdió.
• Las pruebas de propiedades nuevamente requieren humanos. Aquí puede consultar las propiedades exigidas por el cliente que su sistema requiere. p.ej. Rendimiento: ¿su diálogo de búsqueda cumple con el tiempo de respuesta de 2 segundos? Seguridad: ¿alguien puede hackear este Sistema? Disponibilidad: ¿su sistema está en línea el 99.99% del tiempo?

Los comprobadores no deben perder tiempo ejecutando planes de prueba en la mitad izquierda. Esa es la responsabilidad de los desarrolladores de garantizar que el código funcione como el cliente y el desarrollador lo intentaron. Los evaluadores pueden de hecho ayudar al cliente a formular las pruebas de aceptación.

Answer 6

Mi opinión general es que los probadores nunca deben encontrar errores de nivel de unidad (incluidos los casos límite). Los verificadores de errores encuentran que debe estar en el componente, la integración o el nivel del sistema. Por supuesto, al principio los probadores pueden encontrar errores de "ruta feliz" y otros errores simples, pero estas anomalías deberían usarse para ayudar a los desarrolladores a mejorar.

Parte de su problema podría ser el uso de desarrolladores de $ 100 por hora y probadores de $ 30 por hora:}. Pero independientemente del costo, creo que sabiendo que los errores detectados anteriormente en el ciclo de desarrollo son inevitablemente más baratos, probablemente aún ahorrarías dinero haciendo que los desarrolladores tengan más pruebas. Si tienes un equipo de desarrollo altamente pagado y probadores de hackear, probablemente encontrarás muchos de los grandes problemas obvios, pero te perderás muchos de los errores más oscuros que volverán a perseguirte más adelante.

Por lo tanto, supongo que la respuesta a su pregunta es que los evaluadores deben probar tanto como usted quiera. Puede disparar todos los probadores y hacer que los desarrolladores realicen todas las pruebas, o puede contratar un ejército de probadores y dejar que los desarrolladores comprueben lo que quieran.

Answer 7

Cuando sea apropiado, los equipos de control de calidad deben ser capaces de llevar a cabo Seguridad, Regresión, usabilidad, rendimiento, estrés, Instalación/Actualización de la prueba y no Desarrolladores

los desarrolladores deben hacer las pruebas unitarias con el código de cobertura para el código que está siendo escrito como un objetivo mínimo.

en el medio, todavía hay un poco de pruebas para hacer

ruta de código completo de pruebas

pruebas de componentes

Pruebas de integración (de componentes)

sistema de pruebas

• (integración)
• etc

La respon La posibilidad de que se combinen entre QA y Desarrollo se basa en un acuerdo mutuo sobre lo que tiene más sentido. Algunas pruebas de componentes solo se pueden realizar mediante pruebas unitarias, mientras que otras se prueban "suficientemente" durante las pruebas de integración, etc.

Hablen entre ellos y descubran con qué se sienten más cómodos. Llevará algún tiempo, pero vale la pena.

Answer 8

Las pruebas deben ser tan automatizadas como sea posible, lo que lo convierte nuevamente en un trabajo de desarrollo si los evaluadores están escribiendo código que se agrega al conjunto de pruebas automáticas.

Además, descubrí que realizamos una gran cantidad de control de calidad en la revisión del código, ya que las personas sugerirán que se agreguen casos extra y esquineros adicionales a las pruebas unitarias que están siendo revisadas (junto con el código prueba por supuesto).

Answer 9

Hay 2 tipos de grupos de qa, aquellos que quieren mantener el status quo. Siempre lo hicimos. Naturalmente odian y se deshacen de aquellos que intentan hacer las cosas más eficientes y, por lo tanto, van más allá de su zona de confort. Eso me pasó más de una vez. Desafortunadamente los gerentes de qa son tan incompetentes como sus equipos de qa. Entonces un gerente qa que ha estado administrando durante los últimos 6 años matará cualquier automatización, introducirá muchos procesos solo para justificar su existencia. Esta es una responsabilidad superior de la administración para reconocer eso. Hay personas qa un tanto técnicas que conocen las 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 administración a correr el riesgo de cambiar las cosas. Las pruebas se deben escribir de la misma manera que se escribe un código principal estructura orientada a objetos fácil de mantener. Creo que los desarrolladores deberían revisar las pruebas qa. La mayoría de las veces encontré que la automatización no probaba nada. Desafortunadamente, el trabajo qa 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. Funciona solo la mitad de las veces, desafortunadamente. Los probadores en mi humilde opinión deben informar al gerente de desarrollo. Y todo el equipo debe asumir la responsabilidad de lo que las pruebas de qa realmente prueban.