Agile QA

You as QA, tester, developer, project manager, product owner or any role you have on your company may came across or may be related or informed about the bugs logged by the team within the project, bugs touches all team members because in some phase or in some moment everyone will see the bugs and review them. First of all let's be clear, bugs are not intended for QAs to bring out a developer's error or to criticize their job, bugs are intended to discover failures before the client or some stakeholder do, this will be worst and may generate a negative impact to the company and the project, this also may cause the client to lose confidence on the company or team. This is not a competition about how many bugs QA found and the seniority level of a QA is not measurable by how many bugs he/she finds, I do not agree that if a day passes and QA didn't log any issues is because QA did no work, perhaps there were a lot of meetings, or QA was doing test cases, feature files, or ...

Cada uno, como QA, tester, desarrollador, gerente de proyecto, dueño del producto, o cualquier rol que tenga en la compañía se puede encontrar o puede estar relacionado con fallos del sistema (bugs) reportados por el equipo de trabajo, estos bugs o fallas tocan a todos los miembros del equipo porque en alguna fase o en algún momento, todos tendrán que ver los bugs reportados y revisarlos. Primero que todo, aclaremos algo, los bugs no tienen la intención de criticar el trabajo de los desarrolladores o de resaltar un mal trabajo, los bugs tienen como objetivo encontrar fallas antes de que el cliente o partes interesadas lo hagan, si esto pasa, causaría un impacto negativo en la compañía y el proyecto, lo cual tambien causaría la perdida de confianza por parte del cliente. Esto no es una competencia sobre cuantos bugs QA encuentre y no es más senior o experimentada la persona que encuentra más bugs, un buen QA no se mide por esto. Tampoco estoy de acuerdo en que si en un día no se re...

Accessibility testing is the way to make your websites, application and projects accessible for everyone, you may have clients or users with visual disabilities, no mouse and with no way to access your website and its components. It's important to keep in mind that accessibility contains 3 levels according to Web Content Accessibility Guidelines (WCAG 2.0) level A, AA and AAA, if you support AA you must support A and AA and if you support AAA you must support AA and A, each level is different and contains more criteria to met. In terms of accessibility guidelines, A is the basic level, AA is the most used and a good level of accessibility, finally, AAA is the level with most complexity. In my experience AAA level is only used for medical systems or pharmaceutical companies. For more information about these levels and their criteria, you can visit https://www.w3.org/TR/WCAG20 There are a lot of test cases and criteria on the page mentioned above, however I'm not going to rep...

Las pruebas de accesibilidad son la forma de hacer que las aplicaciones, sistemas, y páginas web sean accesibles para todo el mundo, puede haber clientes o personas que usen los sistemas que hacemos y que no tengan mouse o tengan discapacidad visual y que por esto, no puedan usar el sistema. Es importante tener en cuenta que existen tres niveles de accesibilidad de acuerdo a las Pautas de Accesibilidad al Contenido Web (WCAG 2.0) nivel A, nivel AA y nivel AAA. Estos niveles son inclusivos, por tanto, si el sistema soporta AA debe soportar A y AA y si el sistema soporta AAA debe soportar A, AA y AAA, cada nivel es distinto y contiene diferentes criterios de aceptación. En ese sentido A es el nivel más básico, AA es el nivel intermedio y a la vez el más usado a nivel mundial y AAA es el nivel mas complejo y avanzado, en mi experiencia he visto que el nivel AAA es usado en sistemas médicos, entidades de salúd y farmacéuticas. Para mas información sobre los niveles pueden visitar https:/...

Hoy no voy a hablar sobre la definición de las pruebas exploratorias porque ya hay bastantes páginas web y libros que hablan sobre ellas, voy a hablar de los beneficios de estas pruebas y para mi, la mejor arma de un QA en temas de ejecución de pruebas. Las pruebas exploratorias ayudan mucho a conocer el sistema (más que los casos de prueba o feature files) porque el QA está realmente usando el sistema, probándolo y haciendo cosas dentro de el, se puede saber lo que hace el sistema, lo que no hace y como se comporta. Las pruebas exploratorias son la mejor arma del QA más que otro tipo de pruebas, yo creo, sin temor a equivocarme,  que si la historia de usuario o requerimiento está bien definido, se puede probar el sistema usando pruebas exploratorias sin necesidad de casos de prueba, feature files o documentación excesiva y se puede entregar un producto con muy buena calidad. Hay muchas técnicas que se pueden aplicar al hacer pruebas exploratorias, la mayoría se aprenden con la...

