Você está na página 1de 17

Processo de Teste de Software

por Alexandre Bartie

O Processo de Testes de Software representa uma estruturao de etapas, atividades, artefatos, papis e responsabilidades que buscam a padronizao dos trabalhos e ampliar a organizao e controle dos projetos de testes. O Processo de Teste, como qualquer outro processo deve ser revisto continuamente, de forma a ampliar sua atuao e possibilitar aos profissionais uma maior visibilidade e organizao dos seus trabalhos, o que resulta numa maior agilidade e controle operacional dos projetos de testes.

Etapa 1: Planejamento dos Testes


Esta etapa caracteriza-se pela definio de uma proposta de testes baseada nas expectativas do Cliente em relao prazos, custos e qualidade esperada, possibilitando dimensionar a equipe e estabelecer um esforo de acordo com as necessidades apontadas pelo Cliente.

Dinmica das Macro-Atividades


Este diagrama representa a seqncia das "macro-atividades" a serem executadas na etapa de "Planejamento dos Testes".

Detalhamento das Macro-Atividades


Esta lista representa o conjunto de atividades que devero ser executadas para que cada macro-atividade seja considerada finalizada, funcionando como um "check-list" de execuo da etapa de "Planejamento dos Testes".

Estudo do Projeto:

Estudar as modificaes solicitadas pelo Cliente (novos requisitos); Estudar as modificaes de arquiteturas dos aplicativos; Estudar as lies aprendidas dos Projetos Anteriores; Avaliar expectativas de custos, prazos e qualidade exigidas pelo Cliente; Avaliar os riscos envolvidos nos Projetos e seus impactos neste processo;

Avaliao de Impacto:

Avaliar se o projeto exige a criao de casos de testes "progressivos"; Avaliar se o projeto exige modificaes em casos de testes "regressivos" Avaliar se o projeto exige adequaes na automao dos testes; Avaliar se o projeto exige adequao nas atuais ferramentas empregadas; Avaliar se o projeto exige a aquisio/construo de novas ferramentas; Avaliar se o projeto exige modificaes na estruturao do ambiente;

Anlise Interna de Esforo

Levantar mtricas histricas para auxiliar na elaborao das estimativas de esforo; Estimar esforo interno para absoro dos impactos da Arquitetura dos Testes; Demonstrar esforo externo para absoro dos impactos da Arquitetura dos Testes;

Anlise Externa de Esforo:

Avaliar disponibilidade de espao fsico e infra-estrutura para os Terceiros; Especificar as necessidades de adequaes que sero repassadas a Terceiros; Especificar mtricas de qualidade e produtividades esperadas; Especificar SLA's de servio e multas contratuais; Estabelecer concorrncia e obter a melhor proposta (opcional); Receber Proposta de Trabalho (Cronograma, Prazos e Custos da Terceirizao);

Definio de Cenrios Possveis (Durao, Esforo, Custo e Qualidade):

Levantar Lista de Projetos em Andamento e a serem Iniciados; Avaliar a disponibilidade de recursos internos para alocao no Projeto; Identificar Cenrios Diversos (Terceirizao, Reduo de Escopo, Repriorizao de Projetos); Definir Cronograma-Macro para cada cenrio identificado; Definir Riscos para cada cenrio identificado e Planos de Ao Esperados; Estabelecer Propostas e Aguardar aprovao da Diretoria;

Aprovao do Planejamento:

Obter o Aceite das Propostas de Cenrios Aprovados pela Diretoria; Obter o Aceite de uma das Propostas pelo Cliente; Divulgar do Cenrio Aprovado do Projeto aos colaboradores e terceiros; Obter a Assinatura do CONTRATO-MESTE e elaborar os ANEXOS; (no caso de terceirizao) Alocar Espao Fsico dos Terceiros; (no caso de terceirizao) Comunicar a Finalizao da Etapa de Planejamento dos Testes; (externo)

Definio das Responsabilidades


Neste diagrama, est a representao dos papis e responsabilidades para cada grupo de atividades envolvido na etapa de "Planejamento dos Testes".

Mapeamento dos Artefatos


Nesta representao grfica, esto destacados os "artefatos de entrada" exigidos como premissa para que cada macro-atividade possa ser realizada. Tambm so destacados os "artefatos de sada" produzidos como resultado da atividade.

Etapa 2: Especificao dos Testes


