Realizar pruebas tempranas y frecuentes

Detectar los defectos en la fase más temprana posible es la forma menos costosa de asegurar la calidad del software.Kent Beck y Cynthia Andres han escrito que el dilema que se plantea al desarrollar software es que los defectos son caros, pero eliminarlos también lo es.Sin embargo, la mayoría de los defectos acaban costando más de lo que habría costado evitarlos. (Programación extrema explicada: Cambio de abrazo) Los procedimientos recomendados y las herramientas pueden ayudarle a minimizar el costo de evitar y corregir defectos manteniendo la calidad del proyecto en el ciclo de vida.

El equipo puede calibrar en todo momento y con mayor precisión la calidad del proyecto si los defectos se detectan y se corrigen y se comprueban las correcciones.Al realizar pruebas con frecuencia, el equipo y las partes interesadas pueden mantenerse al corriente del estado actual del código y tomar decisiones documentadas a lo largo del proyecto.En última instancia, es importante poder responder a la pregunta "¿Se puede lanzar esta versión?" y entender las repercusiones para las personas que usan el software.

En este tema, se recomiendan los siguientes procedimientos:

• Cree un conjunto de pruebas unitarias automatizadas para cada clase y para la API de cada componente principal.Escribir pruebas unitarias debe ocupar aproximadamente un 40% del tiempo de los miembros del equipo.Para obtener más información, vea Crear pruebas automatizadas mediante Microsoft Test Manager.

• Cree pruebas para cada caso de usuario.Deben ser preferiblemente pruebas automatizadas.Para obtener más información, vea Crear pruebas para elementos de trabajo pendiente de productos, casos de usuario o requisitos.

• Cree directivas de protección que recuerden a los miembros del equipo que ejecuten las pruebas unitarias antes de proteger el código.Para obtener más información, vea Add Check-in Policies.

• Prepare una compilación continua o nocturna que ejecute el conjunto completo de pruebas.

• Supervise la cobertura de las pruebas para asegurarse de que se somete a prueba todo el código.El objetivo debe ser una cobertura mínima de un 70%.Para obtener más información, vea Informe de Excel Vacíos en pruebas (Agile).

• Ejecute pruebas manuales cuando se aproxime el final de cada sprint.

El equipo puede administrar y ajustar estas actividades de prueba en el marco del proyecto gracias a la integración entre Microsoft Test Manager, Visual Studio Application Lifecycle Management (ALM) y Visual Studio Team Foundation Server.Para obtener más información, vea Probar la aplicación.

En este tema

• Estrategia de pruebas

• Planeación de pruebas

• Pruebas de aceptación

• Pruebas unitarias

• Desarrollo basado en pruebas y pruebas tempranas

• Pruebas manuales y automatizadas

• Notificar los resultados de pruebas

Estrategia de pruebas

El hecho de que el equipo consiga realizar correctamente las pruebas depende de varios factores, entre los que se incluyen el tamaño del equipo, los métodos que utiliza y las herramientas de administración de que dispone.Puede utilizar métodos ágiles para mejorar continuamente los resultados de pruebas.Aplicando este método, no solo se puede empezar a realizar pruebas con recursos muy limitados, sino también es posible ajustar las prácticas según corresponda durante todo el proyecto.

Aspectos que se deben tener en cuenta a la hora de introducir pruebas ágiles

Al introducir pruebas ágiles en una aplicación existente, el equipo puede empezar por pensar en la estrategia de pruebas, tanto en el nivel de sprint como en el nivel del proyecto.En el nivel de sprint, se puede incluir un conjunto de pruebas de aceptación que cubra todos y cada uno de los casos de usuario del sprint actual.En el nivel del proyecto, se pueden realizar pruebas que abarquen el proyecto completo, tales como las pruebas de extremo a extremo.Esto resulta útil para comprobar alguna funcionalidad que abarca dos o más sprints.Puede crear todo tipo de pruebas mientras el equipo compila el código durante un sprint.Estas pruebas incluyen pruebas unitarias, pruebas de aceptación y pruebas no funcionales, como las de rendimiento, de seguridad o de facilidad de uso.

Para aplicar los métodos de pruebas ágiles, en primer lugar se debe tener en cuenta el historial de la aplicación y el sistema que el equipo utiliza.Se pueden aplicar métodos de prueba ágiles a aplicaciones tanto nuevas como existentes.Se puede utilizar Microsoft Test Manager para crear un plan de pruebas para el proyecto completo y otro para cada sprint del proyecto.Estos planes de pruebas permiten que el equipo organice los casos de prueba en conjuntos de pruebas, a fin de ayudar a clasificar su ejecución y a entender sus resultados.Para obtener más información, vea Crear pruebas para elementos de trabajo pendiente de productos, casos de usuario o requisitos.El equipo puede utilizar Visual Studio ALM para agrupar los casos de prueba en conjuntos de pruebas mediante varios métodos:

