Get best of the week

Libro "Cómo probar en Google" - versión electrónica gratuita

imagenHola habrozhiteli!

El libro describe cómo probar productos de software en Google: cómo se organizan los procesos, cómo se organizan los equipos, qué técnicas se utilizan, quién es responsable de la calidad. Los principios en los que se basa la prueba de Google se aplican a proyectos y empresas de cualquier tamaño. Los propios autores del libro trabajaron en productos de Google, creando herramientas de prueba, personalizando procesos y haciendo pruebas directamente.

El libro está dirigido a profesionales de la industria de desarrollo de software: especialistas en pruebas, programadores, gerentes.

Extracto. La reducción de riesgos


Rara vez es posible eliminar por completo los riesgos. Manejamos un automóvil, aunque esto es peligroso, pero ¿tenemos que ir a trabajar? En general, la posibilidad de un accidente no significa que sucederá y, muy probablemente, no sucederá nada terrible. ¿Por qué? Porque por nuestras acciones reducimos el posible riesgo. Por ejemplo, no manejamos en estado de ebriedad y no manejamos en condiciones de visibilidad insuficiente. Por lo tanto, reducimos los riesgos.

En el desarrollo de productos de software, lo más simple es evitar áreas de riesgo: cuanto menos código, menos riesgo. Pero además de usar el "hacha y el hacha", podemos hacer mucho más para reducir los riesgos:

  • , , .
  • -, , .
  • , .
  • .
  • , . , .

La solución específica depende de las características de la aplicación, de las expectativas del usuario con respecto a su seguridad y confiabilidad. Como evaluadores, nosotros, por supuesto, podemos participar en el proceso de reducción de riesgos, pero ciertamente estamos involucrados en el proceso de identificarlos. Comenzamos priorizando las características marcadas en rojo en la tabla. Queremos probar para reducir riesgos. Esto es importante: si no puede probar todo, primero pruebe lo más importante. Y lo más importante es que está más expuesto a los riesgos más graves.

En algunos proyectos, son los evaluadores quienes preguntan sobre la disponibilidad del producto para su lanzamiento. Es suficiente que un buen probador eche un vistazo al mapa de calor para determinar si aún vale la pena mantener el producto en el horno o si es hora de servirlo en la mesa. Si estamos hablando de lanzar un Google Labs experimental, entonces la presencia de zonas rojas de riesgo no es tan significativa, por supuesto, si no están relacionadas con la seguridad. Y si este es el lanzamiento de una nueva versión de Gmail, incluso las zonas amarillas son un grave peligro. Una gradación de color tan simple es clara para todos, incluso para los altos directivos.

Las preocupaciones sobre los riesgos disminuyen con el tiempo, y el gran volumen de pruebas exitosas es una buena señal de que los riesgos están en un nivel aceptable. Aquí nos beneficiamos de vincular casos de prueba a características de productos individuales y luego a atributos y componentes en la tabla de riesgos. El "análisis ACC" es ideal para este caso, y es por eso que creamos esta herramienta así como así.

Plan de prueba de recetas de James Whittaker en diez minutos


, , . , , — ? , , . Google, , -. , , : «», « » — « » ( ). ’, , - , .

— . -, , — , , ( ), , , . : , ,
?

- , , , . , — . : ?

- , - . . : -.

, : - . - , .

, . : . , , .
-, .

. : « , - ». , , . , , , , .

, , , (Google Docs, App Engine, Talk Video . .), .

, ACC-. , . — , — . , . - — . , , .

’, - . . ,
- .

, . , . 80% . ? , , ? , (, , ) . , , .

. -!


Google Test Analytics toma como base los criterios de evaluación de riesgos descritos anteriormente ("muy raro", "rara vez", "a veces", "a menudo"). Específicamente, no queremos convertir el análisis de riesgos en una tarea difícil, de lo contrario no se completará. No nos interesan los detalles matemáticos exactos, porque los números significan poco. Es suficiente saber que "A" es más arriesgado que "B", sin prestar atención a la importancia exacta de los riesgos. El simple conocimiento de qué oportunidad es más riesgosa que otra permitirá al administrador de pruebas distribuir de manera más eficiente el trabajo de los evaluadores. Y personas como Patrick Copeland pueden decidir fácilmente cuántos evaluadores asignar a cada equipo de desarrollo. Comprender los riesgos beneficia a toda la empresa.