Esta etapa caracterizada pela identificao dos casos de testes que devero ser construdos e modificados em funo das mudanas solicitadas pelo Cliente, bem como pelo prprio aperfeioamento do processo de testes (ampliao da cobertura).

Dinmica das Macro-Atividades


Este diagrama representa a seqncia das "macro-atividades" a serem executadas na etapa de "Especificao dos Testes".

Detalhamento das Macro-Atividades


Esta lista representa o conjunto de atividades que devero ser executadas para que cada macro-atividade seja considerada finalizada, funcionando como um "check-list" de execuo da etapa de "Especificao dos Testes".

Estudo dos Requisitos:

Estudar os requisitos funcionais e no funcionais solicitadas pelo Cliente (novos requisitos); Estudar as modificaes de requisitos solicitados pelo Cliente (mudanas de requisitos); Revisar os artefatos e identificar "inconsistncias" dos requisitos; Estabelecer o Aceite dos Documentos fornecidos e "feedback" da qualidade dos mesmos; Estudar as lies aprendidas da Etapa "Especificao de Testes";

Especificar as Adaptaes da Arquitetura dos Testes:

Especificar as adequaes nas atuais ferramentas empregadas; Especificar as novas ferramentas exigidas pelo projeto; Especificar as modificaes estruturais na organizao do ambiente; Especificar as adequaes na automao da preparao do ambiente (script de teste); Especificar as adequaes na automao da execuo dos testes (script de teste); Especificar as adequaes na automao da anlise dos resultados (script de teste);

Identificao dos Casos de Testes

Identificar cada solicitao de mudana requisitada pelo Cliente; Identificar todos os Casos de Uso envolvidos em cada solicitao; Identificar Casos de Uso no cobertos adequadamente por Casos de Testes; (legado) Identificar todos o Fluxos do Caso de Uso (Bsico, Alternativo e Exceo); Identificar os casos de testes que garantam cada Fluxo do Caso de Uso;

Refinamento dos Casos de Testes:

Estabelecer dinmica com os Analistas de Testes que possuem conhecimento horizontal; Apresentao de um quadro-geral do impacto das mudanas nos respectivos aplicativos; Cada Analista de Testes apresenta seus casos de testes por aplicativo; O grupo de Analistas de Testes criticam e sugerem melhorias nos casos de testes; O grupo de Analista de Testes avaliam o nvel de cobertura alcanado; Novas reunies sero realizadas at que seja alcanado o patamar ideal de casos de testes;

Aceite dos Casos de Testes:

Identificar reas-Chaves para apresentao dos casos de testes (Clientes Internos e Externos) Apresentar os casos de testes "progressivos" que sero aplicados nos testes; Apresentar os casos de testes "regressivos" que sero aplicados nos testes; Realizar refinamento dos casos de testes apresentados ("regressivos e progressivos"); Estabelecer o acordo Mtuo de Responsabilidade sobre o Nvel de Qualidade do Software;

Refinamento do Projeto de Testes:

Reavaliar as estimativas de esforo e durao do Processo de Teste; (se necessrio) Estabelecer um Cronograma-Detalhado, baseado no Cronograma-Macro j elaborado; Reavaliar riscos do Projeto em funo de uma maior detalhamento sobre os requisitos; Negociar eventuais modificaes em relao durao, prazo e custo do projeto de testes; Comunicar a Finalizao da Etapa de "Especificao dos Testes"; (externo)

Definio das Responsabilidades


Neste diagrama, est a representao dos papis e responsabilidades para cada grupo de atividades envolvido na etapa de "Especificao dos Testes".

Mapeamento dos Artefatos


Nesta representao, esto destacados os "artefatos de entrada" exigidos como premissa para que cada macro-atividade possa ser realizada. Tambm so destacados os "artefatos de sada" produzidos como resultado da atividade.

Diferena entre Verificao e Validao


Verificao A verificao tem o objetivo de avaliar se o que foi planejado realmente foi realizado. Ou seja, se os requisitos, funcionalidades e performance documentados foram implementados. Verificao tambm pode ser realizada para especificao de sistemas, para avaliar se os requisitos esto sendo documentados como deveriam e ainda prever falhas ou inconsistncias entre requisitos.

Validao A validao tem o objetivo de avaliar se o que foi entregue atende as expectativas. Ou seja, se os requisitos, independente do que foi planejado, esto implementados para atender ao negcio (cliente).

Validao final do sistema realizada pelo cliente ou usurio.

