unit-testing - software - pruebas automatizadas selenium

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

Estas son algunas de las formas en que las pruebas para desarrolladores son las más eficientes / más altas:

El desarrollador modifica una biblioteca compartida mientras trabaja en una función: dev tiene una idea de los posibles efectos secundarios que la validación de QA / no valida
El desarrollador no está seguro del rendimiento de la llamada a la biblioteca y escribe una prueba unitaria
El desarrollador descubre el caso de la ruta de uso no considerado en la especificación de que el código debe ser compatible, escribe código, actualiza especificaciones, escribe pruebas

Es discutible la cantidad de tareas de prueba que 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. Esta tormenta perfecta puede no ser alcanzable por un probador después del hecho.

¿Estamos hablando de QA 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.

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)?

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".

Tratamos de 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 unitarias las realizan los desarrolladores.

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

Estoy pegando mi respuesta a una pregunta en nuestro foro interno. Si tienes una hora más o menos ... escucha a Mary Poppendieck''s Competing sobre la base de Speed video. Recomendado

Nota (por probadores, me refiero al equipo de control de calidad)

Pruebas de desarrollador / unidad ________ = _______ Prueba de usabilidad y pruebas exploratorias

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

Pruebas de aceptación / cliente ___ = _____ Pruebas de propiedad

Imagina que es 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 / cualquier herramienta casera
Las pruebas de los clientes verifican que el código funcione como el cliente lo deseó. 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: las herramientas de regresión FIT también se encuentran aquí. Grabación-repetición

La mitad derecha utiliza mejor el tiempo y el esfuerzo de los buenos evaluadores. Por ejemplo, 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 propiedad nuevamente requieren humanos. Aquí puede consultar las propiedades exigidas por el cliente que su sistema requiere. por ejemplo, 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 evaluadores no deberían 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.

Mi postura general es que los evaluadores nunca deben encontrar errores de nivel de unidad (incluidos los casos de 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.

Entonces, supongo que la respuesta a su pregunta es que los evaluadores deberían probar todo lo que quieran. 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.

Cuando corresponda, los equipos de Control de calidad deberían poder realizar pruebas de Seguridad, Regresión, Usabilidad, Rendimiento, Estrés, Instalación / Actualización y no Desarrolladores

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

En el medio, todavía hay un poco de prueba por hacer

prueba de ruta de código completo
Pruebas de componentes
Pruebas de integración (de componentes)
Prueba de sistema (integración)
etc

La responsabilidad de estos se mezcla entre QA y Desarrollo en base a algún 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, descubran con qué se sienten más cómodos. Llevará algún tiempo, pero vale la pena.

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

Además, descubrí que recibimos una gran cantidad de control de calidad en la revisión del código, ya que las personas sugerirán casos extra y de esquina que deseen que se agreguen a las pruebas unitarias que se están revisando (junto con el código que prueban por supuesto) .

Hay 2 tipos de grupos 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.

Es la diferencia entre las pruebas de "caja negra" (donde se sabe lo que 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 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 compañía donde el equipo de control de calidad también son desarrolladores de software. (Eso reduce mucho el campo si le interesa adivinar la compañía.) 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, ciertos tipos Los verificadores de caja blanca que saben cómo escribir el código encuentran mejor los errores comunes (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 al control de calidad son parte del proceso desde la fase de diseño inicial, teóricamente pueden ayudar a impulsar 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 bajo esa luz, es menos una cuestión de usar desarrolladores para probadores que una especie de programación par desconectada en la que un desarrollador tiene énfasis 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 intercambien las tareas de revisión y prueba de códigos 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".