I'm not going to talk about what exploratory testing is, because there are a lot of websites that talk about it, I'm going to talk about the benefits and for me, the best weapon of a QA in terms of test execution. Exploratory testing helps a lot to know the system (more than the test cases or feature files) because you are on the actual system using it, testing it and doing stuff on it, you can know what the system does and doesn't do and how it behaves. Exploratory testing is the weapon of choice of the QA more than any other testing type, I must say without fear, that if a user story has a good and defined acceptance criteria you can test your system using exploratory testing in a great way without test cases, feature files or excess of documentation and you can deliver a system with good quality. There are a lot of techniques to apply exploratory testing, most of them are learned with experience, for example: Submit a form with empty fields or spaces Submit a form...

I think all of us (or most of us) love automation testing, not only because we learn a lot about the code of the project we are at, but also because it saves time while the project advances and you can focus on other areas while the testing is running, finally, you can learn more while you're coding your automation scripts. I have worked in a lot of projects (E-commerce, finders, intranets, matchmakers, TV channels, and a lot more) however not all the projects should be automated, of course you can automate what you want, but does it make sense ? for me the answer is no, what makes sense for me is to automate things you do daily that takes a lot of time to be done manually, if you ask me, look and feel or UI testing should not be automated, you can quickly check with your eyes the look and feel and UI of the project you are testing faster than doing a code that will check styles or correct UI, as I said in my previous post, testing takes priority over everything, this includes...

Creo que todos (o la mayoría) amamos las pruebas automatizadas, no solo porque aprendemos mucho sobre el código del proyecto en el que estamos trabajando, sino porque nos ayuda a aprender mas, ahorrar tiempo de ejecución de pruebas mientras nos enfocamos en otras áreas a probar y finalmente, se aprende mas de código y se hace mejor mientras avanza el proyecto. He trabajado en muchos proyectos (E-commerce, buscadores, intranets, configuradores, canales de TV, etc) sin embargo, no todos los proyectos deben ser automatizados, por supuesto, se puede automatizar lo que se quiera, pero  ¿ tiene sentido ? para mi la respuesta es no, lo que tiene sentido es automatizar módulos, áreas o tareas que se hacen diariamente y que toman bastante tiempo en ser ejecutadas manualmente, si me lo preguntan a mi, la interfaz de usuario y el diseño del sistema (look and feel) no deberían ser automatizadas, se puede ver rapidamente y facilmente con los ojos que hacer un código que valide que se vea b...

When you are on the QA design phase of a project or you are documenting how your tests will be executed, you will come across two different options, test cases and feature files, they may have a common purpose, and this is to document the tests that testers or QAs involved in a project will execute, I have used both and I'm going to describe here my findings. Test cases as the name implies, are cases that testers and QAs will test during the project, they are great for documenting the tests and the functionality of the project. Test cases include an ID, a precondition to start the test case, a series of steps and a expected result, the way I have done test cases in the past, is to add a expected result for each step, it has worked better for me than only having one result at the end, of course this is up to you, both ways work. Test cases are done in a really formal format and they are really structured. In my experience, test cases are shared internally with the development t...

Cuando se está en la fase de QA de diseño o se requiere documentar el como las pruebas serán ejecutadas, nos encontramos con diferentes opciones, los casos de prueba y los feature files (el termino en español sería archivos de características), ambos tienen un propósito común que es documentar las pruebas que los testers o QAs harán al momento de la ejecución de las mismas. He trabajado y usado las dos y a continuación describiré mis experiencias. Los casos de prueba, como su nombre lo indica, son los casos que los testers o QAs van a probar durante el proyecto, son geniales para documentar que se va a probar y la funcionalidad a cubrir. Los casos de prueba generalmente tienen un identificador único, pre-condición para poder ejecutarlo, una serie de pasos a seguir y finalmente el resultado esperado, de la forma como yo he trabajado en el pasado, siempre agrego un resultado esperado por cada paso y no solo un resultado esperado al final de los pasos, me ha resultado mejor, pero por...