Matriz de Rastreamento
O objetivo principal dos testes reduzir a probabilidade da ocorrncia de um defeito quando o software estiver em produo, minimizando os riscos para o negcio e garantindo que as necessidades do cliente esto sendo atendidas. Erro (error): uma ao humana que produz um resultado incorreto. Defeito (fault): A manifestao de um erro no software.
Tambm conhecido como Bug. Se executado, o defeito pode causar uma falha.

Falha(failure): Diferena indesejvel entre o observado e o esperado. Defeito encontrado. Falha um evento;Defeito um estado do software, causado por um erro. O Software pode conter defeito, mas no falhar.

Confiabilidade do Software x Defeito.


a probabilidade que o software no causar uma falha no sistema por um tempo especificado, sob condies determinadas. Isso importante por que definido em que condies o sistema atingira o nvel de confiabilidade prometida. Ex.:O Software pode atingir a confiabilidade de no apresentar mais do que uma falha por ms quando no for utilizado por mais de dez usurios

"uma pessoa inteligente resolve um problema. Uma pessoa sbia evitlo". Einsten

Tipos de teste
Alguns dos principais tipos de Teste de Sistema Tipo de Teste Teste de Unidade Teste de Integrao Teste Operacional Teste Positivo-negativo Teste de regresso Teste de caixa-preta Descrio Teste em um nvel de componente ou classe. o teste cujo objetivo um pedao do cdigo. Garante que um ou mais componentes combinados (ou unidades) funcionam. Podemos dizer que um teste de integrao composto por diversos testes de unidade*1 Garante que a aplicao pode rodar muito tempo sem falhar. Garante que a aplicao vai funcionar no caminho feliz de sua execuo e vai funcionar no seu fluxo de exceo. *2 Toda vez que algo for mudado, deve ser testada toda a aplicao novamente. Testar todas as entradas e sadas desejadas. No se est preocupado com o cdigo, cada sada indesejada visto como um erro.

Teste caixa-branca Teste Funcional Teste de Interface Teste de Performance Teste de carga Teste de aceitao do usurio

O objetivo testar o cdigo. s vezes, existem partes do cdigo que nunca foram testadas. Testar as funcionalidades, requerimentos, regras de negcio presentes na documentao. Validar as funcionalidades descritas na documentao (pode acontecer de a documentao estar invlida) Verifica se a navegabilidade e os objetivos da tela funcionam como especificados e se atendem da melhor forma ao usurio. Verifica se o tempo de resposta o desejado para o momento de utilizao da aplicao. Verifica o funcionamento da aplicao com a utilizao de uma quantidade grande de usurios simultneos. Testa se a soluo ser bem vista pelo usurio. Ex: caso exista um boto pequeno demais para executar uma funo, isso deve ser criticado em fase de testes. (aqui, cabem quesitos fora da interface, tambm). Testar a quantidade de dados envolvidos (pode ser pouca, normal, grande, ou alm de grande). Testar a aplicao sem situaes inesperadas. Testar caminhos, s vezes, antes no previstos no desenvolvimento/documentao. Testar se a aplicao funciona corretamente em diferentes ambientes de hardware ou de software. Testar se a instalao da aplicao foi OK. Testar a segurana da aplicao das mais diversas formas. Utilizar os diversos papis, perfis, permisses, para navegar no sistema.

Teste de Volume Testes de stress Testes de Configurao Testes de Instalao Testes de Segurana

Muitos outros tipos de testes so possveis. Entretando, preciso entender os requisitos funcionais e no funcionais (garantia e utilidade) do negcio, para definir exatamente o nvel de testes que pretende-se estabelecer para uma determinada aplicao. Testar demais to infeficiente quanto testar pouco.

Teste de software
Origem: Wikipdia, a enciclopdia livre.

O teste do software a investigao do software a fim de fornecer informaes sobre sua qualidade em relao ao contexto em que ele deve operar. Isso inclui o processo de utilizar o produto para encontrar seus defeitos. O teste um processo realizado pelo testador de software, que permeia outros processos da engenharia de software, e que envolve aes que vo do levantamento de requisitos at a execuo do teste propriamente dito.
[editar]Viso

geral