• Crear y administrar un grupo estático de casos de prueba.

• Utilizar una consulta para crear y administrar un grupo dinámico de casos de prueba (es decir, buscar los casos de prueba según su prioridad).

• Agregar un caso de usuario o un requisito a un plan de pruebas, cuando los casos de prueba tengan un vínculo al requisito.

• Copiar un conjunto de pruebas existente de otro plan de pruebas.

Para obtener más información, vea Organizar casos de prueba mediante conjuntos de pruebas.

En segundo lugar, se debe tener en cuenta la capacidad para realizar pruebas con el código.Para averiguar cuál es, es preciso entender la arquitectura y los modelos de la aplicación.Si se utilizan modelos como Model View Controller (MVC), Model View ViewModel (MVVM) o Model View Presenter (MVP), se pueden aislar determinadas funciones y ejecutar pruebas funcionales sin la repercusión negativa de las pruebas de la interfaz de usuario.Sin embargo, esto no siempre representa la situación real.Por ejemplo, no se puede aislar la funcionalidad de las partes de refactorización de la aplicación. Por otra parte, a determinadas áreas del código únicamente se puede llegar a través de los controladores de eventos de interfaz de usuario o de red.Si se desea mejorar de forma significativa la calidad de las pruebas, se ha de incrementar el porcentaje de código que se puede probar.Para obtener más información sobre estos modelos, vea ASP.NET Model View Controller (MVC).

En tercer lugar, se deben tener en cuenta las capacidades del equipo antes de implementar pruebas ágiles.Es importante que algunos miembros del equipo puedan crear pruebas unitarias al implementar las funcionalidades.Algunos miembros del equipo deberían poder crear y definir los casos de uso manuales y pruebas de flujo de trabajo si están familiarizados con las reglas de negocio de la aplicación.Además, otros miembros del equipo deberían poder crear pruebas automatizadas y más detalladas basadas en estas pruebas manuales si cuentan con las habilidades técnicas necesarias.

Cómo administrar el ciclo de vida de las pruebas

La realización de pruebas es un proceso reiterativo que abarca toda la duración del proyecto.Tenga en cuenta los siguientes pasos:

1. Defina objetivos de prueba inequívocos y asegúrese de que todo el equipo los acepta.Según estos objetivos, determine la estrategia de pruebas.Por ejemplo, su estrategia podría ser "Las pruebas se realizarán antes de cada protección, las pruebas unitarias tendrán un 70% de cobertura de código y cada caso de usuario tendrá al menos una prueba automatizada".

2. Defina el plan de pruebas basándose en los casos de usuario del proyecto, las hipótesis de diseño y los requisitos no funcionales en el sprint actual.

   1. Puede agregar casos de usuario al trabajo pendiente y planearlos para los próximos sprints.Cada plan de pruebas debe corresponder al menos a un sprint y, por consiguiente, debe haber casos de prueba para todos los casos de usuario del sprint.

3. Defina y compile casos de prueba, tales como pruebas de aceptación, unitarias, funcionales y de rendimiento.

4. Agrupe los casos de prueba en conjuntos de pruebas.Estos conjuntos de pruebas se pueden enmarcar en los planes de pruebas definidos que ayudan a orientar los esfuerzos de realización de pruebas.

5. Empiece a ejecutar los conjuntos de pruebas y los casos de pruebas que contienen repetidamente a lo largo de un sprint.Empiece a ejecutar las pruebas desde el principio del sprint y siga agregando casos de prueba a los conjuntos de pruebas.Si desea identificar condiciones de prueba y situaciones importantes, puede aplicar las pruebas exploratorias y mantener conversaciones frecuentes en el seno del equipo.

6. Asegúrese de que se han superado todas las pruebas de aceptación de un caso de usuario antes de establecer su estado en Completado.

Aunque el flujo de trabajo puede exigir mucha más implicación, según el desglose del software, la ilustración anterior captura la esencia de un flujo de trabajo entre los componentes principales.

• El código genera compilaciones.

• El trabajo definido, los planes de pruebas y la calidad de las compilaciones influyen en el código.

• Los objetivos planeados y otros aspectos del proyecto que no se muestran en esta ilustración influyen en los planes de pruebas, los conjuntos de pruebas y los casos de prueba.

• Los cambios del código pueden afectar a los casos de prueba.

Corregir errores

1. Los errores se deben solucionar cuanto antes.Un error grave significa que no se han completado los casos de usuario afectados.

2. Cree elementos de trabajo de error para los errores que se detectan a través de pruebas u otras actividades.Defina la gravedad del error para indicar el grado en que afecta a los casos de usuario.Una gravedad alta (por ejemplo, 0 ó 1) indica que no se implementan importantes casos de usuario o que los usuarios deben aplicar soluciones alternativas significativas para lograr su objetivo.Una gravedad baja (por ejemplo, 3) indica que los usuarios pueden alcanzar sus principales objetivos sin tener que realizar ningún trabajo adicional.

