Teste de Software e Qualidade

8/8/2019 Teste de Software e Qualidade

1/82

1

Testes de Software &Testes de Software &

Garantia da QualidadeGarantia da Qualidade

(Conceitos & Fundamentos(Conceitos & Fundamentos))Professor: Rodrigo Zauza PassosProfessor: Rodrigo Zauza Passos


2/82

2

Slide: 2

Capacitar o aluno a testar umasoluo tecnolgica fundamentando-

senas melhores prticas de

Testes e de Garantia da Qualidade.

:.::.: ObjetivoObjetivo


3/82

3

Slide: 3

Achar falhas

Previnirfalhas

Evitar falhas

:.::.: A Oratec trabalha com as prticas:A Oratec trabalha com as prticas:


4/82

4

Slide: 4

Ferramen

tas

Ferramen

tas

Proces

sos

Proces

sos

Pesso

as

Pesso

as

Qualquer ciclo deproduo em TI sustentado por 3 pilares: Processos: o melhor

mtodo simples deusar e cabe no bolso dequem o usa.

Pessoas: devem atuarem suas competnciasnivelada ao seu perfilpessoal;

Ferramentas: socomponentesfacilitadores e nocomplicadores.

e ele amparado pelaquadra Escopo, Prazo,Custo & Qualidade ,mandamento de qualquerbom gerente de rea.

:.::.: Variveis de ContextoVariveis de Contexto


5/82

5

Aurlio Requisito

Condio que se deve satisfazer para que uma coisa fique legal e regular;

Exigncia imprescindvel para a consecuo de certo fim;

Qualidade, dotes, predicados exigidos para um produto;

Requerimento Ato ou efeito de requerer (pedir /solicitar).

Para um Analista

Um requisito algo que o produto deve fazer ou alguma qualidade que deveapresentar.

Para um Testador:

Um requisito algo (verificvel) que o produto deve fazer ou alguma qualidade(mensurvel)que deve apresentar e que (pelo seu risco de comprometer o sucesso

do projeto, compen$a) deve ser testado.

:.::.: Nivelamento de Conceitos (I)Nivelamento de Conceitos (I)

Conc

eito


6/82

6

Usurio Implementador Testador Organizao

Facilidade deuso,

desempenho,confiabilidade

dos resultados,etc.

Facilidade demanuteno e

conformidade emrelao aos

requisitos deusurios, etc.

Software com boaqualidade aqueleque cumpre com

os requisitosnegociais com omnimo de falhas

possvel.

Cumprimentode prazo, boapreviso decusto, boa

produtividadee rentabilidade.

Vises sobre a qualidade de um Software:

:.::.: Nivelamento de Conceitos (II)Nivelamento de Conceitos (II)

Conc

eito


7/82

7

Existe defeito quando um software ou parte dele:

No funciona, mas os requisitos ou os artefatos indicam quefunciona;

Faz algo na aplicao em que os requisitos ou os artefatosindicam que no deveria fazer;

Faz algo que os requisitos ou os artefatos no indicam; Faz algo que os requisitos ou os artefatos no indicam, pormdeveriam indicar;

No funciona adequadamente aos olhos do testador, pois difcil de entender, de usar ou lento.

:.::.: Nivelamento de Conceitos (III)Nivelamento de Conceitos (III)

Defeito=Falha=Anomalia=Bug=Ocorrncia

Conc

eito


8/82

8

Caso1- DisneysLionKing(1994-1995)-ADisney,em1994lanouseuprimeirojogodemultimediaparacrianasLionKingAnimated stories. Eraaprimeira

da Disney,erenom

ada, fezumenormecampanhademarketingportodo osEUA.Vendasforamabsurdamentefantsticas (vendasdenatal).Porm,nodiaseguinte,26dedezembrode1994 odepartamentodeatendimentoaocliente daDisney recebeuumaenxurradadeligaesdeclientesindignadosenervosos.OCDnofuncionava emmuitasdasplataformas dePCexistentesnomercado.Razo: Osoftwarefoidesenvolvidoemumanicaplataforma(quenorefletia

asmaiscomunsdomercado!).

Faltouumsimples testedemultiplataforma....

:.::.: Bug Arrasadores (1/4)Bug Arrasadores (1/4)


9/82

9

Caso2PatriotMissileDefenseSystem,1991UmprogramadedefesaamericanochamadodestarwarsincluaochamadoU.S.Patriotmissile.Oprimeirousofoinaguerradogolfoem1991paradefenderdo

smisseisScuds doIraque.Porem,estesistemafalhouinmerasvezescontravriosmisseis,incluindoummssiliraquianoquematou28soldadosamericanosemDhahran,na Arbia Saudita. Numaanalise,encontraramacausa:umbugnosistemadecontagem(pequenotimingerror) culminandonumerrode14horasdediferenaentreosrelgios,deixandoosistemadecontagemdefasado.