No se pode garantir que todo software funcione corretamente, sem a presena de erros,[1] visto que os mesmos muitas vezes possuem um grande nmero de estados com frmulas, atividades e algoritmos complexos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo aumentam ainda mais a complexidade. Idealmente, toda permutao possvel do software deveria ser testada. Entretanto, isso se torna impossvel para a ampla maioria dos casos devido quantidade impraticvel de possibilidades. A qualidade do teste acaba se relacionando qualidade dos profissionais envolvidos em filtrar as permutaes relevantes.[2] Falhas podem ser originadas por diversos motivos. Por exemplo, a especificao pode estar errada ou incompleta, ou pode conter requisitos impossveis de seremimplementados, devido a limitaes de hardware ou software. A implementao tambm pode estar errada ou incompleta, como um erro de um algoritmo. Portanto, uma falha o resultado de um ou mais defeitos em algum aspecto do sistema. O teste de software pode ser visto como uma parcela do processo de qualidade de software. A qualidade da aplicao pode, e normalmente, varia significativamente de sistema para sistema. Os atributos qualitativos previstos na norma ISO 9126 so funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e portabilidade. De forma geral, mensurar o bom funcionamento de um software envolve compar-lo com elementos como especificaes, outros softwares da mesma linha, verses anteriores do mesmo produto, inferncias pessoais, expectativas do cliente, normas relevantes, leis aplicveis, entre outros. Enquanto a especificao do software diz respeito ao processo de verificao do software, a expectativa do cliente diz respeito ao processo de validao do software. Um desenvolvimento de software organizado tem como premissa uma metodologia de trabalho. Esta deve ter como base conceitos que visem a construo de um produto de software de

forma eficaz. Dentro desta metodologia esto definidos os passos necessrios para chegar ao produto final esperado. Assim, quando se segue uma metodologia para o desenvolvimento de um produto de software, espera-se um produto final que melhor agrade tanto aos clientes quanto ao prprio fornecedor, ou seja, a empresa de desenvolvimento. Observando este aspecto, no faz sentido iniciar a construo de um produto de software sem ter uma metodologia de trabalho bem solidificada e que seja do conhecimento de todos os envolvidos no processo. Porm, alm de uma crescente demanda por softwares de qualidade, as empresas de desenvolvimento de software sofrem cada vez mais presso por parte dos clientes para que o produto seja entregue num curto perodo de tempo. Este fato pode fazer com que uma slida metodologia de trabalho acabe por se desequilibrar. Independentemente da metodologia de trabalho empregada no desenvolvimento de um software, para que se obtenha um produto final com um certo nvel de qualidade imprescindvel a melhoria dos processos de engenharia de software. Uma maneira vivel para se assegurar a melhoria de tais processos seria tomar como base modelos sugeridos por entidades internacionais respeitadas no assunto. Dentro de uma gama de modelos, sejam eles para situaes e ambientes especficos ou para solues genricas, existem alguns que so mais utilizados e tidos como eficientes, como por exemplo os SWCMM, SE-CMM, ISO/IEC_15504 e o mais conhecido CMMI. Outro fator com grande influncia sobre a qualidade do software a ser produzido o que diz respeito aos testes que sero executados sobre tal produto. Todas as metodologias de desenvolvimento de software tm uma disciplina dedicada aos testes. Atualmente esta uma tarefa indispensvel, porm muitas vezes efetuada de maneira ineficiente, seja pelo subestimar dos que desenvolvem, pela falta de tempo ou mesmo pela falta de recursos humanos e financeiros. De acordo com um estudo conduzido pelo NIST em 2002, os defeitos resultam num custo anual de 59,5 bilhes de dlares economia dos Estados Unidos. Mais de um tero do custo poderia ser evitado com melhorias na infraestrutura do teste de software.[3]
[editar]Princpios

Para Myers (2004), h princpios vitais para o teste de software. O caso de teste deve definir a sada esperada, de forma a reduzir a interpretao do critrio de sucesso. A sada da execuo do teste deve ser exaustivamente analisada. Os casos de teste devem verificar no somente as condies invlidas de execuo, como tambm as condies vlidas. Outro conceito apresentado utilizar pessoas e organizaes diferentes para a implementao e para a verificao. A entidade de teste possui uma viso destrutiva do sistema, em busca de erros, enquanto a entidade de programao possui uma viso construtiva, em busca da implementao de uma especificao. Myers tambm aborda o esforo para se construir casos de teste. Deve-se evitar testes descartveis, pois a qualidade do teste piora gradualmente com as iteraes de desenvolvimento. Em contrapartida, h o teste de regresso, que permite quantificar a evoluo da qualidade de software, mantendo e executando novamente testes realizados anteriormente. O mesmo autor afirma que, diferente do que se poderia considerar senso comum, a probabilidade de existncia de erros num certo trecho de cdigo proporcional quantidade de erros j encontradas anteriormente. Basicamente, erros aparecem em grupos. Trechos especficos de cdigo de um software qualquer esto mais propensos a ter erros que outros.
[editar]Tcnicas