3. Trabaje con los demás miembros del equipo a fin de decidir un plan de acción para cada error.

4. Resuelva los errores en cuanto se corrijan.El error debe asignarse a otra persona para que lo compruebe.Compruebe y cierre los errores lo antes posible.

5. Realice un seguimiento del estado de los errores.En la reunión retrospectiva al final de cada iteración, revise el informe Tendencias de errores y aborde las razones de cualquier incremento inusual.Para obtener más información, vea Informe Tendencias de errores.

Planeación de pruebas

La planeación de pruebas es el proceso consistente en ayudar al equipo a entender el panorama global del proyecto y en preparar al equipo para todos los tipos de pruebas.Las pruebas ágiles se inician en el nivel de sprint.En cada sprint, el equipo crea pruebas para comprobar los casos de usuario que se han compilado en ese sprint.El equipo realiza las pruebas que se crearon en el sprint actual y el sprint anterior.A lo largo del proyecto, se crean numerosas pruebas que abarcan todas las funcionalidades.En la siguiente ilustración se muestra una plantilla para los planes de pruebas del proyecto.

Crear un plan de pruebas para cada sprint y para el proyecto

Gracias a las características de prueba de Visual Studio ALM, el equipo puede planear, organice, ejecutar y notificar las pruebas de forma incremental.El equipo puede crear una plantilla para los planes de pruebas y los miembros del equipo pueden rellenar los conjuntos de pruebas.En un plan de pruebas, el equipo puede identificar en qué puntos se deben utilizar casos de prueba manuales o automatizados.

Para cada sprint del proyecto, se puede empezar a crear un plan de pruebas.Con este plan, el equipo se puede centrar en comprobar la funcionalidad del sprint actual.Si bien el plan está vacío al principio, se puede utilizar como marcador de posición para los conjuntos de pruebas.A continuación, se pueden organizar los casos de prueba en los conjuntos de pruebas apropiados.Es importante crear estos casos de prueba al principio y a lo largo del sprint para recibir con puntualidad los comentarios de las partes interesadas del proyecto.

También puede crear un plan de pruebas que abarque todo el proyecto.Los planes de pruebas del proyecto se pueden utilizar para fusionar las pruebas de los sprints anteriores y organizar conjuntos de pruebas que se apliquen al proyecto completo.Se deben continuar ejecutando los conjuntos de pruebas de regresión, porque es importante para mantener la estabilidad y la fluidez cuando el equipo compila proyectos de mayor tamaño.Sobre todo cuando se trabaja con equipos mayores y distribuidos que carecen de proximidad, los conjuntos de pruebas de regresión pueden detectar errores debidos a cambios que tienen una repercusión en cascada.Si no se implementan las medidas oportunas, estos errores son muy difíciles de detectar y podrían descubrirse en fases tardías del ciclo o incluso después de la entrega.

Pueden que algunos equipos deseen definir un plan de pruebas que abarque el proyecto completo.Este tipo de planes de pruebas permite comprobar funcionalidades relacionadas en varios sprints y contener conjuntos de pruebas que se ejecuten a lo largo del proyecto.Por ejemplo, se puede probar una característica que solo abarque los casos de usuario en todos los sprints cuando se haya completado la característica entera.

Definir pruebas de aceptación antes de un sprint

Antes de un sprint se deben definir las pruebas de aceptación.Estas pruebas de aceptación pueden ayudarle a determinar si un caso de usuario está completo.Puede realizar el seguimiento de los casos de prueba de aceptación creando un conjunto de pruebas denominado Pruebas de aceptación en un plan de pruebas para cada sprint.Para obtener más información, vea Pruebas de aceptación más adelante en este tema.

Compilar pruebas unitarias durante un sprint

El equipo debe compilar las pruebas unitarias durante un sprint.Las pruebas unitarias permiten comprobar el rendimiento del código, como el costo de tiempo y recursos que se utilizan para ejecutar el código.Otros tipos de pruebas, como las no funcionales (es decir, de rendimiento y de seguridad) se deben compilar y agregar a los conjuntos de pruebas adecuados.Estos conjuntos de pruebas se deben organizar de forma que se pueda identificar su costo con facilidad.

Enfocar las pruebas en áreas de gran uso

Entender cuáles son los puntos de gran variabilidad del software ayuda a determinar dónde se pueden encontrar las zonas problemáticas.Los datos proporcionados por el usuario, el entorno donde se ejecuta el software, la red y el hardware son ejemplos de variables de configuración que permiten al equipo detectar las zonas problemáticas del software.Si una condición casi nunca se produce o existe un número intrincado de condiciones que se pueden producir durante una prueba, el valor de la prueba disminuye, pero la posible repercusión de un defecto es muy alto.En general, es deseable aislar las funcionalidades cuando sea posible.Probar situaciones de gran repercusión también es importante.Para obtener más información sobre cómo administrar las configuraciones mediante Microsoft Test Manager, vea Configuraciones de prueba: especificar las plataformas de prueba.

