Defectos y sugerencias

Apuntes:

Defectos y Sugerencias

Un defecto es aquello que no cumple los requerimientos ya sea funcionales, de diseño, de arquitectura, y es la consecuencia de un error humano en el código o en la interpretación de la información con la que se construyó el software.

Una sugerencia podría ser cómo la experiencia del usuario se ve afectada.

Ejemplos de sugerencias

• Ejemplo #1, el mensaje de error no comunica adecuadamente
• Ejemplo #2, el color de la pantalla, no contrasta bien con el texto
• Ejemplo #3, no recibí un correo adicional de confirmación

“Si la calidad la define el usuario final… sus sugerencias se vuelven defectos?”

Sugerencias convertidas en defectos / Actualizaciones de software

• Hace lenta la operación
• Detiene parcial o totalmente el proceso
• El contenido o el flujo confunde al usuario
• Deja cometer muchos errores al usuario
• La traducción o el lenguaje empleado no es correcto
• No funciona sin internet

Yo agregaría un campo adicional que sería el impacto del defecto, de esta manera se podría priorizar su ciclo de reparación de acuerdo a este impacto. Sin embargo, ¿Quién definiría este impacto? ¿El tester que está documentando el defecto? ¿Cómo podría validarse si el impacto asignado es el correcto?
Otro campo que yo agregaría, dependiendo de la complejidad del software sería el módulo en el cual se encontró el defecto, para que la persona que revisa estos defectos documentados, pueda filtrarlos fácilmente; algo que por ejemplo uso para documentar los bugs cuando realizo pruebas, es usar prefijos dependiendo del módulo donde encuentro el bug, por ejemplo si el que se menciona en el video es del formulario de registro se podría colocar REG-109 o si es de login LOG-001.

Esta sería mi forma de reportar

Si la calidad la define el usuario final, ¿Sus sugerencias se vuelven defectos?
R= No siempre lo que el usuario pide es lo que necesita. En ese caso habría que hacer un análisis en conjunto para determinar si la sugerencia da valor al negocio y en caso de que no, hacer labor de convencimiento con el cliente para que no se tome como un defecto.

La corrección del texto de la clase podría ser:
Este correo ya está registrado.
Ingresa otro correo o haz click aquí para restablecer tu contraseña.

En realidad que muestre esa alerta sin decir que ya hay una cuenta con ese mail en la plataforma no es un error ya que eso (en terminos de seguridad informatica) no me da mas informacion de la que necesito, por ejemplo: digamos que quiero saber si una persona que conozco (o no) tiene una cuenta registrada en una pagina de citas y yo conozco su hotmail… si me muestra que ya hay una cuenta en ese sitio pues es porque esa persona se registro… asi mismo puede pasar con otras plataformas a las que las personas no les gustaria que por el simple hecho de registrar su mail puedan saber en todos las plataformas que estan de alta.

Nosotros ademas agregamos una columna con el nombre de la persona que realizo el test y detecto el defecto, de manera que si surgen dudas al replicar el error, se puedan contactar

Pero el resultado esperado deberia ser recibir un error de “la cuenta ya esta registrada ingrese otra” ya que no debe permitir registros dobles

Para que lo tomen en cuenta los testers:

Debe recordarse, que la escritura apropiada es clic, plural clics, y no la grafía inglesa click.

El resultado esperado en el ejercicio seria mas acorde un mensaje de error como: “El correo ya está registrado”

Seria genial poder tener acceso a esos excel que realizas para descargarlos

Considero mejor para captura de evidencias una aplicación llamada Screenspresso, es gratis y con el fin de resaltar o seleccionar mejor el contenido, añadir texto adicional, degradar u ocultar información, etc. Es muy bueno, o también Snagit, que ya sirve para hacer grabación de una ejecución de pruebas, o de cualquier otra cosa.

Si la calidad la define el usuario final… ¿sus sugerencias se vuelven defectos?

A mi punto e vista si, pues es algo que hay que corregir y serian defectos de usabilidad

Muy claro los conceptos que explicas en cada clase. Es muy importante que los mensajes sean lo más claros posibles para que sea entendible por cualquier persona.

En Mantis BT se puede reportar Bug de esa forma, hay un espacio para el paso a paso.

Defectos y sugerencias
Defecto es aquello que no cumple los requerimientos
Una sugerencia es cómo la experiencia del usuario se ve afectada.
"Si la calidad la define el usuario final… sus sugerencias se vuelven defectos?"
Sugerencias Convertidas en defectos pueden convertirse en actualizaciones

• Hace lenta la operación
• Detiene parcial o totalmente el proceso
• El contenido o flujo confunde al usuario
• Deja cometer muchos errores al usuario
• La traducción o el lenguaje empleado no es correcto
• No funciona sin Internet

