archivo

Archivos diarios: agosto 6, 2012

Hay testing que requiere conocimiento del negocio, en muchos casos si la materia es complicada el conocimiento que se requiere es bastante profundo y no es algo que se pueda conseguir en dos ratos.

Este testing se podría realizar aplicando técnicas de testing exploratorio pero se requeriría un apoyo importante por parte del equipo de proyecto salvo que se disponga del tiempo suficiente para que el tester pueda aprender con el soporte adecuado lo necesario del negocio para realizar las pruebas.

Siempre está la posibilidad de que los casos de prueba vengan desde el equipo de proyecto (con el soporte si se requiere del equipo de testing) en cuyo caso bastará con seguirlos (esta mayor simplicidad al final es fruto de un mayor esfuerzo por parte de otras personas, por lo que al final el esfuerzo lo que hace es distribuirse, si bien no todas las combinaciones son igual de efectivas), combinándose con las exploraciones que se estimen oportunas sobre la aplicación.

Cuanto más complejo sea el sistema desde el punto de vista del negocio más proximidad se requerirá por parte del equipo de testing (o por personas claves de dicho equipo), más interesante resulta el soporte por parte del equipo de proyecto (nunca está de más tener ayuda si es necesario) y más interesante resulta la realización de pruebas por parte del área usuaria (no solo en el momento de la aceptación, sino lo antes posible).

El testing no solo es encontrar bugs sino también localizar discrepancias con respecto a las expectativas de los usuarios.

La opinión de Brian Marick al respecto es la siguiente: “Para encontrar los bugs que los clientes ven – que son importantes para los clientes – necesitas escribir tests que verifiquen las áreas funcionales imitando tareas típicas de los usuarios. Este tipo de testing se denomina testing de escenarios, testing basado en tareas o testing de casos de uso”.