Para los proyectos existentes, supervise las áreas que tienen el mayor número de defectos y determine por qué existen esos defectos.Además, supervise la renovación de código, porque esta área podría pasar por alto las hipótesis subyacentes.Algunos motivos para que existan defectos de código incluyen la dificultad de administrar no solo los estados (por ejemplo, la red y la interfaz de usuario) sino también el código.

Pruebas de aceptación

Las pruebas de aceptación comprueban los casos de usuario.Estas pruebas no solo le permiten asegurarse de compilar correctamente lo que el cliente necesita a lo largo del ciclo de vida del proyecto, sino también de consolidar la confianza del cliente y de mostrar las responsabilidades que ha aceptado.Para obtener más información, vea la siguiente página web: Acceptance Test Engineering Guide.

Cómo comenzar a usar las pruebas de aceptación

Abra Microsoft Test Manager y, a continuación, cree un conjunto de pruebas denominado Pruebas de Aceptación en el plan de pruebas.El equipo debe tener al menos un conjunto de pruebas que agrupe las pruebas de aceptación para cada sprint. Para obtener más información, vea Definir un plan de prueba.

Migrar de pruebas manuales a pruebas automatizadas

Las pruebas manuales son más fáciles de definir que las pruebas automatizadas pero su ejecución es más costosa.Por consiguiente, se recomienda comenzar con pruebas manuales y reemplazar gradualmente las más importantes por pruebas automatizadas.

En primer lugar, empiece por compilar un conjunto de prueba manuales que comprueben cada caso de usuario definido para el sprint.Puesto que al principio de un sprint no hay código, un caso de prueba debe describir acciones de alto nivel asignadas a las partes de un caso de usuario.Por ejemplo, un paso de un caso de prueba puede ser "En calidad de usuario autenticado, hacer…" Empezar por un caso de prueba manual permite al equipo definir con rapidez las pruebas de aceptación idóneas antes de iniciar el sprint.

En segundo lugar, revise y actualice las pruebas de aceptación de modo que reflejen las experiencias concretas del usuario cuando el equipo tenga código que implemente casos de usuario en un sprint.Sin embargo, si el equipo no desea modificar el conjunto existente de pruebas de aceptación, puede importar las pruebas a un nuevo conjunto de pruebas y disponer así de un punto de partida para pruebas más detalladas.Por ejemplo, un paso de un caso de prueba más detallado puede ser "Escribir el nombre en el cuadro de texto Nombre de usuario y seleccionar el botón Iniciar sesión para iniciar sesión en la cuenta bancaria".

En tercer lugar, según las pruebas de aceptación, cree las pruebas de la interfaz de usuario (IU) codificada mediante la grabación de acciones.Para obtener más información, vea Generar una prueba de IU codificada a partir de la grabación de acciones existente.Las pruebas de IU codificadas pueden generar código más limpio si se crean pasos que aíslan funcionalidades.Puede ejecutar pruebas automatizadas a partir del plan de pruebas si adjunta la prueba de IU codificada a casos de la prueba manuales (para obtener más información, vea Cómo: Asociar una prueba automatizada a un caso de prueba).

Las pruebas manuales que se definieron al principio de un sprint pueden ayudarle a crear las pruebas automatizadas.Tanto las pruebas manuales como las automatizadas suponen un costo, porque las manuales las tiene que ejecutar una persona y las automatizadas se tienen que actualizar si cambia el código o la experiencia del usuario.Para obtener más información, vea Pruebas manuales y automatizadas más adelante en este tema.

¿Quién ejecuta los casos de prueba de aceptación?

El equipo, el propietario del producto y los clientes pueden ejecutar los casos de prueba de aceptación.El equipo debe ejecutarlos con tanta frecuencia como sea posible a fin de proporcionar una línea base en el conjunto de pruebas que es preciso superar en un sprint.El propietario del producto y el cliente pueden ejecutar también las pruebas de aceptación y exigir la comprobación para completar correctamente el sprint.

El equipo puede utilizar Microsoft Test Manager para ejecutar cada caso de prueba de aceptación y grabar una captura de pantalla de vídeo de los resultados de pruebas.De esta manera, puede obtener un registro visual de los resultados de pruebas y, además, compartirlos con sus clientes.Esto es útil cuando resulta difícil crear configuraciones necesarias (por ejemplo, configuraciones multiservidor).

Definir casos de prueba de aceptación junto con los casos de usuario

