Agile QA

Regression testing is a really common term used within the software industry, not only by QAs, but also for developers, PMs, clients, this term is sometimes confused by some people and I'm going to explain what a regression testing means to me. First things first, every single project must have regression testing, from my perspective, before every single release to the client, QA must execute a regression testing to ensure the deliverables are in place and that other areas of the system were not affected by the multiple changes and new functionality added, this testing needs also to be done before every update to pushed to live. Regression testing is a type of testing where you confirm and double check that the system works correctly with the new functionality added and that the previous functionality developed before works fine with no bugs, that being said, a regression testing involves the testing of every single page, module, functionality, service, etc in all the brow...

El término pruebas de regresión es un término común usado frecuentemente en la industria del software, no solo por QA, sino por desarrolladores, gerentes de proyecto, incluso clientes, este término es a veces confundido por algunas personas y por eso hoy voy a darles mi visión de lo que para mí son las pruebas de regresión. Primero que todo, cada proyecto debe tener una o más fases de pruebas de regresión, a mi modo de verlo, antes de cada entregable al cliente, QA debe ejecutar pruebas de regresión para asegurar que lo que se entrega está bien y que otras áreas del sistema que ya fueron probadas antes no se vean afectadas por los múltiples cambios, actualizaciones y nuevas funcionalidades agregadas, este tipo de pruebas también deben hacerse antes de cada actualizaión o cambios en el ambiente de producción. Las pruebas de regresión son un tipo de pruebas en donde se confirma y se verifica que el sistema funciona correctamente con nuevas funcionalidades agregadas y que las anterio...

No matter if you work with agile or not, on some projects or all of them you may or may not heard the term bug triage, this is a great meeting which in my experience involves three or four people: tech lead, product owner, project manager and QA lead. This meeting takes place at the end of the day or starting the day, the idea for this meeting is to review all the bugs logged during the day or the day before and check if the bugs was logged correctly checking all the important fields like, clear summary, correct steps and results, severity, priority and the bug itself to make sure all bugs are understood, it also has the goal to identify duplicated bugs . The idea here is that there may be some bugs that can be tackled later and the bugs related to functional areas that may be delivered soon, in that case there may be minor bugs that may have a higher priority and major or critical bugs may have less priority as well. The other purpose of this meeting is also to check in some ...

No importa si trabajan con metodologías ágiles o no, en algunos proyectos o en todos tal vez hayan escuchado el término bug triage, en español sería algo así como triaje de errores o priorización de errores, esta es una gran reunión en donde, desde mi experiencia, deben estar tres o cuatro personas: líder técnico, dueño de producto (PO), gerente del proyecto y líder de QA. Esta reunión tiene dos opciones para hacerse, al final del día o empezando el dia, yo prefiero siempre que sea al final del día, la idea es revisar todos los bugs o errores reportados durante el día o día anterior y verificar si están reportados correctamente, es decir, verificar que todos los campos están bien diligenciados, que hay un título y pasos claros para reproducir el error, ver la severidad y prioridad del mismo y ver si el bug se entiende. La idea aquí también es ver si la prioridad y severidad debe ser cambiada o no y actualizar el error para que sea más fácil de entender, esto con el fin de saber qu...

If you work with web, clients often require to test their websites in multiple browsers and mobile devices, including tablet and mobile, you don't get to decide which browsers or devices should be tested, however, if clients don't know a lot about their analytics, you can always propose browsers and devices based on the most used world wide, of course, this needs to be approved by the client. Sometimes the most used browsers don't matter to clients, they want their webistes to work on the browsers users use when going into them, that being said you may end up testing browsers that people worldwide don't use like old Internet Explorer versions or old OSs, believe me, it happens. Now, let's say you only have a Mac, but you are requested to test on Internet Explorer 10, Internet Explorer 11, Edge, Chrome and Firefox, what would you do ? The correct answer is: you have to test on all those browsers because it is requested by the client although you c...

Cuando hablamos de web, los clientes frecuentemente requieren que sus páginas web sean probadas en múltiples navegadores y dispositivos móviles como tablets o celulares, el equipo no decide que navegadores o dispositivos se deben probar, sin embargo, si el cliente no sabe mucho acerca de esto y no tiene métricas para saber que navegadores deben ser soportados, siempre se debe proponer en que navegadores, sistemas operativos y dispositivos móviles probar, basado en su uso mundial, por supuesto, esto lo aprueba unicamente el cliente. Hay ocasiones en que los navegadores más usados a nivel mundial no le importan al cliente, ellos quiren que sus páginas web funcionen en los navegadores o dispositivos que los usuarios usan para acceder el sitio, así que puede llegar el caso en el que al ser QA, termine probando en navegadores viejos que a nivel mundial tienen un uso casi nulo como por ejemplo versiones muy viejas de Internet Explorer y sistemas operativos viejos, créanme, me ha pasado....