Curso Técnico em Informática
Testes de Software
Robson Braga de Andrade
Presidente da Confederação Nacional da Indústria
Rafael Lucchesi
Diretor do Departamento Nacional do SENAI
Regina Maria de Fátima Torres
Diretora de Operações do Departamento Nacional do SENAI
Alcantaro Corrêa
Presidente da Federação da Indústria do Estado de Santa Catarina
Sérgio Roberto Arruda
Diretor Regional do SENAI/SC
Antônio José Carradore
Diretor de Educação e Tecnologia do SENAI/SC
Marco Antônio Dociatti
Confederação Nacional da Indústria
Serviço Nacional de Aprendizagem Industrial
Curso Técnico em Informática
Testes de Software
Carlos Eduardo Carvalho
Florianópolis/SC
2011
É proibida a reprodução total ou parcial deste material por qualquer meio ou sistema sem o prévio consentimento do editor.
Autor
Carlos Eduardo Carvalho
Fotografias
Banco de Imagens SENAI/SC http://www.sxc.hu/
http://office.microsoft.com/en-us/ images/ http://www.morguefile.com/
http://www.bancodemidia.cni.org.br/
Ficha catalográfica elaborada por Luciana Effting CRB14/937 - Biblioteca do SENAI/SC Florianópolis
C331t
Carvalho, Carlos Eduardo
Teste de software / Carlos Eduardo Carvalho. – Florianópolis :
SENAI/SC/DR, 2011.
59 p. : il. color ; 30 cm.
Inclui bibliografias.
1. Software. 2. Software - Controle de qualidade. 3. Software - Testes. 4.
Engenharia de software. I. SENAI. Departamento Regional de Santa
Catarina. II. Título.
CDU 004.415.53
SENAI/SC — Serviço Nacional de Aprendizagem Industrial
Rodovia Admar Gonzaga, 2.765 – Itacorubi – Florianópolis/SC CEP: 88034-001Fone: (48) 0800 48 12 12 www.sc.senai.br
Prefácio
Você faz parte da maior instituição de educação profissional do estado. Uma rede de Educação e Tecnologia, formada por 35 unidades conecta-das e estrategicamente instalaconecta-das em toconecta-das as regiões de Santa Catarina. No SENAI, o conhecimento a mais é realidade. A proximidade com as necessidades da indústria, a infraestrutura de primeira linha e as aulas teóricas, e realmente práticas, são a essência de um modelo de Educação por Competências que possibilita ao aluno adquirir conhecimentos, de-senvolver habilidade e garantir seu espaço no mercado de trabalho. Com acesso livre a uma eficiente estrutura laboratorial, com o que existe de mais moderno no mundo da tecnologia, você está construindo o seu futuro profissional em uma instituição que, desde 1954, se preocupa em oferecer um modelo de educação atual e de qualidade.
Estruturado com o objetivo de atualizar constantemente os métodos de ensino-aprendizagem da instituição, o Programa Educação em Movi-mento promove a discussão, a revisão e o aprimoraMovi-mento dos processos
de educação do SENAI. Buscando manter o alinhamento com as neces-sidades do mercado, ampliar as possibilidades do processo educacional, oferecer recursos didáticos de excelência e consolidar o modelo de Edu-cação por Competências, em todos os seus cursos.
É nesse contexto que este livro foi produzido e chega às suas mãos. Todos os materiais didáticos do SENAI Santa Catarina são produções colaborativas dos professores mais qualificados e experientes, e contam com ambiente virtual, mini-aulas e apresentações, muitas com anima-ções, tornando a aula mais interativa e atraente.
Mais de 1,6 milhões de alunos já escolheram o SENAI. Você faz parte deste universo. Seja bem-vindo e aproveite por completo a Indústria do Conhecimento.
Sumário
Conteúdo Formativo 9
Apresentação 11
12 Unidade de estudo 1
O que é o teste de
software?
Seção 1 - Metodologia de desenvolvimento de softwareSeção 2 - Objetivos do teste de software
Seção 3 - O que é teste de software?
Seção 4 - E se não testar o software?
Seção 5 - Casos de testes Seção 6 - Tipos de testes
20 Unidade de estudo 2
Técnicas de teste de
software
Seção 1 - O que é técnica de teste?
Seção 2 - Técnicas funcional, estrutural e baseadas em erros
Seção 3 - Critérios para gera-ção de casos de teste Seção 4 - Níveis de teste 13 13 14 15 16 16
26 Unidade de estudo 3
Processo de teste de
software
Seção 1 - Ciclo de vida de de-senvolvimento de software Seção 2 - Conceito “V” de teste
Seção 3 - Ciclo de vida do processo de teste
Seção 4 - Preparação do ambiente
32 Unidade de estudo 4
Análise de riscos
Seção 1 - Definição de risco Seção 2 - Riscos relativos ao teste de softwareSeção 3 - Determinação da magnitude dos riscos Seção 4 - Controle dos riscos
36 Unidade de estudo 5
Planejamento dos
testes
Seção 1 - Plano de teste, o que é isso? Seção 2 - Desenvolvimento do plano de teste Seção 3 - Documentação do teste
40 Unidade de estudo 6
Execução dos
testes
Seção 1 - Contexto dos testes
Seção 2 - Processo de execu-ção dos testes
Seção 3 - Relatório de teste segunda a IEEE 829 Seção 4 - Gerenciamento de comunicação do projeto de teste
48 Unidade de estudo 7
Teste de aceitação
Seção 1 - Definição dos crité-rios de aceitação
Seção 2 - Elaboração do plano de aceitação
Seção 3 - Execução do teste de aceitação
52 Unidade de estudo 8
Estimativas
Seção 1 - Análise do ponto de teste
Seção 2 - Estimativa baseada no tamanho e complexidade do caso de uso
Finalizando 57
Referências 59
21 21 21 24 27 28 28 29 33 33 33 34 37 37 39 41 42 45 46 49 49 50 53 54Conteúdo Formativo
Carga horária da dedicação
Carga horária: 30 horas
Competências
Aplicar testes relacionados ao desenvolvimento de software para validação da solução computacional.
Analisar os resultados de testes realizados em sistemas computacionais.
Conhecimentos
▪ Diário de teste; ▪ Especificação de teste;
▪ Especificação e relato de teste; ▪ Especificações de caso de teste;
▪ Especificações de procedimento de teste; ▪ Especificações de projeto de teste; ▪ Ferramenta de teste;
▪ Metodologia de desenvolvimento de programa de computador; ▪ Metodologia de teste;
▪ Normas técnicas vigentes; ▪ Procedimento de teste; ▪ Registro de teste; ▪ Relato de teste;
▪ Relatório de encaminhamento de item de teste; ▪ Relatório de incidente de teste;
▪ Relatório-resumo de teste; ▪ Requisitos de ambiente; ▪ Técnicas de teste.
Habilidades
▪ Identificar os tipos de teste a serem executados no procedimento; ▪ Utilizar o plano de testes;
▪ Testar os programas; ▪ Elaborar registros de teste;
▪ Identificar defeitos e falhas em programas de computador; ▪ Utilizar artefatos de manutenção;
▪ Elaborar registros na documentação da manutenção de programas de computa-dor.
Atitudes
▪ Organização e zelo na utilização de equipamentos; ▪ Foco no conteúdo trabalhado;
▪ Acesso a sítios relacionados ao tema trabalhado; ▪ Organização e limpeza dos ambientes coletivos;
▪ Dedicação e empenho nas atividades curriculares e extra-curriculares; ▪ Capacidade de abstração;
▪ Trabalho em equipe;
▪ Apresentação de novas soluções para situações problemas; ▪ Cumprimento de prazos;
Apresentação
Caro aluno,
imagine a seguinte situação...
É início do mês, você recebeu o seu merecido salário e agora vai fazer o pagamento de uma conta por meio do site do banco. Você precisa trans-ferir R$ 100,00 para poder efetuar este pagamento. Mas, como muitas pessoas estão fazendo a mesma coisa que você, o sistema do banco dá aquela “travada”. Quinze segundos depois o sistema volta e a sua tran-sação foi efetuada. No dia seguinte, você vê o seu saldo e percebe que foram debitados R$ 200,00 da sua conta! E agora? O que aconteceu com o sistema? Ele estava preparado para fazer todas aquelas transações ao mesmo tempo? Ele foi testado para verificar se havia problemas caso o sistema travasse?
Esse material didático foi elaborado pensando nestas questões, que de-verão ser refletidas por você, como um técnico em informática, respon-sável por sistemas de banco, de hospitais, de pequenos supermercados e de grandes empresas. Neste livro você vai encontrar os diversos tipos e técnicas para se testar um software de modo a garantir que ele funciona-rá corretamente nos momentos mais difíceis. Também vefunciona-rá que certos sistemas não precisam ser testados nos mínimos detalhes. Eles serão testados apenas até o ponto onde os custos do teste não são maiores do que a correção. Além de aprender que é mais barato testar no começo do desenvolvimento do que corrigir no final.
O estudo e pesquisas realizadas para elaborar este material didático fo-ram demorados e detalhados, mas valeu a pena, pois certamente você encontrará ao longo da leitura deste livro respostas para muitas pergun-tas como as que você leu no início desta apresentação e muipergun-tas outras que surgirão ao longo de sua carreira profissional. Então, espero que você consiga aproveitar o material para se desenvolver profissionalmen-te e pessoalmenprofissionalmen-te.
É importante considerar que sempre haverão coisas novas para aprender e você pode pesquisar muito mais e aprender a partir dos livros e blogs que foram utilizados para preparação deste material. Perceba que muita gente está estudando, discutindo, e aprendendo e inovando sobre teste de software todos os dias. Por fim, espero que, daqui a alguns anos, quan-do você estiver trabalhanquan-do em uma grande empresa de desenvolvimen-to e precisar elaborar um processo de teste, lembre-se desse material e utilize,o como um ponto de partida para atingir o sucesso nos seus trabalhos.
Bons estudos!
Carlos Eduardo Carvalho Formado em Engenharia Elé-trica pela Udesc – Joinville. Atuou em desenvolvimento de software e hardware para equipamentos eletrônicos, em usinas hidroelétricas. Leciona as disciplinas de lógica de pro-gramação, microcontroladores, acionamentos elétricos e proje-tos elétricos nos cursos técnicos de automação, mecatrônica e eletrotécnica. Atua em STT, de-senvolvendo programas para microcontroladores aplicados em equipamentos eletrônicos.
Unidade de
estudo 1
Seções de estudo
Seção 1 – Metodologia de desenvolvimen-to de software
Seção 2 – Objetivos do teste de software Seção 3 – O que é teste de software? Seção 4 – E se não testar o software? Seção 5 – Casos de testes
O que é teste de software?
SeçãO 1
Metodologia de desenvolvimento de software
Você sabia que utilizar uma metodologia para desenvolver um software é o primeiro passo de uma prática profissional?É isso mesmo! Confira a seguir um formato básico de metodologia para elaboração de um software, de acordo com Bartié (2002, p. 25).
Figura 1: Ciclo de desenvolvimento de software Fonte: Bartié (2002, p. 25)
Perceba que o item teste é apenas uma parte da metodologia e aparece
somente no final do projeto.
Por isso, o objetivo desta seção de estudo é mostrar à você que as práticas de teste devem iniciar juntamente com o início do projeto, no momento em que as primeiras documentações são geradas. Assim, os erros e problemas não são transferidos para as próximas fases, ok?
Quando a cultura da aplicação da metodologia estiver bem entendida e difundida, você verá que os processos e métodos de teste permitirão a qualidade dos produtos. Neste momento é importante fazer referência ao PMI (Project Management Institute) que fez o PMBOK (Project Manage-ment Body of Knowledge), no qual o processo de gerenciaManage-mento da qualida-de qualida-de software é subdividido em três partes complementares, acompanhe!
Processo de Garantia da Qualida-de do Software:
1. Planejamento da Qualidade.
2. Garantia da Qualidade.
3. Controle da Qualidade.
Neste momento você deve estar se perguntando: mas porque devo testar um software? Qual o objeti-vo deste teste? Não seria perda de tempo, já que na maioria das ve-zes o tempo de desenvolvimento de um software é curto?
É sobre este assunto que conver-saremos na próxima seção de es-tudo. Vamos em frente!
SeçãO 2
Objetivos do teste de
software
De forma bem básica, o objetivo do teste de software é simplesmente garantir a qualidade do software.
Para Bartié (2002) o processo de qualidade de software está decom-posto em fases e cada fase possui uma numeração que indica a se-quência de execução dos testes a serem aplicados.
Assim, deve-se dividir os testes em duas categorias: testes de ve-rificação e testes de validação.
Os testes de verificação visam
garantir a correta elaboração do software e os testes de validação
Para que você possa verificar as atividades e avaliar os documen-tos gerados durante as fases do processo de engenharia de softwa-re, deve utilizar os testes de veri-ficação.
As fases da metodologia que fa-zem parte dos testes de verifica-ção são:
▪
Modelo de Negócios:verifi-cação de negócios;
▪
Especificação de Requisi-tos: verificação de requisitos;▪
Análise e Modelagem:verifi-cação, análise e modelagem;
▪
Implementação: verificaçãoda implementação.
Desta forma, defini-se testes de validação como:
[...] um processo formal de ava-liação de produtos tecnológicos que podem ser aplicados em componentes isolados, módulos existentes ou mesmo nos siste-mas como um todo. Seu objeti-vo é avaliar a conformidade do software com os requisitos e especificações analisadas e revi-sadas nas etapas iniciais do pro-jeto (BARTIÉ, 2002, p. 38).
Ou seja, os testes de validação são aqueles feitos quando já existe alguma parte do software pronta. São os testes feitos no software e não na documentação. Nos testes de validação, temos as seguintes fases:
▪
Unidade Especificada ou Modificada: validação dauni-dade;
▪
Integração Especificada ou Modificada: validação daintegração;
▪
Sistema Especificado ou Modificado: validação dosiste-ma;
▪
Disponibilização de Solu-ção: validação doaceite.Lembre--se de que o conhecimento se adquire por meio de uma cons-trução significativa da aprendiza-gem. Então, vamos juntos trilhar novos caminhos do conhecimen-to?
SeçãO 3
O que é teste de
software?
Existem atualmente, duas defini-ções para teste.
Você sabe quais são? Vamos ver juntos.
A definição mais comum, que a maioria das equipes de desenvol-vimento aplica está simplificada como:
▪
Teste é o processo de de-monstrar que algo funciona corretamente.▪
Teste é o processo de pro-var que determinadas coisas fazem o que deveriam fazer.Ou seja, todo mundo vê os tes-tes como uma forma de mostrar que está tudo bem. Na verdade, é mais fácil mostrar que um software está funcionando do que mostrar que ele não está funcionando. Mas, ao colocar uma pessoa que não está envolvida no desenvolvi-mento do software e que não tem nenhuma ligação com este, esta pessoa criará diversas situações, possíveis no dia-a-dia do produto, e conseguirá demonstrar que em determinados cenários, o com-portamento deste produto pode gerar um funcionamento inade-quado.
Neste ponto, é possível chegar à segunda definição de teste:
▪
Teste é um processo siste-mático e planejado que tem por finalidade única a identi-ficação de erros.Esta é considerada a definição
correta sobre os testes.
Inde-pendentemente do teste ser apli-cado a um documento ou a um software, o objetivo é criar situa-ções onde o produto pode não funcionar.
Porém, é preciso sempre lembrar que você não conseguirá mostrar a ausência de erros. Ou seja, por melhor que seja um processo de qualidade, nunca será possível cobrir todas as infinitas combina-ções existentes em um ambiente de execução real. Pense sempre nisso!
Vamos em frente? Na próxima seção você verificar o que pode acontecer quando um software não é testado.
SeçãO 4
E se não testar o
software?
Erros, falhas, incidentes, não con-formidades e inconsistências são palavras que representam nature-zas diferentes de defeitos. Apesar de ser um pensamento comum, esses defeitos não vêm apenas no código – fonte do produto. E também não são apenas os pro-fissionais de desenvolvimento, qualidade e testes, os responsáveis por um software sem defeitos.
Os erros são resultados do não entendimento dos re-quisitos do cliente e especi-ficações mal feitas. Portan-to, você deve trabalhar mais tempo nas especificações e modelagem da solução. Isso fará com que muitos erros se-jam eliminados por meio de um levantamento bem feito.
A falta de testes em todas as etapas do processo de desenvolvimento fará com que os erros passem de uma fase para a outra. Quando o ciclo atingir a fase específica de testes, muitos erros serão encon-trados e mesmo assim o produto pode não atingir o esperado. Você sabia que esse processo de qualidade de software, do qual os testes fazem parte, traz diversas vantagens para a organização? Sim, isso mesmo! Ealgumas des-sas vantagens são:
▪
os testes tornam o ciclo de desenvolvimento confiável;▪
garantem ações corretivas durante o desenvolvimento▪
ampliam as chances de sucesso do projeto de software e,▪
evitam a propagação de erros.Interessante, não é mesmo? Bastos et al (2007) cita a regra 10 de Myers, que estabelece que o custo de correção de um erro aumenta muito com o passar do tempo.
DICA
Quanto mais tempo demorar para se descobrir um erro, mais caro será a solução deste erro. Defeitos encontrados na documentação de modelamento são muito mais baratos do que defeitos encontra-dos durante a produção. Portanto fique atento!
Confira na imagem a seguir um gráfico que apresenta um aumento do custo durante as fases do projeto.
Figura 2: Custo da correção dos defeitos.
Finalizando esta seção, você pode ver que os testes são extremamente importantes no alcance da qualidade do software. Não testar ou fazer testes da forma errada pode trazer custos extremamente altos para a empresa.
DICA
E para alcançar a qualidade desejada pelo cliente, muitas vezes é necessário possuir uma equipe de testes, trabalhando em conjunto com o desenvolvimento, desde a primeira reunião.
Apesar de gerar um custo inicial, após o treinamento e mudança de filo-sofia da empresa, os ganhos serão muito maiores.
Que tal passar para a próxima seção e conhecer alguns casos de teste? Siga em frente!
SeçãO 5
Casos de testes
De acordo com Bastos et al (2007, p. 153) um caso de teste é a espe-cificação mais detalhada do teste, apresentando os campos detelas, formulários etc. O caso de teste estabelece as informações empre-gadas nos testes dos cenários e quais são os resultados esperados. Ou seja, é necessário fazer um de-talhamento do que será testado, como será feito o teste, quem é responsável, quais são as entradas necessárias e quais são as saídas esperadas.
Um bom caso de teste deve con-ter:
▪
identificação das condições de teste;▪
o que testar (identificação dos casos);▪
detalhamento da massa de entrada e de saída (dados);▪
critérios especiais, quando necessários, para gerar os dados de entrada e saída do teste;▪
especificação das configura-ções de ambiente no qual o teste será executado: sistema operacio-nal, ferramentas necessárias, ori-gem dos dados etc (onde testar);▪
como testar: automático/ma-nual (definir o tipo de implemen-tação do teste);▪
quando testar (cronograma, em qual fase o teste será execu-tado);▪
listar as interdependências, caso existam, entre os casos de teste.O quadro a seguir é um exemplo de caso de teste aplicado a um sis-tema de uma imobiliária. Veja!
Caso de teste Portal de Administração de Sites – Imóveis Carvalho
Caso de teste CT 85 – Buscar para alteração. Botão visualizar o calendário de locação.
Pré-condições
Ter clicado em “Buscar para alteração” na página de imóveis e estar com a opção de locação para a temporada.
Procedimentos
1. O ator clica em “Visualizar o calendário de locação do imóvel”representado pelo terceiro ícone da esquerda para a direita na parte superior da descrição do imóvel.
2. O sistema carrega um calendário destacando os dias de locação do imóvel.
Resultado
esperado Carregar o calendário de locação do imóvel. Critérios
especiais Não se aplica. Implementação Manual. Iteração 1ª iteração.
Quadro 1: Exemplo de caso de teste
Neste exemplo você pode ver que os casos de teste são bem detalhados e devem ser descritos de uma forma criteriosa. Todos os cenários e casos de uso devem ser criados, verificando todas as funcionalidades do software. Por isso eles dão bastante trabalho para a pessoa responsável pela sua elaboração.
Preparado para seguir mais um percurso? Conheça na próxima seção os tipos de teste.
SeçãO 6
Tipos de testes
No momento em que você começar a fazer os testes de validação, signi-fica que já tem um produto computacional, ou seja, um software que pode ser executado.
Para fazer esta validação você pode utilizar duas abordagens:
▪
a estratégia da caixa branca ou,▪
a estratégia da caixa preta.Estas estratégias não excluem uma a outra. Na verdade, se você aplicar as duas, terá um produto com uma qualidade maior. Os testes de caixa branca são baseados na estrutura interna do software. Ou seja, é preciso empregar técnicas que trabalhem todas as estruturas utilizadas na codi-ficação.
Os testes de caixa branca possuem alta eficiência na detecção de erros, mas também costumam ser difíceis de implementar.
Para isso é necessário que o profissional de testes conheça a tecnolo-gia usada no software. Assim como, tenha acesso a fontes, estruturas dos bancos de dados etc.
Confira a seguir a imagem que representa um teste de caixa branca.
Figura 4: Teste de caixa branca.
Você pôde observar na imagem anterior que o teste de caixa branca mostra um software que tem um processamento inicial, representado pelo retângulo 1, uma tomada de decisão, representada pelo losango 2. A partir desta decisão, o software pode passar por dois caminhos, o caminho A ou o caminho B.
Importante: o software nunca vai passar pelos dois caminhos ao mesmo tempo.
Independente do caminho percorrido, o software chega ao processamen-to final, retângulo 3. Após este processamenprocessamen-to, o software é finalizado.
Perceba que para fazer este teste, é importante que o profissional conheça o que cada processamento faz e que resultado cada tomada de decisão deverá dar.
Neste momento você deve estar se perguntando: mas e a caixa preta, qual a sua função?
O teste de caixa preta não tem o objetivo de verificar como ocorrem internamente os processamentos, mas se o algoritmo utilizado produz os resultados necessários. A vantagem desta estratégia é que não é ne-cessário conhecer os conceitos de implementação aplicados no software. Dessa forma é muito mais fácil encontrar um profissional capacitado a modelar os testes de caixa preta da aplicação.
Veja a seguir a imagem que representa um teste de caixa preta.
Figura 5: Teste de caixa preta.
Esta estratégia é muito encontrada nas organizações, em forma de testes manuais executados por profissionais ou usuários.
Ao estudar os testes de software, é possível perceber que existem diversos tipos de teste que devem ser feitos nos softwares. Muitas vezes, você não terá tempo para fazer todos os testes e criar todos os cenários. Assim, é importante conhecer os tipos e priorizar aqueles que podem encontrar erros mais preocupantes.
Bartié (2002) cita alguns testes que devem ser feitos:
1. Teste de funcionalidade: tem por objetivo simular os cenários de
negócio e garantir que todos os requisitos funcionais sejam imple-mentados.
2. Teste de usabilidade: a ideia desse teste é medir o nível de
facilida-de da aplicação, facilida-de modo a facilida-deixar o software mais simples e intuitivo. Também é possível avaliar se o software avisa sobre ações que podem danificar ou perder dados pertencentes ao usuário.
Por exemplo, botão “desfazer alteração” e “cancelar operação”, além da mensagem “Esta operação excluirá seu histórico. Deseja continuar?”
3. Teste de volume: tem por objetivo determinar os limites de
proces-samento do software e de toda a infra-estrutura da solução. Esse tipo não focaliza oscilações, mas o aumento contínuo dos parâmetros de execução.
4. Teste de configuração (ambiente): o objetivo desta categoria é
executar o software sobre diversas configurações de softwares e hardwa-res. Desta forma, é preciso garantir que a solução “rode” sobre os mais diversos ambientes. Para aplicá-los deve-se variar os sistemas operacionais, browsers e hardwares.
5. Teste de compatibilidade: a ideia é garantir que as novas versões
estão suportando antigas interfaces, submetendo a aplicação trocar informações com componentes que utilizam os protocolos de ver-sões anteriores.
6. Teste de segurança: esta categoria de teste tem por objetivo
detec-tar falhas de segurança que podem comprometer o sigilo das infor-mações. Sendo assim, é importante que você simule situações que provocam a quebra de protocolos de segurança, expondo os pontos frágeis.
7. Teste de performance (desempenho): nesta categoria você deve
determinar se o desempenho do software está de acordo com os requi-sitos definidos, nas situações de pico máximo de acesso. Para estes testes deve-se especificar claramente o cenário que você deseja obter. Omitir informações significa a criação de um cenário irreal, que im-possibilita a avaliação do desempenho.
8. Teste de confiabilidade e disponibilidade: nessa categoria, deve-se
monitorar o software por um determinado tempo e coletar informa-ções para identificar se ocorrem falhas na infra-estrutura (confiabili-dade), e quanto tempo é necessário para a resolução desse problema (disponibilidade).
A próxima unidade vem cheia de novidades. Veja o que preparamos para você.
Unidade de
estudo 2
Seções de estudo
Seção 1 – O que é técnica de teste? Seção 2 – Técnicas funcional, estrutural e baseada em erros.
Seção 3 – Critérios para geração de casos de teste.
Técnicas de teste de software
SeçãO 1
O que é técnica de
teste?
De acordo com Bastos et al (2007, p. 86) a técnica de teste é um pro-cesso que assegura o funciona-mento adequado de alguns aspec-tos do sistema ou da unidade. Já as ferramentas de teste são re-cursos para o testador. Utilizar apenas a ferramenta, sem a técni-ca adequada, não é suficiente para conduzir todo o teste.
DICA
Por exemplo, um serrote é apenas uma ferramenta, que se não for usada com a técni-ca adequada, pode não cor-tar a madeira e sim a pessoa.
Enfim, são poucas as técnicas e muitas as ferramentas existentes. Na próxima seção você verá as principais técnicas de teste. Va-mos em frente!
SeçãO 2
Técnicas funcional,
estrutural e baseada em
erros
Os testes funcionais são aqueles que verificam o funcionamento do software e se ele atende os re-quisitos. Ou seja, se o código faz aquilo que foi pedido pelo cliente e que está na documentação. Nor-malmente é necessária a criação de condições de teste que serão usadas na avaliação da correção da aplicação.
Já os testes estruturais verificam se o software possui uma estrutura robusta, ou seja, se ele se mantém funcionando quando ocorrem condições adversas. Nesses tipos de teste, não há preocupação com o atendimento aos requisitos e sim se a tecnologia foi usada de modo adequado e se os com-ponentes montados funcionam como uma unidade.
Quando você usa uma técnica de teste baseada em erros, deverá in-serir erros no software e verificar o seu funcionamento. Na verdade, esta é uma variação da técnica fun-cional, pois ele testa os requisitos. Mas serve para encontrar aqueles defeitos que já são esperados. Agora que você já conheça algu-mas técnicas de teste, veja os cri-térios utilizados para geração de casos de teste!
SeçãO 3
Critérios para geração
de casos de teste
Para que você possa garantir certa qualidade no software é necessário que teste certa quantidade de pos-sibilidades, ou cenários.
Quanto maior a quantidade de cenários testados, maior a qualidade do produto. Lem-bre-se que não será possível chegar ao software perfeito, sem defeitos. Portanto, você deve determinar quais serão os cenários necessários para atingir a qualidade desejada, ok?
A ênfase dos testes de validação está nos métodos que identificam todos os possíveis cenários de testes, chamados casos de testes.
Como você possuí duas técnicas para lidar com os testes de software (testes estruturais e funcionais), a obtenção dos casos de teste estará associada a uma dessas técnicas. Para Bartié (2002, p. 122),
“Um dos maiores desafios de um processo de garantia da qualidade é conseguir medir o grau de qualidade alcançado nos testes de software. Se em nosso entendimento os cenários estiverem adequadamente simu-lados e garantidos, então devemos buscar todas as alternativas possíveis e inseri – las em nosso processo de teste de software, de forma a refinar e ampliar o nível de cobertura alcançado.”
Assim, os casos de teste se tornam extremamente importantes no pro-cesso de teste de um software e, consequentemente, no processo de ga-rantia da qualidade.
A imagem a seguir considerou o método da caixa preta para a obtenção dos casos de testes, confira!
Figura 6: Método da caixa preta para geração dos casos de teste.
Se você utilizar o método da caixa preta para gerar os casos de teste, irá criar testes funcionais. Ou seja, testará cada requisito que aparece na documentação inicial do software.
Assim, você cria um caso de teste para o requisito A (Caso A1). Aplica este caso ao software e verifica se o resultado apresentado pelo software atende aquele requisito. Depois, você criará o próximo caso (Caso A2) e assim por diante. Até que todos os casos de todos os requisitos tenham sido testados.
Desta forma, quando você for fazer testes estruturais, deverá utilizar o método da caixa branca para gerar os casos de teste.
Lembre-se que os testes estruturais verificam o código do software e devem percorrer todos os caminhos possíveis, passando por cada parte do proces-samento e das tomadas de decisão.
Figura 7: Obtenção dos casos teste através do método da caixa branca.
De acordo com a fig. 7, você pode ver que o software em questão tem 2 caminhos possíveis para chegar ao fim do processamento: ABCDEF ou AGHF. Seguindo o método da caixa branca, você deve criar casos de
teste que obriguem o software a percorrer os dois caminhos.
Vendo estas duas abordagens, caixa preta e caixa branca, você pode pen-sar “Mas, qual das duas eu devo utilizar?”
Na verdade, em uma aplicação real, as duas abordagens devem ser uti-lizadas de modo a gerar os casos de testes necessários ao processo de teste.
Mas, lembre-se sempre: cmo você viu anteriormente, não será possível eliminar todos os defeitos. Também não é economica-mente viável que se faça todos os testes possíveis e imagináveis no software.
É importante que o profissional de testes avalie quais são os testes ne-cessários para validar determinado produto.
DICA
Por exemplo: um software de um banco é testado de forma diferente de um software para fazer pedido de pizza na internet, portanto devem possuir testes específicos para cada um deles.
As bibliografias especializadas apresentam diversos tipos de testes que estão dentro das técnicas estruturais (teste de carga, de execução, de recuperação, de conformidade etc) e das técnicas funcionais (teste de requisitos, de regressão, de interconexão, de controle etc).
Bartié (2002, p. 112) recomenda que os testes de cada software sejam organizados em categorias e que em uma reunião com a equipe, cada categoria receba um peso relativo a sua prioridade. Normalmente, todos querem colocar alta prioridade para a sua área. Então deve ser definido que apenas 3 categorias poderão ter alta prioridade. Assim, todos devem entrar em acordo para determinar quais são as categorias mais importan-tes para importan-testar determinado produto.
E por falar em peso, prioridade, que tal conhecer os níveis de teste? É sobre este assunto que conversaremos a seguir, vamos lá!
SeçãO 4
Níveis de teste
Como você estudou no início deste livro, de forma geral existem duas fases no processo de qualidade dos softwares. A fase de verificação
(tes-tes estáticos - documentação) e a fase de validação (testes dinâmicos
- software).
Dentro da fase de verificação, você pode encontrar algumas das ativida-des que estão ativida-descritas no quadro a seguir, acompanhe!
Fase de
Verificação Principais Atividades
Modelo de negócios
▪
Revisar contexto do mercado e necessidade do cliente.▪
Revisar riscos do projeto.▪
Revisar estudo de viabilidade. Especificação derequisitos
▪
Revisar especificação de requisitos funcionais e não – funcionais.▪
Auditar rastreabilidade de requisitos.▪
Revisar priorização de requisitos.Análise e modelagem
▪
Revisar arquitetura da aplicação.▪
Revisar nível de componentização. Saiba mais so-bre componentização de software no artigo escrito pelo professor Antonio Mendes da Silva filho, dis-ponível em: <http://www.espacoacademico.com. br/087/87amsf.htm>▪
Revisar nível de reutilização.Implementação
▪
Revisar código fonte.▪
Avaliar complexidade do código fonte.▪
Auditar rastreabilidade entre componentes.▪
Revisar manual do usuário.Quando você chegar à fase de validação, encontrará 2 níveis de teste: baixo e alto nível. Os testes de baixo nível exigem um profissional com bastante conhecimento da estrutura do produto. Já os testes de alto ní-vel não exigem conhecimento da estrutura interna e possibilitam testes com maior nível de abstração.
No quadro a seguir você pode ver algumas características destes testes, confira!
Fase da Validação Características
Tes
te de baix
o nív
el Teste de unidade
▪
Estratégia caixa branca e caixa preta.▪
Testa partes do software.▪
Executada pelo desenvolvedor ou profis-sional de teste.Teste de integração
▪
Estratégia caixa branca e caixa preta.▪
Teste integrações entre as partes do sof-tware.▪
Executada pelo desenvolvedor ou profis-sional de teste. Tes te de alt o nív el Teste de sistema▪
Estratégia de caixa preta.▪
São aplicados no software como um todo.▪
Requer ambiente semelhante ao da pro-dução.▪
Executado por um grupo de testes inde-pendente.Teste de aceitação
▪
Estratégia de caixa preta.▪
São aplicados no software como um todo.▪
Requer ambiente semelhante ao da pro-dução.▪
Executado pelos usuários finais.Quadro 3: Características do testes de validação
Unidade de
estudo 3
Seções de estudo
Seção 1 - Ciclo de vida de desenvolvimen-to de software
Seção 2 – Conceito “V” de teste Seção 3 – Ciclo de vida do processo de teste
Processo de teste de software
SeçãO 1
Ciclo de vida de
desen-volvimento de software
(CVDS)
De forma geral, os ciclos de vida de desenvolvimento de software (CVDS) são bastante diferentes, pois em todos haverá atividades específicas dos testes aplicados. A seguir você verá um ciclo de vida básico que demonstrará as princi-pais atividades que acontecem du-rante o desenvolvimento de um software. Acompanhe!
Segundo Bastos et al (2007, p. 33) as seguintes fases fazem parte de um CVDS.
▪
Fase 1 – Estudo preliminar:Essa fase começa com o reco-nhecimento de um problema ou identificação de uma necessida-de. Durante essa fase o projeto é justificado e aprovado no alto nível da organização. As alterna-tivas de solução são exploradas e seleciona-se a solução mais viável e que atenda melhor às necessida-des identificadas. Muitas vezes, realiza-se um estudo de custo--benefício para apoiar o processo de decisão.
▪
Fase 2 – Análise de requi-sitos:Agora, os requisitos são definidos, coletados, validados e aprovados. Também nesta fase são levantadas as informações necessárias para realização dos testes.
Os requisitos geralmente são modificados nas fases seguintes, quando se adquire um melhor en-tendimento do problema.
Ainda nesta fase é preparado o Plano de Projeto, que inclui cro-nograma, recursos, orçamento, produtos intermediários, ativida-des de gestão, análise de riscos e os planos previstos no modelo do Project Management Institute (PMI). Deve-se incluir o plano de testes, com os recursos e prazo para rea-lizar as atividades de teste.
Este plano do projeto não é fixo e deve ser atualizado sempre que certos eventos ocorram, como uma mudança no escopo do pro-jeto.
▪
Fase 3 – Desenho do siste-ma:As atividades desta fase resultam no detalhamento da solução para os aspectos que compõem um sistema: funcionalidade, dados e técnica. O Plano de Projeto deve ser revisto para refletir as novas informações.
▪
Fase 4 – Construção:Nesta fase os modelos devem ser transformados em realidade e suas atividades resultam em pro-gramas prontos e testados. Nes-ses programas devem ser aplica-dos os testes unitários conforme os planos de teste e os casos de
Os manuais de treinamento, de manutenção e do usuário também são preparados nesta fase, além do Plano de Instalação.
▪
Fase 5 – Implantação:Agora é o momento de efetuar os testes de integração e de sistema. O sistema tem de receber certi-ficação quanto a sua adequação aos requisitos de segurança antes da instalação. E antes de ser cer-tificado, todos os resultados das verificações e validações devem ser documentados e comparados com o antes e o depois. Por fim, o sistema deve ser aceito pelo usuário.
▪
Fase 6 – Operação:Nesta fase o Modelo de Operação do sistema deve ser implemen-tado, incluindo a expansão para a instalação em outros locais. O sistema deve iniciar a operação continuada e todas as mudanças devem ser controladas de forma a manter e modificar o ciclo de vida durante o restante de sua vida. Relatórios dos problemas e soli-citações de mudanças são usados para facilitar a correção de forma sistemática e a evolução do siste-ma.
Também devem ser executadas medições de desempenho e ava-liação das atividades para garantir que o sistema continuará
atenden-Você já ouviu falar sobre o conceito “V” de teste? Caso ainda não tenha tido a oportunidade de conhecer este conceito, não se preocupe, pois na próxima seção você verá uma figura que ilustra exatamente o que seria o chamado conceito “V” de teste. Vamos!
SeçãO 2
Conceito “V” de teste
Observe na imagem a seguir que os procedimentos de fazer e conferir convergem do início ao fim do projeto. Ou seja, os testes devem fazer parte de todo o processo de desenvolvimento.
Figura 8: Conceito “V” de teste de software.
DICA
Lembre-se: testar o produto durante todo o desenvolvimento dimi-nui o custo da correção dos defeitos.
Na próxima seção você conhecerá o ciclo de vida do processo de teste. Siga em frente!
SeçãO 3
Ciclo de vida do processo de teste
De acordo com Rios (2003, p. 29) o ciclo de vida do processo de teste é composto por diversas etapas e é conhecido como Modelo 3Px3E.
Confira na imagem a seguir um modelo de ciclo de vida do processo de teste.
Figura 9: Modelo de ciclo de vida do processo de teste.
Conheça agora cada uma das etapas do modelo.
Na etapa de procedimentos iniciais, os requisitos do negócio serão
aprofundados.Isso garantirá que o sistema de informação a ser desen-volvido esteja completo. Claro que esta abordagem deve ser restrita ao projeto de teste.
No planejamento serão elaborados a estratégia de teste e o plano de
teste, os quais serão utilizados posteriormente.
DICA
Você estudará sobre a estratégia e o plano de teste mais para frente.
O ambiente de teste será organizado na etapa de preparação, de forma
que os testes sejam executados corretamente. Esta etapa corre em pa-ralelo com as outras.
O objetivo básico da etapa de especificação é elaborar/revisar os casos
de teste e os roteiros de teste.
Na fase de execução os testes deverão ser executados de acordo com os
casos de testes e roteiros de teste. Devem ser usados scripts de teste, caso alguma ferramenta de automação seja empregada.
Na etapa de entrega oprojeto de teste é finalizado. Toda a
documenta-ção será concluída e arquivada e todas as ocorrências importantes deve-rão ser relatadas.
Agora que você já conhece o ciclo de vida do processo de teste, que tal conhecer mais detalhadamente um ambiente de teste? Então, vamos juntos!
SeçãO 4
Ambiente de Teste
Nesta seção você estudará sobre ambiente de teste, o qual é preparado em uma das etapas do ciclo de vida do processo de teste.
Script: está relacionado à programas executados dentro de outros programas de forma a estender a funcionali-dade deste programa ou con-trolá-lo.
O ambiente de teste é a estrutura onde o teste será executado.
Para este ambiente é preciso considerar a criação da massa de dados de teste, o modelo de dados e a configuração dos softwares usados.
É importante que você não confunda o ambiente com a configuração do
hardware, ok?
Veja na lista a seguir alguns itens que fazem parte de um ambiente de teste:
1. Pessoal: usuários, desenvolvedores, testadores. 2. Hardware: plataforma, impressora, scanners.
3. Software: software a ser testado, sistema operacional, software de teste, procedimentos de teste.
4. Suprimentos: papel, formulários.
5. Interface: interna, externa.
6. Rede: protocolos, conexões, gateways.
7. Ambiente físico: local, segurança, estrutura.
8. Documentação: requisitos, design, usuários.
Para preparar um ambiente de teste você pode usar o seguinte fluxogra-ma:
Figura 10: Fluxograma de teste.
Perceba que a figura apresentada anteriormente é um ciclo, ou seja, deve ser aplicada continuamente até que os testes estejam concluídos.
Mas, como toda ação geralmente possui um risco, a ação de testar um sof-tware não poderia ser diferente, não é mesmo? Por isso, na próxima uni-dade você estudará sobre a análise destes riscos, desde sua definição até como controlá-los. Gostou deste novo assunto? Então, siga em frente!
Unidade de
estudo 4
Seções de estudo
Seção 1 – Definição de risco
Seção 2 – Riscos relativos ao teste de
software
Seção 3 – Determinação da magnitude dos riscos
Análise de risco
SeçãO 1
Definição de risco
Você sabe o que significa a pala-vra risco?
Segundo o dicionário da língua portuguesa Michaelis, risco é a possibilidade de perigo, incerto, mas previsível, que ameaça de dano a pessoa ou a coisa.
Quando falamos de software, es-tamos procurando aqueles fatos cujas ocorrências poderão acarre-tar perdas para a empresa. No entanto, um risco presente nem sempre vai gerar uma perda. Se uma empresa faz todo o seu negócio na internet, por exem-plo, venda de produtos, existe um grande risco de perda de dinheiro, se os computadores pararem de funcionar. Mas se você pensar no mercadinho da esquina, não existe nenhum problema se o computa-dor do caixa parar.
Mas, o que isso tem haver com o teste de software? Encontre a res-posta para este questionamento na próxima seção.
SeçãO 2
Riscos relativos ao teste de software
A atividade de testar o software está bastante ligada ao risco. Você já estudou como o custo dos testes influencia no desenvolvimento de um software. Também já viu que os defeitos encontrados tardiamente aumen-tam bastante o custo da correção.
Por isso, as equipes de teste devem procurar um nível de cobertura que minimize a possibilidade de defeitos graves, principalmente por causa da existência de prazos. Ou seja, apesar de existirem riscos relativos a de-terminados defeitos, é necessário um tempo maior de teste com aqueles que podem gerar os maiores problemas.
DICA
Ao fazer a análise de riscos, leve em consideração a probabilidade de ocorrência do risco e o impacto e perda associados a esse risco.
Neste momento possivelmente você esteja se perguntando: mas, como analisar e avaliar os riscos que possam surgir? É sobre isso que conver-samos a seguir.
SeçãO 3
Determinação da magnitude dos riscos
Você precisa lembrar que, quando se trata de riscos, é necessário avaliar o custo da ocorrência do risco e o custo dos mecanismos de controle para evitar que o risco ocorra.
Para fazer uma análise preliminar da qualificação do risco você pode usar a tabela a seguir. Confira!
Impacto que o risco causa Probabilidade de ocorrência Alta Média Baixa
Alto AA AM AB
Médio MA MM MB
Baixo BA BM BB
Quadro 4: Qualificação dos riscos (probabilidade x impacto).
Considerando o quadro apresentado anteriormente , perceba que você deve dar prioridade àquele teste que vai causar o maior problema e que pode ocorrer com mais facilidade (AA).
E como controlar os riscos? Confira a seguir.
SeçãO 4
Controle dos riscos
Considere uma loja que vende livros, CD’s e DVD’s pela internet e que mantém uma base de dados num ambiente de grande porte (legado). Você pode encontrar alguns riscos associados a operação dessa loja. Imagine os seguintes riscos:
▪
Facilidade de uso do site, pois se a navegação não for bastante ami-gável, pode ser que o cliente desista de comprar.▪
Tempo de resposta muito longo para as páginas abrirem, também pode fazer com que o cliente desista.▪
A conectividade tem que ser confiável, para que o sistema não caia e interrompa o processo de compra.O primeiro risco pode ser controlado fazendo um teste de usabilidade bem rigoroso. Uma das possibilidades é criar um protótipo para ser avaliado por um público externo. O sistema só será liberado quando um grupo de usuários concordar que o sistema está amigável.
Para contornar o segundo risco é preciso submeter o sistema a um teste de carga e comparar os tempos de resposta com os requisitos do negó-cio. Por exemplo, os requisitos poderiam ser:
Deve ser prevista uma média de 6 mil acessos por dia, com pico de 8 mil. O tempo de resposta não deve ser superior a 4 segundos e, no pico, a 8 segundos.
No controle desse risco é necessário utilizar uma ferramenta de auto-mação que faça o teste de carga, adicionando novos usuários pouco a pouco até que o sistema comece a se degradar, ou seja, apresentar um tempo de resposta maior do que o requisitado.
Com este exemplo pode-se perceber que é preciso relacionar todos os possíveis riscos que podem ocorrer com a implantação do software e posteriormente analisar cada um deles buscando uma resposta ou até mesmo solução prévia para que o risco não se torne realmente um “pro-blema”. Então fique atento também aos riscos durante o processo de teste do software, ok?
Na próxima unidade você estudará sobre como fazer um plano de teste. Vamos em frente!
Unidade de
estudo 5
Seções de estudo
Seção 1 – Plano de teste, o que é? Seção 2 – Desenvolvimento do plano de tese
Planejamento dos testes
SeçãO 1
Plano de teste, o que é?
Se você trata os testes como um processo contínuo, que faz parte do desenvolvimento do software, torna-se necessário fazer um pla-no para estes testes, não é mesmo? Da mesma forma que qualquer coisa que é executada em um am-biente industrial, é extremamente importante que haja um planeja-mento dos testes.Imagine que você vai viajar de avião. Você sabe que o software de controle do avião foi testado. Mas e se não foi feito um plane-jamento e alguém se esqueceu de testar alguma coisa?
Segundo Bastos et al (2007, p. 113) o plano de teste é uma ma-neira de documentar o projeto de testes e desse modo, permitir que os mesmos testes possam ser re-petidos e controlados. Quando, posteriormente, o software passar por algum tipo de manutenção e precisar voltar para ser testado, esse documento será um ótimo guia para orientar a repetição ou servir de base para executar os testes de regressão.
Confira a seguir as etapas que fa-zem parte de um plano de teste.
▪
Repetibilidade: uma coisa que torna qualquer sistema confiávelé a repetibilidade, ou seja, se você executar o sistema com as mesmas entradas ele deverá apresentar as mesmas saídas. O plano de testes permite a repetibilidade da aplicação dos testes.
▪
Controle: como você saberá se os objetivos do teste foramatingi-dos ou se toatingi-dos os elementos críticos foram testaatingi-dos? A única forma de fazer controle sobre os testes é possuir um plano que determine quais são os passos a serem seguidos na hora de testar.
▪
Cobertura: o plano de teste também determinará o nível decober-tura dos testes. Essa cobercober-tura deve atingir os elementos mais críticos, seja pelo risco que representa para o negócio, seja por sua importância para o projeto.
Em resumo, o plano de testes é extremamente importante para o pro-cesso de teste. Ele estabelece o que vai ser testado, durante quanto tempo e quando os testes serão interrompidos.
O plano de teste descreve como o teste deverá ser executado e traça uma linha mestra a ser seguida.
Confira na seção seguinte como desenvolver um plano de teste. Siga adiante!
SeçãO 2
Desenvolvimento do plano de teste
Para que você possa desenvolver um plano de teste existe um padrão que é mundialmente aceito. Este padrão foi definido pelo Institute of Electrical and Electronics Engineeres (IEEE). Nele está a lista com o conte-údo do plano de teste.
O Quality Assurance Institute (QAI) segue basicamente este mesmo pa-drão, apenas com algumas características próprias.
Para lembrar significa: PMI = Project Management Institu-te, criadores do PMBOK. Para relembrar significa: PM-BOK (Project Management Body of Knowledge).
Além desses dois formatos de plano, existe o Plano Global do Projeto, definido pelo PMBOK, que foi citado na primeira unidade de estudos deste livro.
Este último trata o teste como um projeto, por isso você irá estudálo com mais detalhes a seguir. Os itens do PMBOK são os se-guintes:
▪
Escopo: o escopo defineexatamente a extensão do projeto de teste, até suas interfaces com outros softwares, componentes, elementos de rede ou demais ele-mentos. Deve definir o que será e o que não será coberto pelo teste.
▪
Custo: para saber quantoo projeto de teste vai custar é preciso medir o seu tamanho,ou seja, é preciso fazer a métrica de teste. É possível adaptar algumas métricas existentes, como análise de pontos de caso de teste. Mas normalmente isso leva tempo e a métrica deve ser ajustada gradati-vamente.
▪
Tempo: a elaboração docro-nograma está ligada ao tamanho do projeto, que servirá de base para o cálculo dos custos. Você pode imaginar, por exemplo, um projeto com 180 pontos de teste. Por meio de indicadores da em-presa é possível transformar este número de pontos em horas (por exemplo, 220 horas). Depois, transformar horas em custo é simples. Como tempo é dinheiro, você deve também estabelecer o momento de encerramento dos testes. Ficar testando uma aplicação por muito tempo pode aumentar demais o custo do projeto.
▪
Qualidade: você sempredeve lembrar que o produto a ser entregue deve estar de acordo com as necessidades de qualidade estabelecidas pelo cliente. Então, a medição da qualidade tem que ser acompanhada por um progra-ma de indicadores, implementado no decorrer do projeto.
▪
Integração: a principalinte-gração do projeto de teste é com o processo de desenvolvimento. Além disso, como normalmente o projeto de teste é segmentado em etapas, por isso é preciso manter a integração entre elas.
▪
Recursos humanos: aquanti-dade de homens/hora imaginada para o projeto é estabelecida após a estimativa de seu tamanho. Porém, é necessário definir os re-cursos envolvidos em cada etapa do projeto.
▪
Comunicação: a função dessaetapa é garantir a maneira como as partes envolvidas no projeto receberão as informações de que precisam para tomar decisões. Todo material produzido deverá estar disponível para consulta de maneira clara em algum ambiente criado pelo projeto. As regras de gerenciamento de projetos determinadas pelo PMI definem a necessidade de um gerencia-mento de comunicação para dar suporte aos projetos.
▪
Riscos: o projeto de testeimplica seus riscos específicos, como o uso de uma nova ferra-menta de automação para a qual os testadores ainda não tenham sido treinados. Se você é o líder do projeto de teste, tome cuidado para não confundir os riscos do projeto de teste com os riscos do negócio.
▪
Suprimentos: é importanteque as necessidades de compra de bens ou serviços sejam aten-didas no momento certo. Talvez algumas ferramentas precisem ser compradas ou um ambiente de teste tenha de ser configurado.
▪
Conclusão:independen-temente de qual modelo você seguirá na elaboração do plano de teste, o importante é que este planejamento seja feito com cuidado e precisão.
Você sabe quais são os documen-tos necessários às atividades de um projeto de software? É sobre este assunto que você estudará na sequência. Siga em frente!
SeçãO 3
Documentação do teste
Segundo Bastos et al (2007, p. 150), em torno de 50% a 60% do tempo do analista de teste é gas-to na documentação do teste. A norma IEEE 829 descreve um conjunto de documentos neces-sários às atividades de um projeto de software. Veja!▪
Plano de teste: identifica ositens e as funcionalidades a serem testadas, os riscos associados ao teste, as tarefas a serem realizadas e apresenta o planejamento para a execução do teste.
▪
Especificação de projeto de teste: trata-se de umdetalhamen-to da abordagem apresentada no plano de teste que identifica as funcionalidades e as característi-cas a serem testadas pelo projeto. Este documento também aponta os casos e os procedimentos de teste e apresenta os critérios de aprovação.
▪
Especificação de caso de teste: define os casos de teste, comtodas as características que você estudou nas seções anteriores.
▪
Especificação do procedimento de teste: identifica todos ospassos necessários para a operação do sistema e o exercício dos casos de teste especificados. Os procedimentos de teste devem ser seguidos passo a passo, sem imprevistos. Esta especificação forma um docu-mento separado.
Figura 11: Documentação IEEE 829.
Na próxima unidade você verá como deve ser executado o teste de um software. Como já mencionado nas unidades anteriores todos os testes devem ser executados buscando a qualidade do software. Mas, muitas ve-zes, os requisitos dos softwares não exigem essas características. E como teste custa dinheiro, será preciso conversar com os usuários sobre a ne-cessidade de alguns tipos de teste.
Ficou curioso(a) para saber mais sobre o assunto? Vamos lá, siga em frente nos estudos!
Unidade de
estudo 6
Seções de estudo
Seção 1 – Contexto dos testes
Seção 2 – Processo de execução dos testes Seção 3 – Relatório de teste segunda a IEEE 829
Seção 4 – Gerenciamento de comunicação do projeto de teste
execução dos testes
SeçãO 1
Contexto dos testes
De acordo com Bastos (2007, p. 169 apud CEM KANER, 1999), teste estático e teste dinâmico são definidos da seguinte forma:
▪
No teste estático, o código é examinado.▪
No teste dinâmico, o código é testado.Para que os testes possam ser executados é necessário que exista o Plano de Teste.
É muito importante que o plano de testes esteja atualizado e bem detalhado, pois isso facilitará o trabalho dos testadores na hora de elaborar os casos de teste e de executar os testes.
A responsabilidade de cada pessoa durante a execução dos testes deve estar no plano de teste. No quadro a seguir você pode verificar o que cada agente da equipe de teste deve fazer. Confira!
Responsáveis pelos testes
Testes unitários Programadores
Testes de integração Analistas de sistemas Testes de sistema Analistas de teste
Testes de aceitação Usuários com a ajuda dos analistas de teste
Quadro 5: Responsabilidade de cada pessoa da equipe de teste.
Você deve analisar os resultados dos testes a cada etapa de teste executa-da. Todo s os registros da execução dos testes devem ser guardados sob ferramentas de gestão dos testes. Desse modo, o gestor de teste poderá saber o que ainda precisa ser corrigido pela equipe desenvolvimento, o que está em processo de teste e o que já foi dado como concluído, ou seja, já foi testado, corrigido, retestado e aprovado.
Que tal conhecer como acontece o processo de execução dos testes? Este é o nosso póximo assunto!
SeçãO 2
Processo de execução dos testes
Nesta seção, você vai ver que o processo de teste que deve ser cumprido na fase de execução. Esse processo está apresentado na figura a seguir. O Plano de Teste de teste é o documento mais importante deste fluxo.
Figura 12: Fluxo de execução dos testes
DICA
Se ele não for elaborado, não é possível executar cada etapa correta-mente, ok? Lembre-se disso!
Você vai ver agora os diversos métodos para testar uma aplicação, se-gundo as características de qualidade dos softwares.
▪
Teste de autorização (funcionalidade): visa garantir que as regrasde autorização sejam cumpridas. Ninguém pode executar, por exem-plo, uma funcionalidade para a qual não está habilitado.
▪
Teste de integridade dos arquivos (funcionalidade): garante queas atualizações de arquivos foram feitas corretamente após a execução de um módulo do software.
▪
Teste de recuperação (continuidade): você deve testar osprocedimentos que permitem que o sistema seja reiniciado após uma falha. Todos os procedimentos que mostram como reiniciar o sistema deverão passar por inspeção.
▪
Teste de estresse (performance): o teste deve colocar a aplicaçãosobre estresse para verificar se o software consegue funcionar correta-mente sob grande carga de processamento.
Manutenibilidade é uma me-dida para mostrar se o sof-tware é fácil de consertar ou ser melhorado.
▪
Teste manual (usabilidade):os sistemas devem ser amigá-veis, fáceis de utilizar, para que possam fazer sucesso com os usuários finais. Normalmente, é difícil avaliar se uma aplica-ção é amigável, apenas usando um ambiente de teste. Então, é melhor fazer o teste manual num ambiente mais próximo possível do ambiente de produção.
▪
Teste de segurança (segu-rança): este tipo de teste deveverificar se é possível que pessoas não autorizadas violem as infor-mações. Em geral, o testador não é especialista em segurança, então em alguns casos é necessá-rio contratar técnicos especialis-tas para a execução deste teste.
▪
Inspeções (manutenibilida-de): é muito importante testar seserá fácil efetuar a manutenção da aplicação no futuro. Para a pessoa que desenvolveu o softwa-re, é fácil fazer alterações, pois ela conhece bem a aplicação. Mas se esta aplicação for mantida por outro técnico, é necessário que ela seja simples de entender.
▪
Teste de conexão (conec-tividade): estes testes devemgarantir que a aplicação está se comunicando corretamente com outra.
▪
Teste de performance (performance): muitas vezes, asaplicações apresentam alguns cri-térios de desempenho que preci-sam ser atendidos, como número de clientes ativos ou transações executadas por hora.
▪
Teste operacional (ope-racionalidade): neste tipo deteste, toda a documentação de operação do software será avaliada. Ele deve ser feito pela equipe de produção ou pela equipe que irá operar a aplicação.
O quadro a seguir é um exemplo de checklist que pode ser utiliza-do na execução utiliza-dos testes. Este exemplo foi retirado do livro Ga-rantia da Qualidade de Software do autor Alexandre Bartié. O quadro mostra vários procedimentos de teste para integrações batch em um sistema de vendas, que cole-ta todas as entradas de pedidos realizadas pelos vendedores, nas quais são informados os produtos e suas quantidades, descontos e as condições de pagamento negocia-das com o cliente.
Normalmente, nas integrações ba-tch, se você deseja provocar uma situação no sistema, é necessário interagir com outros softwares de forma produzir o resultado dese-jado.
Batch: a tradução direta é lote. No caso de software, essa palavra está relacionada com um arquivo de lote (.bat) utilizado para automatizar tare-fas.
Processo: importa resultado da análise de crédito Cenário #1
Executar a importação sem a existência do arquivo
Pré - requisitos
▪
Garantir que não exista arquivo – texto de importação. Ações▪
Executar importação da análise de crédito.Conferências
▪
Mensagem “Não foi encontrado o arquivo de Análise de Crédito”.Cenário #2
Executar a importação com o arquivo disponível
Pré - requisitos
▪
Garantir que existam pedidos que aguardam análise de crédito.▪
Garantir que exista arquivo de simulação Simula-01.TXT. Ações▪
Executar importação da análise de crédito.Conferências
▪
Mensagem “Importação da Análise de Crédito realizada com sucesso”.▪
Confirmar se o arquivo foi excluído.▪
Confirmar se as situações dos pedidos foram alteradas corretamente.▪
Confirmar os motivos para os pedidos com recusa de crédito.Cenário #3
Executar a importação com arquivo já processado
Pré - requisitos
▪
Garantir que exista arquivo de simulação Simula-01.TXT.▪
Garantir que o arquivo Simula-01.TXT já tenha sido processado. Ações▪
Executar importação da análise de crédito.Conferências
▪
Mensagem “Este arquivo já foi anteriormente processado!”.▪
Confirmar se a operação foi cancelada.▪
Confirmar se o arquivo foi excluído.Cenário #4
Executar a importação de pedidos com dois dias em pendência de análise de crédito
Pré - requisitos
▪
Garantir que existam pedidos aguardando análise de crédito há dois dias.▪
Garantir que exista arquivo de simulação Simula-02.TXT.Ações
▪
Executar importação da análise de crédito.Conferências