Los criterios de aceptación se pueden definir justo después de definir los casos de usuario.Con la definición de las pruebas de aceptación, puede ayudar al equipo a entender los criterios de aceptación del sprint actual planteados por el propietario del producto y los clientes.Dado que el cliente tiene que aceptar las pruebas de aceptación, es conveniente crear los casos de prueba de aceptación antes de iniciar el sprint.

Pruebas unitarias

Las pruebas unitarias son pruebas automatizadas que comprueban la funcionalidad en los niveles de componente, clase, método o propiedad.Las pruebas unitarias constituyen la base de las pruebas automatizadas y de regresión, que proporcionan estabilidad a largo plazo y la facilidad de mantenimiento futuro del proyecto.

¿Cómo ayudan las pruebas unitarias a modificar el diseño de la aplicación?

El proceso de crear pruebas unitarias mientras se compila el código probado ayuda a definir la forma del código.Es posible crear código que se pueda probar mediante pruebas unitarias.Las dificultades para crear pruebas unitarias para el código es señal de que el código se debería refactorizar.

¿Cómo se deben organizar las pruebas unitarias?

Cada miembro del equipo que escribe código debe crear las pruebas unitarias correspondientes a los componentes que compile y proteger el código de prueba unitaria en el control de versiones dentro de un proyecto de Visual Studio.Almacene los elementos de trabajo del caso de prueba en un conjunto de pruebas de comprobación de la compilación que se ejecutarán durante cada compilación por medio de la integración continua y también dentro del conjunto de pruebas que comprueba el caso de usuario correspondiente.

¿Cómo se administra la varianza de las pruebas unitarias sin tener que cambiar el código de prueba?

La varianza de las entradas de pruebas define las similitudes o diferencias entre las pruebas cuando se comprueba la funcionalidad del código del proyecto.Por ejemplo, al probar el componente de inicio de sesión de una aplicación web, se pueden proporcionar varios tipos de contraseñas para crear una cuenta de usuario.El sistema puede tener reglas relativas al orden y la combinación de los tipos de caracteres que se utilizan.

Visual Studio Test Professional proporciona capacidades para escribir pruebas unitarias basadas en datos y pruebas codificadas de IU.Para obtener más información, vea Cómo: Crear una prueba unitaria controlada por datos y Cómo: Crear una prueba de IU codificada controlada por datos.

Desarrollo basado en pruebas y pruebas tempranas

El desarrollo basado en pruebas (TDD) es una disciplina de diseño y programación en que cada línea de código se escribe en respuesta a una prueba que el programador escribe justo antes de codificar.La idea de convertirse en consumidor del código que se desea implementar es muy eficaz y mantiene una expectativa realista de cómo se debe utilizar y diseñar el código.

En TDD, el desarrollador trabaja con un gran número de pequeños incrementos.El desarrollo de cada pequeño incremento tarda entre unos minutos y unas horas.Normalmente, un gran número de esos incrementos constituyen un caso de usuario.El desarrollador protege las pruebas y el código cuando funciona el caso de usuario.El desarrollador trabaja según el siguiente ciclo:

1. Escribe una prueba automatizada de la que se espera que se ejecute correctamente cuando se escriba el incremento.

2. Comprueba que la nueva prueba no se ejecuta correctamente para asegurarse de que la prueba funciona.

3. Escribe código de modo que la prueba se supere.

4. Ejecuta la prueba para comprobar que funciona correctamente.

5. También ejecuta todas las demás pruebas en la misma área para asegurarse de que no se ha introducido ningún error.

6. Refactoriza el código, si es necesario, para mejorar su estructura sin agregar comportamiento alguno.Vuelve a ejecutar las pruebas para asegurarse de que el código sigue funcionando.

7. Repite todos estos pasos hasta que se implemente un caso de usuario completo.Cuando los incrementos anteriores se integran en un caso completo, agrega pruebas que comprueban todo el caso.

8. Protege el código de implementación y las pruebas unitarias.

Si está interesado en las ventajas de los métodos de pruebas tempranas, puede empezar por crear pruebas manuales (o de aceptación manuales).Estas pruebas manuales se pueden automatizar creando una prueba de IU codificada.(Para obtener más información, vea Cómo: Generar una prueba de IU codificada mediante la grabación de la aplicación que se prueba.) También se pueden crear pruebas de integración que utilizan el marco de pruebas unitarias de Visual Studio ALM para comprobar la funcionalidad que se implementa.Los grupos de casos de prueba que se crean al principio de la iteración se ejecutan temprano en la iteración para intentar comprobar la funcionalidad y buscar los errores.Estos conjuntos de pruebas y casos de prueba se pueden ejecutar continuamente a modo de pruebas de regresión a lo largo de la vida del proyecto.La continua ejecución de estas pruebas, ayuda a asegurarse de que los errores que han encontrado y la funcionalidad que se ha comprobado al principio de la iteración no se vean afectados por los cambios realizados más adelante en el proyecto.

