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/

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

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

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 .

---

Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Start Free Trial   Upgrade Today

   Free Delphi Community Edition   Free C++Builder Community Edition

---