Custo: Nomnimo,28vidas.



10/82

10

Caso3LimitedeendereosdecomputadornaWWWQuandooTCP/IP(protocolodetransmissodepacotesdaInternet)foicriadopelossr.VintCerfeBobKahn,elesacharamque4.3bilhesdeendereoseramsufici

entes.Parecemuito,mascomocrescimentoexponencialdetransaesnessaplataforma,pode-seatingirolimiteantesdoprevisto.Umconsrciodeorganizaesgovernamentaisestosepreparandoparaampliarestenmeroparamaisde200trilhesdeendereospossveis.

Asingelamudanaimplicamexercommuitagenteemuitoscomputadoresespalhadospeloplaneta.Serumproblemacomplexo

delogsticaesincronizaodossistemas.



11/82

11

Caso4NovoSistemaDDDnoBrasilEmjulhode1999,oBrasilexperimentouumcaosnosistemadetelefoniapormaisde uma semana,devidoainstalaodonovosistemadecodificaodeDDD. Asrazesdoproblema foram: Aanatelno

checouo resultadodostestesfeitospelas operadorasdentrodosestados.Entreestadosnenhumtestefoifeito;

AtrocadoSistemanopassouporumtestesimuladoemnvelnacional; Asoperadorasapenassimularamconexodosequipamentosemrealimitadas;

Nemtodasasoperadoras fizeraminvestimentossuficientesparasuportaramudana;

AcampanhapublicitriadaAnatelenfatizavasomenteodireito deescolhadasoperadoras, masno explicavacom clarezaasmudanas; SeiscentraisdaEmbrateltiveramerrosnaprogramao,fazendocomqueaschamadasfossempararemlocaisdiferentes.



12/82

12

So disciplinas distintas, mas convergentes: meta aqualidade;

Testar significa verificar e validar um ou mais artefatos; Garantir a qualidade significa disciplinar a verificao e

validao deles nos ciclos de produo e testes de software; Misso do time de teste: achar anomalias; Misso do time de QA: no deixar que elas se repitam; Nas tratativas legais, o Analista de QA quem responde pela

qualidade do software, baseando-se nas mtricas do time detestadores.

:.::.: Nivelamento de Conceitos (IV)Nivelamento de Conceitos (IV)

Testes de Software Garantia da Qualidade

Viv

ncia


13/82

13

Slide: 13

ProcessosProcessos


14/82

14

Slide: 14

Processo de Software

Gerncia eficaz e controledas atividades

Processo de Software

muito bem definido

pessoas

procedimentos

ferramentas

Req usurios

Req.desenvolvedor

Req.organizao

:.::.: Processo de SoftwareProcesso de Software


15/82

15

Slide: 15

RADRADRADRAD

XM

XM

XM

XM

OMT

OMT

OMT

OMT

Booc

Booc

hhB

ooc

Booc

hh

PMBOK

PMBOK

PMBOK

PMBOK

Ca

tal

ysi

Ca

tal

ysi

ss

Ca

tal

ysi

Ca

tal

ysi

ss

Wa

te

Wa

te

rfall

rfall

Wa

te

Wa

te

rfall

rfall

USDP

USDP

SSADSSAD

MM

W-M

odelV

-Mod

el

Na Engenharia de Software,

existem vrias metodologias de produo ...

Focaliza o quFocaliza o qu

Anlise do sistemaAnlise do sistema

Fase planejamentoFase planejamento

Anlise de requisitosAnlise de requisitos

Focaliza o comoFocaliza o como

Projeto da ArquiteturaProjeto da Arquitetura

CodificaoCodificao

TestesTestes

Focaliza as mudanasFocaliza as mudanas

Manutenes A.C.E.Manutenes A.C.E.

DefinioDefinio

DesenvolvimentoDesenvolvimento

ManutenoManuteno

Informaes processadas

Funo e desempenho desejados

Riscos mapeadosInterfaces estabelecidas

Arquitetura da soluoEstrutura de dados

Padres de codificao

Planejamento dos Testes

Contramedidaspara a gerncia

da produo

XP

XP

XP

XP

FDD

FDD

FDD

FDD

RUP

RUP

RUP

RUP

DS

DM

DS

DM

DS

DM

DS

DM

SC

RU

M

SC

RU

M

SC

RU

M

SC

RU

M

Iconix

Iconix

Iconix

Iconix

Crista

Crista

ll

Crista

Crista

ll

EUP

:.::.: Mtodos de ProduoMtodos de Produo


16/82

16

Slide: 16

Existem vrios modelos e padres de qualidade:Existem vrios modelos e padres de qualidade:

:.::.: Padres de QualidadePadres de Qualidade


17/82

17

Slide: 17

Existem vrios modelos e padres de qualidade:Existem vrios modelos e padres de qualidade:

Efici

ncia

Integ

ridade

Usabilid

ade

Corretitu

de

Confiabili

dad

e

Manuten