Utilizar pruebas unitarias para la integración continua

Las pruebas unitarias que se crean utilizando las pruebas tempranas deben organizarse en el interior del conjunto de pruebas del sprint actual y el caso de usuario.Estas pruebas unitarias se pueden promover al plan de pruebas del proyecto en su conjunto y ejecutarse periódicamente por el equipo y en el seno del ciclo de integración continua.Las pruebas unitarias también pueden actuar como base para las pruebas de integración, carga y rendimiento.

Las pruebas unitarias que se crean al principio se pueden utilizar como parte de la integración continua.Para obtener más información sobre cómo ejecutar pruebas durante una compilación, vea TestToolsTask Task.

Utilizar la virtualización para administrar configuraciones de pruebas

Para ejecutar las pruebas unitarias, puede crear un conjunto de entornos que sean imágenes administradas de Hyper-V en Microsoft Test Manager. Para obtener más información sobre cómo ejecutar las pruebas automatizadas usando Microsoft Test Manager, vea Cómo: Ejecutar pruebas automatizadas en un entorno de laboratorio usando Microsoft Test Manager.

Pruebas manuales y automatizadas

Los casos de prueba automatizados y manuales son complementarios.Los equipos ágiles se esfuerzan por tener más casos de prueba automatizados porque promueven ejecuciones de pruebas frecuentes o continuas.Para ejecutar las pruebas continuamente, deben ejecutarse con rapidez y con frecuencia, lo que resulta difícil de lograr con las pruebas manuales.

Hay varios aspectos que se deben tener en cuenta al decidir la distribución de casos de prueba manuales y automatizados.

¿Cómo influyen las habilidades de la organización en la distribución de tipos de pruebas?

El propietario del producto ayuda a definir los casos de usuario del proyecto y debe contribuir también a la creación de las pruebas de aceptación.Es probable que el propietario del producto no genere pruebas codificadas, pero cuenta con conocimientos significativos del dominio del negocio.Por tanto, los casos de prueba definidos por el propietario del producto se situarán en el nivel del vocabulario y las reglas de negocios.Por ejemplo, un propietario del producto de una empresa transportista especificará los distintos medios de transporte utilizados en la empresa (por ejemplo, camión, tren, avión, barco, o una combinación de ellos).A continuación, el propietario del producto puede definir varios casos de prueba que ejercitan las distintas posibilidades.Para estas pruebas manuales, es importante especificar el número mínimo de pruebas que ejercitan las diferentes opciones (en este caso, los medios de transporte).

Los miembros del equipo que generan el código pueden compilar pruebas de IU codificadas, que se pueden basar en las pruebas manuales o ser independientes de las demás pruebas.Para obtener más información, vea How to: Generate a Coded UI Test by Recording the Application Under Test.Los miembros del equipo con capacidad para administrar y desarrollar código de proyecto deben darle soporte a las pruebas de IU codificadas.

¿Cuándo se deben convertir las pruebas manuales en pruebas automatizadas o es preferible crear pruebas automatizadas desde el principio?

Se pueden compilar pruebas automatizadas cuando se prevé ejecutar pruebas repetidamente para mantener la estabilidad del código.Es importante tener en cuenta el esfuerzo que supone la creación de pruebas automatizadas porque la inversión en la automatización afecta a los recursos del equipo.Crear pruebas automatizadas cuando la renovación del código es escasa produce una mayor rentabilidad de la inversión (ROI), porque las pruebas se renuevan menos.Sin embargo, crear la automatización desde el principio aporta valor porque ayuda a detectar los problemas en la lógica y el diseño.En ambos casos, se deben tener en cuenta los recursos que se necesitan para el código de pruebas automatizadas.

Una vez se ha decidido que es necesario automatizar un conjunto de pruebas, se debe avanzar para completar la automatización lo antes posible, porque entre sus ventajas se incluye la administración de la estabilidad del código.La estabilidad y la cantidad de defectos que se encuentran al escribir la automatización afectará al esfuerzo que se necesita para completarla.En definitiva, el equilibrio entre pruebas manuales y automatizadas se refiere a determinar las prioridades relativas a qué tipos de pruebas es preciso compilar y ejecutar durante la vida del proyecto.

¿Qué tipos de pruebas se automatizan?

Pruebas unitarias

Las pruebas unitarias comprueban la funcionalidad del código o por medio de un proceso como TDD.Las pruebas unitarias son importantes porque ayudan a mantener la estabilidad y las dependencias en el código.El TDD también tiende a generar un mejor diseño con dependencias y una definición correcta de las capas, porque ayuda a entender el diseño desde la perspectiva del consumidor de código.

Pruebas de carga