El análisis de riesgos es un campo científico independiente respetado en muchas industrias. Utilizamos una versión simplificada de la metodología, pero esto no evita que nos interesemos en nuevas investigaciones para mejorar nuestro enfoque de las pruebas. Si desea obtener más información sobre el análisis de riesgos, comience con el artículo "Gestión de riesgos" en Wikipedia.

GTA ayuda a identificar riesgos, y las pruebas ayudan a reducirlos. El probador sirve como intermediario en este proceso. Puede realizar pruebas internas en algunas de las áreas más riesgosas o desarrolladores de tareas y desarrolladores en pruebas para que agreguen pruebas de regresión. Hay otras herramientas en su arsenal: pruebas de investigación, atracción de usuarios internos y beta y la fuerza de la comunidad externa.

Es responsabilidad del probador conocer todas las áreas en riesgo. Debe tratar de reducir los riesgos de cualquier manera que esté sujeta a él. Aquí hay algunas recomendaciones que encontramos útiles para tratar con los riesgos.

  1. Para las características más arriesgadas y los pares de atributos / componentes marcados en rojo, escriba un conjunto de historias de usuarios, escenarios de uso o una guía de prueba. En Google, la responsabilidad de las oportunidades más riesgosas recae en el probador. Puede coordinar su trabajo con colegas, usar diferentes herramientas, pero la responsabilidad personal aún recae en él.
  2. , . , GTA? ? ? . , , .
  3. , / , , . .
  4. — . , . , . , : «!», . , .
  5. , . , , . , « ?» « ?». Google , , .
  6. 6 , , , . ! .




, . , , , .

, , - . - , , , . , , . , , .

, , . -, - — !

— . - . — . Google , . -: Google Documents — , .

, , , . — .

No seremos demasiado defectuosos con las oportunidades de bajo riesgo. Podemos decidir que escribir casos de prueba para estas áreas es demasiado costoso. En cambio, podemos limitarnos a las pruebas de investigación o las pruebas de crowdsource. Para administrar el trabajo de los probadores de la comunidad externa, a menudo utilizamos el concepto de recorridos; estas son instrucciones de alto nivel para las pruebas de investigación. En pocas palabras, este enfoque le brinda a su solicitud los detalles que necesita. Por ejemplo, preguntando a la comunidad: "Realice un recorrido por FedEx para un conjunto de características de este tipo": obtendremos un resultado mucho mejor que simplemente dar la aplicación y esperar lo mejor. Determinamos de inmediato las características que deben probarse y damos instrucciones sobre cómo hacerlo.

Crowdsourcing




— . , , - ! , . . ?

, , . , , — , , -. , Chromium, . , , . , .

( ) — . , , . , , ? — .

, , , . , : -1000 , : Chrome, : 1 = 1000 20 = 50 . .

, , , . , , . Chrome, , , ( « Chrome»). . , . « , » , .

- — Google: , , . , . , , , (, uTest). .

Entonces, la fortaleza del análisis ACC es que obtenemos una lista de características del producto que pueden clasificarse por riesgo y asignarse a diferentes artistas. Los probadores que trabajan en el mismo proyecto pueden recibir diferentes conjuntos de capacidades de prueba. Los usuarios internos, los participantes del "veinte por ciento", los evaluadores, los evaluadores de la comunidad, los desarrolladores y los desarrolladores en las pruebas recibirán sus listas de características y, para alegría del evaluador, las áreas importantes se cubrirán con menos solapamiento que si solo entregáramos la solicitud para prueba para todos.

El trabajo del probador, en contraste con el trabajo del desarrollador en las pruebas, no termina con la entrada del producto.

» Descargar epub y pdf

More articles:


All Articles