Clasificar un problema¶
{{ nombre_formal }} recibe regularmente informes de usuarios que tienen problemas. Cuando se informa de un nuevo problema, ese informe debe ser triaged, es decir, necesitamos a alguien que lea el informe, tome la información proporcionada por el informador e intente reproducir el problema descrito.
Por desgracia, aunque los informes de incidencias suelen tener buenas intenciones, a menudo están incompletos o son confusos. El objetivo del proceso de triaje es rellenar las lagunas del informe original. Esto significa generar suficientes detalles para que podamos confirmar cómo se puede reproducir el problema, o confirmar que el informante original se equivocó en su informe.
Evaluar un problema no significa que debas solucionarlo. Dependiendo del problema, el triaje puede que ni siquiera implique escribir código. Puedes triar un problema con muy poco conocimiento de BeeWare, ya que debes ser capaz de seguir los pasos incluidos en el informe y reproducir el problema que se ha descrito.
Contribución al triaje de problemas¶
Reproduce el problema.
No se puede solucionar un problema si no se tiene el problema en primer lugar. Por tanto, reproducir el problema es un requisito previo para solucionarlo. En software, los problemas suelen denominarse "bugs", y las incidencias, "informes de errores".
Alguien ha informado de un fallo. Necesitas validar que los pasos que describe el informador dan como resultado el fallo del que se informa. ¿Puedes reproducir el mismo resultado haciendo exactamente lo que se describe en el informe? Si no puedes, tienes que averiguar por qué.
Errores en el código¶
En una situación ideal, tendrás la misma configuración que la persona que informó del fallo, seguirás los pasos y podrás reproducir el fallo tal y como se describe. En muchos casos, sin embargo, no será tan sencillo. Muchos informes de fallos sólo incluyen vagas explicaciones y un vago conjunto de condiciones. El problema es que muchos fallos varían en función del conjunto de condiciones implicadas, incluyendo cómo se interactúa con ellos, varias condiciones previas, el sistema operativo, la versión del sistema operativo, la arquitectura de la CPU, o si la máquina del usuario es vieja y lenta o nueva y rápida. Cuanta más información tengamos sobre la situación que rodea al fallo, mejor. Intenta reproducir el conjunto de condiciones que te ha proporcionado el informador. Si no puedes hacerlo, puede que tu siguiente paso sea solicitar más información a la persona que ha informado del fallo.
La mejor forma de reproducir un fallo es con el ejemplo más pequeño posible que muestre el problema. La mayoría de las veces los informadores no proporcionarán un ejemplo mínimo viable; si proporcionan algún ejemplo, será copiado directamente de su aplicación del "mundo real". Tu objetivo será reducir el informe a la forma más simple posible que muestre el problema. El mejor caso de reproducción es el programa más pequeño posible. Esta reducción es útil en sí misma porque determina cuál es el problema real. Cualquiera puede tomar el ejemplo mínimo, ejecutarlo y observará el fallo que se describe.
Errores en la documentación¶
Los errores en la documentación pueden manifestarse de diferentes maneras. Hay problemas de formato que dan lugar a problemas de representación. A veces ni siquiera se trata de un error; la persona puede haber leído mal la documentación o haber cometido un error genuino. Esto no significa necesariamente que no haya un problema con la documentación. El contenido puede ser poco claro o impreciso y dar lugar a confusiones o malas interpretaciones. Es posible que un concepto que debería tratarse no se trate, porque está completamente indocumentado.
Cuando se archiva un error por un problema de documentación, querrá verificar que el problema notificado sigue existiendo realmente. En el caso de los problemas de renderizado, tendrá que crear la documentación para ver si puede reproducir el problema. Los problemas de contenido son una cuestión de lectura para verificar que nadie ha enviado una actualización.
Actualizar la edición¶
El último paso en el proceso de triaje es documentar los resultados dejando un comentario sobre el problema.
Si eres capaz de reproducir el problema exactamente como se describe, eso es todo lo que necesitas decir. Deja un comentario diciendo que has confirmado que tienes el mismo problema, exactamente como lo describe el informador original.
Si puedes aportar algún contexto adicional, incluye los detalles de ese contexto. Esto podría incluir la posibilidad de reproducir el problema en un sistema operativo diferente, o con una versión distinta de alguno de los programas implicados, o cualquier otra cosa que varíe con respecto al informe original.
Si al informe original le faltaban detalles que usted necesitaba para reproducirlo, incluya esos detalles. Esto podría incluir detalles sobre el sistema operativo o la versión que el informe original no incluía, registros o trazas de pila más completos, o instrucciones más claras sobre la secuencia exacta de operaciones necesarias para reproducir el problema. Si has desarrollado una forma más sencilla de reproducir el problema (o el informador original no proporcionó un caso de reproducción), puedes incluir detalles de esa metodología de reproducción.
Si no puede reproducir el problema, también deje un comentario detallando lo que ha intentado. Saber dónde no existe un problema es casi tan importante como saber dónde sí existe, ya que eso ayuda a reducir las posibles causas. Si tienes alguna teoría sobre por qué no puedes reproducir el problema (por ejemplo, si crees que se trata de un error de uso o que el problema se ha resuelto con una actualización reciente del sistema operativo), incluye esa especulación en tu comentario.
Por último, puede hacer recomendaciones al equipo central. Si cree que el informe original es erróneo, sugiera que se cierre el problema; si tiene una teoría sobre la causa del problema, también puede sugerirla. Sus comentarios ayudarán al equipo central a decidir cómo avanzar en la resolución del problema.