¡Hola! Nos gustaría expresar nuestra gratitud a todos los que pasaron por la mesa de Test Team (o por la mesa de CoreCore Core es el conjunto de software necesario para ejecutar WordPress. El equipo de desarrollo de Core crea WordPress.:Test) en el Día del Colaborador de WCEU de este año 🙇. Sus ideas, perspectivas y debates abiertos ayudan a fomentar iniciativas fundamentales para probar WordPress. ¡Gracias a todos los que participaron!
Los participantes del evento trataron los siguientes temas (algunos de los cuales también se mencionaron en #core-test en Slack):
Plantillas de informes de pruebas
- En las directrices propuestas para los informes de pruebas, aclarar cómo deben utilizarse en los informes los emojis de marca de verificación verde (✅) y “X” roja (❌): esperado frente a inesperado.
- Separar las plantillas de informes en subpáginas bajo una descripción principal de “Informe de prueba” en el Manual de pruebas para mejorar la legibilidad.
- Propuesta para proporcionar plantillas de creación de tickets para informar de incidencias en TracTrac Trac es el lugar donde los colaboradores crean incidencias por errores o solicitudes de funcionalidades, de forma similar a GitHub.https://core.trac.wordpress.org/., similares a las de Gutenberg Issues (por ejemplo, para errores frente a mejoras).
@todoInvestigar si Trac admite opciones de plantillas rellenadas previamente, para la publicación inicial y/o los comentarios.
Contribuciones a las pruebas más sencillas
- Mejorar/actualizar las directrices del Manual de pruebas para crear un entorno local de WordPress.
- El deseo de contar con entornos de prueba efímeros (sin necesidad de una instalación localInstalación local Una instalación local de WordPress es una forma de crear un entorno de prueba mediante la instalación de una pila LAMP o LEMP en el ordenador local.) para probar solicitudes de incorporación de cambios y parches. Algunas ideas:
- Crear una versión de gutenberg.run orientada a Core.
- Debería admitir tanto solicitudes de incorporación de cambios como archivos adjuntos de parches individuales de Trac.
- Utilizar un servicio similar al empleado para calypso.live.
- Crear una versión de gutenberg.run orientada a Core.
- Añadir al Manual de pruebas directrices para aplicar parches desde GitHubGitHub GitHub es un sitio web que ofrece una implementación en línea de repositorios git que otros desarrolladores pueden compartir, copiar y modificar fácilmente. Los repositorios públicos se alojan de forma gratuita; los repositorios privados requieren una suscripción de pago. GitHub introdujo el concepto de la “solicitud de incorporación de cambios”, mediante la cual los cambios de código realizados en ramas por los colaboradores pueden revisarse y debatirse antes de que el propietario del repositorio los fusione. https://github.com/ o Trac, cubriendo los distintos métodos de “buenas prácticas”.
- Reiterar la importancia de contar con distintos tipos de entornos entre el grupo de colaboradores de pruebas (Docker/
wp-env, VVV, Laravel Valet, Local, etc.). No debería existir una preferencia por “el mejor” o “un único modo” de ejecutar/probar WordPress, ya que debería reflejar la diversidad del mundo real en la comunidad de WordPress. - Asignar una nueva
week-in-testcategoríaCategoría La taxonomía de “categoría” permite agrupar publicaciones o contenido que comparten un vínculo común. Las categorías están predefinidas y son amplias. a las publicaciones de Semana en pruebas, para facilitar el filtrado de “por dónde empezar” en las pruebas (actualmente agrupadas bajo la categoría más genéricasummary).
Pruebas de extremo a extremo (E2E)
- Preguntas sobre dónde comenzar las pruebas E2E en WordPress:
- Se mencionaron los esfuerzos de migración de las pruebas E2E a Playwright.
- Se animó a los colaboradores de E2E a ponerse en contacto en #core-test y #core-editor para obtener información actualizada, así como con los participantes en debates anteriores.
- Se señaló que es habitual que las pruebas E2E fallen de forma intermitente, lo que puede confundir y obstaculizar el desarrollo. Esto suele atribuirse a retrasos inesperados en las actualizaciones del DOM.
- Considerar que las pruebas E2E pueden validar pasivamente la accesibilidadAccesibilidad La accesibilidad (comúnmente abreviada como a11y) se refiere al diseño de productos, dispositivos, servicios o entornos para personas con discapacidades. El concepto de diseño accesible garantiza tanto el “acceso directo” (es decir, sin asistencia) como el “acceso indirecto”, que significa compatibilidad con la tecnología de asistencia de una persona (por ejemplo, lectores de pantalla de ordenador). (https://en.wikipedia.org/wiki/Accessibility) (“a11yAccesibilidad La accesibilidad (comúnmente abreviada como a11y) se refiere al diseño de productos, dispositivos, servicios o entornos para personas con discapacidades. El concepto de diseño accesible garantiza tanto el “acceso directo” (es decir, sin asistencia) como el “acceso indirecto”, que significa compatibilidad con la tecnología de asistencia de una persona (por ejemplo, lectores de pantalla de ordenador). (https://en.wikipedia.org/wiki/Accessibility)”) como un subproducto beneficioso.
- Añadir una sección sobre E2E a Semana en pruebas para aumentar la concienciación sobre este aspecto de las pruebas de WordPress.
Cambio de hora de las reuniones de los martes
- Se sugirió cambiar las reuniones de los martes de
<test-chat>y<test-triage>de las 17:00 a las 16:00 UTC para permitir una mayor participación de los colaboradores europeos. Comparte aquí tu voto o tus comentarios.
Gracias a @boniu91 por la revisión entre pares de esta publicación.