El Portal de calidad de Embarcadero proporciona un proceso comunitario para resolver, aclarar y hacer un seguimiento de los problemas de calidad relacionados con los productos y servicios de Embarcadero. Los clientes de Embarcadero con una cuenta EDN pueden crear informes de errores y solicitudes de funciones, ver los informes de otros clientes y comentar y votar los informes más importantes para ellos. El personal de Embarcadero también participa en Quality Portal, proporcionando un vínculo permanente entre los clientes de Embarcadero y los equipos que producen los productos de Embarcadero.
Los desarrolladores que tengan un contrato de soporte y mantenimiento activo y necesiten una respuesta urgente a una consulta deben generar un ticket de soporte en su lugar: un registro de Quality Portal no es lo mismo que un ticket de soporte.
Esta guía está aquí para ayudarlo a informar problemas sobre el producto RAD Studio , incluidos Delphi y C++Builder . Esta publicación de blog actualiza y reemplaza la publicación en https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/
Tabla de contenido
Uso del Portal de Calidad de Embarcadero
Antes de utilizar Quality Portal (QP), debe crear su cuenta de usuario EDN (EDN significa Embarcadero Developers Network). Vaya a https://my.embarcadero.com para crear su cuenta, si no tiene una existente. Esta es la misma cuenta que puede usar para registrar un producto de Embarcadero.
Con su cuenta, vaya a https://quality.embarcadero.com/ e inicie sesión en Quality Portal (o QP).
Proceso comunitario
Quality Portal es una aplicación respaldada por pares, donde otros miembros de la comunidad pueden comentar o votar sobre informes existentes, o crear los suyos propios. Con Quality Portal, la comunidad tiene un gran impacto al ayudar a Embarcadero a priorizar la solicitud que hacen nuestros clientes. Puede “observar” los problemas de otros usuarios para recibir una notificación cuando se actualicen.
Ya mencioné anteriormente, pero vale la pena repetirlo, que Embarcadero también ofrece un programa de soporte técnico, al que puede acceder en línea en https://www.embarcadero.com/support , que incluye soporte de instalación y registro y una cantidad de tickets de soporte técnico ( dependiendo de su nivel de soporte). Si desea atención inmediata para un problema, utilice Embarcadero Support y no Quality Portal.
Maximizando los beneficios de su Portal de Calidad
Puede obtener el mayor beneficio de QP si lo usa “correctamente”. Esta sección de la guía del usuario describe técnicas efectivas para publicar informes de errores, realizar solicitudes y sugerencias de funciones y, de hecho, trabajar en los errores, funciones y sugerencias. Después de todo, está utilizando QP porque desea que Embarcadero aborde los problemas que le preocupan. Esta sección de la guía del usuario describe las diversas formas en que puede maximizar su impacto positivo con Quality Portal.
Guía de informes de errores
Para muchas personas, el interés inicial en QP serán los informes de errores. Los principios discutidos en esta sección analizan formas obvias y sutiles de crear y procesar informes de errores de manera efectiva.
Verá un formulario similar a:
Se específico
Escriba informes de errores efectivos. Sea lo más completo posible al describir el error y lo que sucede. Incluir pasos. La forma más eficiente de corregir un error es proporcionar un caso de prueba reproducible. Si no puede reproducirlo fácilmente, describa lo más completamente posible lo que sucedió antes de ver el error. Los informes de errores deben proporcionar toda la información requerida en un solo lugar . En caso de que tenga un caso de prueba reproducible, pero no quiera compartir el código en el sistema QP público por algún motivo, podemos organizar un proceso de envío directo y más privado: indíquelo en el propio informe. Tenga en cuenta también que para algunas áreas de productos como CodeInsight y FireDAC hay pasos específicos para proporcionarnos información de registro, como se explica en la sección de consejos al final de esta publicación de blog.
Regla de oro: incluir solo un problema en cada informe.
Tipo de problema
- Error: un problema con el producto
- Error de documentación: un problema con la ayuda o la documentación del producto.
- Solicitud de función: una nueva función que le gustaría ver en el producto
Tenga en cuenta que las solicitudes de funciones siguen un camino diferente: son examinadas por los gerentes de producto (en lugar del equipo de control de calidad) y asignadas a los desarrolladores para su investigación o implementación en una versión futura.
Ocasionalmente, convertimos un problema de un tipo a otro diferente, por ejemplo, cuando un informe de error realmente se puede abordar agregando una característica importante al producto o en caso de que el cliente lo presente incorrectamente.
Resumen
Proporcione al informe un resumen breve pero descriptivo. “TButton no funciona” no es un buen título, pero “[Android] Se genera un error cuando se invoca TButton al tocar dos veces” es mejor.
Cuando sea apropiado, use etiquetas en el título para ayudar a quien lo lea a comprender mejor el contexto.
Un buen resumen ayuda a identificar rápidamente lo que está pasando y ayuda a reducir los problemas duplicados. Evite describir problemas genéricos en el resumen. Nunca debes usar:
- Tengo un problema con XYZ
- XYZ no funciona correctamente
Algunos ejemplos de resúmenes deficientes y sus buenos equivalentes:
Pobre: Infracción de acceso en IDE
Mejor: abrir un archivo .pas vacío genera una infracción de acceso
Pobre: error de notificación push
Mejor: el recuento de notificaciones push agrega una notificación adicional
Componente
Identifique qué subparte del software se ve afectada por este error.
- Instalar
- Mono de Fuego
- VCL
- Compilador de C++ (consulte las sugerencias para el envío de errores del compilador/vinculador de C++)
- RTL en C++
- Compilador Delphi
- Delfos RTL
- Enlazador (consulte las sugerencias de envío de errores del compilador/enlazador de C++)
- Base de datos
- depurador
- IDE (Entorno de desarrollo)
- ayuda y doc
- Población
Descripción
Toda la información generada por el tema. Cuando esté disponible, incluya:
- Mensaje de error completo
- Pila de llamadas completa
- Si cree que es relevante, incluya información sobre su entorno (por ejemplo, la versión de Android o la configuración regional de Windows)
- Para los errores que se manifiestan visualmente (p. ej., los controles no se muestran correctamente o problemas de diseño de IDE), incluya una captura de pantalla para ayudar a quien lea su informe a evaluarlo.
- Si es relevante, agregue registros de dispositivos, como la salida logcat para Android.
- Para mensajes de error o pilas de llamadas, use las etiquetas {code} o {quote}.
- Si basa su informe en una fuente de información externa (p. ej., una página de MSDN para una llamada API), incluya un enlace a esa información.
- Si su informe de errores contiene código, adjúntelo al proyecto o agréguelo a la sección Pasos . Si agrega código como texto a su informe, asegúrese de usar etiquetas {code}. Esto evita que JIRA interprete su código y lo arruine y también ayuda con la legibilidad del informe (evita desplazarse por algunas páginas para llegar a los campos relevantes).
- Mantenga el tamaño del archivo adjunto al mínimo. Comprima sus archivos y nunca incluya archivos binarios generados al compilarlos (por ejemplo, DCU o EXE). Solo use el formato ZIP, nunca use otros formatos que requieran un programa de terceros.
- No incluya más de un problema en un informe. Informe por separado y vincúlelos según sea necesario.
Pasos
El objetivo es mostrar cómo reproducir el error. Manténgalo conciso y fácil de leer, debe describirlo como una receta para reproducir el error. Intenta alcanzar el objetivo con el mínimo número de pasos.
Nota: Los mensajes de error o las pilas de llamadas van en la Descripción, no en los Pasos. Por ejemplo, la descripción debe decir “Se genera el siguiente error al invocar TButton al tocarlo dos veces en mi dispositivo Android: [mensaje de error]” y los pasos solo deben proporcionar instrucciones sobre cómo reproducir el problema.
Resultados esperados y reales
Al final de su descripción paso a paso, debe describir cuál debería ser el resultado esperado y qué sucede realmente.
Ejemplo de una mala descripción:
Esperado: la aplicación no falla
Real: la aplicación falla
Mejor uso:
Esperado: la aplicación muestra el menú XYZ
Real: la aplicación genera una infracción de acceso (consulte el seguimiento de pila adjunto)
Aislar informes
Sea concienzudo acerca de enviar pensamientos corolarios como informes nuevos , no solo incluirlos como comentarios para un informe existente. Esto asegurará que el problema sea rastreado y eventualmente solucionado.
Comprender los informes duplicados
El equipo de control de calidad marca un informe “duplicado”. Qué informe está marcado como “maestro” y cuál se basa en un “duplicado” en qué informe brinda la información más precisa y detallada que describe el problema que ambos (o muchos) informes analizan.
El informe maestro puede cambiar con el tiempo si alguien más envía otro duplicado, pero ese duplicado en realidad describe mejor el problema. “Maestro” y “duplicado” no tienen nada que ver con quién entró primero, pero qué informe cubre el problema con mayor precisión.
Por lo general, un problema “duplicado” tiene el estado “Resuelto”, una resolución “Duplicado” y está vinculado al problema “principal” con un enlace “duplicados”. Debe verificar el estado y ver las actualizaciones del problema “maestro”.
Cómo interpretar algunos de los campos en QP
Debido a que Quality Portal se sincroniza con los sistemas internos, hay algunos campos que tienen significado para nuestros procesos internos que pueden no tener un significado obvio fuera de nuestros procesos internos. Se espera que las siguientes tablas expliquen algunos de los valores para estos campos sincronizados.
Campo de estado
|
Valor
|
Descripción
|
|---|---|
| Reportado | Nuevo defecto, requiere revisión del probador |
| Abierto | Defecto abierto, requiere resolución. El problema permanece en este estado mientras se trabaja internamente. |
| Resuelto | Trabajo realizado y entregado en un producto de envío, el reportero puede verificar o resolver disputas |
| Necesita retroalimentación | Requiere información/pasos adicionales |
| Cerrado | Defecto cerrado, no se requiere acción |
Un informe comienza con un estado de “Reportado”. Cuando un probador de control de calidad de Embarcadero lo valida en el sistema interno de seguimiento de errores de Embarcadero, el estado pasa de “Reportado” a “Abierto”. Cuando se completa el trabajo con el informe y la solución es parte de un producto lanzado, el estado pasa de “Abierto” a “Resuelto”. Tenga en cuenta que un problema se marca como resuelto solo cuando la corrección está disponible, no cuando I+D la implementa internamente.
Campo de resolución
|
Valor
|
Descripción
|
|---|---|
| Fijado | Se ha solucionado el error. |
| No puede reproducirse | El error no se pudo reproducir tal como se envió en la última versión del producto |
| Funciona como se esperaba | El comportamiento es el diseñado o es un efecto del diseño actual |
| Duplicar | El error es un duplicado (debe tener en cuenta el número de error duplicado) de otro problema, que aún podría estar abierto |
| Error de caso de prueba | La descripción del error no es válida tal como se envió |
| Necesita más información | Necesita más información/demostración/pasos para que nuestro equipo reproduzca |
| Ya no aplica | Se eliminó la función o el error ya no es relevante |
| no arreglará | Hubo una decisión de que esto nunca se implementará o arreglará. |
Para los problemas que se devuelven con Necesita más información , el estado se marcará como ‘ Necesita comentarios ‘ para permitir que el reportero agregue información adicional. Debe usar el botón ” Actualizar contenido ” al enviar información adicional. Una vez que los cambios enviados a través de ‘Actualizar contenido’, el estado vuelve a ‘Informado’ y el equipo de control de calidad repetirá la validación internamente. ” Actualizar contenido” también se puede utilizar cuando se realizan correcciones a un problema ya enviado.
En general, intente aclarar la descripción agregando más detalles y/o información de contexto utilizando las recomendaciones dadas anteriormente o agregue/revise los pasos para reproducir. Adjuntar capturas de pantalla y/o proyectos también sería útil. Un video corto y enfocado también puede ser bueno para entender.
Algunos consejos más
Para problemas relacionados con el motor CodeInsight LSP, consulte la información al final de este artículo de docWiki . Tenga en cuenta que los registros de LSP pueden contener partes significativas del código fuente que se está analizando, por lo que si hay razones para mantenerlo reservado, solicite un canal de comunicación directo en lugar de agregar el archivo de registro a un informe QP público.
Del mismo modo, si está informando sobre problemas de FireDAC, debe proporcionar datos del entorno y registros de seguimiento. Los pasos se describen en este artículo .
Puede consultar los consejos de formato de texto QP del artículo original en https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/#Hints_and_Tips
Finalmente, una buena fuente de recomendaciones para informar errores está disponible en http://www.mozilla.org/bugs/bug-reporting.html .