Existem muitas maneiras de se testar um software. Mesmo assim, existem as tcnicas que sempre foram muito utilizadas em sistemas desenvolvidos sobrelinguagens estruturadas que ainda hoje tm grande valia para os sistemas orientados a objeto. Apesar de os paradigmas de desenvolvimento serem completamente diferentes, o objetivo principal destas tcnicas

continua a ser o mesmo, encontrar falhas no software. Abaixo esto descritas algumas das tcnicas mais conhecidas.
[editar]Caixa-branca

Ver artigo principal: teste de caixa-branca Tambm chamada de teste estrutural ou orientado lgica, a tcnica de caixa-branca avalia o comportamento interno do componente de software. Essa tcnica trabalha diretamente sobre o cdigo fonte do componente de software para avaliar aspectos tais como: teste de condio, teste de fluxo de dados, teste de ciclos, teste de caminhos lgicos, cdigos nunca executados. Os aspectos avaliados nesta tcnica de teste dependero da complexidade e da tecnologia que determinarem a construo do componente de software, cabendo portanto avaliao de mais aspectos que os citados anteriormente. O testador tem acesso ao cdigo fonte da aplicao e pode construir cdigos para efetuar a ligao de bibliotecas e componentes. Este tipo de teste desenvolvido analisando o cdigo fonte e elaborando casos de teste que cubram todas as possibilidades do componente de software. Dessa maneira, todas as variaes relevantes originadas por estruturas de condies so testadas. Um exemplo bem prtico desta tcnica de teste o uso da ferramenta livre JUnit para desenvolvimento de classes de teste para testar classes ou mtodos desenvolvidos em Java. Tambm se enquadram nessa tcnica testes manuais ou testes efetuados com apoio de ferramentas para verificao de aderncia a boas prticas de codificao reconhecidas pelo mercado de software. A aderncia a padres e boas prticas visa principalmente a diminuio da possibilidade de erros de codificao e a busca de utilizao de comandos que gerem o melhor desempenho de execuo possvel. Apesar de muitos desenvolvedores alegarem que no h ganhos perceptveis com essa tcnica de teste aplicada sobre unidades de software, devemos lembrar que, no ambiente produtivo, cada programa pode vir a ser executado milhares ou milhes de vezes em intervalos de tempo pequenos. na realidade de produo que a soma dos aparentes pequenos tempos de execuo e consumo de memria de cada programa poder levar o software a deixar de atender aos objetivos esperados. A tcnica de teste de caixa-branca recomendada para as fases de teste de unidade e teste de integrao, cuja responsabilidade principal fica a cargo dos desenvolvedores do software, que por sua vez conhecem bem o cdigo fonte produzido.
[editar]Caixa-preta

Ver artigo principal: Teste de caixa-preta Tambm chamada de teste funcional, orientado a dado ou orientado a entrada e sada, a tcnica de caixa-preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo.[4] Dados de entrada so fornecidos, o teste executado e o resultado obtido comparado a um resultado esperado previamente conhecido. Como detalhes de implementao no so considerados, os casos de teste so todos derivados da especificao. Quanto mais entradas so fornecidas, mais rico ser o teste. Numa situao ideal todas as entradas possveis seriam testadas, mas na ampla maioria dos casos isso impossvel.[5] Outro problema que a especificao pode estar ambgua em relao ao sistema produzido, e como resultado as entradas especificadas podem no ser as mesmas aceitas para o teste.[6] Uma abordagem mais realista para o teste de caixa-preta escolher um subconjunto de entradas que maximize a riqueza do teste. Pode-se agrupar subconjuntos de entradas possveis que so processadas similarmente, de forma que testar somente um elemento desse subconjunto serve para averiguar a qualidade de todo o subconjunto. Por exemplo, em um sistema que aceita um inteiro como entrada, testar todos os casos possveis pode gerar pelo menos dezenas de milhares de casos de testes distintos. Entretanto, a partir da especificao do sistema, pode-se encontrar um subconjunto de inteiros que maximizem a qualidade do teste. Depende do propsito do sistema, mas casos possveis incluem inteiros pares, inteiros mpares, zero, inteiros positivos, inteiros negativos, o maior inteiro, o menor inteiro.