ibilidad

e

Flexibilidade

Tes

tabilidade

PortabilidadeReusabilidade

Interoperabilidade

A maioria deles avaliam a qualidade do software a partir de3 aspectos:

(1) Operao do Produto;

(2) Reviso do Produto;(3) Transio do Produto.

A maioria deles avaliam a qualidade do software a partir de3 aspectos:

(1) Operao do Produto;

(2) Reviso do Produto;(3) Transio do Produto.

Modelo de MCall (1977)

:.::.: Padres de QualidadePadres de Qualidade


18/82

18

Slide: 18

Testability Maturity Model (TMM) Test Organization Maturity (TOM) Testing Assessment Program (TAP)

Evaluation&Test SW-CMM Key Process Area(CMM-I KPA)

Metrics-based Testing Maturity Model (MB-TMM)

Em desenvolvimento

:.::.: Padres de Qualidade para testesPadres de Qualidade para testes


19/82

19

Slide: 19

ProcessoProcesso

ProdutoProduto

RequerimentosRequerimentos

AnliseAnlise

DesenhoDesenho

CodificaoCodificaoTestes

de Unidade

Testesde Unidade

Testesde SistemaTestes

de Sistema

Testesde Aceitao

Testesde Aceitao

Testesde Integrao

Testesde Integrao

testeteste

testeteste

testeteste

testeteste

docdoc

docdoc

docdoc

docdoc

:.::.: Um bom modelo de produoUm bom modelo de produo


20/82

20

Slide: 20

A implantao de umprocesso de formal de

Testes no ciclo produtivo

otimiza as relaessetoriais e garante acadncia do trabalho

coorporativo

:.::.: Viso Geral sobre os TestesViso Geral sobre os Testes


21/82

:.: O Processo de Testes de Software:.: O Processo de Testes de Software

Existem basicamente 2 vises sobre os testes:

Viv

ncia

Viso Restrita Viso Abrangente

Um bom testador um bomprogramador;

Testar significa mais gastosde recursos e tempo doprojeto;

O testador s deve achar

erros.

Um bom testador aqueleque domina as regrasnegociais do SUT (SystemUnder Testing);

Testar significa investir paragastar menos;

Alm de ach-los, o testador

deve indicar como evit-los epreven-los. (QA/QD/QC)

21


22/82

Registrar/monitorar erros

Analisar todos os requisitos

Produzir mtricas

Formular indicadoresde qualidade


So premissas dos testes de software:

22


23/82

23

Com

ple

xid

ad

e

Ciclo de Vida

ConcepoDiagnosticar

situao

atual

Assimilar

Conhecimento

Definir

Estratgias

InstrumentalizaoInstrumentalizar as estratgias definidas

Criar, compartilhar e realimentar Expertise

EvangelizaoMonitorar e criar cultura, Divulgar, Negociar,

Compartilhar, Justificar, Celebrar, Aperfeioar...

Analistas /Arquitetode Testes

Analista/Executores deTestes

t+1

Analistas eExecutores


Atividades Macro X Responsveis:

t


24/82

Todos os testes devem ser rastreveis at a sua origem,que so os requisitos negociais;

Planeje sempre. Mas seja comedido ! Cerca de 60% das falhas ocorrem na concepo do produto;

Crie casos de testes genricos; Testes no tm fim. Eles apenas provocam um ponto de

corte ! Processos inteligentes (e eficientes) so independentes de

ferramentas;

Antes de executar um esforo de testes defina bem ospapis e responsabilidades;


Dicas teis:Vi

vncia

24

o


25/82

25

:.::.: Nivelamento de Conceitos (V)Nivelamento de Conceitos (V)Conc

eito

Artefatos documentais do processo de testes de

software: Requisitos: lista contendo todas asnecessidades negociais do SUT(funcionais/no funcionais);

Plano ou estratgia: documentocom o conjunto das atividades doesforo de teste. Aqui se definem ostipos de testes, cronograma, papis,responsabilidades e infra necessria;

Cenrio ou roteiro: conjunto decasos de testes que seroexecutados para cobrir um ou maisprocessos negociais;

Casos de teste: um conjunto deprocedimentos que valida/verificaum ou mais requisitos negociais;

Etapas: aes devalidao/verificao de um caso deteste.


26/82

26

Construa um simples caso de teste cujameta :

Verificar se um palito de fsforo acende.

Tempo estimado: 30 minutos (20/10)

:.: Desafio #1:.: Desafio #1


27/82

27


Estratgia de testes

Testes caixa branca

Testes exploratrios

Testes caixa preta

Testes de vulnerabilidades

Testes de Carga e Stress

Testes Funcionais

Testes baseados em cenrios Testes negativos

Inspeo deArtefatos Doc.

Verificao deDiagramas UML

Validao de modelos ER

Validao/Verificao derequisitos

Rgua de AvaliaoFornecedores

Testes unitrios

