“Tecnicas

 de  Diseño  de  Casos  de  Prueba.”  

www.bstriker.com   1  
Logo@Copyright  
 Objetivos  

1.  Compartir  conocimiento  adquirido  en  distintos  proyectos  con  la  comunidad  de  
Testing.    

2.  Generar  un  espacio  donde  se  generen  nuevas  relaciones  entre  los  participantes.  
(Francisco)  

3.  Proveer  herramientas  de  desarrollo  profesional  para  los  referentes  de  la  
comunidad.    

4.  Facilitar  teoría  y  fuentes  de  información  académica.      

www.bstriker.com  
 Historia  del  Testing  

•  Antes  de  1956.  Periodo  orientado  a  debugging.  En  el  ‘49  A.M.  Touring  es  el  
precursor  (Checking  a  large  routine).    

•  Entre  1957  y  1978.  Periodo  orientado  a  demostración.  

•  Entre  1979  y  1982.  Periodo  orientado  a  destrucción.  Myers  -­‐  The  Art  of  Software  
Testing.    

•  Entre  1983  y  1984.  Periodo  orientado  a  evaluación.  (V,V&T).  

•  Entre  1985  y  la  actualidad.  Periodo  orientado  a  prevención.  STEP  (Systematic  

Test  and  Evaluation  Process)  
 

www.bstriker.com  
 ¿Por  qué?  
•  Modelo  de  trabajo  incorrecto.  (Ágiles  o  Estructurados)  
•  Los  objetivos  del  Testing  no  son  claros.  
•  Se  realiza  más  Testing  basado  en  la  experiencia  de  los  testers.  
•  Testers  sin  formación  o  habilidad.  
•  No  se  cuenta  con  información  relevante  a  las  pruebas.    
•  No  hay  criterios  claros  de  comienzo  o  fin  de  Prueba.    
•  Testing  como  cuello  de  botella.  
•  La  infraestructura  de  Testing  no  se  condice  con  la  del  ambiente  productivo.  
•  Herramientas  obsoletas  o  demasiadas  herramientas.  
•  Equipo  de  Testing  muy  lejos.  (¿Testers  en  Desarrollo  o  un  área  de  Testing?)  
•  Proceso  de  trabajo  incorrecto.  
 

Muchas  otras  razones  

www.bstriker.com  
Mejora  Continua  
Modelos  Básicos  
Otros  modelos  
 Criterios  Comunes.  
•  Iniciar  
•  Medir          
•  Priorizar/Planificar  
•  Redefinir  
•  Operar  
•  Validar  
•  Evolucionar  
 
Comparativo  
 Resumen  

    Antes  '56   57-­‐78   79-­‐82  (Myers)  83-­‐84   85  ….  

TESTING   Evaluacion  
Debbuging   Demo   Destruccion   (V,V  &T)   Prevención  
Cascada  (Benignton  -­‐  
MODELOS  DE   Royce)   92  Modelo   94  RUP  
DESARROLLO     V  /  W   Primer  Agil   99  TDD  

MODELOS  DE   TMM  -­‐  90   TPI  -­‐  97  (4)   CMMi  -­‐   SPICE  -­‐  
MEJORA  CONTINUA     STEP  -­‐  86  (3)   (5)   CTP  (12)   (SOGETI)     02   '04  (6)  

MODELOS   Six  Sigma  -­‐  

GENERALES   Deming  PDCA   Kaizen   TQM   EFQM  -­‐  88   86                  
 Técnicas  De  Diseño  
 
También  son  técnicas  de  esamación.  
Ayudan  a  generar  escenarios  de  pruebas  eficaces.  
Tienen  el  concepto  de  probar  lo  menos  posible  pero  tanto  como  haga  falta.  
Es  donde  mayor  parte  del  esfuerzo  de  Tesang  debe  concentrarse.  
Miden  la  CALIDAD  de  un  objeto  de  prueba  desde  disantos  puntos  de  vista.  
 Cuando  tiene  calidad?  
 
- Exactitud (“accuracy”) Atributos de calidad
 
- Adecuación (“suitability”) para pruebas del
 - Interoperabilidad (“interoperability”) dominio
- Seguridad funcional (“functional security”) (funcionales)
- Usabilidad (“usability”)
- Accesibilidad (“accessibility”)

- Seguridad técnica (technical security)