Debido a qué no cuento con experiencia como programador-desarrollador o de un tester adicionalmente comparto la información siguiente:
Documentación de los reportes de testing
Para mejorar la documentación del reporte y su lectura, se sugiere contar con los siguientes atributos:

Un caso de prueba escrito correcta y detalladamente: Facilitará el entendimiento y redacción del defecto.

Identificador del reporte: Un identificador único que permita trazar el defecto .
Tarea padre: Generalmente el caso de prueba es la tarea padre para asociar el defecto, esta asociación facilita la trazabilidad.

Informador o tester: Responsable del reporte, quien encuentra el defecto y redacta el reporte.

Estado: Según los estados definidos para el ciclo de vida, por

ejemplo: Abierto, cerrado, en revisión, anulado, etcétera. Este ítem se detalla con precisión más adelante.

Versión: Especificar en qué versión del paquete, funcionalidad, producto o commit, se encontró el defecto.

Severidad: La severidad facilita la priorización para la resolución de la incidencia y afecta los datos que se obtendrán en el informe. Este ítem se detalla con precisión más adelante.

Reproducibilidad: Identificar si es un defecto común, si nunca se ha intentado o si es un defecto frecuente.

Resumen: Escribir un título que permita interpretar fácilmente el defecto.
Pasos para reproducir el error: Describir todos los pasos que faciliten el camino para que cualquier persona del equipo pueda llegar a reproducir el defecto.

Información adicional: Datos de prueba, diagnóstico.
Ambiente o ubicación: Documentar la base de datos de pruebas, el nombre o identificador del ambiente.
Imágenes y/o videos: Respaldar el reporte con imágenes o videos para ampliar y facilitar su lectura.
Descripción del defecto: Este ítem se detalla a continuación.
Descripción del defecto
Se ha dejado este tópico aparte por la atención que merece. De la buena redacción del defecto depende en gran medida que se logren minimizar los problemas asociados a los altos reprocesos producidos por las falencias en la interpretación del reporte.

Para lograr con mayor facilidad este objetivo, se puede realizar la descripción del defecto teniendo en cuenta los siguientes elementos:

Cuándo: Acción que describe el evento y las variables dentro de la descripción del caso de prueba.

Qué: Resultado que se obtuvo al ejecutar la acción (cuándo), que discrepa del resultado esperado.

Dónde: Ubicación del objeto de prueba.

Resultado esperado: Describe el objetivo de la funcionalidad.

Si es una sugerencia que está afectado el objetivo de la aplicación (ej, no se entiende el UX de la app y no se sabe por donde se paga) es un defecto.

¿Si la calidad la define el usuario, sus sugerencias se vuelven defectos?

Mi opinión es que depende de lo que reporte el usuario. Si ya hubo un análisis previo y una verificación con el cliente de dicho análisis, y aún así un requerimiento no funcione, puede ser que sea un defecto por parte del desarrollador.
.
Pero, si el sistema cumple con lo solicitado, el usuario solo podría anunciar sugerencias.

En mi proceso como tester encontraba defectos como por ejemplo al clickear en el calendario y usar un dia y oprimir 2 veces y arrastrarlo hacia arriba, podría apreciar un bug visual que no podría afectar la plataforma, o al usuario ya que jamas haría algo como eso, pero pienso, si ese tipo de bugs que se sacan insistiendo en algún lugar se deben contar como defectos para arreglar o no hay necesidad, ya que el desarrollador decía que el usuario jamas llegaría a realizar algo como eso y que el bug no daña la experiencia del usuario ni la plataforma. Todo esto termino fue tomado como una sugerencia no mas y no como un defecto.

Si la prueba consiste en registrar una cuenta de correo duplicada, el resultado no debería ser cuenta dada de alta, debería ser mensaje de error informando que ya existe un usuario con esa cuenta.

Si al usuario no le gusta la calidad, quizás no sea un Defecto puede que desde el inicio no se capturo bien los requerimientos del cliente.

Dependiendo del objetivo del proyecto podemos encontrar que no todos quieren que des sugerencias, solo encuentres defectos. Cosas que pongan en riesgo por costo, prestigio o calidad del producto.
Defectos
Es aquello que no cumple los requerimientos funciones, de diseño, de arquitectura y es la consecuencia de un error humano en el código o la interpretación de la información.
Sugerencias
Es cómo la experiencia del usuario se ve afectado. La lentitud del proyecto, la legibilidad, combinación de colores, la forma de navegar no es adecuada.
Si la calidad la define el usuario final … sus sugerencias se vuelven defectos??
Las sugerencias convestidas en defectos / actualizaciones de software

