Construir casos de prueba que no apesten (y cómo evitar errores comunes)
Las pruebas de software son un componente crucial del ciclo de vida del desarrollo de software. Sin ellas, podría pasar por alto problemas de funcionalidad o fallos importantes de usabilidad que acaban frustrando a sus usuarios finales. Pero no todos los casos de prueba son iguales. Escribir casos de prueba eficaces y de alta calidad es tan importante como probar sus aplicaciones. De hecho, los casos de prueba deficientes pueden dar lugar a un proceso de prueba que es poco más eficaz que no probar en absoluto.
Entonces, ¿qué tienen en común los casos de prueba mal escritos? ¿Cómo pueden los profesionales de las pruebas de software escribir casos de prueba de calidad y evitar los errores más comunes? Para averiguarlo, buscamos en la web los mejores consejos para escribir casos de prueba eficaces y nos pusimos en contacto con un panel de profesionales del desarrollo y probadores de software y les pedimos que opinaran sobre esta cuestión:
«¿Qué tienen en común los casos de prueba mal construidos (y cómo pueden los desarrolladores evitar estos errores)?»
Conozca a nuestro panel de expertos en pruebas de software:
|
|
|
Descubre lo que nuestros profesionales tenían que decir leyendo sus respuestas a continuación.
Avaneesh Dubey
@qsometests
Avaneesh Dubey es el CEO de Qsome Tech. Su carrera está salpicada de un fuerte conjunto de innovaciones en diferentes aspectos del negocio: Personas, Procesos y Tecnología. Ahora, está construyendo Qsome Tech como un innovador de vanguardia en el área de la Calidad del Software.
«Hay algunas cosas que muchos casos de prueba mal construidos tienen en común…»
1. Demasiado específicos: ejecutan sólo una condición de prueba específica.
Los casos de prueba deben considerar una variedad de condiciones que se espera que el software maneje. El caso de prueba debe ser capaz de probar exhaustivamente el módulo de software con casi todas las posibles combinaciones de condiciones principales. Para poder probar de forma exhaustiva todas las combinaciones de condiciones, el autor debe encontrar una forma de presentar estas condiciones de forma que sea fácil de revisar para los demás.
2. Cubrir una pequeña parte de la funcionalidad: deben probar una parte mayor del sistema.
Los casos de prueba suelen centrarse en una función específica. A menudo esta función está determinada por el diseño técnico interno del software. En cambio, los casos de prueba deben reflejar los patrones y flujos de uso. Cada caso de prueba debe intentar cubrir la mayor parte del flujo que sea razonablemente posible, atravesando los límites técnicos de la aplicación subyacente.
3. Prueba según un rol de usuario específico.
A menudo hemos visto casos de prueba escritos para un rol de usuario específico. Esto los limita en su alcance y por lo tanto, compromete su eficacia de manera significativa. Los casos de prueba que son más eficaces reflejan los patrones de uso. Una aplicación empresarial, por ejemplo, debería probarse con casos de prueba que estén diseñados para probar todo el proceso empresarial – cubriendo todos los roles de usuario y todos los sistemas que puedan estar involucrados en el proceso empresarial.
4. Escritos para probar que los casos de uso más comunes están bien cubiertos en la aplicación.
Este, en mi opinión, es uno de los problemas más comunes y es el resultado de lo que yo llamo un enfoque «perezoso» del diseño de pruebas. El diseñador de pruebas simplemente repite el documento de requisitos en los casos de prueba. El diseñador de pruebas debería, en cambio, buscar los «casos de esquina» o las «condiciones límite». La mayoría de los desarrolladores son capaces de escribir fácilmente código para los casos de uso más comunes. Los problemas afloran en el momento en que se da una condición del caso de uso más común. Un caso de prueba bien diseñado los detectará fácilmente.
5. Cualquier caso de prueba puede volverse completamente inútil si no se cataloga sistemáticamente y se mantiene disponible para su uso.
Imagina una biblioteca con libros no catalogados y no guardados sistemáticamente en las estanterías. Sería imposible utilizar los libros si no puedes encontrarlos con facilidad cuando los necesitas.
A menudo se escriben cientos de casos de prueba con mucho esfuerzo y luego se vuelcan en una estructura de carpetas compartida. Aunque esto puede funcionar si tienes muy pocos casos de prueba, esto sólo se colapsa en el momento en que el número de casos de prueba aumenta. Por lo tanto, es necesario etiquetar y catalogar sistemáticamente los casos de prueba. A continuación, un sistema de gestión de pruebas debe ser capaz de «sacar» los casos de prueba cuando sea necesario ejecutarlos. Crear y mantener múltiples versiones de los casos de prueba es crucial.
Wes Higbee
@g0t4
Wes Higbee es el presidente de la empresa Full City Tech.
«El código de prueba que se ha forzado no suele tener valor…»
Quizá haya una regla que diga que debe haber un 100% de cobertura de código, o que no se puede añadir código sin al menos una prueba. Así que la gente escribe sólo el código de prueba suficiente para satisfacer esa regla. Es papeleo glorificado, informes TPS (Office Space).
La gente aprende imitando lo que observa. Así que si exiges pruebas sin ayudar a la gente a entender el valor de las pruebas, entonces tienden a verlo como algo ceremonioso y sólo tratan de copiar las pruebas existentes y meter con calzador su caso de uso.
Las pruebas no son un fin en sí mismas. Las pruebas, cuando son beneficiosas, proporcionan confianza, pueden ahorrar tiempo y pueden salvaguardar futuros cambios. Así que si las personas que han experimentado estos beneficios pueden transmitirlos a sus compañeros, entonces otras personas buscarán esos beneficios y eso a menudo conduce a pruebas productivas.
Las personas que han experimentado los beneficios de las pruebas deben tratar de ensalzar esos beneficios, no las pruebas en sí mismas. Por ejemplo, si tomas un código complicado en un sistema de software real que en el pasado ha estado plagado de errores, y pones algunas pruebas sencillas a su alrededor y ya no tienes esos errores – entonces la confianza subirá, la gente no tendrá tanto miedo, y recordarán eso y traerán las pruebas a la mesa cuando la próxima vez se sientan inseguros.
No es necesario imponer las pruebas si la gente ha experimentado los beneficios de primera mano.
Bernard Perlas
@MyCorporation
Bernard Perlas es un director de control de calidad en MyCorporation que se formó en la Universidad DeVry. Realiza pruebas para productos existentes, así como actualizaciones de productos y sistemas internos. Trabaja en el diseño de pruebas de automatización de la interfaz de usuario y en las pruebas de caja gris del sitio para garantizar que la información sea correcta.
«Los casos de prueba mal construidos tienen en común unos pasos de prueba vagos…»
Para evitar estos errores, debes ser específico con respecto a lo que estás probando y tener claros tus pasos a lo largo del camino. Cuanto más específico seas, más podrás replicar los problemas e identificar las áreas de mejora y actuar sobre ellas.
Benjamin Waldher
@wildebeest_dev
Benjamin Waldher es el Lead Dev Ops Engineer en Wildebeest.
«Los casos de prueba pobres suelen ser muy dependientes de…»
El funcionamiento interno del código que se está probando, lo que puede significar que si se cambian los detalles internos de una función, entonces el caso de prueba se romperá – incluso si la función ya funciona correctamente. Si sientes que estás cometiendo este error, puede ser porque las funciones que estás probando son demasiado largas, o puede que necesites ejercitar más la separación de preocupaciones.
Matt MacPherson
@itsMattMac
Matt MacPherson es el fundador de Edabit.
«Hay algunas cosas que los casos de prueba mal construidos tienen en común…»
1. Probar cosas irrelevantes
Probar sin ningún propósito real no tiene sentido. Soy un gran fan del principio de responsabilidad única. Cada prueba unitaria debe probar una cosa y eso es todo.
2. Probar de inmediato
Probablemente recibiré muchas críticas por esto, pero nunca hago pruebas unitarias hasta que mis decisiones de diseño se han solidificado. Esto se debe a que sé que estoy obligado a hacer cambios bastante grandes y esos cambios es probable que rompan muchas de mis pruebas. Esto significa que en la práctica acabaré escribiendo menos pruebas o no haré grandes cambios de diseño. Ambas cosas son malas, y esperar a tener claridad en el diseño resuelve el dilema.
3. Pruebas de integración vs. pruebas unitarias
Veo a muchos desarrolladores haciendo pruebas de integración cuando en realidad están intentando hacer pruebas unitarias (y viceversa). Cuando se prueba la aplicación en su conjunto en busca de errores, se considera una prueba de integración. La prueba unitaria se ocupa de una unidad específica de comportamiento de los códigos, mientras que la prueba de integración se ocupa del comportamiento de la aplicación en su conjunto.
Manu Singh
@ClrMobile
Manu Singh es un arquitecto móvil en Clearbridge Mobile con experiencia en diseño, desarrollo y pruebas de Android. En Clearbridge, Manu gestiona los recursos del proyecto para un equipo de desarrolladores que construyen aplicaciones de clase mundial para clientes empresariales.
«Hay varios puntos en común que comparten los casos de prueba mal construidos…»
En primer lugar, los casos de prueba podrían ser demasiado simples, lo que significa que sólo prueban la función principal sin probar demasiados casos extremos. Para evitar esto, un desarrollador debe cubrir tantos casos extremos como sea posible. Si se está desarrollando una interfaz que requiere una entrada que no es trivial, entonces es importante probar las entradas malas o vacías.
En segundo lugar, los casos de prueba mal construidos no reflejan cómo un usuario percibirá y utilizará la funcionalidad. Hacer casos de prueba para esto es más difícil de hacer, ya que tienes que entrar en la mentalidad de otro usuario. Considere la posibilidad de segmentar a sus usuarios e identificar sus casos de uso. A continuación, identifique los caminos más rápidos para completar un recorrido de usuario, ya que un usuario tratará de reducir el número de pasos que debe introducir para completar un determinado recorrido. Es importante calificar los diferentes casos de uso, con los diseñadores y los directores de proyecto para identificar aún más estos tipos de casos de prueba.
Y por último, un caso de prueba mal construido no prueba contra los aspectos de una aplicación que podrían hacer que se inicie en paralelo o después de otro. Muchas veces los casos de prueba sólo prueban una característica específica de una app sin ver las ramificaciones de las múltiples características que se habilitan y se interconectan. Es importante tener en cuenta los casos de prueba interfuncionales, especialmente si hay restricciones de rendimiento. Dos funciones aparentemente separadas pueden consumir los mismos recursos, causando así bloqueos.
Rick Rampton
@QASource
Rick Rampton es Jefe de Éxito de Clientes en QASource, supervisando el marketing, las ventas y la gestión de clientes. Ha sido fundamental en la construcción de QASource, con un historial probado de construcción, gestión y retención de equipos de ingeniería de alto rendimiento en el extranjero. Con sede en Pleasanton, California, QASource es uno de los principales proveedores de control de calidad de software del mundo.
«Hay múltiples identificadores con los que podemos reconocer un caso de prueba mal construido…»
- Muchas veces, un resumen de los casos de prueba pobres no destaca el objetivo del caso de prueba, o lo que se necesita lograr.
- El prerrequisito para ejecutar el caso de prueba no está claramente definido o falta, lo que puede causar confusión al desarrollador/probador sobre qué datos o condiciones de prueba se requieren antes de ejecutar el caso de prueba.
- Si hay pasos que faltan en los casos de prueba, entonces deja vacíos para el desarrollador/probador, haciendo que hagan suposiciones al ejecutar los casos de prueba. Esto puede provocar una ejecución inexacta de los casos de prueba y que se pierdan escenarios importantes.
- La ausencia del entorno adecuado para ejecutar los casos de prueba es otro indicador de casos de prueba mal construidos.
- Si el resultado esperado no está claramente descrito en el caso de prueba, entonces el probador no estará seguro de los resultados/que tiene que verificar con ese caso de prueba.
- Cualquier dependencia de datos del usuario (por ejemplo, el usuario debe estar conectado, en qué página debe comenzar el viaje, etc.)
- Dependencias en el entorno de prueba
- Cualquier configuración especial que deba realizarse antes de la ejecución de la prueba
- Dependencias de cualquier otro caso de prueba – ¿el caso de prueba debe ejecutarse antes/después de algún otro caso de prueba?
Rachel Honoway
@rachelhonoway
Rachel es una experimentada ejecutiva especializada en Startups de Internet y empresas en modo de crecimiento. Su carrera se ha dedicado a trabajar de forma práctica con emprendedores para construir y hacer crecer productos SaaS y servicios relacionados.
«La secuencia de eventos es a menudo demasiado simplificada, lo que lleva a un caso de prueba mal construido…»
Los desarrolladores tienden a asumir un camino recto y lógico de principio a fin. En realidad, sin embargo, los usuarios finales tomarán un número exponencial de caminos, muchos de ellos ilógicos. Cuando los desarrolladores no se toman el tiempo de considerar todas las variables que pueden estar afectando al usuario en el momento en que se enfrenta a la característica/página/función, dejan mucho espacio para las pruebas de falsos positivos.
En realidad, los desarrolladores deberían observar a varios usuarios mientras interactúan con la plataforma, y luego dedicar algo de tiempo a preguntar a los defensores del cliente interno (soporte al cliente, gerentes de producto, agentes de ventas) para entender mejor al usuario. Los agentes de ventas pueden ayudar a definir quién es el usuario y describir la necesidad que satisface la aplicación. Los representantes del servicio de atención al cliente pueden identificar los puntos de fricción habituales de la base de usuarios, como la pérdida de contraseñas o los detractores habituales de la atención, como los anuncios en la página. Los gestores de productos pueden proporcionar información sobre cómo interactúa el usuario con la aplicación y cómo esa interacción encaja en el flujo de trabajo mayor del usuario o en su rutina diaria, describiendo las distracciones que se producen fuera de la propia aplicación (gestión de varias pantallas a la vez, usuarios de móviles que reciben notificaciones mientras conducen, etc).
Entender qué puede alejar al usuario final del camino lógico y recto ayudará a los desarrolladores a probar esas variables y a garantizar una experiencia satisfactoria a pesar de las distracciones, los caminos ilógicos y la pérdida de concentración.
Anthony Breen
@BreenAnthony77
Anthony Breen es el cofundador y director general de la aplicación Feasty Eats. Feasty Eats es una plataforma SaaS integrada que ayuda a los restaurantes a impulsar el tráfico durante sus épocas de bajo volumen.
«Al considerar los casos de prueba…»
Es importante para los desarrolladores volver a algunos de los aspectos más simples, pero más importantes, del proceso de investigación. Al igual que en un experimento científico, hay dos factores que deben estar a la vanguardia de cualquier desarrollador para facilitar una prueba eficaz y significativa: la claridad y el control. Más concretamente, antes de comenzar la prueba es necesario comunicar las hipótesis claramente delineadas y prestar cuidadosa atención a los indicadores clave de rendimiento. Al hacerlo, se crea un marco sólido para la investigación posterior.
Además, es esencial que todas las variables no sólo se identifiquen, sino que se controlen cuidadosamente. Hay que eliminar el sesgo de las poblaciones de prueba y hay que identificar las posibles variables de confusión para que los desarrolladores puedan adquirir datos perspicaces y precisos. Un propósito bien definido y claramente articulado, cuando se combina con un entorno de prueba meticulosamente controlado, no sólo producirá resultados valiosos, sino que, lo que es más importante, suscitará nuevas preguntas e hipótesis que conduzcan a una investigación más amplia.
Devlin Fenton
@devfen
Devlin Fenton es el director general de Go99. Devlin dirige un pequeño equipo especializado de ingenieros y programadores que se dedican a resolver problemas por la Industria, para la Industria. Este equipo ha puesto en marcha recientemente una plataforma digital de concordancia de fletes destinada a perturbar la industria de los camiones de 700 mil millones de dólares en Norteamérica. Devlin cree que hay que construir un equipo de expertos y dejar que prosperen.
«Los peores casos de prueba son los que no existen…»
De lejos, el mayor problema es que no hay suficientes y el sistema no puede volver a probarse de forma fiable y automatizada. No tienen en cuenta la prioridad. Una vez que los desarrolladores se ponen a escribir casos de prueba, suelen desarrollar muchos de los fáciles, que prueban código trivial, estático y de bajo riesgo. Hay que esforzarse en apuntar al código complejo y de riesgo y para ello, a veces, el caso de uso es también más complejo y más difícil de desarrollar.
La creencia es que si no es una prueba unitaria no debe hacerse. Las pruebas de integración, las pruebas de datos, las pruebas de rendimiento, las pruebas de estrés, etc. deberían formar parte del conjunto de pruebas.
La falta de enfoque en cuanto al objetivo es otro problema. Por ejemplo, ¿se trata de una prueba de unidad, de integración, de rendimiento o de otro tipo? Mezclar estas prioridades hace que los casos de uso sean más frágiles y más difíciles de arreglar. Necesitan tener un enfoque y ser anotados en consecuencia para que el conjunto de pruebas pueda ser ejecutado de forma dirigida.
Además, algunos casos de prueba carecen de exhaustividad al cubrir sólo un camino feliz y no lo suficiente de los flujos alternativos y de excepción. Efectivamente, el caso de uso sigue el estándar de «haz que funcione» del desarrollador, en lugar del estándar de «haz que falle» de las pruebas.
Otro problema es el de los casos de prueba que no se mantienen, lo que haría que fallaran si se ejecutaran, o que se comentan por completo. Con las prisas, los desarrolladores a menudo cambian el código y pasan por alto la fijación de los casos de prueba.
Los casos de prueba mal construidos también pueden carecer de claridad en cuanto a lo que se está probando, incluyendo el objeto, el método o el escenario. Los casos de prueba deben seguir una convención (nomenclatura, comentarios, etc.) que facilite la identificación del alcance de la prueba.
Los buenos casos de prueba evitan una red de dependencias. Deben evitarse las dependencias entre los casos de prueba; de lo contrario, un solo fallo puede mostrar muchas pruebas que fallan, lo que hace más difícil identificar la causa. Si hay una lógica común para establecer precondiciones, o evaluar resultados, dicha lógica debe ser abstraída y compartida en lugar de apilar casos de prueba.
Rohit Keserwani
@EquifaxInsights
Rohit Keserwani es un consultor de BI y analista de negocio senior de Equifax.
«He observado las siguientes características comúnmente presentes en los malos casos de prueba…»
1. Análisis de impacto no documentado. Cuando un analista de pruebas no documenta el impacto, asume que no lo conoce. ¿El resultado? POOF…
2. La precondición de la prueba no está definida o está poco articulada.
3. Pasar por alto el fondo del usuario y asumir cosas. Si no entiendes el nivel de conocimiento de la persona que va a hacer la prueba, no asumas nada. Documenta todo hasta el más mínimo detalle. Si no, puedes acabar asumiendo algún conocimiento del que carecen, lo que puede hacer que el usuario realice la prueba de forma diferente a la esperada.
4. Criterios de aprobación y tolerancia no claramente definidos. Si por alguna razón no se articulan los criterios de aprobación, la persona que realiza la prueba queda a su antojo para decidir si una determinada prueba ha pasado o no. Si no se tiene un escenario de aprobación claramente definido, el probador no tendrá un punto de referencia con el que comparar. Esto crearía ambigüedad y eventualmente pondría en juego todo el esfuerzo de las pruebas.
Pete Van Horn
@PraxentSoftware
Pete Van Horn es un analista de tecnología de negocios para Praxent.
«Tengo mucha experiencia con casos de prueba mal construidos, y también soy probablemente culpable de escribirlos de vez en cuando…»
Muchas veces, un caso de prueba no es fácilmente ejecutable. Si soy un desarrollador, debería ser capaz de tener suficiente información y estar posicionado de manera que pueda ejecutar mi caso de prueba para determinar un resultado. Creo que una cosa sobre los casos de prueba es que no tienen que dar necesariamente el resultado previsto, pero siempre tienen que ser ejecutables de principio a fin. Incluso si obtienes un resultado negativo, es mejor que quedarte atascado. Un caso de prueba mal construido no permite a quien está haciendo las pruebas ejecutarlo completamente.
En términos de errores de los desarrolladores, tal vez estoy pensando demasiado en ello, pero normalmente los desarrolladores no escriben el caso de prueba. Puede que escriban las pruebas unitarias, pero un caso de prueba lo suele escribir un analista de negocio o un arquitecto de soluciones. Ellos se encargan de crear lo que debe ser el resultado esperado. Yo diría que tener casos de prueba bien escritos realmente encuentra su génesis en tener requisitos realmente bien escritos. Tener unos buenos requisitos te permite crear un buen caso de prueba. Y un buen caso de prueba es capaz de ser ejecutado de principio a fin, sin interrupción.
Hans Buwalda
@logigear
Hans Buwalda es el Director de Tecnología de LogiGear. Dirige la investigación y el desarrollo de soluciones de automatización de pruebas de LogiGear, así como la prestación de servicios avanzados de consultoría e ingeniería de automatización de pruebas.
«El diseño de las pruebas puede desempeñar un papel importante en el éxito o el fracaso de la automatización…»
Una de las causas más comunes de la automatización es la falta de enfoque en los casos de prueba. Las pruebas deben tener un alcance claro que las diferencie de otras pruebas. Todos los pasos y comprobaciones en las pruebas deberían entonces ajustarse a ese alcance. El alcance de un caso de prueba debe ser muy claro; de lo contrario, no se sabe cuán detallados deben ser los pasos de las pruebas y qué comprobaciones deben realizarse.
Una práctica común en muchos proyectos es tener largas secuencias de pasos detallados, cada uno con una o más comprobaciones para verificar su resultado esperado. Esto hace que las pruebas sean difíciles de mantener. Los detalles de navegación y las comprobaciones que no contribuyen al alcance de las pruebas deberían encapsularse en palabras clave de alto nivel reutilizables o en funciones de script. Esto hará que las pruebas sean más legibles y más fáciles de mantener. Los probadores, los propietarios del producto y los desarrolladores pueden trabajar juntos para obtener un conjunto óptimo de pruebas que puedan servir durante mucho tiempo con el mínimo esfuerzo.
Ulf Eriksson
@ReQtester
Ulf Eriksson es uno de los fundadores de ReQtest, un software de seguimiento de errores online desarrollado en Suecia. El objetivo de Ulf es hacer la vida más fácil para todos los involucrados en las pruebas y la gestión de requisitos. Como propietario del producto, se esfuerza por hacer que ReQtest sea fácil y lógico de usar para cualquier persona. El autor de una serie de libros blancos y artículos, en su mayoría sobre el mundo de las pruebas de software, Ulf también está esclavizando un libro, que será un compendio de sus experiencias en la industria.
NOTA: La siguiente información es extraída de Cómo escribir casos de prueba eficaces a través de ReQtest.
«Cuando los probadores informan de los defectos basados en el caso de prueba, deben indicar qué paso de la prueba ha fallado, con el fin de facilitar la resolución de problemas…»
Cuando escriba un caso de prueba, no necesita especificar el resultado esperado para cada paso de la prueba si el resultado es obvio. Por ejemplo, si el navegador no se abre, el probador no podrá pasar al siguiente paso.
Si su caso de prueba tiene demasiados pasos de prueba, debería pensar en dividir el caso de prueba en un conjunto de pasos más pequeños.
Si el caso de prueba contiene una larga lista de pasos de prueba, y se produce un error, el desarrollador tendrá que retroceder y repetir todos los pasos de prueba, lo que podría no hacer por accidente, o por pereza.
Tener demasiados pasos de prueba puede ser una desventaja para el probador, también. El probador puede tener que repetir cada uno de los pasos de prueba para asegurarse de que el error se soluciona.
Sanoj Swaminathan
@rapidvalue
Sanoj Swaminathan es un Jefe Técnico – Garantía de Calidad en RapidValue Solutions.
NOTA: La siguiente información se extrae de Test Case Design and Testing Techniques: Factors to Consider via RapidValue Solutions.
«El proceso de diseño de pruebas es de alta prioridad. Una prueba mal diseñada conducirá a…»
Una prueba inadecuada de una aplicación y, por tanto, a realizar la prueba de forma errónea y con resultados perjudiciales. Esto, a su vez, conducirá a un fallo en la identificación de defectos. Como consecuencia, puede salir al mercado una aplicación que contenga errores.
Existen varios tipos de técnicas de diseño, y el reto consiste en seleccionar el conjunto adecuado de técnicas de diseño de pruebas pertinentes para la aplicación en cuestión. Los diferentes tipos de técnicas de prueba tienen sus propias ventajas. El uso de cualquier técnica particular se considera sólo después de mucha contemplación y dando el máximo énfasis en el tipo de aplicación.
TestLodge
@TestLodge
TestLodge es una herramienta de gestión de casos de prueba en línea, que le permite gestionar sus planes de prueba, requisitos, casos de prueba y ejecuciones de prueba con facilidad.
NOTA: La siguiente información se ha extraído de ¿Qué es la prueba de usabilidad? (With Example) via TestLodge.
«La clave del mayor éxito está justo aquí…»
Antes de comenzar las pruebas, defina claramente los objetivos. Por qué está realizando estas pruebas en primer lugar? Qué motivó a tu organización o equipo a hacerlo y qué buscas lograr? ¿Qué es lo que define el éxito de una prueba? Además, piense en la hipótesis que tiene. ¿Dónde crees que vas a encontrar más problemas y por qué? Entender y establecer claramente los fundamentos es absolutamente esencial.
También deberías establecer cualquier metodología específica que pretendas seguir, tanto para facilitar la ejecución de las pruebas como para facilitar la replicación más adelante, en caso de que sea necesario por cualquier motivo.
Amandeep Singh
@quickswtesting
Amandeep Singh escribe para Quick Software Testing, un blog dedicado a temas relacionados con las pruebas de software y el aseguramiento de la calidad. Los ingenieros de pruebas de software pueden discutir la automatización y las herramientas de pruebas de software manual y tutoriales.
NOTA: La siguiente información es extraída de Top 13 Tips for Writing Effective Test Cases for Any Application via Quick Software Testing.
«Mientras escribe los casos de prueba, debe comunicar todas las suposiciones que se aplican a una prueba, junto con cualquier condición previa que deba cumplirse antes de que la prueba pueda ejecutarse…»
A continuación se indican los tipos de detalles que debe cubrir:
Kyle McMeekin
@QASymphony
Kyle McMeekin contribuye al blog de QA Symphony. QA Symphony ayuda a las empresas a crear un mejor software al ser el único proveedor de herramientas de pruebas ágiles de nivel empresarial.
NOTA: La siguiente información está extraída de 5 Manual Test Case Writing Hacks vía QASymphony.
«Para ser considerado un ‘gran tester de software’, tienes que tener un ojo para los detalles…»
Pero no puedes ser verdaderamente grande a menos que puedas escribir eficazmente casos de prueba. Escribir casos de prueba es una tarea que requiere tanto talento como experiencia.
El propósito de escribir casos de prueba es definir el «cómo» y el «qué». Para algunos probadores, esto se considera un trabajo aburrido, pero si se hace bien, los casos de prueba se convertirán en algo muy valioso, mejorarán la productividad de todo el equipo y ayudarán a su empresa a crear un software de mayor calidad.
Mantenga la sencillez: Nadie va a aceptar un caso de prueba que sea excesivamente complejo y que no se pueda entender fácilmente. Los casos de prueba tienen que estar escritos en un lenguaje sencillo utilizando la plantilla de la empresa.
Hazlo reutilizable: Al crear nuevos casos de prueba, hay que recordar que los casos de prueba se reutilizarán, por lo que hay que hacerlo bien. El mismo caso de prueba podría ser reutilizado en otro escenario o un paso de prueba podría ser reutilizado en otro caso de prueba.
Clases de Pruebas de Software
Clases de Pruebas de Software es un sitio web completo para la gente de pruebas de software.
NOTA: La siguiente información está extraída de Cómo escribir buenos casos de prueba a través de Software Testing Class.
«Los casos de prueba deben ser escritos de tal manera que deben ser…»
Fácil de mantener. Considere un escenario en el que, después de la finalización de la escritura de los casos de prueba, el requisito se cambia, entonces el probador debe sin esfuerzo capaz de mantener el conjunto de casos de prueba.
Cada caso de prueba debe tener un número de identificación único que ayuda a vincular los casos de prueba con los defectos y los requisitos.
Akanksha Goyal
@TOTHENEW
Akanksha Goyal contribuye a TO THE NEW, una empresa de tecnología digital innovadora y de rápido crecimiento que proporciona servicios de desarrollo de productos de extremo a extremo.
Nota: La siguiente información está extraída de Top 9 Tips to Write Effective Test Cases via TO THE NEW.
«El conocimiento del dominio es el núcleo de cualquier aplicación de software…»
Las reglas de negocio pueden variar según el dominio y pueden impactar en gran medida en las funciones del negocio. La falta de conocimiento del dominio en las pruebas puede resultar en una pérdida de negocio. Por lo tanto, para evitar conflictos entre las normas de dominio, un probador de productos debe obtener este conocimiento antes de escribir los casos de prueba.
No asuma nada; cíñase a los documentos de especificación. Asumir características y funcionalidades de las aplicaciones de software puede crear una brecha entre las especificaciones del Cliente y el producto en desarrollo, lo que también puede impactar en el negocio.
# #
En Stackify, entendemos lo crucial que son las pruebas de software en el ciclo de vida del desarrollo, por lo que es un tema que discutimos regularmente. Sabías que puedes integrar APM en tu estrategia de pruebas? Descubre cómo aquí.
Para más consejos de expertos sobre la escritura de casos de prueba de calidad (y por qué es como el método científico), echa un vistazo a este post, o visita este artículo para obtener una lista de 101 consejos de pruebas de software de expertos y consejos para sacar el máximo provecho de su proceso de pruebas. Para una mirada más profunda a los tipos de pruebas de rendimiento y pruebas de software, los pasos de las pruebas de rendimiento y las mejores prácticas, visite esta guía.