Essa tcnica aplicvel a todas as fases de teste teste unitrio, teste de integrao, teste de sistema e teste de aceitao. A aplicao de tcnicas de teste leva o testador a produzir um conjunto de casos de teste (ou situaes de teste). A aplicao combinada de outra tcnica tcnica de particionamento de equivalncia (ou uso de classes de equivalncia) permite avaliar se a quantidade de casos de teste produzida coerente. A partir das classes de equivalncia identificadas, o testador construir casos de teste que atuem nos limites superiores e inferiores destas classes, de forma que um nmero mnimo de casos de teste permita a maior cobertura de teste possvel. Uma abordagem no desenvolvimento do teste de caixa-preta o teste baseado na especificao, de forma que as funcionalidades so testadas de acordo com os requisitos. Apesar de necessrio, esse tipo de teste insuficiente para identificar certos riscos num projeto de software.[7]
[editar]Caixa-cinza

A tcnica de teste de caixa-cinza um mesclado do uso das tcnicas de caixa-preta e de caixabranca. Isso envolve ter acesso a estruturas de dados e algoritmosdo componente a fim de desenvolver os casos de teste, que so executados como na tcnica da caixa-preta. Manipular entradas de dados e formatar a sada no considerado caixa-cinza pois a entrada e a sada esto claramente fora da caixa-preta. A caixa-cinza pode incluir tambm o uso de engenharia reversa para determinar por exemplo os limites superiores e inferiores das classes, alm de mensagens de erro.
[editar]Regresso

Ver artigo principal: teste de regresso Essa uma tcnica de teste aplicvel a uma nova verso de software ou necessidade de se executar um novo ciclo de teste durante o processo de desenvolvimento. Consiste em se aplicar, a cada nova verso do software ou a cada ciclo, todos os testes que j foram aplicados nas verses ou ciclos de teste anteriores do sistema. Inclui-se nesse contexto a observao de fases e tcnicas de teste de acordo com o impacto de alteraes provocado pela nova verso ou ciclo de teste. Para efeito de aumento de produtividade e de viabilidade dos testes, recomendada a utilizao de ferramentas de automao de teste, de forma que, sobre a nova verso ou ciclo de teste, todos os testes anteriores possam ser executados novamente com maior agilidade.
[editar]Tcnicas

no funcionais

Outras tcnicas de teste existem para testar aspectos no-funcionais do software, como por exemplo, a adequao a restries de negcio, adequao a normas, ou restries tecnolgicas. Em contraste s tcnicas funcionais mencionadas acima, que verificam a produo pelo sistema de respostas adequadas de suas operaes, de acordo com uma especificao, as tcnicas no funcionais verificam atributos de um componente ou sistema que no se relacionam com a funcionalidade (por exemplo, confiabilidade, eficincia, usabilidade, manutenibilidade e portabilidade)[8]. Uma delas o uso conjunto de teste de desempenho e teste de carga, que verifica se o software consegue processar grandes quantidades de dados, e nas especificaes de tempo de processamento exigidas, o que determina a escalabilidade do software. O teste de usabilidade necessrio para verificar se a interface de usurio fcil de se aprender e utilizar. Entre verificaes cabveis esto a relao da interface com conhecimento do usurio, a compreensibilidade das mensagens de erro e a integridade visual entre diferentes componentes.[9] J o teste de confiabilidade usado para verificar se o software seguro em assegurar o sigilo dos dados armazenados e processados. O teste de recuperao usado para verificar a robustez do software em retornar a um estado estvel de execuo aps estar em um estado de falha.
[editar]Fases Abstrao do teste Descendente Sistema

Integrao Unidade

Ascendente

Uma prtica comum testar o software aps uma funcionalidade ser desenvolvida, e antes dela ser implantada no cliente, por um grupo de profissionais diferente da implementao. Essa prtica pode resultar na fase de teste ser usada para compensar atrasos do projeto, comprometendo o tempo devotado ao teste. Outra prtica comear o teste no mesmo momento que o projeto, num processo contnuo at o fim do projeto. Em contrapartida, algumas prticas emergentes como a programao extrema e o desenvolvimento gil focam o modelo de desenvolvimento orientado ao teste. Nesse processo, os testes de unidade so escritos primeiro ( TDD ), por engenheiros de software. Antes da implementao da unidade em questo, o teste falha. Ento o cdigo escrito, passando incrementalmente em pores maiores dos casos de teste. Os testes so mantidos junto com o resto do cdigo fonte do software, e geralmente tambm integra o processo de construo do software.
[editar]Teste