A estratgia de testes faz parte da Metodologia dos

testes !!!Testes de regresso

Testes automatizados


28/82


Tipos de testes mais comuns:

Funcionais: verificam se o SUT est agindo conforme os requisitos negociaisprojetados inicialmente; Baseados em cenrios: uma boa estratgia para abranger a maior parte dos

requisitos negociais do SUT; Testes negativos: so atividades que tentam contradizer a natureza para qual

aquela funcionalidade foi projetada; Testes de caixa-preta: valida somente a entrada e a sada de um processo, no

importando o que acontece dentro dele; Performance: so atividades que avaliam o desempenho do SUT ou de umcomponente de acordo com parmetros balisadores de aceitabilidade (requisitos nofuncionais);

Load/Stress: a estratgia utilizada para averiguar a suportabilidade dainfraestrutura do SUT (rede, middleware, RDBMS, etc.). O teste de stress nada mais do que o ponto limite da carga utilizada no esforo do teste e suportada pela

infraestrutura; Teste exploratrio: sua finalidade reconhecer as caractersticas do prottipo etentar provocar a ocorrncia de anomalias;

Teste de vulnerabilidade: com o advento da Internet tornou-se atividadeestratgica, pois verifica os limites do SUT com relao s atividades de XSS, Cross-Scripting, sobrecarga de nveis de servio;

Testes automatizados: so viveis quando os requisitos do SUT so maduros e

estveis; Testes de regresso: aplicvel quando um coponente do SUT sofre alterao.28


29/82

Slide: 29

Levantamento de

Necessidades

Anlise dosRequisitos e

ArtefatosEspecificao

/Desenho

Inspeo eValidao

Corrigir e solucionardvidas

Esclarecimento

Reescrever

Revalidar

EnviarDefeitoFornecedor

AbrirDefeito

RetestarDefeito

CancelarDefeito

EncerrarDefeito

Defeito ?

BUGFix ?

Ciclo de Reparo deDefeitos

Gerenciamento de

Testes e Defeitos

:.: O ciclos de produo e:.: O ciclos de produo ede testes de softwarede testes de software

Gerenciamento do ciclode produo do

software


30/82

30

No se pode testar aquilo que no se sabe;

Clientes sempre mudam os requisitos; Uso de prottipos no pode ser desculpa para nodocumentar requisitos;

Interfaces grficas abrangem unicamente requisitosfuncionais de alto nvel, sem detalhes, sem regras de

negcios; Usurios no sabem o que querem at terem algopaupvel.

:.: Melhores prticas de testes (1/9):.: Melhores prticas de testes (1/9)

#1) Requisito a base do teste


31/82

31

fcil de configurar: customizar uma funcionalidade conforme asnecessidades do usurio deve ser uma tarefa fcil para ele;

Est em conformidade com os requisitos que o cliente pediu.

eficiente: recursos de infraestrutura atendem a performance dafuncionalidade (processador, memria, discos e linhas decomunicao);

Seja expandvel: recursos que permitam a utilizao de objetos ecomponentes de estrutura funcional para compor os novos requisitosde sistema (isso ideal para a perfeita manuteno do software);

Tenha flexibilidade: procedimento que permite a mudana dosoftware em ambientes diferentes. Ex.: mudana de Banco deDados;

Tenha integridade: que a habilidade do software proteger a elemesmo via permissionamento de nveis de acesso.

#2) Um bom software aquele que



32/82

32

Tenha interoperabilidade: que a capacidade de trocar dadoscom outros softwares;

Seja de fcil manuteno: reutilizao de componentes,parametrizao, orientao a objetos e todas as demais tcnicas que

organizam e facilitem a vida do programador; Seja gerencivel: que a habilidade de gerenciar os recursos de

alocao, gesto de contedo e configurao; Seja seguro: que a capacidade do software executar uma

funcionalidade sem causar condies inseguras;

Seja fcil de usar: a facilidade que o software pode seraprendido e operado;

Seja verificvel: a capacidade de verificar que o software esttrabalhando corretamente.

#2) Um bom software aquele que



33/82

33

A linguagem escrita no um meio confivel de especificarrequisitos. Podem aparecer requisitos: Vagos Ambguos Incompletos De difcil compreenso e entendimento No to fceis de se testar

DICA: Use alguns desses modelos para incrementar a linguagemescrita:

Modelo de dados Modelo de processos Modelo de objetos Tabelas de deciso Casos de uso

#3) Adote um modelo baseado em requisitos



34/82

34

Para cada requisito, identifique os possveiscenrios;

Use tcnicas como: Classes de equivalncia; Grficos de causa e efeitos;Tabelas de deciso;

rvores de deciso; Anlise da integridade relacional; Casos de uso.

#4) Defina formalmente os casos de testes



35/82

35

Testes positivos: qualquer atividade que aponta avalidao de um requisito. Supe-se que o dado entrado vlido e ele ser processado atravs dos caminhos normais;

