Reproducción de una incidencia¶
No se puede solucionar un problema si no se tiene el problema en primer lugar. Por tanto, reproducir la incidencia es un requisito previo para solucionarlo. En software, los problemas suelen denominarse "bugs", y las incidencias, "informes de fallos".
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 fue descrito en el informe? Si no puedes, tienes que averiguar por qué.
Para comenzar a reproducir una incidencia, necesitarás configurar un entorno de desarrollo.
Fallos 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 explicaciones vagas y un conjunto de condiciones vago. El problema es que muchos fallos varían en función del conjunto de condiciones implicadas, incluyendo como 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 antigua 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 la incidencia. 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 propósito será reducir el informe a la forma más simple posible que exhiba la incidencia. 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.
Fallos en la documentación¶
Los defectos en la documentación pueden manifestarse de diferentes maneras. Hay problemas de formato que dan lugar a representar incidencias. A veces ni siquiera se trata de un fallo; la persona puede haber leído mal la documentación o haber cometido una equivocación genuino. Esto no significa necesariamente que no haya una incidencia 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 una incidencia de documentación, querrá verificar que la incidencia notificada sigue existiendo realmente. En el caso de las incidencias de representación tendrá que crear la documentación para ver si puede reproducir la incidencia. Las incidencias del contenido son una cuestión de lectura para verificar que nadie ha enviado una actualización.
Actualizar la incidencia¶
El último paso en el proceso de triaje es documentar los resultados dejando un comentario sobre la incidencia.
Si eres capaz de reproducir la incidencia 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 informe 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, bitácoras 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 la incidencia 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 la incidencia; si tiene una teoría sobre la causa de la incidencia, también puede sugerirla. Sus comentarios ayudarán al equipo central a decidir cómo avanzar en la resolución de la incidencia.
En este punto, puede optar por intentar solucionar la incidencia que acaba de reproducir; alternativamente, puede anotar sus hallazgos e intentar reproducir otra incidencia.