Para completar la serie de de videos relacionados con las técnicas de diseño de casos de prueba, te compartimos este último en el cual hablamos sobre las técnicas Basadas en la Experiencia o mejor conocidas como técnicas no formales.
Son técnicas que dependen directamente de la experiencia, la habilidad y la intuición del probador. No tienen asociados procesos.
Compártelo con todos tus compañeros y amigos para que juntos apliquen estas técnicas. Si tienes preguntas me puedes escribir en comentarios. Para ver más videos visita nuestro Canal Youtube TKTKASE
Frecuentemente, me encuentro en la búsqueda de otras opiniones o nuevas perspectivas con el fin de confirmar si voy por al camino correcto o si debo incorporar nuevas ideas en mi constante proceso de aprendizaje.
Esta vez explorando en el blog de SOGETI España, QA:News encontré una entrada que me confirmó varias de mis creencias sobre la actitud que un tester profesional debe cultivar. En realidad, aplica no solo a los testers sino también a cualquier profesional que es parte de un equipo, responsable de productos de software en el contexto de la ingeniería de software.
De acuerdo con el marco de trabajo TMap® NEXT, un tester debe:
Tener habilidades de comunicación verbal y escrita.
Ser capaz de trabajar con precisión y tener habilidades analíticas.
Ser convincente y perseverante.
Ser objetivo y tener una actitud crítica positiva.
Ser creativo
Pero sobre todo debe tener una actitud de curiosidad ante eventos obvios o desconocidos. Por esta razón, siempre sugiero desarrollar la habilidad de hacer preguntas sencillas que permitan «saciar» la curiosidad.
Recently a friend of mine lost his job in software development. I offered him the possibility of submitting his curriculum vitae to see if he could fit in Sogeti as a tester. He asked me a really good question: Do I have what is needed to be a good tester?
De manera muy resumida queremos mostrarte los aspectos fundamentales de las técnicas estructurales o mejor conocidas como Caja Blanca. Cobertura de Sentencia y de Decisión son nuestro tema central. En este video podrás igualmente encontrar la definición de lo que es el Flujo de Control: una técnica estática que es usada para calcular la cobertura de las técnicas dinámicas.
En este video incluimos los aspectos fundamentales que debe saber sobre las técnicas de CAJA BLANCA para el examen de certificación del Nivel Básico de ISTQB.
Las técnicas de Caja Blanca se pueden describir de la siguiente manera:
Conocidas como técnicas o pruebas estructurales, pues aplican cuando el probador tiene acceso a la caja es decir al código
El probador que usa estas técnicas es el desarrollador o codificador
Los casos de prueba están centrados en probar basados en la estructura interna del código
Miden la cobertura del código luego de la ejecución de los casos de prueba basados en el Flujo de Control
Relación de las Técnicas de Caja Blanca más usadas
El Flujo de control es una técnica estática, generada a través de herramientas y es la estructura del código representada como un diagrama de control de flujo. Se puede visaulizar como un grafo dirigido, donde:
–Nodos: representan sentencias o secuencias de sentencias
–Aristas: representan la transferencia del flujo de control
Ejemplo de un flujo de control el cual corresponde a un programa
El resultado es una visión del conjunto del código de programa mediante el cual podemos calcular, a través de las mismas herramientas, la cobertura del código por los casos de prueba y podemos detectar anomalías estructurales.
Otro video más de la serie, espero que te guste. Compartelo con todos tus compañeros y amigos para que juntos apliquen estas técnicas. Si tienes preguntas me puedes escribir en comentarios. Puedes igualmente, compartir tu experiencia en la aplicación de estos conceptos.
Para ver más videos relacionados con las Técnicas de Caja Negra vista Canal Youtube TKTKASE
La técnica de Diagramas de Transición de Estados es la más apropiada para contestar a esta pregunta. Lo particular es que esta técnica no solo es para evidenciar los posibles estados de un objeto (por ejemplo: abierto, cerrado, cancelado) y sus transiciones (por ejemplo: solo de abierto puede ir a cerrado). También esta técnica, nos permite identificar la secuencia u orden en los cuales un proceso puede ser implementado. Y todo de manera muy visual, lo cual reduce cualquier posibilidad de doble interpretación.
Esta es la última técnica de caja negra que mostraremos. Tambien es una buena técnica para documentar o especificar las características de los ítems de prueba. Adicionalmente, es otra de las técnicas súper importantes para el examen de certificación del Nivel Básico – ISTQB.
Otro video más, espero que te guste
Compártelo con todos tus compañeros de trabajo y amigos, para que juntos apliquen las recomendaciones. Si tienes más dudas escribe o si te gustó dale like debajo del video o en esta misma entrada.
Para ver más videos visita nuestro Canal Youtube TKTKASE
Esta es una de mis técnicas preferidas…no solo te ayuda a especificar casos de prueba, sino que también te permite conocer más el proceso de negocio y las reglas relevantes del mismo. Adicionalmente, es una técnica súper importante para el examen de certificación del Nivel Básico – ISTQB.
Condiciones: muestra las entradas
Acciones: son los resultados que se darán basados en la combinación de las condiciones
Reglas: define un único conjunto de condiciones que terminan en un conjunto de acciones
No te pierdas este video…
Compártelo con todos tus compañeros de trabajo y amigos, para que juntos apliquen las recomendaciones. Si tienes más dudas escribe o si te gustó dale like debajo del video o en esta misma entrada.
Para ver más videos visita nuestro Canal Youtube TKTKASE
¿Conoces la técnica de Análisis de Valores Frontera?
Es importate que reconocer la técnica de Valores Límite o también conocida como Valores Frontera, como una técnica que permite identificar valores claves o valores de datos de entrada que deberíamos usar para probar los Valores Válidos y los Valores no Válidos para un dato o un campo o una transacción. La técnica AVF trabaja de manera colaborativa con la técnica de Clases de equivalencia.
¿Sabes cuál es la razón de esta técnica? ¿Y cómo se aplica?
Si es tu primera vez con esta técnica No te pierdas este video y lo sabrás
Compártelo con todos tus compañeros de trabajo y amigos, para que juntos apliquen las recomendaciones.
Si tienes más dudas escribe o si te gustó dale like debajo del video o en esta misma entrada.
Si te estás preparando para el examen de certificación del nivel básico – Foundation level ISTQB – te recomiendo este video sobre las técnicas más importantes para el diseño de casos de prueba: las CLASES DE EQUIVALENCIA (CE)
Una Clase de equivalencia se puede entender como un grupo de valores de datos de entrada o de salida que son tratados de igual manera. Existen CE tanto para valores válidos como para los no válidos.
Compártelo con todos tus compañeros de trabajo y amigos, para que juntos apliquen las recomendaciones. Si tienes más dudas escribe o si te gustó dale like debajo del video o en esta misma entrada.
Para ver más videos visita nuestro Canal Youtube TKTKASE
Introducción a los Riesgos de Producto (Quality Risks)
Las pruebas basadas en el riesgo del producto (risk based testing) es una estrategia recomendada para atender las pruebas en un proyecto de desarrollo de software. Esta estrategia se enfoca en identificar las áreas más críticas/problemáticas del software con el fin de aplicar las acciones del caso para disminuir la posibilidad de que se presente un evento no deseado en producción.
La gestión de riesgos del producto (quality risk) deben ser gestionados por el equipo de Pruebas bajo la responsabilidad del Líder de Pruebas.
Se entiende como Riesgos del Producto (quality risk) aquellos eventos que podrían afectar la aceptación del sistema. Problemas potenciales que pueden afectar la calidad del producto que está siendo entregado al cliente o usuario final.
En cierta ocasión Mr Lee Copeland me hizo dos preguntas…bueno fueron más de dos:
1. ¿Es usted una tester profesional?R/Sí (con entonado acento)
2. ¿Está usted certificada como probadora profesional? R/ Sí… ojalá le pudiera contar que ya logré el Advanced Level
3. ¿Conoce usted a este señor? (ver foto abajo) R/ Mmmm…nop (ups)
Bueno, luego de la correspondiente investigación les comparto los resultados. Sí, es la foto de Mr Cem Kaner. Mr Kaner es uno de los referentes más relevantes de las pruebas de software (software testing). Tester desde los años 80 en Silicon Valley y autor del bestseller Testing Computer Software. Para más detalle los invito a visitar el siguiente enlace y leer su biografía CEM KANER.
«My career is centered around a consistent theme: Enhancing the satisfaction and safety of software customers, users, and developers.«
Cem Kaner
Este post lo escribí en el año 2012. Hoy esta afirmación (Cem Kaner statement) me hizo pensar y crear el propio. Paso por aquí y me atrvo a compartirlo. ¿Cuál es el tuyo?
Soy una autodidacta nata, escritora y creadora de corazón. Mi sueño es escribir un best-seller y compartir mi conocimiento con millones de personas alrededor del mundo. En este momento, estoy enfocada en mi gran desafío: motivar a los testers a adoptar un quality mindset.
Desde nuestro punto de vista la caja negra y la caja blanca son dos enfoques diferentes y a la vez complementarios, los cuales son necesarios para comprobar que el producto de software cumple el nivel de calidad esperado.
Ambos enfoques coinciden en:
Son sistemáticos, pues cumplen o siguen un proceso o método. Es decir, deben cumplir con un conjunto de lineamientos.
Tienen como finalidad que con el menor número de escenarios o casos o preguntas logren la mejor cobertura de los requisitos o de la estructura.
En el siguiente mapa mental, resumimos los aspectos que las hacen relevantes.
Ninguna de las dos es más importante que la otra. Por el contrario, las dos son necesarias puesto que tienen una perspectiva distinta que nos permite tener una observación más completa del producto de software.
– Caja Negra desde el comportamiento esperado (los requisitos del sistema y del negocio).
– Caja Blanca desde la estructura interna del código.
Por otra parte, si bien es más probable que la persona encargada de la generación de código aplique el enfoque de caja blanca (pues tiene acceso al código), es igualmente cierto que dicha persona debe aplicar el enfoque caja negra. Lo mismo podría decirse de la persona que se centra en confirmar que los requisitos de negocio y del sistema se cumplan. Es decir, puede hacer preguntas o hacer revisiones con el equipo desde la estructura del software.
Al final, lo relevante es usar ambos enfoques para comprobar el cumplimiento de la calidad esperada del producto de software.
telo con todos tus compañeros y amigos para que juntos apliquen estas técnicas. Si tienes preguntas me puedes escribir en comentarios. Para ver más videos visita nuestro Canal Youtube TKTKASE
Testing Knowledge 