Testes negativos: o processo de execuo de umprograma com a inteno de encontrar erros. Supe-se que odado entrado invlido e ele ser processado atravs da

manipulao errada dos caminhos funcionais;

#5) Execute casos de testes positivos enegativos



36/82

36

Requisito #1 Requisito #2 Requisito #... Requisito #n

Caso de Teste #1 Passou Passou No executado

Caso de Teste #2 Passou Passou

Caso de Teste #3 Falhou Passou Passou

Caso de Teste #...

Caso de Teste #n

#6) Crie matriz de rastreabilidade decomponentes



37/82

37

Baseie os cenrios de teste de regresso em: Anlise de impacto

Quando um requisito modificado, quais so os componentes

afetados com a mudana ?Quando um componente modificado, quais os requisitos que

devem ser retestados novamente ?Este tipo de anlise comea no desenvolvimento com os

programadores e continua durante a fase dos testes

Anlise de risco

Ferramentas de Capture/Playback podem ser muito til (inclusive paraautomatizar os testes de regresso).

#7) Execute testes de regresses maisabrangentes



38/82

38

Ferramenta de planejamento de testes Gerenciamento de testes

Ferramentas de Case Design Ferramentas para testes de cobertura Ferramentas para execuo de testes e de

capture/replay Ferramentas para anlise esttica BugTrackers

#8) Selecione ferramentas para suportar ostestes



39/82

39

Testes de software uma disciplina contextual; A prtica a melhor maneira de aprimorar seus

conhecimentos; Procure se certificar profissionalmente:

CSTE (QAI/USA) CSQA (QAI/USA)

CBTS (ALATS/BRZ)

#9) Aprimore continuamente sua capacitao



40/82

40

Em desenvolvimentoEm teste

Em teste

Em homologao

Em homologaoEm produo

:.: Ambientes de produo:.: Ambientes de produo


41/82

41



42/82

42

Toda a estrutura destinada aosanalistas de sistema e programadores;

segmentado em produo e testes facultativo o uso das equipes



43/82

43

Toda a estrutura destinada equipe detestadoresTesta os requisitos de softwareEstrutura semelhante ao da produo



44/82

44

Pelos erros ocorridos e mtricascoletadas, novos casos seroconfeccionados para garantir a qualidadede software

Beta testes somente para um grupo deusurios


Slide: 45


45/82

45

Escolhamaisdetrsmaneirasparamediraestabilidadedoprodutoserliberadoemproduo:

1. PadresdeCodificao2. FluxodeFalhas/Condio3. EstabilidadePerformtica4. Qualidad

edosTestes5. MNC(MtricasNoCartesianas)

:.: Mtricas clssicas:.: Mtricas clssicasem testesem testes

Slide: 46


46/82

46

Emcadaciclodetestes,consegue-secoletar: Asfalhaspormdulos(local aondeafalhafoidetectada);

Oprogressodostestes; Aquantidadedefalhasporstatus,severidade,testador,etc;

Obugfixtime;

Aquantidadedefalhasemambientesdeprepsproduo;