- Fiabilidad (“reliability”) Atributos de calidad
- Eficiencia (“efficiency”) para pruebas
- Mantenibilidad (“maintainability”) técnicas
- Portabilidad (“portability”)
 Invitado  Especial  
 
 
Carlos  R.  Cusmai  –  Director  de  QAustral  SA  
Formador  ISTQB  

 
General

-  Las pruebas funcionales están dirigidas a verificar la corrección y la

completitud de una función
-  ¿Están disponibles en el módulo todas las funciones especificadas?
-  ¿Las funciones ejecutadas presentan resultados correctos?
-  La ejecución de casos de prueba deberían ser ejecutados con una
baja redundancia, pero sin embargo con carácter integral /
completo
-  Probar lo menos posible, pero
-  Probar tanto como sea necesario

Página 14
Partición de equivalencia o clase de
equivalencia (CE)
-  La partición en clases de equivalencia es lo que la mayoría de los
probadores hacen de forma intuitiva: dividen los posibles valores en
clases, mediante lo cual observan
-  Valores de entrada (“input values”) de un programa (uso habitual del
método CE)
-  Valores de salida (“output values”) de un programa (uso poco habitual
del método CE)
-  El rango de valores definido se agrupa en clases de equivalencia
para las cuales se aplican las siguientes reglas:
-  Todos los valores para los cuales se espera que el programa tenga un
comportamiento común se agrupan en una clase de equivalencia (CE)
-  Las clases de equivalencia no pueden superponerse y no pueden
presentar ningún salto (discontinuidad)
-  Las clases de equivalencia pueden consistir en un rango de valores (por
ejemplo, 0<x<10) o en un valor aislado (por ejemplo, x = Verdadero)
Partición de equivalencia - ejemplo
-  Las clases de equivalencia se escogen para entradas (“inputs)
válidas y no válidas
-  Si el valor x se define como 0 ≤ x ≤ 100, entonces, inicialmente, se pueden
identificar tres clases de equivalencia:
1. x<0 (valores de entrada no válidos)
2. 0 ≤ x ≤ 100 (valores de entrada válidos)
3. x > 100 (valores de entrada no válidos)
-  Se pueden definir CE adicionales, conteniendo, pero no limitadas a:
-  Entradas no numéricas
-  Números muy grandes o muy pequeños
-  Formatos numéricos no admitidos

<0 0 - 100 > 100

Partición de equivalencia: variables de
entrada

-  Todas las variables de entradas (“input variables ”) del objeto de

prueba son identificadas, por ejemplo,
-  Campos de una Interfaz Gráfica de Usuario (“GUI”)
-  Parámetros de una función (por ejemplo, componente de prueba)
-  Se define un rango para cada valor de entrada (“input”)
-  Este rango define la suma del todas las clases de equivalencia válidas
(CEv)
-  Las clases de equivalencia no válidas (CEnv) están constituidas por
aquellos valores no pertenecientes al rango
-  Aquellos valores que deben ser tratados de una forma diferente
(conocidos o sospechosos) son asignados a una clase de equivalencia
aparte

