Lic.
Desarrollo de Videojuegos
2do Año - 1er Cuatri
Resumen
Control de Calidad en
Videojuegos
Unidad 1
¿Qué es ISTBQ?
Es una organización internacional basada en el trabajo voluntario de expertos
en pruebas de software a nivel mundial.
Definición de Testing y su Uso
El software testing es la actividad de probar un software para verificar el
funcionamiento y encontrar errores. Existen varias técnicas de prueba manual
que ayudan a reducir el número de casos de prueba que se ejecutan al tiempo
que aumentan la cobertura de prueba. Esto ayuda a reconocer pruebas que de
otra manera no se podrían detectar.
Existen personas que se dedican a realizar software testing. Su trabajo se basa
en poner a prueba cada software para entregar un informe a las partes
interesadas, con detalles como, por ejemplo, si el software cumple con los
requisitos necesarios y el diseño acordado.
Esto consiste en la verificación dinámica del comportamiento de un programa
sobre un conjunto finito de casos de prueba, correctamente seleccionados a
partir del dominio de ejecución que usualmente es infinito, en relación con el
comportamiento esperado.
Se dice que es dinámico debido a que se pone a prueba el programa
ejecutandolo de la forma más parecida posible a cómo se ejecutará cuando
esté en producción (post lanzamiento del juego).
Es finito porque se prueba ejecutando unos pocos casos de prueba, dado que
en general es física, económica o técnicamente imposible ejecutarlo para todos
los valores de entrada posibles. Estos se eligen según las reglas o criterios
seleccionados. Si la salida esperada no corresponde con la salida producida se
dice que se detectó un caso de error y se debe documentar.
Testear un programa significa ejecutarlo en condiciones controladas que te
permitan ver una salida o resultado. Este se estructura en casos de prueba, los
que se reúnen en conjuntos de pruebas. Esto quiere decir que el testing va
desde un eje cartesiano de entrada a un eje cartesiano de salida.
Resumiendo un error se va a encontrar oculto hasta que una falla cause esto.
Con esto el testing incrementará estos errores al seleccionar casos de pruebas
apropiados.
Finalmente, una falla es un estado intermedio incorrecto al cual se llega
durante la ejecución de un programa.
1
Contribuciones de la Prueba al Éxito
La utilización de técnicas de prueba adecuadas pueden reducir la frecuencia de
estas entregas problemáticas. Cuando estas técnicas se aplican con:
- el nivel adecuado de experiencia en materia de prueba,
- en los niveles de prueba adecuados y
- en los puntos adecuados del ciclo de vida del desarrollo del software
… mayor probabilidad hay de que no haya errores en el software.
Objetivos de las Pruebas de Calidad
Antes de comenzar las pruebas se deben establecer pautas o principios que
aseguran que el resultado se ajusta a los objetivos principales:
● Todos los casos de prueba deben prepararse basándose en los requisitos del
cliente. De forma contraria se estarán probando los requisitos incorrectos.
Cada característica o función del sistema se debe probar con uno o más
casos de prueba.
● Algunos de los tipos de prueba de software, como las de rendimiento y las
de aceptación, deben realizarlas expertos (ej.: personal de QA).
● Se planifica primero en base a las funcionalidades básicas y luego se
amplían para funcionalidades avanzadas.
● Se recomienda empezar con los casos de prueba en fases tempranas del
proyecto ya que impacta menos que cuando se comienzan a realizar en
fases tardías.
● No se recomienda utilizar los mismos casos de prueba una y otra vez,
debido a que después de cierto tiempo no encontrarán problemas nuevos.
Por lo tanto es mejor ajustar los casos de prueba para encontrar nuevos
fallos o errores.
● La Ley de Pareto dice que el 80% de los errores causados son por el 20%
de las características del sistema, esto quiere decir que se asocian a una
cantidad pequeña de funcionalidades.
● Las pruebas dependen del contexto, lo que implica que las pruebas y
metodologías a aplicar deben estar basadas en el contexto del sistema que
se va a probar.
2
Elementos de la Prueba de Calidad
Los objetivos de prueba pueden incluir:
● Evaluar productos de trabajo, como: requisitos, código, diseño, historia de
usuario, entre otras.
● Verificar el cumplimiento de todas las especificaciones técnicas.
● Verificar si el objeto de prueba está completo y funciona como es esperado.
● Generar confianza en el nivel de calidad del objeto de prueba.
● Prevenir defectos.
● Encontrar fallos y defectos.
● Proporcionar información para la toma de decisiones.
● Reducir el nivel de riesgo de calidad inadecuada.
● Cumplir con requisitos contractuales y normas vigentes.
Estos pueden variar dependiendo del contexto que se está probando y su nivel
de prueba. Estas diferencias pueden ser:
● Durante la prueba del componente
Encontrar tantas fallas como sean posibles para identificar defectos
subyacentes.
● Durante la prueba de aceptación
Confirmar que el sistema funciona como se espera y que cumple con los
requisitos.
Quality Assurance & Quality Control
● Quality Assurance (QA)
Se diseñan y definen los parámetros de aceptación de un software. Es un
sistema de prevención de fallos y se generan medidas correctivas para
evitar salidas a producción.
Los QA son cada miembro del equipo involucrado en el desarrollo del
producto, desde el desarrollador, pasando por los managers y clientes.
Están presentes desde la fase 0, por eso son los desarrolladores que inician
la “mecha” del QA. Está orientado al proceso, este se diseña y ejecuta antes
de terminar el producto. Se ejecuta todo en white-box testing.
3
● Quality Control (QC)
Se controla el comportamiento final del producto. Es un sistema de
corrección de fallos e introducción de mejoras. QC entra en escena cuando
el producto está finalizado. Sus pruebas son no funcionales, es decir
pruebas realizadas por humanos (¿?), por lo tanto es black-box testing.
El departamento de QC es totalmente independiente al equipo de QA. Los
técnicos de QC solo necesitan saber cómo funciona el producto, es decir
cómo debería funcionar el producto y están orientados al cliente. En cambio
los QA son personas especializadas dentro del equipo de desarrollo. Su
tarea será completar pruebas que los desarrolladores no llegaron a
completar por falta de tiempo o debido al número de tests que se debían
hacer.
¿Qué son QA y QC?
La garantía de calidad se centra en el proceso, mientras que el control de
calidad se centra en el resultado.
● La misión crítica de QA es la prevención. Se centra en planificar,
documentar y acordar un conjunto de normas que garanticen la calidad. El
objetivo es evitar que los problemas lleguen a producción, es decir, siendo
provocativos se logra garantizar un nivel de calidad establecido
previamente. Cualquier estrategia que implique el éxito debe tener un alto
nivel de comunicación entre los equipos que participan en el proyecto.
● La misión crítica de QC es establecer la estrategia de detección. Al tratarse
de actividades destinadas a determinar el nivel de calidad de la solución,
está diciendo que es posterior, es decir, tras terminar la solución. Se trata de
un método reactivo que permite medir si se cumplen los requisitos del
negocio, acordado previamente por el cliente y el equipo.
Esto implica la verificación de la conformidad de los resultados con los
niveles de calidad deseados. Inspeccionando todo pero desde un punto de
vista manual.
4
¿En qué etapa del proceso entra cada tipo de test?
● Durante la integración del código
Pasar “Unit Test”, “Integration Test”, “Code Coverage” y un control estático
del código fuente mediante el uso de herramientas, lograran que la
integración del código no contenga ningún problema que aflore en fases
futuras. Otra buena práctica es hacer un “Regression Test” ya que ayuda a
evitar la introducción de inestabilidades en el código.
● Durante el despliegue
El más conocido es el “A/B Testing”, dentro de la promoción de la
funcionalidad a estudiar en diferentes entornos.
Origen del Rol
El rol se origina tras un famoso incidente ocurrido en 1947, cuando el equipo
encargado de trabajar en la super-computadora Mark II de la Universidad de
Harvard compartió el primer reporte de error. El cuál fue causado ni más ni
menos que por un bicho. Dando así también origen al término “bug” para
referirse a los errores en la informática.
Responsabilidades del Tester
● Prueba y depuración
La depuración es la actividad de desarrollo que encuentra, analiza y corrige
los defectos de software. La prueba de confirmación posterior comprueba si
las correcciones han resuelto los defectos. En algunos casos los probadores
son los responsables de la prueba inicial y la de confirmación, mientras que
los desarrolladores realizan la depuración y la prueba de componentes
asociada.
● Otras responsabilidades
- Reunirse con usuarios del sistema para comprender el alcance de los
proyectos.
- Trabajar con desarrolladores de software y equipos de soporte.
- Identificar la necesidades del negocio
- Planificar proyectos.
5
- Supervisar aplicaciones y sistemas de software.
- Llevar a cabo pruebas de estrés, pruebas de rendimiento, pruebas
funcionales y pruebas de escalabilidad.
- Escribir y ejecutar scripts de prueba.
- Realizar pruebas manuales y automatizadas.
- Pruebas en diferentes entornos, incluyendo web y móvil.
- Escribir informes de fallos.
- Llevar a cabo la planificación de recursos.
- Revisar la documentación.
- Trabajar para cumplir los plazos departamentales y de proyectos.
- Proporcionar garantía de calidad.
- Proporcionar información objetiva a los equipos de proyectos de
desarrollo de software.
- Detectar potenciales fallos.
- Pruebas de diseño para mitigar el riesgo.
- Presentar los resultados a los equipos de desarrollo de software y al
cliente.
- Trabajar en múltiples proyectos a la vez.
- Análisis de documentación.
Roles y Perfiles dentro del Testing
Los perfiles de testing son clave para las organizaciones, al prevenir y solventar
errores de software que pueden acarrear consecuencias significativas tanto
para los usuarios como para las empresas si no fuesen detectados.
6
Un QA debe monitorear cada ciclo de este proceso, haciendo las pruebas
pertinentes que aseguren los estándares de calidad del mismo. Buscar fallas y a
partir de ellas dar posibles soluciones.
Dentro de las funciones de un tester se encuentran:
● Examinar los requerimientos.
● Planificar las estrategias para el testing.
● Ejecutar la prueba.
● Analizar los resultados obtenidos.
● Registrar errores obtenidos.
● Realizar una evaluación de los resultados.
● Plantea las posibles soluciones.
● Ejecutar y validar las modificaciones.
● Monitorea las correcciones.
Pasos de un Proceso de Prueba
1. Planificación de la prueba
Definir objetivos y el enfoque para cumplir dichos objetivos dentro de las
restricciones del contexto de la prueba.
2. Monitorización y control de la prueba
Comprobar contínuamente el avance respecto al plan, utilizando una
métrica de monitorización. El control implica tomar las medidas necesarias
para cumplir con los objetivos del plan.
3. Análisis de la prueba
Analizar las bases de la prueba correspondiente, su nivel y elementos. Con
esto podremos identificar defectos, priorizando así condiciones de prueba.
Las pruebas de caja blanca o negra y las experiencias ayudan en esta
etapa.
4. Diseño de la prueba
Transformar las condiciones de prueba en casos de prueba. Mientras que el
análisis dice lo que se debe probar el diseño dice cómo se deberá probar.
5. Implementación de la prueba
Crear o completar los productos necesarios para ejecutar la prueba.
Desarrollar y priorizar procesos de prueba, crear casos de pruebas a partir
7
de procedimientos de prueba, organizar los casos de prueba dentro de un
calendario de ejecución, construir el entorno de prueba, preparar los datos
de prueba y asegurar que estén en el entorno. Actualizar la trazabilidad
entre la base de prueba, condiciones, casos, procedimientos y casos de
prueba.
6. Ejecución de la prueba
Se ejecuta siguiendo el calendario. Las actividades implican registrar
identificadores y versiones de los casos de prueba.
Ejecutar pruebas de forma manual / automatizadas, comparar resultados
obtenidos vs esperados, analizar anomalías para establecer causas,
informar defectos en función de las fallas observadas, repetir las
actividades de prueba como resultado de una anomalía o como parte de la
prueba planificada, actualización de la trazabilidad entre base de prueba,
condiciones, casos, procedimientos, y resultado de la prueba.
7. Compilación de la prueba
Implica la recopilación de datos de las actividades de prueba completadas
para consolidar la experiencia, productos de prueba y cualquier
información relevante. Incluye actividades como comprobar que todos los
informes de defectos esten cerrados: finalizar, archivar y almacenar el
entorno de prueba, datos, infraestructura y lo que correspondiera para su
posible posterior reutilización, traspaso de los productos al servicio de
mantenimiento, analizar lo aprendido para encontrar oportunidades de
mejora, utilizar la información recopilada para mejorar el proceso de
prueba.
Principios del Testing
Estos principios ayudan a organizar la estrategia de pruebas bajo una
perspectiva innovadora y proporciona una visión privilegiada, que permite
desempeñar la función con más precisión y eficacia.
1. La prueba muestra la presencia de defectos, no su ausencia
Tras el reporte de un incidente y su posterior arreglo, se reducen las
probabilidades de cruzarse con un defecto. Pero la inexistencia absoluta de
incidentes resulta imposible de comprobarse.
2. La prueba exhaustiva es imposible
8
Probar todas las combinaciones de datos y acciones en las funcionalidades
de un software es casi imposible, ya sea por tiempo o recursos. Por este
motivo, al estructurar las estrategias y diseñar los casos de pruebas, resulta
muy conveniente considerar estos factores, para poder enfocarse en
ejecutar las verificaciones más significativas y que tengan mayor impacto.
3. La prueba temprana ahorra tiempo y dinero
Como decíamos antes cuanto antes testeas mejor. Pues permite detectar
incidentes en los albores del producto. El costo de reparación de estos
incidentes será significativamente más elevado si recién fueran detectados
en fases posteriores.
4. Los defectos se agrupan
Hay ciertos módulos y funcionalidades que son más propensos a presentar
incidencias en comparación al resto de las partes que conforman un
producto. Esto va de la mano de la ley 80% consecuencias emergen del
20% de las causas.
5. Cuidado con la paradoja del pesticida
Ejecutar los mismos casos en las mismas partes hace que sea muy difícil
detectar nuevos fallos. Para aumentar las posibilidades de detección de
incidentes, es imprescindible revisar y actualizar de manera constante la
estrategia de pruebas y asegurar la exploración de las diversas partes que
componen el producto con mayor profundidad.
6. La prueba depende del contexto
La estrategia y el tipo de pruebas serán seleccionados en función del
sistema y a los entornos que se pretenden verificar. Los procedimientos
estructurados, así como los casos diseñados, serán seleccionados teniendo
en consideración todos y cada uno de estos factores.
7. La ausencia de errores es una falacia
La ausencia de nuevos errores detectados no implica necesariamente que el
software sea útil, ya que la utilidad del mismo no es indicada por este
parámetro, sino por la satisfacción de las expectativas del cliente que el
producto pueda brindar.
