Reproducción de un 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é.
Para comenzar a reproducir un problema, necesitarás configurar un entorno de desarrollo.
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.
En este punto, puede optar por intentar solucionar el problema que acaba de reproducir; alternativamente, puede anotar sus hallazgos e intentar reproducir otro problema.