Página 17
Partición de equivalencia - ejemplo
•  El porcentaje será presentado en un diagrama de barra. Se
aplicarán los siguientes requisitos adicionales (ambos valores
incluidos:
–  Valores entre 0 y 15: barra color gris
–  Valores entre 16 y 50: barra color verde
–  Valores entre 51 y 85: barra color amarillo
–  Valores entre 86 y 100: barra color rojo

•  Ahora hay cuatro clases de equivalencia válidas en lugar de una:

–  1ra clase de equivalencia válida: 0 ≤ x ≤ 15
–  2da clase de equivalencia válida:16 ≤ x ≤ 50
–  3ra clase de equivalencia válida: 51 ≤ x ≤ 85
–  4ta clase de equivalencia válida: 86 ≤ x ≤ 100

<0 0 - 15 16 - 50 51 - 85 86 - 100 > 100

Clase de equivalencia – selección de representantes

•  En el último paso, se determina un representante de cada clase de

equivalencia así como el resultado esperado para cada uno de ellos

Variable Clase de equivalencia Representantes

Valor porcentaje EC1: 0 ≤ x ≤ 15 + 10
(válido)
EC2: 16 ≤ x ≤ 50 + 20
EC3: 51 ≤ x ≤ 85 + 80
EC4: 86 ≤ x ≤ 100 + 90
Valor porcentaje EC5: x < 0 -10
(no válido)
EC6: x > 100 +200
EC7: x no entero 1,5
EC8: x non numérico fred
 •  Ejemplo  de  Tabla  de  Análisis  

Variable Clase de equivalencia Estado Representante T01 T02 T03

Precio de venta EC11: x >= 0 válido 1000,00 ­ ­ ­
al público
EC12: x < 0 no válido -1000,00
EC13: x valor no numérico no válido fred
Descuento EC21: 0% < x < 100% válido 10% ­ ­ ­
EC22: x < 0% no válido -10%
EC23: x > 100% no válido 200%
EC24: x valor no numérico no válido fred
Precio del porte EC31: x = 6 válido 6 ­
EC32: x = 9 válido 9 ­
EC33: x = 12 válido 12 ­
EC34: x ≠ {6, 9, 12} no válido 4
EC35: x valor no numérico no válido fred
 Partición en clases de equivalencia :
ejemplo 2/3
-  Los siguientes casos de prueba han sido generados utilizando CE
no válidas, cada una en combinación con CE válidas de otros
elementos:

Variable Clase de equivalencia Estado Representante T04 T05 T06 T07 T08 T09 T10
Precio de EC11: x >= 0 válido 1000,00 ­ ­ ­ ­ ­
venta al
público EC12: x < 0 no válido -1000,00 ­
EC13: x valor no numérico no válido fred ­
Descuento EC21: 0% < x < 100% válido 10% ­ ­ ­ ­
EC22: x < 0% no válido -10% ­
EC23: x > 100% no válido 200% ­
EC24: x valor no numérico no válido fred ­
Precio del EC31: x = 6 válido 6 ­ ­ ­ ­ ­
porte
EC32: x = 9 válido 9
EC33: x = 12 válido 12
EC34: x ≠ {6, 9, 12} no válido 4 ­
EC35: x valor no numérico no válido fred ­
Partición en clases de equivalencia:
ejemplo 2/4
-  Se obtienen 10 casos de prueba: 3 casos de prueba positivos
(valores válidos) y 7 casos de prueba negativos (valores no
válidos)

Variable Estado Representante T01 T02 T03 T04 T05 T06 T07 T08 T09 T10
Precio de válido 1000,00 ­ ­ ­ ­ ­ ­ ­ ­
venta al no válido -1000,00 ­
público
no válido fred ­
Descuento válido 10% ­ ­ ­ ­ ­ ­ ­

no válido -10% ­
no válido 200% ­
no válido fred ­
Precio del válido 6 ­ ­ ­ ­ ­ ­
porte válido 9 ­
válido 12 ­
no válido 4 ­
no válido fred ­
Partición en clases de equivalencia -
Transición

-  La transición de la especificación o definición de la funcionalidad a

la creación de las clases de equivalencia
-  Con frecuencia es una tarea difícil debido a la carencia de
documentación precisa y completa
-  Los límites no definidos o las descripciones faltantes hacen difícil la
definición de las clases de equivalencia
-  Con frecuencia, es necesario mantener contacto con el cliente con el
objeto de completar la información
Análisis de valores límite /1
-  El análisis de valores limite amplía la técnica de partición en clases
de equivalencia introduciendo una regla para seleccionar
representantes
-  Los valores frontera (valores límite) de la clase de equivalencia
deben ser probados de forma intensiva
-  ¿Porqué prestar más atención a los límites?
-  Frecuentemente los límites del rango de valores no están bien definidos o
conducen a distintas interpretaciones
-  Comprobar si los límites han sido implementados (programados)
correctamente
-  Observación importante
-  ¡La experiencia demuestra que, con mucha frecuencia, los errores tienen
lugar en los límites del rango de valores!
El análisis de los valores límite puede ser aplicado en todos los niveles de
prueba. Es fácil de aplicar y su capacidad de detección de
defectos es alta en el caso de especificaciones detalladas
Análisis de valores límite /2
-  El análisis de valores límite asume que:
-  La clase de equivalencia está compuesta de un rango continuo de
valores (no por un valor individual o un conjunto de valores discretos)
-  Se pueden definir los límites para el rango de valores
-  Como extensión a la partición en clases de equivalencia el
análisis de valores límite es un método que sugiere la selección
de representantes
-  Partición en clases de equivalencia:
-  Evalúa un valor (típico) de la clase de equivalencia
-  Análisis de valores límite:
-  Evalúa los valores límite (frontera) y su entorno
-  Se utiliza el siguiente esquema:

Rango de valores: Valor Máximo ≤ x ≤ Valor Mínimo

Valor Mínimo - δ Límite Inferior Límite Inferior + δ

Valor Máximo - δ Límite Superior Valor Máximo + δ
δ es el menor incremento definido para el valor.
Por ejemplo: 1 para valores enteros.
Definición de valores límite
-  El esquema básico sólo puede ser aplicado cuando el rango de
valores ha sido definido de conformidad con el mismo esquema.
-  En este caso no son necesarias pruebas adicionales para un valor en el
interior del rango de valores
-  Si un CE está definido como un único valor numérico, por ejemplo, x
= 5, los valores correspondientes al entorno también serán utilizados
-  Los representantes (de la clase y su entorno) son: 4,5 y 6
Análisis de valores límite ejemplo 3a
-  Ejemplo 3a:
-  Rango de valores para un descuento en %: 0,00 ≤ x ≤ 100,00
-  Definición de CE
3 clases:
-  1. CE: x < 0,00
-  2. CE: 0,00 ≤ x ≤ 100,00
-  3. CE: x > 100,00
-  Análisis de valores límite
Extiende los representantes a:
2. EC: -0,01; 0,00; 0,01; 99,99; 100,00; 100,01

-  Nota importante:
-  En lugar de un representante para la CE válida, ahora hay seis
representantes (cuatro válidos y dos no válidos)
Pruebas de tabla de decisión (“decision
table testing ”)
-  La partición en clases de equivalencia y el análisis de valores límite
tratan entradas en condiciones aisladas
-  Sin embargo, una condición de entrada puede tener efectos sólo en
combinación con otras condiciones de entrada
-  Todos los métodos descritos previamente no tienen en cuenta el
efecto de dependencias y combinaciones
-  El uso del conjunto completo de las combinaciones de todas las
clases de equivalencia de entrada conduce, normalmente, a un
número muy alto de casos de prueba (explosión de casos de
prueba)
-  Con la ayuda del gráfico causa-efecto ("cause-effect graph") y
tablas de decisión obtenidas a partir de aquellos, la cantidad de
combinaciones posibles se puede reducir de forma sistemática a un
subconjunto de las mismas
Pruebas de tabla de decisión (“decision
table testing ”)
-  Ejemplo 5: Banca Online (“Online-Banking”).
-  El usuario se identifica a través de su número de cuenta y PIN. Si tuviera
suficiente cobertura podrá realizar una transferencia. Para poder realizar
la transferencia debe introducir los datos del receptor y un TAN válido.

Cobertura
Realizar transferencia
(^
Receptor correcto
(^ TAN identificado como utilizado
~
~ V
Denegar transferencia
TAN válido

~ Solicitar TAN nuevamente

Pruebas de tabla de
-  Ejemplo 5: Banca Online (“Online-Banking”)

T01 T03 T04 T05

T02
Precondiciones (Causas) Suficiente cobertura SI NO - -
Receptor correcto SI - NO -
TAN válido SI - - NO
Actividades (Efectos) Realizar transferencia SI NO NO NO
Marcar TAN como utilizado SI NO NO NO

Denegar transferencia NO SI SI NO
Solicitar TAN nuevamente NO NO NO SI

-  Cada columna de la tabla representa un caso de prueba

-  Construcción de la tabla de decisión:
-  Seleccionar un efecto
-  Retroceder en el diagrama para identificar la causa
-  Cada combinación de causas está representada por una columna en la
tabla de decisión (un caso de prueba)
-  Combinaciones de causas idénticas, conducentes a efectos distintos, se
pueden fusionar para formar un único caso de prueba
Pruebas de transición
de estado muerto   muerto  

•  Para determinar los casos de casado   casado  

prueba utilizando un diagrama de "morir“ "morir“
transición de estado se construye "casarse“ "casarse“
un árbol de transición
divorciado   viudo  
–  El estado inicial es la raíz del árbol
“m.d.p.“
–  Para cada estado que pueda ser “divorciarse“

alcanzado desde el estado inicial se

crea un nodo que está conectado
casado   muerto  
“morir”
a la raíz por una rama “casarse”
–  Esta operación se repite y finaliza
cuando: soltero   muerto  
"morir“
•  El estado del nodo es un estado final
“ser soltero"
(una hoja del árbol)
O
•  El mismo nodo con el mismo estado
No  nacido  
ya es parte del árbol Evento: “m.d.p..”: muerte de pareja
 Pruebas de transición de estado
•  Cada camino desde la raíz a una hoja entonces representa un caso
de prueba de prueba de transición de estado

•  El árbol de transición de estado para este ejemplo conduce a los

siguientes seis casos de prueba

M M
o   o  

estado 1 estado 2 estado 3 estado 4 estado 5 estado final C   C  

no nacido soltero muerto muerto

no nacido soltero casado muerto muerto D   V  

no nacido soltero casado viudo muerto muerto.

no nacido soltero casado viudo casado casado
C   M
no nacido soltero casado divorciado muerto muerto o  
no nacido soltero casado divorciado casado casado

S   M
o  

NN  
Árbol de transición de estado

-  El  árbol  de  transición  de  

muerto   muerto  
estado  de  nuestro  
ejemplo  puede  ser  
casado   casado  
extendido  ualizando  
"morir“ "morir“ transiciones  inválidas  
"casarse“ "casarse“
divorciado  
(casos  de  prueba  
viudo  
negaavos,  pruebas  de  
“divorciarse“
“m.d.p.“ robustez  
casado   muerto   -  Ejemplo:  dos  
“morir”
error   transiciones  inválidas  
“casarse”
muerto   posibles  –  hay  más  
soltero  
“divorciarse“
"morir“ -  Las  transiciones  
“ser soltero" imposibles  entre  estados  
error  
No  nacido   “m.d.p.“ no  se  pueden  probar  

Evento: “m.d.p..”: muerte de pareja

Página 33
 IV - Técnicas de diseño de
pruebas
03 - Técnicas basadas en la especificación o de caja negra
Pruebas basadas en casos de uso /2

-  Ejemplo de un diagrama de caso de uso sencillo (fuente: Wikipedia).

-  El  diagrama  de  la  izquierda  describe  la  funcionalidad  
de  un  Sistema  “Restaurant”  sencillo  
-  Los  casos  de  uso  están  representados  por  óvalos  y  
los  actores  están  representados  por  figuras  de  palo  
-  El  actor  “Patron”  puede  comer  comida  (“Eat  Food”),  
pagar  por  la  comida  (“Pay  for  Food”)o  beber  vino  
(“Drink  Wine”)  
-  El  actor  cocinero  (“Chef”)  sólo  puede  preparar  
comida.  Observar  que  los  actores  “Patron”  y  
“Cashier”  están  involucrados  en  el  caso  de  uso  “Pay  
for  Food”  (pagar  por  la  comida)  
-  La  caja  define  los  límites  del  sistema  “Restaurant”,  
es  decir,  los  casos  de  uso  representados  son  parte  
del  sistema  a  modelar  y  no  los  actores  

Página 34
 Tester Profesional de Software

Consejos:

Test de LIMITES: Diseñar el test case teniendo en cuenta los limites de los
campos en que se va a grabar la información. (ídem para el test de
particiones)
Test de Estados: Comenzar por este tipo de tests cuando no es clara la
definición de partición de datos.
Test de Componentes Funcional: Prestar mayor Atención a las propiedades
y a los componentes que tengan impacto en la información que se esta
ingresando.
Tests basados en experiencia anterior: Analizar información resumida, la
abundancia de información puede ser nocivo.

Recordar que no esta mal consultar o preguntar distintas opiniones de hecho

se espera que un tester sea un generador de dialogo.
 Using structural coverage

Spec   Enough  
SoMware   tests?  
Tests  
Results  OK?  

What's  
covered?  
More  tests   Coverage  OK?  

Stronger structural techniques

(different structural elements)

Increasing coverage
 Statement coverage

•  percentage of executable statements exercised by a test suite

number of statements exercised
total number of statements
•  example:
–  program has 100 statements ?
=  
–  tests exercise 87 statements
–  statement coverage = 87%

Statement coverage
is normally measured
by a software tool.

Typical  ad  hoc  tesQng  achieves  60  -­‐  75%  

 Example of statement coverage

1   read(a)   Test Input Expected

2   IF  a  >  6  THEN   case output
3          b  =  a   1 7 7
4   ENDIF  
5   print  b  

As all 5 statements are ‘covered’ by

this test case, we have achieved
100% statement coverage
Statement
numbers
 Decision coverage (Branch coverage)
Decision coverage
is normally measured
by a software tool.

•  percentage of decision outcomes

exercised by a test suite
number of decisions outcomes exercised
=   False
total number of decision outcomes ?
True
•  example:
– program has 120 decision outcomes
– tests exercise 60 decision outcomes
– decision coverage = 50%

Typical  ad  hoc  tesQng  achieves  40  -­‐  60%  

 Paths through code 1234

12 12 123 ?  

?   ?   ?   ?  

?  
 Paths through code with loops

1 2 3 4 5 6 7 8 ….

for as many times as it

is possible to go round
?   the loop (this can be
unlimited, i.e. infinite)
 Tips

CC >= BC/DC >= SC

Cyclomatic
complexity Minimum no. of
Minimum no. of
tests to achieve 100% tests to achieve
100%
Branch Coverage/
Statement
Decision Coverage
Coverage
 One decision, no ELSE

Read A
Read  
IF A > 0 THEN
Print “A positive”
ENDIF THEN
A>0   Print  
ELSE’s = 0 + 1 = 1 = SC Otherwise
(ELSE)
Indentations (Tabs) = 2 = BC

2
–  cyclomatic complexity: _____
–  minimum tests to achieve:
1
• statement coverage: ______
• branch coverage: _____
2  ENDIF  
 Self-draw 1 Read  
Read stock level for item
IF Item in stock THEN THEN
In?   Get  
Get from stores
ELSE
ELSE
Order   &  
Draw  the  
Order from supplier
Print  
diagram  
Print “Item back-ordered” in  your  
notes  
ENDIF
Print “Item processed”
2
–  cyclomatic complexity: _____  ENDIF  
–  minimum tests to achieve:
2
• statement coverage: ______
2
• branch coverage: _____
Print  
 WHILE loop Read  

Read order line FALSE

?  

WHILE more items ordered DO TRUE

Check availability Get  &  
Get from stores
Check  
ENDDO
Print “Finished processing”
2
–  cyclomatic complexity: _____  ENDDO  
–  minimum tests to achieve:
1
• statement coverage: ______
1
• branch coverage: _____
Print  
 init  

WHILE and IFs

do  
Pseudo-­‐code:  

Result  =  0   if   r=r+1  
Right  =  0  
DO  WHILE  more  QuesQons  
       IF  Answer  =  Correct  THEN     end  
     Right  =  Right  +  1  
       ENDIF   res  
END  DO  
Result  =  (Right  /  QuesQons)   if   pass  
IF  Result  >  60%  THEN    
     Print  "pass"  
4
– complex:  _____   fail  
ELSE  
     Print  "fail”   2
• st  cov:  _____  
END  IF   • br  cov:  _____  
2
end  
 Then Display  
Wait   Valid  
card?   “Enter..  
Self draw 2
Wait for card to be inserted
IF card is a valid card THEN False
Else Valid  
display “Enter PIN number”
PIN?  
WHILE PIN is valid DO
select transaction Reject   True
ENDDO card  
ELSE (otherwise) select  
trans.  
reject card
Print record

ENDIF  ENDDO  
Indentation
Shows – complx:  _____  3
End of IF
ENDIF
• st  cov:  _____  
2
• br  cov:  _____  
2
Print  rec  
LCSAJ  
Stress  
Performance  
Carga  
Volumen  
L10N  
I18N  
Regression  
Recovery  
Usability  
MMD  
Ethical  Hacking  
Taxonomy  
Configuraaon  
API  
Smoke  
Fuzz….  
 
EJERCICIO  
Tienes  1000,  sumale  40.  
Sumale  1000  más.  Agrégale  
30  y  nuevamente  1000.  
Sumale  20.  Sumale  1000  y  
añádele  10.  
  FINISHED  FILES  ARE  THE  RE-­‐  
     SULT  OF  YEARS  OF  SCIENTIF-­‐  
     IC  STUDY  COMBINED  WITH  
     THE  EXPERIENCE  OF  YEARS.  
 Técnicas  De  Diseño  
 
También  son  técnicas  de  esamación.  
Ayudan  a  generar  escenarios  de  pruebas  eficaces.  
Tienen  el  concepto  de  probar  lo  menos  posible  pero  tanto  como  haga  falta.  
Es  donde  mayor  parte  del  esfuerzo  de  Tesang  debe  concentrarse.  
Miden  la  CALIDAD  de  un  objeto  de  prueba  desde  disantos  puntos  de  vista.  
 
Reducen  la  posibilidad  de  un  error  humano  mientras  se  testea.  
 ¡Muchas  gracias!  

www.bstriker.com  
Logo@Copyright