Se pueden crear pruebas de carga basadas en casos de prueba automatizada existentes, o se pueden crear pruebas que generen tipos concretos de cargas en aplicaciones o servicios.Para obtener más información sobre cómo utilizar controladores del agente de prueba y agentes de prueba para generar cargas de prueba simuladas, vea Cómo: Ejecutar una prueba mediante controladores y agentes de pruebas.

Para obtener más información acerca de las pruebas de carga con Visual Studio ALM, vea la página siguiente del sitio web de Microsoft: Comprender las pruebas de carga.

Pruebas de integración continua

Se puede usar la integración continua con Visual Studio ALM para que ayude a asegurarse de que todo el código desarrollado y protegido funciona correctamente con el código existente.La integración continua es fundamental a medida que aumentan el equipo y el código base.Se puede definir un tipo de compilación que incluya parámetros de prueba y especificar qué pruebas se ejecutarán después de completar la compilación.Para obtener más información sobre cómo definir una compilación que ejecuta pruebas, vea Definir un proceso de compilación basado en la plantilla predeterminada.

¿Qué tipos de pruebas se pueden automatizar?

Pruebas de configuración

Realizar pruebas en varios entornos instalados puede ser una tarea muy laboriosa.Microsoft Test Manager proporciona funciones para ejecutar conjuntos de pruebas en distintas configuraciones mediante máquinas virtuales o equipos físicos.Para obtener más información sobre cómo ejecutar pruebas y recopilar datos en varios entornos, vea Configurar máquinas de pruebas para ejecutar pruebas o recopilar datos.

Pruebas de interfaz de usuario

Visual Studio ALM tiene funciones para crear pruebas automatizadas directamente para la interfaz de usuario.Para obtener más información sobre cómo crear pruebas de interfaz de usuario codificadas, vea Cómo: Crear una prueba de IU codificada.

Pruebas de instalación

Se pueden usar las funciones de laboratorio de Microsoft Test Manager para definir un grupo de configuraciones que se puede utilizar para comprobar si los programas de instalación de las aplicaciones funcionan tal y como se espera.

¿Qué barreras obstaculizan la automatización?

Capacidades del equipo

La creación de automatización exige que un subconjunto del equipo de pruebas aprenda a escribir código.Planee la curva de aprendizaje para la creación de la automatización y el diseño del código de pruebas.Al igual que sucede con el código de producción, el código de automatización se debe diseñar para lograr los objetivos deseados, tales como mantenimiento, facilidad de composición y longevidad.

Para obtener más información acerca de cómo se crean las pruebas automatizadas mediante Visual Studio Test Professional, vea Crear pruebas automatizadas mediante Microsoft Test Manager.

Renovación de código

El código que cambia con frecuencia es un objetivo móvil, y provoca efectos en cascada en el código de automatización de pruebas, porque también habrá que cambiarlo.Para evitar estos efectos en cascada, cree código de automatización de pruebas para los componentes y las interfaces que menos probabilidades presenten de cambiar.

Diseño del código

Los marcos de trabajo de código, tales como ASP.NET MVC y MVVM, guían los miembros del equipo para escribir código con el aislamiento necesario para comprobar las distintas partes que lo componen.El código que está enlazado estrechamente a la interfaz de usuario es difícil de probar porque puede exigir que el usuario interactúe con los controles de la interfaz de usuario.

¿Cuáles son las ventajas de los casos de prueba manuales?

Los casos de prueba manuales ofrecen las siguientes ventajas:

• Las pruebas manuales ayudan al equipo a detectar errores a través del proceso de exploración.

• Los casos de la prueba manuales son fáciles de definir, porque se puede definir el conjunto de pasos en cualquier abstracción, además de definir las condiciones que se prefieran de superación o error de las pruebas.

• Es muy fácil empezar a escribir casos de prueba manuales al principio del proyecto, antes de que se haya escrito código.Esto es importante durante el proceso de definición de las pruebas de aceptación.

• Si utiliza Visual Studio Test Professional, se pueden componer los casos de prueba con pasos compartidos, los cuales le ayudan a ahorrar tiempo al definir pruebas similares y le permiten al equipo reutilizar una sola versión de un subconjunto de la prueba.Utilizar pasos compartidos también resulta útil al cambiar los casos de prueba, porque un cambio en un paso compartido modifica automáticamente todos los casos de prueba que utilizan ese paso.Para obtener más información acerca de cómo se crean y utilizan los pasos compartidos, vea How to: Share Common Test Case Steps Using Shared Steps.

• Los casos de prueba manual pueden actuar como medio de comunicación en una fase temprana del proyecto o del sprint.

• Los casos de prueba manual pueden actuar como medio de documentación de un caso de prueba automatizada sin que nadie revise el código.

• Si utiliza Visual Studio ALM, al ejecutar pruebas manuales se pueden recopilar métricas de cobertura de código.

¿Cuáles son las carencias de los casos de prueba manuales?

Los casos de prueba manuales presentan las siguientes carencias:

• Puede resultar complicado definir los criterios de superación de una prueba, porque depende de la perspectiva y del lenguaje que se utilizan en su definición.Algunos lenguajes se pueden interpretar de otra forma, lo que puede dar lugar a errores.

• Ejecutar conjuntos de pruebas que incluyen casos de prueba manuales exige que una persona siga físicamente los pasos de prueba y notifique los resultados.Este proceso puede consumir mucho tiempo y, por consiguiente, puede exigir mayor número de miembros del equipo para ejecutar las pruebas o bien más tiempo para ejecutar el conjunto de pruebas.Con Visual Studio Test Professional, el equipo puede utilizar el "avance rápido de pruebas manuales", en el que las acciones se graban durante las pruebas y, a continuación, se pueden ejecutar en ejecuciones de pruebas ulteriores.

• Según la estabilidad del código, el tiempo y esfuerzo que se necesitan para ejecutar las pruebas varían.En consecuencia, ejecutar pruebas manuales puede afectar al flujo en el equipo.

• La principal carencia es la posibilidad de que se produzcan errores humanos al detectar errores con las pruebas manuales.El evaluador puede tener el error ante sí y no reconocerlo.

¿Cuáles son las ventajas de los casos de prueba automatizados?

Los casos de prueba automatizados ofrecen las siguientes ventajas:

• Las pruebas automatizadas ayudan a mantener la estabilidad y a encontrar las regresiones que se podrían producir debido a los cambios del código.

• Las pruebas automatizadas se pueden ejecutar en modo desatendido.

• Las pruebas automatizadas son software; se pueden diseñar y estar compuestas de otro código reutilizable.Esto las hace flexibles y fáciles de mantener.

• La automatización se puede ejecutar en varias configuraciones mediante Microsoft Test Manager.

• Se pueden recopilar métricas de cobertura de código al ejecutar las pruebas automatizadas.

¿Cuáles son las carencias de los casos de prueba automatizados?

Los casos de prueba automatizados presentan las siguientes carencias:

• Es necesario tener en cuenta e implementar las condiciones especiales mediante código.Cuando se crea y ejecuta la automatización, las condiciones adicionales se implementarán a medida que se detecten.

• Cuando el código se cambia o refactoriza, pueden generarse efectos en cascada que exijan el esfuerzo correspondiente para cambiar las pruebas automatizadas afectadas.

• El equipo puede verse afectado psicológicamente cuando los cambios de código dan lugar a errores en numerosas pruebas.Si estas pruebas se utilizan como marcas, puede que el equipo no quiera generar ninguna marca.

• Puede producirse una falsa sensación de seguridad si todas las pruebas se superan pero no están probando las condiciones correctas.Es importante realizar el mantenimiento de los conjuntos de pruebas y asegurarse de que comprueben las condiciones y los resultados correctos.

Notificar los resultados de pruebas

Desde la perspectiva ágil, los informes y las consultas a Team Foundation Server del estado actual de la calidad, según los errores o las métricas agregadas, constituyen la parte del bucle de comentario que permite al equipo realizar iteraciones y cambios en el código, el plan del proyecto y el plan de pruebas.Para obtener más información, vea Informe de progreso del plan de pruebas.

También puede supervisar el progreso del plan de pruebas mediante la característica de resultados del plan de pruebas en el Microsoft Test Manager.Los resultados del plan de pruebas incluyen gráficos y estadísticas numéricas sobre pruebas superadas, no superadas y activas.Además, los resultados del plan de pruebas incluyen gráficos detallados que muestran los tipos de error y los datos de resolución.Los resultados del plan de pruebas se pueden filtrar para incluir o excluir conjuntos de pruebas concretas en el plan de pruebas.También se pueden ver los resultados para los evaluadores individuales del equipo de pruebas.Para obtener más información, vea Cómo: Ver resultados de planes de pruebas mediante Microsoft Test Manager.

¿Qué niveles de pruebas se deben notificar al equipo?

Gracias al uso de Visual Studio Test Professional y de Team Foundation Server, el equipo puede entender el estado de la planeación y ejecución de las pruebas.Team Foundation Server almacena los planes de pruebas, conjuntos de pruebas, casos de prueba, resultados de pruebas y todos los demás datos asociados que se generan a lo largo del proceso de pruebas.Puede visualizar el proceso de pruebas y el de control de calidad si combina Microsoft Test Manager con informes y consultas de elementos de trabajo en Team Foundation Server. Puede utilizar Microsoft Test Manager para consultar errores en una variedad de estados.Los errores marcados como corregidos por otros miembros del equipo deben encontrarse en el estado Resuelto.Se pueden utilizar las compilaciones subsiguientes para comprobar los errores corregidos.Para obtener información sobre cómo comprobar si se ha corregido un error, vea Cómo: Comprobar si se ha corregido un error mediante el Administrador de pruebas de Microsoft.