Automatización – Elegir el correcto marco automatizado de prueba, es un contenido elaborado por MQS (Mate Quality Services) por parte de Walter Finkbeiner. Un error común al momento de diseñar un marco automatizado de prueba es que los ingenieros encargados de diseñarlo, aceptan lo que el cliente quiere usar en lugar de mostrarles una propuesta que puede ser una mejor solución, o elegir las herramientas en las que tienen más experiencia, sin considerar muchos factores que afectarán el Retorno de la Inversión en el futuro. No es tan fácil elegir el conjunto de herramientas que formará parte del marco. Aspectos que deben tenerse en cuenta:
• Presupuesto:
Este elemento es muy importante porque la lista de posibles soluciones se puede acortar muy rápidamente y se puede ahorrar tiempo. La decisión debe tener en cuenta que se debe comprar una licencia o que se deben comprar complementos para algunas herramientas. Afortunadamente, hay muchas soluciones muy buenas, gratuitas y de código abierto.
• Necesidades:
Tener en cuenta si es compatible con todos los sistemas operativos necesarios, navegadores, si proporciona buenos informes, si permite ejecutar pruebas en paralelo, integración con herramientas de gestión de proyectos, etc.
• Miembros del equipo:
Otro elemento a considerar son los miembros disponibles del equipo. Si son expertos en un lenguaje o herramienta específicos, tendrá sentido apoyarse en eso, en lugar de elegir una herramienta de la que nadie haya oído hablar antes. Pero esto no debería influir al cien por ciento para tomar la decisión final. Además, es importante saber de antemano qué tan fácil será lograr que más personas con experiencia en esas tecnologías crezcan.
• Curva de aprendizaje:
Incluso si una herramienta o un idioma es increíble, algunos miembros del equipo podrían no haber oído hablar de él. Entonces la curva de aprendizaje debe ser considerada. Si los beneficios del aprendizaje son mayores que el tiempo invertido, y si el tiempo lo permite, tal vez valga la pena continuar tomándolo en consideración.
• Estabilidad:
Es realmente importante saber si las herramientas elegidas son lo suficientemente estables para evitar problemas en el medio del proyecto.
• Documentación:
Es vital que haya suficiente documentación para aprender y superar cualquier obstáculo, sin tener que probar soluciones posibles al azar en StackOverflow.
Mate Quality Services (MQS) es una empresa de rápido crecimiento con sede en Uruguay que se especializa en control de calidad, auditoría de TI, gestión de proyectos y servicios de pruebas (testing), asegurando que se brinde la solución adecuada a sus clientes. Como líder de pensamiento e innovador en la industria de TI, Mate Quality Services agrega valor a lo largo de cada fase del desarrollo y gestión de los sistemas de TI, lo que mejora la calidad de las aplicaciones, reduce el tiempo de lanzamiento al mercado y reduce el costo total de propiedad.
• Mantenibilidad:
Las herramientas deben fomentar buenas prácticas y patrones para que el marco diseñado y las pruebas sean fáciles de mantener.
• Simplicidad:
Toda la lógica complicada, si la hay, debe vivir dentro del marco, y los probadores no deberían necesitar hacer cambios constantes allí. Debe ser fácil para los evaluadores escribir, leer y ejecutar las pruebas.
• Reutilización de código en pruebas:
El código debe ser reutilizable. ¡No te repitas!
• Reusabilidad en otros proyectos:
Tenga en cuenta que, en el futuro, podría surgir otro proyecto que deba automatizarse. El marco debe ser lo suficientemente flexible como para ser utilizado en otros proyectos.
• Reutilización del código existente dentro del marco:
Es posible que ya exista un código en el Sistema bajo prueba que pueda reutilizarse en el marco. Por ejemplo, es posible que ya exista un cliente HTTP dentro del proyecto de la aplicación, y podría ser una buena herramienta para probar los servicios web.
• Miembros no técnicos involucrados:
Hay proyectos en los que miembros no técnicos como propietarios de producto o probadores manuales sin conocimiento de programación podrían estar involucrados en la redacción y ejecución de pruebas. Hay algunas herramientas, por ejemplo, marcos BDD, que permiten a los miembros no técnicos escribir pruebas en inglés (Gherkin).
• Equipo de desarrollo implicado:
Si los miembros del equipo de desarrollo tienen experiencia en los idiomas o herramientas elegidos, podrán ayudar haciendo revisiones de código, compartiendo las buenas prácticas del equipo y brindando soporte técnico.
• Informes de prueba:
Es realmente importante que el marco proporcione informes buenos, confiables y fáciles de leer. Eso es lo que la gerencia leerá. Como es posible que no tengan demasiado tiempo, deben ser concisos, informativos y rápidos y fáciles de leer.
• Soporte de integración continua:
La integración continua es muy importante hoy en día para dar retroalimentación rápida al equipo. Un marco de automatización de prueba debe tener soporte para integración continua.
Diseñar un marco no es tan fácil después de todo. Requiere mucha planificación, investigación, conocimiento y comunicación. Hay muchas herramientas muy buenas, pero todos los proyectos son diferentes. Tienen diferentes presupuestos, plazos, requisitos, personas, etc. ¡Y es realmente importante tener todas estas variables en cuenta antes de apresurarse a tomar una decisión!
Autor: Walter Finkbeiner
Choosing the right automated testing framework
A common mistake at the time of designing an automated testing framework is that the Engineers in charge of designing it accept what the client wants to use instead of showing them a proposal that can be a better solution, or choose the tools in which they have more experience, without con-sidering many factors that will affect the Return of Investment in the future. It is not that easy to choose the set of tools that will become part of the framework. Many other items have to be taken into consideration:
• Budget: This item is very important, because the list of possible solutions can be shortened very quickly, and time can be saved. The decision must take into account that a license must be pur-chased, or plugins must be bought for some tools. Luckily, there are a lot of very good, free and open source solutions out there.
• Needs: Take into consideration if it supports all the necessary Operative Systems, browsers, if it provides with good reports, if it allows to run tests in parallel, integration with project management tools, etc.
• Team members: Another item to consider is the available team members. If they are experts on a specific language or tool, it will make sense to lean towards that, instead of choosing a tool that nobody has heard about before. But this should not influence a hundred percent to make the final decision. Also, it is important to know beforehand how easy it will be to get more people with ex-pertise in those technologies if the project grows.
• Learning curve: Even if a tool or language is awesome, some team members might have never heard of it. So the learning curve must be considered. If the benefits of learning are greater than the time invested, and if the time allows it, maybe it is worth it to continue taking it into considera-tion.
• Stability: It is really important to know if the chosen tools are stable enough to avoid having prob-lems in the middle of the project.
• Documentation: It is vital that there is enough good documentation to learn and overcome any obstacle, without having to try random possible solutions on StackOverflow
• Maintainability: The tools must encourage good practices and patterns so that the designed framework and tests are easy to maintain.
• Simplicity: All the complicated logic, if any, should live inside the framework, and testers should not need to make constant changes there. It should be easy for testers to write, read, and execute the tests.
• Reusability of code on tests: Code should be reusable. Don’t Repeat Yourself!
• Reusability in other projects: Take into account that in the future, another project might come up and have to be automated. The framework should be flexible enough to be used in other pro-jects.
• Reusability of existing code inside the framework: There might be already existing code in-side the System Under Test that can be reused in the framework. For example, an HTTP client might already exist inside the application’s project, and it might be a good tool for testing Web Services.
• Non-technical members involved: There are projects in which non-technical members like Product Owners, or manual testers without programming knowledge might be involved in writing and executing tests. There are some tools, for example, BDD frameworks, that allow non-technical members to write tests in English (Gherkin).
• Dev team involved: If the development team members have expertise in the chosen languages or tools, they will be able to help by doing code reviews, sharing the team good practices, and by giving tech support.
• Test reports: It is really important that the framework provides good, trustable and easy to read reports. That is what the management will read. As they might not have too much time, they should be concise, informative and quick and easy to read.
• Continuous Integration support: Continuous integration is very important nowadays to give rapid feedback to the team. A test automation framework must have Continuous Integration sup-port.
Designing a framework is not that easy after all. It requires a lot of planning, investigation, knowledge and communication. There are a lot of very good tools out there, but all projects are different. They have different budgets, deadlines, requirements, people, etc. And it is really im-portant to have all these variables into consideration before rushing to make a decision!
Automatización
Artículo relacionado: ¿AUTOMATIZAR? ¡ES MUY FÁCIL!
[ leer más ]
Autor: Jair Tabares Plebani
CIO & Founder at Mate Quality Services
Barcelona Area, Spain