Adensidadedefalhas(#falhas/KLOC) Adistribuiodeesforoporfasesdeproduo;

Aevoluodaqualidadedostestes; Aevoluodotamanho de cadaverso;

:.: Mtricas clssicas:.: Mtricas clssicasem testesem testes

Slide: 47


47/82

47

Somtricasquedependemdocontextodaanlise.

Fatoresqueatrapalhamaqualidadedostestes(faltademetodologia,

tempocurtoparaexecuodostestes,documentaorudimentar,infraestrutura,etc.);

Percentualdeacertosdobugfix; ndicedesatisfaodocliente;

Evoluodosrequisitosporverso;

:.: Mtricas no:.: Mtricas nocartesianascartesianas

Slide: 48

cia


48/82

48

Viv

nci

Acredite:

Uma mtrica a fotografia de umasituao em um dado momento;

Em um processo, existem ferramentas,mtodos e pessoas. E para medir aspessoas, o conjunto de mtricas, comcerteza, no sero cartesianas;

Por mais catico que seja a produo desoftware na corporao, sempre haver

uma maneira de medir a sua eficincia; Se me fosse dado seis horas para

derrubar uma rvore, as quatro primeiraspassaria afiando o machado. (AbraamLincoln)

Planeje sempre a sua medio.


49/82

49

:.: Mtricas recursos de infra:.: Mtricas recursos de infra


50/82

50

448.5 MB/hr324.9 MB/hr214.0 MB/hr170.1 MB/hr123.2 MB/hr115.7 MB/hr73.9 MB/hr31.4 MB/hr31.0 MB/hr26.0 MB/hr18.0 MB/hr

SMBCC:Mail

IPNFSRPC

NetBIOS Session SrvcTCPISO

SQL ServerWWW (Web)

FTP

10.2 ms1.5 ms

--35.5 ms123.3 ms90.0 ms-- ms-- ms4.2 s

189.0 ms673.4 ms

Application List

Bytes Application Average Response Time

113 Applications

Lock Filter

WAN Top ApplicationsSMB32%

All Others10%

NetBIOSSession Srvc

6%TCP7%

Pipe files8%

IP Port 11779%

CC:Mail28%

Passo Nove

:.: Mtricas recursos de infra:.: Mtricas recursos de infra

Slide: 51


51/82

51

1. Preparao dos testes

Objetivo: preparar todas as informaes eartefatos necessrios para um efetivo e eficienteprocesso de testes. Isto inclui levantar asespecificaes de uso, estabelecer as classe edesenhar um modelo flexvel para o processo detestes.

:.: O ciclo de testes:.: O ciclo de testes

Slide: 52


52/82

52

2. Planejando os testes

Objetivo: identificar a estratgia e

procedimentos que melhor se adaptem metodologia de desenvolvimento garnatindo aeficincia e eficcia dos testes.

Esta etapa est em paralelo ao desenho dosistema e inclui: recursos, responsabilidades eobjetivo dos testes; identificao de riscos e

prioridades e identificao de entidades quesero ou no testadas.


Slide: 53


53/82

53

3. Desenhando os testes

Objetivo: definir os casos de teste, dados eprocedimentos que estaro em conformidade comos requisitos iniciais. Esta etapa envolve

planejamento estratgico prativo que detectepossveis falhas. A definio dos testes deveprimar pela simplicidade e baixo custo deexecuo.



54/82

Slide: 55


55/82

55

4. Anlise do resultado dos testes

Objetivo: Pra aprimorar o processo produtivo,nesta etapa so coletadas analisadas as

evidncias geradas pela etapa anterior.



56/82

56

1. Criar os artefatos

documentais para osseguintes softwares: Controle de Estoque; Locadora de DVD; Automoo Comercial

(lanchonete);1. Consideraes:

Dividam-se em 3 grupos eescolham o System UnderTesting (SUT);

Se tiver dvida, pergunte ao

Professor sobre os requisitosnegociais de cada software;

Garanta a rastreabilidade dosartefatos;

1. Tempo estimado: 1h30min



57/82

57

Interpretao (do usurio e do analista); Ambiguidade; Inconsistncia;

No relevncia; Informalidade; No testabilidade; Gramatical e morfolgica;

Sub especificao.

:.: Anomalias dos Artefatos documentais:.: Anomalias dos Artefatos documentais

ncia


58/82

58

Que exista um

DOCUMENTO ESCRITO (Formal)

com aquilo que deve ser feito e

que neste documento exista uma

lista identificada de REQUISITOS.

(pode ser um anexo)

CMM nvel 2 essencialmente sobre Requisitos

CMM nivel 3 introduz formalmente Testes de Requisitos (peer-reviews)

:.: Premissas para se executarem testes:.: Premissas para se executarem testesVivn

c

ncia


59/82

59

:.: Apresentao da metodologia A360:.: Apresentao da metodologia A360Vivn

Criada por Rodrigo Z. Passos em 2006 para ajudar a rea deGesto de Projetos de uma grande siderrgica. A misso eraenvolver todos os colaboradores na homologao de artefatos defornecedores externos, atestando ou no a entrega do produto.

A metodologia baseia-se em 3 premissas:

1. No perfil de colaborador envolvido (permite at 4 perfis);

2. No Questionrio com n perguntas baseadas na ISO 9126 econfiguradas de acordo com o artefato a ser inspecionado(documentos, diagramas, etc.);

3. No parecer tcnico final.

Objetivo ldico: testar o software antes dele

existir !

ncia


60/82

60


O conceito de qualidade varivel em relao ao perfil doanalisador;

Uma equipe de testes mais qualificada para inspecionar aqualidade do que qualquer outro time; mas a etapa de

homologao legalmente envolve terceiros; O desafio foi desenvolver uma metodologia que transforma asubjetividade da anlise contextual do documento, em mtricasobjetivas que demonstrem matematicamente a qualidade doartefato inspecionado;

Criou-se um questionrio-base para todos os colaboradores

envolvidos responderem uma escala gradativa de 1 a 7. Cada umadas respostas gera uma mdia ponderada para a categoria deanlise realizada (via ISO9126);

Nenhum dos colaboradores pode ter acesso ao questionrio deseu colega;

O confronto das mdias encontradas pelos testadores e demaiscolaboradores fornece vrias perspectivas de anlise sobre a

Fatores motivadores para criao da metodologia

ncia


61/82

61


Insumo bsico - ISO 9126: Portais da QualidadePortais daQualidade

Significado Pergunta Chave

Funcionabilidade Evidencia o conjunto defunes que atendem snecessidades implcitas eexplcitas para a finalidadea que se destina o produto

Satisfaz snecessidades ?

Confiabilidade Evidencia a capacidade do

produto de manter seudesempenho ao longo dotempo e em condiesestabelecidas.

imune a falhas ?

Usabilidade Evidencia a facilidade paraa utilizao do produto

E fcil de usar ?

Eficincia Evidencia o relacionamentoentre o nvel dedesempenho do produto e

a quantidade de recursosutlizados, sob condiesestabelecidadas..

rpido e enxuto ?

Manutenibilidade Evidencia o esforonecessrio para realizarmodificaes no produto.

fcil de modificar ?

ncia


62/82

62


Engenharia Conceitual: normalmente o escopo do projeto acordado entre a rea de

usurios e demais tcnicos; Requistos de Negcio/Funcionais:

lista contendo todas as necessidades do software/soluo emTI;

Especificaes Funcionais ou de Caso de Uso Diagramas UML:

estado, transio, casos de uso, etc; Diagramas Fluxo de Dados Diagramas de Entidade e Relacionamento

Tipos de artefatos que podem ser

inspecionados:


63/82

63

1. Inspecionar os artefatos

documentais criadosanteriormente para: Controle de Estoque; Locadora de DVD; Automoo Comercial

(lanchonete);1. Consideraes:

Dividam-se novamente em 3grupos, com composiorespectiva diferente da anterior;

Use a metodologia A360;

Registre as anomaliasencontradas;

1. Tempo estimado: 2h


Slide: 64


64/82

64

Pessoasessoas

Slide: 65

ncia


65/82

65

Fique preparado: tudo vai bem at o seu relatrio apontar o

primeiro problema; Voc apenas um inspetor ! A garantia da qualidade no a sua

responsabilidade. Bugs so altamente relevantes ao ciclo de produo; Mantenha seu senso de humor e aceitao. No se irrite por estar

testando uma bosta Faa seu trabalho e tenha vida normalaps o expediente de trabalho. Voc s pode testar aquilo que se pode observar;

Algum aqui j testou um sistema de bilhetagem ????

Use a disciplina a seu favor: torne-se amiguinho de padres eprocessos;

Fique esperto: nunca se ter tempo suficiente para se testar umSUT;

No se iluda: no existe Software Zero-Defect ! Desenvolvedores no so inimigos !!! Sobre o SUT: simplicidade no sinnimo de facilidade.

:.: Frases a serem ditas a um testador::.: Frases a serem ditas a um testador:Vivn


66/82

Slide: 67

ncia


67/82

67

Tem um forte auto-marketing; Sabe automotivar-se; Entende e defende o usurio/cliente;

Seleciona talentos na equipe que faro adiferena na hora da entrega do produto desoftware com qualidade;

Estuda o processo negocial, aplica o

conhecimento tcnico e acredita no seu taco( pr-atividade)

:.: Um bom profissional de testes::.: Um bom profissional de testes:Vivn

Slide: 68


68/82

68

O programa de certificao do Quality AssuranceInstitute (QAI) um dos mais aceitosinternacionalmente.

Existem dois tipos de certificao:

1. CSTE (produto): preparao do ambiente de

testes; planejamento de testes; test design;execuo de testes; automao; ferramentas;elaborao de relatrios; etc.

2. CSQA (processo): estrutura de modelos dequalidade; definio de padres de prtica e

controle de qualidade; construo,implementao e melhoria dos processos dequalidade; mtricas.

Outras instituies outorgantes: InternationalSoftware Testing Institute e American Society for

Quality

:.: Certificao Profissional:.: Certificao Profissional

Slide: 69


69/82

69

:.: Papis & Responsabilidades:.: Papis & ResponsabilidadesPapel Responsabilidades

Gerente, Coordenador ouLder de testes

Viabiliza os recursos necessrios paraum esforo de testes; conduz asatividades e as monitora emconformidade com o planejamento;Realoca recursos ao longo do ciclo.

Analistas de Testes Planeja a estratgia e elabora casosde testes, baseando-se nos requisitosde negcio do SUT.

Arquiteto de Testes Prepara toda infra estruturanecessria para se executar aestratgia de testes. Instalaferramenta, gera massa de dados,mede performance, etc.

Executor de Testes Executa tudo o que est planejado.Figura-chave do ciclo de testes pois as

ocorrncias encontradas por ele soos indicadores da qualidade doproduto inspecionado.


70/82


71/82

71

FerramentasFerramentasFerramentasFerramentas

Gerenciamento deDados e Arquivos

Depurao e

Anlise Interativa

Gerenciamento deFalhas e Performance

Automao dosTestes

:.: Viso geral de ferramentas em testes:.: Viso geral de ferramentas em testes

Slide: 72

ncia


72/82

72

Viv

n

A Tecnologia deve conter:

GUI: Interface com capacidades de capture /playback, planejamento, script, gerenciar eanalisar resultados, relatrios e grficos;

Repositrio: Armazena o projeto;

Carga: Simulao de usurios, volume,performance e stress;

Analisador: Monitorar teste;Detector: Detecta e relata erros/problemas;

Tracker: Captura defeitos e armazena;

:.: Dicas sobre ferramentas:.: Dicas sobre ferramentas

Slide: 73

ncia


73/82

73

Viv

Dicas importantes para gerentes que iro adquirir ferramentas de mercado:

Definir requisitos iniciais:

Quais so os principais problemas que as ferramentas dever a ajud-lo resolver ? Quais so as capacidades que a ferramenta dever ter para ser eficiente no ambiente de trabalho ?

Qual o impacto da absoro cultural das novas tecnologias defendidas pela ferramenta ?

Se as diretrizes estratgicas existem investimentos em testes de automao, qual o ROI da ferramenta ?

Pesquisar muito antes de comprar:

Interaja com a comunidade: participe de feiras, congressos, etc;

Leia tudo o que puder: web, livros, revistas, jornais, blog;

Analise a relao contextual: mudana cultural corporativa X nova ferramenta;

Refinar os requisitos: Durante a pesquisa, voc ir descobrir novas necessidades em termos ferramentais;

Ache uma maneira de convencer o setor de que aquela ferramenta no ir acabar com o emprego doscolaboradores. Apresente contigncia, caso isso seja inevitvel;

Fazer prova de aderncia:

a chance que se tm de verificar o quo eficiente a ferramenta ser para o ciclo produtivo da corporao

Cuidado: Os grandesplayers so predadores

Eles sempre iro dizer que ferramentas salvaro a lavoura.

No se enganem: estes s vendem caixinhas.

Delimite o seu terreno.

:.: 5 etapas de avaliao de ferramentas::.: 5 etapas de avaliao de ferramentas:


74/82

74

ExperimentosExperimentos

Slide: 75

ncia


75/82

75

:.: Inspeo de Artefatos em TI (1/5):.: Inspeo de Artefatos em TI (1/5)Por Ciclo de Entregas

Qua

lid

ade

Ciclo de Vida

Qualidade suficientemente boa

No d pra testara Qualidade

O artefato foi liberado.

O Ciclo de testes comeaaqui !

Build / Verso / Release

Fim do Ciclo

Testes NOK:problemas vista

Testes OK:

comportamentoesperado

Testes noexecutados:Vriascausas.

Viv

Slide: 76

vncia


76/82

76

:.: Inspeo de Artefatos em TI (2/5):.: Inspeo de Artefatos em TI (2/5)Ritmo mais demorados de testes

Qua

lid

ade

Ciclo de Vida






Fim do Ciclo


Testes OK:comportamentoesperado


Viv

Slide: 77

vncia


77/82

77

:.: Inspeo de Artefatos em TI (3/5):.: Inspeo de Artefatos em TI (3/5)Ritmo de testes estilo Pizzaria

Qua

lid

ade

Ciclo de Vida






Viv




Slide: 78

vncia


78/82

78

:.: Inspeo de Artefatos em TI (4/5):.: Inspeo de Artefatos em TI (4/5)Sob presso foram a homologao.

Qua

lid

ade

Ciclo de Vida





Fim do Ciclo


Testes OK:

comportamentoesperado

Testes noexecutados:Vrias

causas.

Viv


Slide: 79

vncia


79/82

79

:.: Inspeo de Artefatos em TI (5/5):.: Inspeo de Artefatos em TI (5/5)Est acontecendo algo com quem produz o SUT

Qua

lid

ade

Ciclo de Vida




O Ciclo de testes comeaaqui ! Fim do Ciclo



Testes noexecutados:

Vriascausas.

Viv


Slide: 80

i li d ( / )


80/82

80

:.: Finalizando (1/2):.: Finalizando (1/2)

Resultados obtidos com os desafios deste curso: Desafio#1 : descoberta da real

importncia sobre como se deveescrever um artefato documentalem TI;

Desafio#2: a partir doconhecimento de domnio pblico,foram construdos os artefatosdocumentais para o ciclo de testesde 3 SUTs;

Desafio#3: aplicando a teoria prtica - pelo uso da ferrementaCamaleo, o aluno populou os ciclosde controle de produo e testouefetivamente os prottipos dos

SUTs.

Slide: 81

Fi li d (2/2)


81/82

81

So premissas de uma boa prtica de testes desoftware:

O valor de qualquer prtica, depende de seucontexto;

Existem boas prticas em um contexto, mas noexistem melhores prticas;

Projetos evoluem ao longo do tempo de maneirararamente antecipada;

Pessoas trabalhando em esprito de equipe so ocontexto mais importante de qualquer projeto;

:.: Finalizando (2/2):.: Finalizando (2/2)

Slide: 82


82/82

http://www.oratec.com.br

Dvidas & Sugestes:[email protected]

Teste de Software e Qualidade

Documents

Transcript of Teste de Software e Qualidade