Introducción
Las pruebas de software desempeñan un papel vital en garantizar la calidad y confiabilidad de los productos de software. Las plataformas de pruebas crowdsourced, como uTest y Test IO, permiten que probadores freelance contribuyan con sus habilidades en diversos proyectos de prueba.
Este artículo compara las diferencias entre las plataformas uTest y Test IO, centrándose específicamente en los procesos de prueba, tipos de errores, gravedad de errores funcionales, manejo de archivos adjuntos, pagos y comunicación en el ámbito de las pruebas.
Aspecto | uTest | Test IO |
Procesos de Prueba | uTest sigue un proceso de prueba estructurado que generalmente comprende la incorporación al proyecto, la ejecución de casos de prueba, la presentación de errores y el cierre del ciclo de pruebas. Los probadores reciben casos de prueba específicos y los ejecutan dentro del entorno de prueba designado. Tras la ejecución, los probadores envían informes detallados de errores a la plataforma.
El rechazo de un informe de error impacta negativamente en las puntuaciones del probador, dependiendo del tipo de rechazo recibido.
Los probadores pueden impugnar errores rechazados por los clientes.
Los informes de marcadores de posición están prohibidos.
Los probadores pueden utilizar cualquier dispositivo registrado que cumpla con los requisitos del ciclo de prueba.
El Ingeniero de Pruebas selecciona a los probadores que participarán en una prueba. | Test IO utiliza un proceso de prueba ágil que involucra la planificación, ejecución y retroalimentación continua de pruebas. Los probadores participan en ciclos de prueba que se ajustan a su idioma, dispositivos y ubicación. Ponemos énfasis en las pruebas exploratorias en tiempo real y manuales, permitiendo a los probadores descubrir y reportar errores sobre la marcha.
Para comenzar a contribuir a un ciclo de prueba, los probadores deben iniciar su sesión de prueba con anticipación y confirmar que han leído y comprendido las instrucciones de las características incluidas.
Para identificar duplicados, al enviar un error, la lista de ❝Errores similares❞ en el lado derecho del formulario de errores mostrará la lista de errores ya informados en la prueba actual. Además, puedes buscar y filtrar los errores, así como la lista de Errores Conocidos para evitar duplicaciones.
El rechazo de un informe de error tiene un impacto negativo en las puntuaciones del probador, dependiendo del tipo de rechazo recibido.
Los probadores tienen la opción de impugnar errores que son rechazados por los líderes de equipo. Una vez que un informe es impugnado, queda bloqueado para su revisión por el Equipo de Controversias de Errores.
El uso de marcadores de posición en los informes está estrictamente prohibido.
Con base en los dispositivos registrados en el Perfil del Probador y otra información, el sistema selecciona uno de los dispositivos y te invita a participar en la prueba. Dependiendo de los asientos disponibles para cada ciclo, puede que no puedas elegir un dispositivo diferente al que seleccionó el sistema. Una vez que haz sido invitado a probar con un dispositivo, no podrás cambiar a otro. Por lo tanto, solo podrás enviar errores encontrados en este dispositivo. |
Formulario de Errores | La estructura del formulario de errores de uTest es la siguiente:
| En cambio, el formulario de errores de Test IO simplifica la documentación del probador con la siguiente estructura:
No es necesario seguir un formato específico para construir un título. Sin embargo, debes responder a lo que sucedió, dónde ocurrió el error y cuándo se activó.
En nuestro formulario de errores, no es necesario agregar el número de paso; este dato ya está proporcionado en nuestro formulario. Puedes arrastrarlos y reorganizarlos a tu gusto.
Excepto en el caso del navegador durante las pruebas de sitios web, la información del dispositivo se obtiene del dispositivo que seleccionaste al aceptar participar en un ciclo de prueba, y no puede cambiarse posteriormente. |
Tipos de Errores | uTest clasifica los errores en las siguientes categorias:
Se requiere que los probadores identifiquen y reporten estos errores con precisión. | Test IO clasifica los errores de la siguiente manera:
No realizamos pruebas de seguridad.
Aquí tienes más especificaciones: los errores de contenido están relacionados con todo tipo de información, no solo con texto (por ejemplo, traducciones; los errores tipográficos no se informan). En este contexto, la falta de imágenes y botones se considera un error de contenido en lugar de un error visual.
Los errores funcionales que afectan al rendimiento, como la carga interminable, pueden considerarse errores funcionales si afectan directamente a los usuarios finales, por ejemplo, el acceso a contenido o el progreso en una tarea.
Por otro lado, durante los ciclos de prueba de rendimiento, que se ejecutan según la demanda, la carga interminable se considera un problema de rendimiento y se informa como tal. Por lo tanto, medir la velocidad de Internet y los archivos .har es parte de los archivos adjuntos necesarios para incluir en el informe. |
La Gravedad de los Errores Funcionales | La gravedad de los errores en uTest se clasifica en:
En la cual decides cuál de estas categorías se aplica mejor al problema. | En Test IO, proporcionamos escenarios específicos para guiarte en la selección adecuada de la gravedad, los cuales se dividen en tres niveles:
Estos escenarios te ayudarán a analizar el problema desde diferentes perspectivas, teniendo en cuenta la funcionalidad comprometida y el impacto potencial del error en los usuarios finales. Por ejemplo, los errores que bloquean completamente el sistema se clasifican como críticos, mientras que si existe una solución fácil e intuitiva, como recargar la página, la gravedad adecuada será baja. |
Los Archivos Adjuntos en el Informe de Errores | uTest permite a los probadores adjuntar archivos relevantes a sus informes de errores, como capturas de pantalla, grabaciones de pantalla y archivos de registro.
Capturas de pantalla:
Grabaciones de pantalla:
| Los probadores de Test IO tienen la opción de adjuntar archivos, como capturas de pantalla, grabaciones de pantalla y archivos de bloqueo.
Captura de pantalla:
Grabación de pantalla:
Para pruebas de rendimiento, se requieren archivos .har. |
Comunicación de Pruebas | uTest fomenta la comunicación entre probadores, gerentes de proyectos y desarrolladores a través de un sistema de mensajería dedicado. Los probadores pueden buscar aclaraciones sobre los requisitos e interactuar con las partes interesadas durante todo el ciclo de pruebas. | Test IO pone énfasis en la comunicación en tiempo real, lo que permite a los probadores colaborar y discutir problemas a través del chat de prueba, comentarios en los informes de errores, el servidor de Discord y plataformas de correo electrónico, entre probadores, líderes de equipo (TL), Gerentes de Éxito del Cliente (CSMs) y clientes. Los probadores pueden hacer preguntas, buscar aclaraciones y recibir retroalimentación instantánea de los mencionados interesados, ya que estos pueden solicitar información de las tareas de los probadores. |
Pago por Error | En uTest, el pago depende de cuán valioso sea el error:
| El pago en Test IO varía según el tipo de tarea realizada. Hay tareas directamente relacionadas con Ciclos de Prueba. Por otro lado, otras, como Reproducciones, Confirmación de Corrección de Errores e Informe de Confirmación de Errores, se pueden llevar a cabo sin unirse al ciclo de prueba al que pertenece el informe.
Sin embargo, dentro de un ciclo de prueba, el pago depende del tipo y la gravedad del error, así como de las especificaciones del dispositivo. |
Tareas Pagadas y Bonificaciones | En uTest, los probadores pueden realizar:
| En Test IO, los probadores freelance pueden realizar estas tareas pagadas y recibir las siguientes bonificaciones:
En lugar de esperar a que el cliente acepte o rechace tu trabajo en Test IO, se te paga tan pronto como el Líder de Equipo tome tu error o ejecución. |
En conclusión, tanto las plataformas uTest como Test IO ofrecen experiencias únicas para los probadores en cuanto a procesos de prueba, tipos de errores, evaluación de la gravedad, archivos adjuntos y comunicación durante las pruebas.
Hay varias diferencias entre uTest y Test IO. uTest sigue un proceso de prueba estructurado con casos de prueba asignados, y los probadores envían informes de errores utilizando un formulario estructurado. Los probadores pueden impugnar errores rechazados, pero el rechazo afecta sus puntuaciones. En contraste, Test IO prioriza las pruebas exploratorias en tiempo real y compromete a los probadores en una retroalimentación y colaboración continua durante los ciclos de prueba que coinciden con su perfil. Test IO simplifica el proceso de reporte de errores con títulos de errores simplificados, tipos y niveles de gravedad, lo que permite la reorganización de pasos. Los esquemas de pago también difieren, con uTest categorizando el valor de los errores y Test IO basando los pagos en tipos de tareas, gravedad y especificaciones del dispositivo. Los canales de comunicación y el momento del pago también son diferentes entre las dos plataformas.
Los probadores son fundamentales para mejorar la calidad del software y garantizar la satisfacción de los usuarios finales, independientemente de la plataforma.