MODULO 1 ENCUENTRO 4 / 17
¡Te damos la bienvenida a tu cuarto encuentro de trabajo!
-
Check de 1 minuto: ¿Cómo te sientes hoy? Tómate un minuto y dedícalo a agradecerte a ti mism@ por hacer este esfuerzo de aprender algo nuevo. Ese futuro del que hablan todos ya está aquí: una persona cambiará de carrera de 5 a 7 veces en su vida. No es una frase de marketing, es real. Si no nos crees, aquí tienes un artículo en inglés y aquí uno en español.
-
Ya estás en camino: si este es tu primer estudio luego de la escuela, sentará las bases de los que sigan. Y si estás aquí complementando estudios anteriores, este programa enriquecerá tus conocimientos.
¡Demos comienzo a la actividad del día de hoy!
¡Listos, preparados, ya!
A esta altura conoces bien cómo funciona este momento. ¿Ya se han presentado con el equipo? ¿Te has encontrado nuevamente con alguien? ¿Qué conceptos o nuevo vocabulario has incorporado sobre QA en el encuentro anterior?
Utilicen unos 10 minutos para compartir estas breves presentaciones y repasar los conceptos que han aprendido en el encuentro anterior.
¡Seguro recuerdas más de lo que crees!
En los encuentros anteriores estuvimos analizando el contexto de la producción de software y en qué momentos es posible hacer pruebas o diseñar la mejor estrategia para realizarlas. También, descubrimos en qué momentos es posible interactuar con el equipo de desarrollo.
En el encuentro de hoy, profundizaremos sobre el testing en sí.
El testing o prueba de software es un método para verificar si el producto de software real cumple con los requisitos esperados y busca garantizar que el producto de software esté libre de defectos.
Implica la ejecución de componentes de software o sistemas utilizando herramientas manuales o automatizadas y se evalúan una o más propiedades de interés. El propósito de las pruebas de software es identificar errores, brechas o requisitos faltantes en contraste con los requisitos reales. La prueba de software es el proceso de evaluar y verificar que un producto o aplicación de software hace lo que se supone que debe hacer. Los beneficios de las pruebas incluyen la prevención de errores, la reducción de los costos de desarrollo y la mejora del rendimiento.
Imagen 4.1: Objetivos del testing. Fuente: producción propia.
Uno de los objetivos de las pruebas de software es evitar los errores en las primeras etapas del desarrollo. La detección temprana de errores reduce significativamente el costo y el esfuerzo. La prevención de defectos implica hacer un análisis de causa raíz de los defectos encontrados previamente y luego tomar medidas específicas para prevenir la ocurrencia de ese tipo de errores en el futuro. Las pruebas eficientes ayudan a proporcionar una aplicación sin errores. Si previene los defectos, se reducirá el recuento general de defectos en el producto, lo que garantiza aún más un producto de alta calidad para el cliente.
Los requisitos iniciales, el diseño, las historias de usuario y el código deben verificarse antes de que el desarrollador los recoja para el desarrollo. Identificar cualquier ambigüedad o requisitos contradictorios en esta etapa ahorra un tiempo considerable de desarrollo y prueba. El análisis estático del código (1) (revisiones, recorridos, inspección, etc.) ocurre antes de que el código se integre o esté listo para la prueba. Esta prueba se conoce como Verificación y puede ser realizada por el mismo equipo de desarrollo o por el equipo de QA (quality assurance).
(1) Análisis estático y análisis dinámico son dos tipos de evaluación de código. ¿Tienes tiempo extra y deseas explorar más? Aquí puedes adelantar algunos conceptos.
El principal objetivo de las pruebas debe ser satisfacer las necesidades del cliente. Los testers prueban el producto y aseguran la implementación de todos los requisitos especificados. El desarrollo de todos los casos de prueba, independientemente de la técnica de prueba, garantiza la verificación de la funcionalidad de cada caso de prueba ejecutado. El tester también debe crear una matriz de trazabilidad de requisitos (RTM) (2), que garantizará el mapeo de todos los casos de prueba a los requisitos. RTM es una forma efectiva de garantizar que los casos de prueba tengan la cobertura de requisitos adecuada.
(2) Lo verás más adelante, pero si no aguantas, te dejamos esta definición: La trazabilidad de requerimientos es la capacidad de registrar las relaciones existentes entre la necesidad dada por un interesado (stakeholder), el requerimiento de proyecto y la solución implementada finalmente.
Para validar si el objeto de prueba está completo y funciona según las expectativas de los usuarios y las partes interesadas (stakeholders). Las pruebas aseguran la correcta implementación de los requisitos junto con la seguridad de que funcionan según las expectativas de los usuarios. Esta idea de prueba se llama Validación.
Uno de los objetivos críticos de las pruebas de software es mejorar la calidad del software que se entregará para construir confianza con quien lo solicitó. El software de alta calidad significa un menor número de defectos. En otras palabras, cuanto más eficiente sea el proceso de prueba, menos errores tendrá en el producto final. Lo que, a su vez, aumentará la calidad general del objeto de prueba. La excelente calidad contribuye a un aumento significativo en la satisfacción del cliente, así como a menores costos de mantenimiento.
La posibilidad de pérdida también se conoce como riesgo. El objetivo de las pruebas de software es reducir el riesgo. Cada proyecto de software es único y contiene un número significativo de incertidumbres desde diferentes perspectivas, como ser el tiempo de lanzamiento al mercado, el presupuesto, controlamos estas incertidumbres, podremos tener riesgos potenciales no solo durante las fases de desarrollo sino también durante todo el ciclo de vida del producto. Por lo tanto, el objetivo principal de las pruebas de software es integrar el proceso de gestión de riesgos para identificar cualquier riesgo lo antes posible en el proceso de desarrollo.(3)
(3) Recuerda este objetivo cuando al final del encuentro de hoy estés leyendo sobre el caso de Microsoft. #spoiler
El propósito de las pruebas es proporcionar información completa a las partes interesadas sobre restricciones técnicas o de otro tipo, factores de riesgo, requisitos ambiguos, etc. Puede ser en forma de cobertura de pruebas, informes de pruebas que cubran detalles como lo que falta, lo que salió mal. El objetivo es ser transparente y hacer que las partes interesadas entiendan completamente los problemas que afectan la calidad. Un ejemplo concreto puede ser avisar al cliente que uno de los requerimientos tiene mucho riesgo y eso aumenta la probabilidad de errores y costos asociados. Al mantener informado al cliente, éste puede tomar decisiones con menor costo que si se le avisa al final, cuando no hay nada para hacer.
Otro objetivo esencial de las pruebas de software es identificar todos los defectos en un producto. El lema principal de las pruebas es encontrar el máximo de defectos en un producto de software mientras se valida si el programa funciona según los requisitos del usuario o no. Los defectos deben identificarse lo antes posible en el ciclo de prueba. Mientras que un defecto se pueda encontrar en la fase de pruebas, se lo conoce como error y tiende a ser solucionable antes de llevar el producto al cliente.
Otros objetivos posibles:
A veces debemos cumplir con los requisitos o estándares contractuales, legales o reglamentarios, y se debe verificar el cumplimiento del objeto de prueba con dichos requisitos o estándares. Por ejemplo, en relaciones contractuales con gobiernos o sistemas de seguridad o defensa, hay estándares de seguridad distintos que para una aplicación de compra y venta de ropa usada.
Otros casos incluyen que el software sea desarrollado para una región específica y deba seguir las reglas y regulaciones legales de esa región. Además, el producto de software puede tener que ser compatible con los estándares de prueba nacionales e internacionales.
Toma nota o escribe estos objetivos e intenta recordar si has visto errores de este tipo en tu propia experiencia como usuario. Por ejemplo, en el número 5 (construir confianza), nosotros recordamos esas páginas web que a primera vista no nos resultan confiables ya que tienen demasiada información no relacionada al objetivo principal. ¿Quieres ver un ejemplo? No sabemos muy bien qué desean estas personas, pero desde el primer clic que ya no pondríamos nuestra tarjeta de crédito en este sitio.
Estos son los beneficios de usar pruebas de software:
-
Rentabilidad: es una de las ventajas más importantes de las pruebas de software. Probar cualquier proyecto de TI a tiempo lo ayuda a ahorrar dinero a largo plazo. En caso de que los errores se detecten en la etapa anterior de las pruebas de software, cuesta menos repararlos.
-
Seguridad: Es el beneficio más vulnerable y sensible de las pruebas de software. La gente está buscando productos de confianza. Ayuda a eliminar riesgos y problemas antes.
-
Calidad del producto: Es un requisito esencial de cualquier producto de software. Las pruebas aseguran que se entregue un producto de calidad a los clientes.
-
Satisfacción del Cliente: El objetivo principal de cualquier producto es dar satisfacción a sus clientes. Las pruebas de UI/UX garantizan la mejor experiencia de usuario.
Imagen 4.2: Pantalla de error. Fuente: producción propia.
Este es un mensaje emergente en una aplicación o una página web. A simple vista y sin mayor contexto, ¿puedes entender a qué se refiere? Y no estamos hablando de adivinar qué quisieron decir sino de que nos quede claro como usuarios (1) qué paso, (2) cuál es el próximo paso y (3) cómo evitar que nos vuelva a pasar.
Si tuviéramos que explicar a soporte técnico qué nos pasó, ¿podrías hacerlo? Y si fueras soporte técnico, ¿podrías ayudar a este usuario con este nivel de detalle en el error?
Estamos por explorar una variedad de elementos que “aparecen” en la pantalla de los usuarios. Si deseas explorar más, aquí te dejamos un artículo que explica la diferencia entre un pop up, un modal, un tool tip y una light box. Leer
Un error es una desviación de lo que se esperaba como exacto o correcto. En software, un bug es un error, defecto o falla en un programa o sistema que causa “un resultado inesperado o incorrecto o un comportamiento no deseado.“
Podemos inferir lo siguiente:
-
Un error es una variante inesperada del resultado esperado
-
Los errores son una categoría de bugs de software
Los errores pueden surgir de:
-requerimientos incompletos o incorrectos
-falla humana en el momento de la codificación (programación)
La funcionalidad es la forma en la que se debe comportar el software. Los errores funcionales son, por ejemplo, si algo que se espera que realice es difícil, resulta confuso y extraño o es directamente imposible.
Mira esta pantalla de ejemplo:
Imagen 4.3: Pantalla “Eliminar publicación”. Fuente: producción propia.
La funcionalidad esperada del botón Cancelar es que el modal de Eliminar publicación se cierre y que se regrese a la página original de la publicación, sin eliminarla. Si el botón de cancelar no es clicable, estamos frente a un error de funcionalidad.
El software presenta al usuario opciones o CTA (call to action) que son poco claros o que no realizan la acción que dicen realizar. Por ejemplo, no hay Menú de ayuda o Instrucciones para usuarios nuevos. O acciones que son centrales al software pero no figuran en la sección de Preguntas Frecuentes. Hasta puede ser que un botón lea “Guardar” y esté ejecutando “Eliminar.”
Imagen 4.4: Pantalla con copy erróneo en botón Guardar. Fuente: producción propia.
En este ejemplo - Imagen 4.4-, el equipo responsable de la creación visual de este aviso (Front End) transcribió incorrectamente el texto en el botón “Eliminar” y el usuario lee “Guardar” y el software ejecuta eliminar.
Este tipo de errores ocurre cuando un comando esperado está ausente. Observa el siguiente ejemplo:
Imagen 4.5: Pantalla “Completa tu perfil”. Fuente: producción propia.
Esta pantalla permite que el usuario complete su perfil. Pero, no hay opción para que el usuario se vaya de esta pantalla sin completar su perfil. Ya que el botón “Cancelar” no se le provee al usuario, este es un error de comando faltante.
Los errores de sintaxis corresponden a palabras mal escritas (ortografía o error de tipeado simple) u oraciones que son incorrectas desde lo gramatical.
En el caso de software en español, también encontramos en esta categoría errores de herencia de inglés. Verás muchas veces que algunos textos todavía conservan el idioma en el que fueron escritos originalmente. Observa las siguientes imágenes a ver si puedes identificar todos los errores que puedas.
Recuerda, ¡atención al detalle es una habilidad que debes desarrollar como si fueras investigador profesional!
Dato: estos errores generalmente se ven al testear un software que ya tiene su GUI o UI lista. (4)
(4) ¿GUI o UI? ¡Hora de googlear un concepto fundamental más! Tip: Saber usar los términos UX, UI y GUI te distingue en el mundo laboral. Muchos principiantes cometen el error de pensar que se refieren al mismo concepto. ¡Destácate desde el día #1!
Nota: estos errores de sintaxis no se refieren a errores en la sintaxis del código. Esos los ven los desarrolladores cuando hacen sus tests funcionales.
Practica inglés y tómate una pausa refrescante
Este artículo recopila algunas de las traducciones fallidas más graciosas. Y si tu nivel de inglés es intermedio a avanzado, puedes leer este artículo que anticipa el problema de hacer traducciones técnicas sin traductores certificados.
Cualquier error que ocurra mientras el usuario está interactuando con el software necesita ser manejado en forma clara y con sentido. En otras palabras, el usuario debe comprender qué pasó (en un lenguaje ameno) y debe tener claro qué hacer como siguiente paso. Si esto no ocurre, a estos errores se los denomina “Error en el manejo de errores.”
Imagen 4.8: Pantalla “Error 707”. Fuente: producción propia.
Siempre que sea posible, el usuario debe tener claro qué pasos debe seguir. Si en un formulario, por ejemplo, hay campos obligatorios que necesitan ser llenados, los mensajes de validación deben ser claros e indicar qué acciones debe realizar el usuario. Aquí tienes un ejemplo bien manejado:
Imagen 4.9: Pantalla “Completa tus datos”. Fuente: producción propia.
Otros ejemplos de mal manejo de errores pueden lucir como las pantallas a continuación:
Este tipo de errores ocurre cuando una porción del código del software tiene algún error. Algunos ejemplos son:
-
Errores de lógica
-
Fórmulas incorrectas
-
Tipos de datos no alineados (texto vs números, por ejemplo)
-
Errores de código
-
Errores en las funciones internas del código
-
Bases de datos inexistentes o mal asignadas
En 1999, la NASA perdió su orbitador climático en Marte debido a que uno de los proveedores de la NASA involucrado en su construcción utilizó medidas imperiales (usadas en Inglaterra) en lugar de utilizar el sistema métrico universal (utilizado en todo proyecto científico). Este pequeño error causó que los propulsores del orbitador no funcionen correctamente. Debido a este error, el orbitador se estrelló casi inmediatamente al llegar a Marte.
El control de flujo en un software describe qué hará este en su próximo paso y bajo qué condiciones.
Por ejemplo, consideremos un sistema en el que el usuario debe completar un formulario y las opciones disponibles son: Guardar, Guardar y cerrar y Cancelar.
Si el usuario hace clic en el botón de Guardar y cerrar, la información del usuario en ese formulario debiera ser guardada y el formulario cerrarse. Si al hacer clic en ese botón, no se cierra el formulario, es un error de control de flujo.
Imagen 4.12: Pantalla “Formulario de inscripción”. Fuente: producción propia.
Antes de continuar, vamos a poner en práctica tus habilidades de detección de errores.
La funcionalidad es la forma en la que se debe comportar el software. Los errores funcionales son, por ejemplo, si algo que se espera que realice es difícil, resulta confuso y extraño o es directamente imposible.
La funcionalidad esperada del botón Cancelar es que el modal de Eliminar publicación se cierre y que se regrese a la página original de la publicación, sin eliminarla. Si el botón de cancelar no es clicable, estamos frente a un error de funcionalidad.
El software presenta al usuario opciones o CTA (call to action) que son poco claros o que no realizan la acción que dicen realizar. Por ejemplo, no hay Menú de ayuda o Instrucciones para usuarios nuevos. O acciones que son centrales al software pero no figuran en la sección de Preguntas Frecuentes. Hasta puede ser que un botón lea “Guardar” y esté ejecutando “Eliminar.”
En este ejemplo - Imagen 4.4-, el equipo responsable de la creación visual de este aviso (Front End) transcribió incorrectamente el texto en el botón “Eliminar” y el usuario lee “Guardar” y el software ejecuta eliminar.
Este tipo de errores ocurre cuando un comando esperado está ausente. Observa el siguiente ejemplo:
Esta pantalla permite que el usuario complete su perfil. Pero, no hay opción para que el usuario se vaya de esta pantalla sin completar su perfil. Ya que el botón “Cancelar” no se le provee al usuario, este es un error de comando faltante.
Los errores de sintaxis corresponden a palabras mal escritas (ortografía o error de tipeado simple) u oraciones que son incorrectas desde lo gramatical. En el caso de software en español, también encontramos en esta categoría errores de herencia de inglés. Verás muchas veces que algunos textos todavía conservan el idioma en el que fueron escritos originalmente. Observa las siguientes imágenes a ver si puedes identificar todos los errores que puedas. Recuerda, ¡atención al detalle es una habilidad que debes desarrollar como si fueras investigador profesional!
Nota: estos errores de sintaxis no se refieren a errores en la sintaxis del código. Esos los ven los desarrolladores cuando hacen sus tests funcionales.
Cualquier error que ocurra mientras el usuario está interactuando con el software necesita ser manejado en forma clara y con sentido. En otras palabras, el usuario debe comprender qué pasó (en un lenguaje ameno) y debe tener claro qué hacer como siguiente paso. Si esto no ocurre, a estos errores se los denomina
“Error en el manejo de errores.”
Siempre que sea posible, el usuario debe tener claro qué pasos debe seguir.
Si en un formulario, por ejemplo, hay campos obligatorios que necesitan ser llenados, los mensajes de validación deben ser claros e indicar qué acciones debe realizar el usuario. Aquí tienes un ejemplo bien manejado:
Este tipo de errores ocurre cuando una porción del código del software tiene algún error. Algunos ejemplos son:
-
Errores de lógica
-
Fórmulas incorrectas
-
Tipos de datos no alineados (texto vs números, por ejemplo)
-
Errores de código
-
Errores en las funciones internas del código
-
Bases de datos inexistentes o mal asignadas
El control de flujo en un software describe qué hará este en su próximo paso y bajo qué condiciones.
Por ejemplo, consideremos un sistema en el que el usuario debe completar un formulario y las opciones disponibles son: Guardar, Guardar y cerrar y Cancelar.
Si el usuario hace clic en el botón de Guardar y cerrar, la información del usuario en ese formulario debiera ser guardada y el formulario cerrarse. Si al hacer clic en ese botón, no se cierra el formulario, es un error de control de flujo.
-
Errores de comunicación o interpretación
-
Errores de comandos faltantes
-
Errores de sintaxis e idioma
-
Errores en el manejo de errores
-
Errores de cálculo
-
Errores de control de flujo
Tenemos dos ejemplos de errores para que comiences a practicar.
-
Ejemplos tipo 1: los preparamos para ustedes, basados en documentación real.
-
Ejemplos tipo 2: los traemos del mundo real, así como vienen. Verán que están en inglés o español y puede que les falte contexto.
Para cada uno de los ejemplos presentados a continuación, completa una tabla como esta:
| Ejemplo | Tipo de error (Si hay superposición de errores, numéralos) | Explica tu categorización (¿Con qué evidencia cuentas para elegir una categoría?) | ¿Hay suficiente información? Si la respuesta es no, ¿qué preguntas necesitarías resolver? |
|---|---|---|---|
| 1 | |||
| 2 | |||
| 3 | |||
| 4 | |||
| 5 | |||
| 6 | |||
| 7 |
Indicando el tipo de error que visualizas (de los 7 tipos vistos), si tienes suficiente información para documentarlo o tienes preguntas y si existe superposición de errores (más de un tipo al mismo tiempo en un ejemplo).
-
Errores funcionales: es posible interpretar que la falta de botón de “aceptar” o “cancelar” se clasifique como un error funcional ya que resulta confuso o hasta puede ser percibido como un callejón sin salida para los usuarios.
-
Errores de comandos faltantes: Es posible interpretar este error que no tiene un botón que le aclare el próximo paso. ¿Es cancelar? ¿Es ok?
-
Errores de sintaxis e idioma: Hay porciones del texto en inglés y en español
-
Errores en el manejo de errores: El usuario no tiene claridad de por qué llegó aquí ni qué debe hacer como próximo paso. Tampoco sabe si puede pedir ayuda
-
Errores funcionales: el error apela a utilizar el teclado para resolver el problema y se entiende que el teclado no está disponible por un error de software.
-
Errores de comunicación o interpretación: Los botones se contradicen con la información en el texto. ¿Debo utilizar las teclas del teclado o los botones?
-
Errores de control de flujo: No hay evidencia de un objetivo de flujo claro. De todos modos, falta información para poder afirmar esto. Deberíamos tener un video o mayor cantidad de capturas de pantalla para poder afirmar qué debería pasar aquí.
-
Errores funcionales: Nos falta contexto, pero es posible afirmar que el error de fondo es funcional (es optativa)
-
Errores en el manejo de errores: El usuario no tiene claridad de qué pasa.
- Errores de comandos faltantes: Si bien podemos hacer interpretaciones, lo que falta aquí es un botón de “cancelar” o similar (“X”) que permita que el usuario escape a esta situación.
-
Errores funcionales: Por el mensaje en pantalla, se puede inferir que hay un error que impide que dos usuarios colaboren en un mismo archivo. El error puede deberse a que está mal diseñado este flujo en particular o que una secuencia realizada por el usuario no ha dado los resultados esperados.
-
Errores en el manejo de errores: El botón “cerrar” es inadecuado para un error en el que se espera que el usuario tenga un comportamiento distinto (que cambie lo que hizo para llegar aquí, que pida soporte, etc).
-Errores funcionales: El servidor parece que debiera informar un único resultado y no lo ha hecho. Es un flujo con un resultado erróneo que debiera ser solucionado.
- Errores en el manejo de errores: el usuario no tiene claridad de qué hizo para llegar aquí ni cómo resolverlo. Pareciera un error “interno” de desarrollo que ha quedado expuesto a los usuarios.
-
Errores funcionales: se puede inferir aquí que existe un error en el código que da este resultado.
-
Errores de comunicación o interpretación: la presencia de tres comandos alternativos para salir de este error deja al usuario preguntándose si es lo mismo hacer clic en cualquiera de los tres. Uno de ellos está en gris (indicación de que no es clicable) y deja a la interpretación del usuario de si es posible que ese botón sea “mejor” que los otros en un contexto distinto.
-
Errores en el manejo de errores: Hay muy poca información para el usuario de cuáles son sus próximos pasos y de cuál es la acción que cada botón realizará al ser clicado.
- ¿Por qué no podemos mostrar ejemplos de todos los tipos de errores?
Los errores de flujo o de cálculo, en su mayoría, deben ser capturados en movimiento. Suelen ocurrir durante una secuencia de comandos y se los debe reproducir en video o en gif. Un buen tester busca la replicabilidad de los errores para que los equipos de desarrollo puedan ver exactamente bajo qué condiciones o secuencia de comandos es que se produce el error.
-> ¿Cómo vienes? ¿Cómo están tus poderes de observación?
-> En el trabajo en equipo, ¿te ayuda conversar con tus compañer@s de hoy?
-
Error: Acción humana que produce un resultado incorrecto
-
Defecto: Desperfecto en un componente que puede causar que el mismo falle en sus funciones
-
Fallo: Manifestación visible de un defecto
En el terreno profesional de un tester, normalmente siempre se topará con errores ya que son exactamente lo que está buscando al analizar un producto o un proyecto de software. Los defectos y las fallas se descubren una vez que el producto ya está funcionando del lado del cliente y es éste quien las informa.
La identificación de defectos - poder categorizarlos, reportarlos y que eventualmente se solucionen - es parte de las actividades del equipo de Control y Garantía de calidad. El mayor desafío que tiene este equipo es poder realizar las pruebas necesarias en cada momento de las etapas del Ciclo de vida del Desarrollo de Software (SDLC). El objetivo es poder detectar los errores lo antes posible. ¿Por qué? Porque a medida que se avanza en el proceso, los costos para encontrar y corregir errores crecen en forma exponencial.
El momento más económico para arreglar un error es durante el periodo de análisis de requerimientos, y luego el costo se va incrementando sin excepción en cada etapa subsiguiente, llegando al escenario más costoso de todos que es en el periodo de mantenimiento luego de la implementación. (ver “Objetivos del testing”)
Este artículo describe algunos de los desafíos que tenemos al trabajar en español sobre elementos que han sido creados en inglés, y la dificultad que existe para saber cómo nombrar a cada uno de ellos.
Aquí te dejamos un esquema para que recuerdes la secuencia de producción de un error:
Un tester detecta defectos y explica cómo fallan, acompañando el reporte con un análisis de los efectos negativos. El tester no siempre puede saber cuál es el error que dio lugar a ese defecto.
Windows XP tiene aproximadamente 45 millones de líneas de código. ¿Cuántos errores piensas que puede tener un software con esa cantidad de código?
Aproximadamente, unos 100 mil errores. Es por eso que en 2008, Microsoft contaba con 90 mil empleados, muchos de los cuales se dedicaban a escribir, arreglar y testear esas millones de líneas de código. En la década del 90, Microsoft implementó el reporte automatizado de errores.
Hoy en día estamos muy acostumbrados a ver este tipo de soluciones y rastreo de errores, pero para ese entonces era una idea muy innovadora.
Una vez que Windows XP ya estaba funcionando en más de 1000 millones de computadoras personales, cada error que ocurría se cargaba automáticamente en este sistema (6) y los equipos de soluciones trabajaban directamente con los reportes que se generaban a partir de los millones de reportes enviados por los usuarios.
Uno de los miembros del equipo de investigación de errores descubrió un reporte que le llamó la atención. Y levantó la alarma. Parece que Windows XP tenía una vulnerabilidad que podía ser utilizada para que terceras personas ingresaran al sistema de un usuario vía Windows y luego pudieran infectar toda la computadora, llevándose datos y haciendo que las computadoras crashearan sin arreglo. Este error se conoció como MS08-067. Fue publicado por Microsoft (MS) en su reporte interno del año 2008 y ese reporte era el número 67 ese año. Por ello se lo conoce como el MS08-067.
¿Puedes imaginar lo que costó arreglar este defecto? Si quieres saber más, ¡prepárate! El material es abundante. Podemos darte algunas pistas para que sepas qué leer primero. Busca MS08-067 y Conficker.(7)
(6) Quieres saber más? Se llama WER, Windows error reporting
(7) Solo podemos adelantarte que esto ocurrió en 2008… y en 2019 el total de sistemas afectados rondaba las 500.000 computadoras.
¡Lo hemos logrado! Has llegado al final del cuarto encuentro. Tómense 5 minutos como equipo para conversar sobre el ejercicio de clasificación de errores.
Les dejamos algunas preguntas disparadoras - no necesariamente tienen una sola respuesta correcta:
-
¿Todos los errores entran en una sola categoría? O sea, ¿si es un error de sintaxis, eso anula que pueda ser parte de otra categoría o tipo de error?
-
¿Hasta qué punto es importante clasificar el error en una categoría correcta? ¿Cómo ayuda a su resolución que tenga categoría?
¡Gran momento para recordar y agradecer a nuestro equipo de hoy! ¿Ya se han vuelto a encontrar con alguien de los equipos anteriores?