Dependiendo del objetivo del proyecto podemos encontrar que no todos quieren que des sugerencias, solo encuentres defectos. Cosas que pongan en riesgo por costo, prestigio o calidad del producto.

Defectos: Es aquello que no cumple los requerimientos funciones, de diseño, de arquitectura y es la consecuencia de un error humano en el código o la interpretación de la información.

Sugerencias: Es cómo la experiencia del usuario se ve afectado. La lentitud del proyecto, la legibilidad, combinación de colores, la forma de navegar no es adecuada.

Dependiendo de la sugerencia del usuario, porque si es algo que pueda afectar los requerimientos iniciales pensaría que si, pero si es un

" Si la calidad la define el usuario final… sus sugerencias se vuelven defectos? "

Pienso que desde el momento que el usuario sugiere algo, es porque piensa que al software le falta algo para que se ajuste a sus necesidades. Por lo tanto lo más probable es que, eso que le falta es un defecto, desde el punto de vista del usuario.

podría llegar a convertirse una sugerencia del cliente en un defecto pero esto luego de una evaluación de esta, ya que el usuario podría sugerir poner un componente en una posición donde él supone será mas cómodo pero resulta que interfiere con otras partes del software

Yo agregaría el nombre de la funcionalidad o modulo donde aparece el defecto y si ya fue revisando o no luego de arreglado

Para los que hicimos Testing de Videojuegos no se asusten. Comienza explicando por el CUERPO del Bug y luego concluye con el ENCABEZADO del Bug.

No, para eso existen las mejoras y se puede integrar en alguna interacción

Me gusta documentar defectos y errores en forma de video con Loom video, es más rápido y el equipo en general lo entiende mejor.

muy buena clase

Estaria bueno agregar el nombre y el ID de quien va a reportar el defecto, la URL

Scrum es una metodología ideal para lidiar con el cambio.

En especifico para incorporar las sugerencias de los usuarios y los cambios solicitados por los clientes.

Las sugerencias del usuario no se convierten en defectos si están fuera del alcance del proyecto.

++Si la calidad la define el usuario, sus sugerencias se vuelven defectos?
No necesariamente en caso de que ya se haya llegado a un acuerdo previamente entre la empresa y el cliente, y además el software cumpla con lo requerido.

en mi opinión las sugerencias del usuarios afectan al negocio de forma indirecta, por ende ellas serian defectos o deficiencias del software…

Si la calidad la define el usuario, ¿la sugerencia se vuelve un defecto?

Dependerá del alcance acordado que se haya llegado con el cliente. Pero si funcionalmente la solución cumple lo acordado, se debería negociar con el cliente la adición de esa sugerencia al alcance.

Yo agregaría la fecha que lo he encontrado y la fecha de realización para monitorear cuánto tiempo se han demorado en resolver el problema.

Me gusta la frase del minuto 4, mi opinión sobre la frase es que las sugerencias están apoyadas en cómo debería comportarse una aplicación, por lo tanto se interpretan como defectos.

Sería bueno que se permitiera descargar ese documento realizado por la profesora, a pesar de ser ejemplo es una visualización muy buena

Esos mensajes “Genéricos” de errores hasta puede crear inconformidad en los usuarios finales

Existen muchos casos, si tiene muchas sugerencias entonces habría que ponerlo como prioridad?
Si el uso se dificulta pero no impide el objetivo y el personal esta obligado a usarlo, entonces lamentablemente será aceptado el software sino le afecta el jefe inmediato, pasa mucho en instituciones públicas.
Si el software debe ser atractivo para los clientes como un juego o un servicio de paga, entonces si se le dará prioridad a la facilidad que brinde la interfaz.

Con respecto a la pregunta:

Mas o menos, creo que el usuario final es el que mejor da feedback de la app porque al final es el quien la usa, PERO, no podemos arreglar o tener en cuenta TODAS las sugerencias que dan los usuarios porque lo hacen desde su propio unto de vista y tal vez mejorar lo que sugieren puede dañarse para otro que le guste.

Lo mejor (en mi opinion) es mirar cuantas de estas sugerencias se repiten o estan ligadas ya que ahi si seria para un bien mayor.

Como principio de seguridad, es preferible no dar mayor detalle al usuario al momento de fallar una autenticación, para no facilitar su tarea a los hackers. Un mensaje vago como el que muestra inicialmente el ejemplo es preferible.

Como registrar un bug

Si el usuario hace sugerencias, creo que si son un defecto

Nombre
El color de la pantalla no contrasta bien con el texto
Descripción
El texto tiene un color claro que no se distingue bien del fondo
Pasos
1, Ir al sitio
2, No se distingue el texto
Resultado esperado
Se pueda leer con poca luz
Resultado actual
No se lee