de unidade

Ver artigo principal: teste de unidade Tambm conhecida como teste unitrio ou teste de mdulo, a fase em que se testam as menores unidades de software desenvolvidas (pequenas partes ou unidades do sistema).[10] O universo alvo desse tipo de teste so as subrotinas ou mesmo pequenos trechos de cdigo. Assim, o objetivo o de encontrar falhas de funcionamento dentro de uma pequena parte do sistema funcionando independentemente do todo.
[editar]Teste

de integrao

Ver artigo principal: teste de integrao Na fase de teste de integrao, o objetivo encontrar falhas provenientes da integrao interna dos componentes de um sistema. Geralmente os tipos de falhas encontradas so de transmisso de dados. Por exemplo, um componente A pode estar aguardando o retorno de um valor X ao executar um mtodo do componente B; porm, B pode retornar um valor Y, gerando uma falha. No faz parte do escopo dessa fase de teste o tratamento de interfaces com outros sistemas (integrao entre sistemas). Essas interfaces so testadas na fase de teste de sistema, apesar de, a critrio do gerente de projeto, estas interfaces podem ser testadas mesmo antes de o sistema estar plenamente construdo.
[editar]Teste

de sistema

Ver artigo principal: teste de sistema Na fase de teste de sistema, o objetivo executar o sistema sob ponto de vista de seu usurio final, varrendo as funcionalidades em busca de falhas em relao aos objetivos originais. Os testes so executados em condies similares de ambiente, interfaces sistmicas e massas de dados quelas que um usurio utilizar no seu dia-a-dia de manipulao do sistema. De acordo com a poltica de uma organizao, podem ser utilizadas condies reais de ambiente, interfaces sistmicas e massas de dados.
[editar]Teste

de aceitao

Ver artigo principal: teste de aceitao Geralmente, os testes de aceitao so realizados por um grupo restrito de usurios finais do sistema, que simulam operaes de rotina do sistema de modo a verificar se seu comportamento est de acordo com o solicitado. Teste formal conduzido para determinar se um sistema satisfaz ou no seus critrios de aceitao e para permitir ao cliente determinar se aceita ou no o sistema. Validao de um software pelo comprador, pelo usurio ou por terceira parte, com o uso de dados ou cenrios especificados ou reais. Pode incluir testes funcionais, de configurao, de recuperao de falhas, de segurana e de desempenho.
[editar]Teste

de operao

Ver artigo principal: teste de operao Nessa fase o teste conduzido pelos administradores do ambiente final em que o sistema ou software entrar em ambiente produtivo. Vale ressaltar que essa fase aplicvel somente a

sistemas de informao prprios de uma organizao, cujo acesso pode ser feito interna ou externamente a essa organizao. Nessa fase de teste devem ser feitas simulaes para garantir que a entrada em produo do sistema ser bem sucedida. Envolve testes de instalao, simulaes com cpia de segurana dos bancos de dados, etc.. Em alguns casos um sistema entrar em produo para substituir outro e necessrio garantir que o novo sistema continuar garantindo o suporte ao negcio.
[editar]Testes alfa e beta

Ver artigo principal: verso alfa Ver artigo principal: verso beta Em casos especiais de processos de desenvolvimento de software sistemas operacionais, sistemas gerenciadores de bancos de dados e outros softwares distribudos em escala nacional e internacional os testes requerem fases tambm especiais antes do produto ser disponibilizado a todos os usurios. O perodo entre o trmino do desenvolvimento e a entrega conhecido como fase alfa e os testes executados nesse perodo, como testes alfa. PRESSMAN afirma que o teste alfa conduzido pelo cliente no ambiente do desenvolvedor, com este "olhando sobre o ombro" do usurio e registrando erros e problemas de uso. Completada a fase alfa de testes, so lanadas a grupos restritos de usurios, verses de teste do sistema denominadas verses beta. Ele tambm um teste de aceitao voltado para softwares cuja distribuio atingir grande nmero de usurios de uma ou vrias empresas compradoras. PRESSMAN afirma que o teste beta conduzido em uma ou mais instalaes do cliente, pelo usurio final do software. Diferente do teste alfa, o desenvolvedor geralmente no est presente. Conseqentemente, o teste beta uma aplicao do software num ambiente que no pode ser controlado pelo desenvolvedor. O cliente registra todos os problemas (reais ou imaginrios) que so encontrados durante o teste beta e os relata ao desenvolvedor em intervalos regulares. Com o resultado dos problemas relatados durante os testes beta, os engenheiros de software fazem modificaes e depois se preparam para liberar o produto de software para toda a base de clientes. A comunidade do teste de software usa o termo teste gama de forma sarcstica referindo-se aos produtos que so mal testados e so entregues aos usurios finais para que estes encontrem os defeitos j em fase de produo.
[editar]Candidato a lanamento

Ultimamente, e principalmente na comunidade de software livre, comum utilizar o termo candidato a lanamento (release candidate) para indicar uma verso que candidata a ser a verso final, em funo da quantidade de erros encontradas. Tais verses so um passo alm do teste beta, sendo divulgadas para toda a comunidade.
[editar]Papis

Segue abaixo alguns dos papis que uma pessoa pode desenvolver num projeto de teste de software. Uma pessoa pode acumular mais de um dos papis citados, de acordo com caractersticas e restries de projetos de desenvolvimento de software nas quais estejam inseridas. Nas fases de teste de unidade e de integrao, por exemplo, os papis de arquiteto de teste e analista de teste podem ser assumidos pelo analista de sistemas do projeto; o papel de testador pode ser assumido pelo programador ou por um segundo programador que atue num processo de programao em pares. Na fase de teste de sistema, num contexto em que haja uma equipe de teste independente, pode haver profissionais acumulando os papis de arquiteto de teste, analista de teste e testador. O lder (ou gerente) do projeto de testes a pessoa responsvel pela liderana de um projeto de teste especfico, normalmente relacionado a um sistema de desenvolvimento, seja um projeto novo ou uma manuteno. J o engenheiro (ou arquiteto) de teste o tcnico responsvel pelo levantamento de necessidades relacionadas montagem da infraestrutura de teste, incluindo-se o ambiente de teste, a arquitetura de soluo, as restries tecnolgicas, as ferramentas de teste. tambm responsvel pela liderana tcnica do trabalho de teste e

pela comunicao entre a equipe de teste e a equipe de projeto (ou equipe de desenvolvimento). O analista de teste o tcnico responsvel pela operacionalizao do processo de teste. Deve seguir as orientaes do gerente de teste ou do arquiteto de teste para detalhar a forma de execuo dos testes e as condies de teste necessrias. Tambm deve focar seu trabalho nas tcnicas de teste adequadas fase de teste trabalhada. Tambm no campo de anlise, o analista de ambiente o tcnico responsvel pela configurao do ambiente de teste e pela aplicao das ferramentas necessrias para tal. Esse profissional deve ser especializado em arquiteturas de soluo e nos sistemas operacionais e softwares de infraestruturaque regem o ambiente. Ele ser responsvel por tornar disponvel o ambiente de teste. O testador o tcnico responsvel pela execuo de teste. Ele deve observar as condies de teste e respectivos passos de teste documentados pelo analista de teste e evidenciar os resultados de execuo. Em casos de execues de teste mal-sucedidas, esse profissional pode tambm registrar ocorrncias de teste (na maioria das vezes, defeitos) em canais atravs dos quais os desenvolvedores tomaro conhecimento das mesmas e tomaro as providncias de correo ou de esclarecimentos. Por fim, o automatizador de teste o tcnico responsvel pela automao de situaes de teste em ferramentas. Ele deve observar as condies de teste e respectivos passos de teste documentados pelo analista de teste e automatizar a execuo desses testes na ferramenta utilizada. Normalmente so geradosscripts de teste que permitam a execuo de ciclos de teste sempre que se julgar necessrio, desde claro, que sejam garantidas as mesmas condies iniciais do ciclo de teste (valores de dados, estados dos dados, estados do ambiente, etc..)
[editar]Artefatos

O processo de teste de software pode produzir diversos artefatos. O caso de teste geralmente consiste de uma referncia a um identificador ou requisito de uma especificao, prcondies, eventos, uma srie de passos a se seguir, uma entrada de dados, uma sada de dados, resultado esperado e resultado obtido. A srie de passos (ou parte dela) pode estar contida num procedimento separado, para que possa ser compartilhada por mais de um caso de teste. Um script de teste a combinao de um caso de teste, um procedimento de teste e os dados do teste. Uma coleo de casos de teste chamada de suite de teste. Geralmente, ela tambm contm instrues detalhadas ou objetivos para cada coleo de casos de teste, alm de uma seo para descrio da configurao do sistema usado. A especificao de teste chamada plano de teste.