Nombre
No recibí un correo adicional de confirmación
Descripción
El mail confirmando el registro no llegó ni por Spam
Pasos
1, ir al sitio
2, Dar click en registro
3. Registrarse
4, Esperar el correo de confirmación
Resultado esperado
Llegó el mail y activó la cuenta
Resultado actual
No llegó el mail ni por spam

Bastante interesante la información

¿Si la calidad la define el usuario, sus sugerencias se vuelven defectos?
Creería que si la experiencia del cliente no ha sido óptima en un alto o aceptable porcentaje sus sugerencias si se convierten en defectos ,lo primordial es la experiencia del usuario ,eso sí como es un defecto no esperado se debe dar el tipo de prioridad y analizar el impacto que tiene en el proyecto

Los defectos son errores que generan el no cumplimiento de un requerimiento determinado.

Sugerencia: Cuando no se visualiza hacia que público estará dirigido el sitio o la aplicación. Y un usuario nuevo no puede disfrutar de una experiencia optima, generándole conflictos o problemas a la hora de utilizarla.

Una herramienta interesante para la gestión de defectos es Mantis.

Yo diría que las defectos u errores encontrados en las aplicaciones usadas por usuarios no pensados se convierten en defectos no esperados, lo cual por supuesto es una opción de mejora pero siguen siendo defectos, una nueva versión de estos.

Sugerencias convertidas en defectos pueden ser actualizaciones de software. Ejemplo, cuando Whatsapp empezó a incursionar en otros mercados como Asia.
O como Uber en China, quien tuvo que reaprender como gestionar esos usuarios.

No siempre las sugerencias de un cliente son defectos, sin embargo, todo software debe satisfacer las necesidades del cliente ya sea un producto o un servicio y esto conlleva a la calidad, eficiencia, flexibilidad, corrección, confiabilidad, mantenibilidad, portabilidad, usabilidad, seguridad e integridad

No, las sugerencias del usuario tienden a ser fallo y no defectos según la ISTQB

Las sugerencias que dan los clientes siempre deben ser tomadas como defecto y se les debe dar el tratamiento adecuado para mitigar el riesgo . las sugerencias de los clientes nos llevan a encontrar alternativas de mejora.

¿Si la calidad la define el usuario, sus sugerencias se vuelven defectos? No se convierten en defectos, mientras la observación dada por el cliente no se haya tenido en cuenta dentro de las definiciones iniciales y se convertiría en oportunidades de mejora

Si el usuario define la calidad se convierte en defecto ya que no satisface la necesidad y causa rechazo tal vez por malas practicas desde la toma de requerimientos o errores los pasos del ciclo de vida del software

creeria que las sugerencias del usuario final no serian defectos, creo que serian como alcances o iteraciones que se pueden agregar en una nueva version o un la version 2.0

Muy buena clase

Prueben lightshot como herramienta para screenshots

En nuestra empresa usamos gifs, para mostrar los pasos del error, así lo pueden ver de forma más clara y en la documentación agregamos la URL del video

La documentación es muy importante al momento de dar a entender al equipo lo que va pasando con el software, pero lo mas importante es saber documentar, si no hay un buen trabajo se puede decir que no se esta llevando a cabo como deber ser, y viene el re trabajo.

me encantan estas clases, muy asertiva

Excelente clase

Serian requerimientos del usuario, entraría el estudio previo de parte y parte hasta llegar aun acuerdo…

Esa hoja de cálculo no parece ser Excel, creo que es Google Docs.

Yo creo que cuando un producto es funcional y funciona muy bien (ósea que no hay errores o bug), aunque para el cliente no sea de calidad, no significa que las sugerencias del cliente se conviertan en defectos. Por ejemplo Amazon funciona bien y una sugerencia mía seria que se cambiar el diseño de la plataforma, que es horrible. Sin embargo, como la plataforma funciona, las personas la usan incluso aunque la UI es horrible

Un mensaje de error erróneo se ha generado*

Las sugerencias del usuario no necesariamente se convierten en defectos del software, se pueden tomar como requerimientos adicionales ya que pueden estar fuera del alcance inicial del proyecto.

Un defecto es lo mismo que una falta (“fault”), problema o “bug”, pero el defecto es mucho más que un error de la aplicación, realmente un defecto abarca todo el proceso productivo del desarrollo de software.
La mayoría de los defectos se producen en etapas tempranas del proceso de desarrollo, por lo que en estas etapas debe existir una estructura robusta de control y prubas, debido a que los defectos afectan el comportamiento del programa.

es el primer caso de prueba que hago en mi vida /…/