Testes Software curso técnico em informatica

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 Diretor de Desenvolvimento Organizacional do SENAI/SC

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-001 Fone: (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 conectadas e estrategicamente instaladas em todas 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, desenvolver 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 Movimento promove a discussão, a revisão e o aprimoramento dos processos de educação do SENAI. Buscando manter o alinhamento com as necessidades do mercado, ampliar as possibilidades do processo educacional, oferecer recursos didáticos de excelência e consolidar o modelo de Educaçã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 Apresentação

9

26 Unidade de estudo 3

11

Processo de teste de software

12 Unidade de estudo 1 O que é o teste de software?

41

Seção 1 - Contexto dos testes

28

Seção 2 - Conceito “V” de teste

42

Seção 2 - Processo de execução dos testes

28

Seção 3 - Ciclo de vida do processo de teste

45

Seção 3 - Relatório de teste segunda a IEEE 829

29

Seção 4 - Preparação do ambiente

46

Seção 4 - Gerenciamento de comunicação do projeto de teste

13

Seção 2 - Objetivos do teste de software

14

Seção 3 - O que é teste de software?

15

Seção 4 - E se não testar o software?

16

Seção 5 - Casos de testes

33

Seção 1 - Definição de risco

16

Seção 6 - Tipos de testes

33

Seção 2 - Riscos relativos ao teste de software

33

Seção 3 - Determinação da magnitude dos riscos

34

Seção 4 - Controle dos riscos


36 21

Seção 2 - Técnicas funcional, estrutural e baseadas em erros

21 24

Seção 3 - Critérios para geração de casos de teste Seção 4 - Níveis de teste

48

Análise de riscos


Seção 1 - O que é técnica de teste?

Execução dos testes

Seção 1 - Ciclo de vida de desenvolvimento de software

Seção 1 - Metodologia de desenvolvimento de software

21

Unidade de estudo 6

27

13

Técnicas de teste de software

40

Unidade de estudo 5

Teste de aceitação

49

Seção 1 - Definição dos critérios de aceitação

49

Seção 2 - Elaboração do plano de aceitação

50

Seção 3 - Execução do teste de aceitação

52

Planejamento dos testes 37

Seção 1 - Plano de teste, o que é isso?

37

Seção 2 - Desenvolvimento do plano de teste

39

Seção 3 - Documentação do teste

Unidade de estudo 7

Unidade de estudo 8 Estimativas

53

Seção 1 - Análise do ponto de teste

54

Seção 2 - Estimativa baseada no tamanho e complexidade do caso de uso

Finalizando

57

Referências

59

8

CURSOS TÉCNICOS SENAI

Conteú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; ▪▪ Interpretar as especificações de teste;

TESTES DE SOFTWARE

9

▪▪ 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 computador.

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; ▪▪ Análise crítica da solução proposta.

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 transferir 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 transaçã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 deverão ser refletidas por você, como um técnico em informática, responsá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 funcionará corretamente nos momentos mais difíceis. Também verá 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 foram demorados e detalhados, mas valeu a pena, pois certamente você encontrará ao longo da leitura deste livro respostas para muitas perguntas como as que você leu no início desta apresentação e muitas outras que surgirão ao longo de sua carreira profissional. Então, espero que você consiga aproveitar o material para se desenvolver profissionalmente e pessoalmente. É 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, quando você estiver trabalhando em uma grande empresa de desenvolvimento 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.

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 programação, microcontroladores, acionamentos elétricos e projetos elétricos nos cursos técnicos de automação, mecatrônica e eletrotécnica. Atua em STT, desenvolvendo programas para microcontroladores aplicados em equipamentos eletrônicos.

Bons estudos!

TESTES DE SOFTWARE

11

Unidade de estudo 1 Seções de estudo Seção 1 – Metodologia de desenvolvimento 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 Seção 6 – Tipos 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).

Processo de Garantia da Qualidade do Software: 1. Planejamento da Qualidade. 2. Garantia da Qualidade. 3. Controle da Qualidade.

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 Management Body of Knowledge), no qual o processo de gerenciamento da qualidade de software é subdividido em três partes complementares, acompanhe!

Neste momento você deve estar se perguntando: mas porque devo testar um software? Qual o objetivo deste teste? Não seria perda de tempo, já que na maioria das vezes o tempo de desenvolvimento de um software é curto? É sobre este assunto que conversaremos na próxima seção de estudo. 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á decomposto em fases e cada fase possui uma numeração que indica a sequência de execução dos testes a serem aplicados. Assim, deve-se dividir os testes em duas categorias: testes de verificaçã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 estão focados na garantia da qualidade do software.

TESTES DE SOFTWARE

13

Para que você possa verificar as atividades e avaliar os documentos gerados durante as fases do processo de engenharia de software, deve utilizar os testes de verificação. As fases da metodologia que fazem parte dos testes de verificação são:

▪▪ Disponibilização de Solução: validação do aceite.Lembre-se de que o conhecimento se adquire por meio de uma construção significativa da aprendizagem. Então, vamos juntos trilhar novos caminhos do conhecimento?

▪▪ Modelo de Negócios: verifi-

Seção 3

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ção da implementação. Desta forma, defini-se testes de validação como: [...] um processo formal de avaliação de produtos tecnológicos que podem ser aplicados em componentes isolados, módulos existentes ou mesmo nos sistemas como um todo. Seu objetivo é avaliar a conformidade do software com os requisitos e especificações analisadas e revisadas nas etapas iniciais do projeto (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 da unidade;

▪▪ Integração Especificada

ou Modificada: validação da integração;

▪▪ Sistema Especificado ou Modificado: validação do sistema;

14


O que é teste de software?

▪▪ Teste é um processo sistemático e planejado que tem por finalidade única a identificação de erros.

Esta é considerada a definição correta sobre os testes. Independentemente do teste ser aplicado a um documento ou a um software, o objetivo é criar situações onde o produto pode não funcionar.

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 desenvolvimento aplica está simplificada como:

▪▪ Teste é o processo de demonstrar que algo funciona corretamente. ▪▪ Teste é o processo de provar que determinadas coisas fazem o que deveriam fazer.

Ou seja, todo mundo vê os testes 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 desenvolvimento 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 comportamento deste produto pode gerar um funcionamento inadequado. Neste ponto, é possível chegar à segunda definição de teste:

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 conformidades e inconsistências são palavras que representam naturezas 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 profissionais de desenvolvimento, qualidade e testes, os responsáveis por um software sem defeitos.

▪▪ 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 encontrados 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.

Os erros são resultados do não entendimento dos requisitos do cliente e especificações mal feitas. Portanto, você deve trabalhar mais tempo nas especificações e modelagem da solução. Isso fará com que muitos erros sejam 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 encontrados 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 dessas vantagens são:

▪▪ os testes tornam o ciclo de desenvolvimento confiável; ▪▪ garantem ações corretivas durante o desenvolvimento

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 filosofia 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!

TESTES DE SOFTWARE

15

Seção 5

Casos de testes De acordo com Bastos et al (2007, p. 153) um caso de teste é a especificação mais detalhada do teste, apresentando os campos de telas, formulários etc. O caso de teste estabelece as informações empregadas nos testes dos cenários e quais são os resultados esperados. Ou seja, é necessário fazer um detalhamento 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 conter:

▪▪ 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 operacional, ferramentas necessárias, origem dos dados etc (onde testar);

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. 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.

Procedimentos

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

▪▪ como testar: automático/ma-

Tipos de testes

▪▪ quando testar (cronograma, em qual fase o teste será executado);

No momento em que você começar a fazer os testes de validação, significa que já tem um produto computacional, ou seja, um software que pode ser executado. Para fazer esta validação você pode utilizar duas abordagens:

nual (definir o tipo de implementação do teste);

▪▪ listar as interdependências, caso existam, entre os casos de teste. O quadro a seguir é um exemplo de caso de teste aplicado a um sistema de uma imobiliária. Veja!

▪▪ a estratégia da caixa branca ou, ▪▪ a estratégia da caixa preta.

Figura 3: Estratégias fundamentais dos testes.

16


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 codificaçã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 tecnologia 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 processamento final, retângulo 3. Após este processamento, 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?

TESTES DE SOFTWARE

17

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 é necessá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 implementados. 2. Teste de usabilidade: a ideia desse teste é medir o nível de facilidade da aplicação, de modo a 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 processamento 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.

18


4. Teste de configuração (ambiente): o objetivo desta categoria é executar o software sobre diversas configurações de softwares e hardwares. 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 versões anteriores. 6. Teste de segurança: esta categoria de teste tem por objetivo detectar falhas de segurança que podem comprometer o sigilo das informaçõ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 requisitos 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 impossibilita 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 (confiabilidade), 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ê.

TESTES DE SOFTWARE

19

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. Seção 4 – Níveis 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 processo que assegura o funcionamento adequado de alguns aspectos do sistema ou da unidade. Já as ferramentas de teste são recursos para o testador. Utilizar apenas a ferramenta, sem a técnica 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écnica adequada, pode não cortar 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. Vamos 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 requisitos. Ou seja, se o código faz aquilo que foi pedido pelo cliente e que está na documentação. Normalmente é 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 componentes montados funcionam como uma unidade. Quando você usa uma técnica de teste baseada em erros, deverá inserir erros no software e verificar o seu funcionamento. Na verdade, esta é uma variação da técnica funcional, pois ele testa os requisitos. Mas serve para encontrar aqueles defeitos que já são esperados. Agora que você já conheça algumas técnicas de teste, veja os crité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 possibilidades, ou cenários. Quanto maior a quantidade de cenários testados, maior a qualidade do produto. Lembre-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),

TESTES DE SOFTWARE

21

“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 simulados 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 processo de teste de um software e, consequentemente, no processo de garantia 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 processamento e das tomadas de decisão.

22


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 pensar “Mas, qual das duas eu devo utilizar?” Na verdade, em uma aplicação real, as duas abordagens devem ser utilizadas 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 é economicamente 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 necessá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).

TESTES DE SOFTWARE

23

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 importantes para 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 (testes 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 atividades que estão descritas no quadro a seguir, acompanhe! Fase de Verificação

Modelo de negócios

Especificação de requisitos

Principais Atividades

▪▪ Revisar contexto do mercado e necessidade do cliente. ▪▪ Revisar riscos do projeto. ▪▪ Revisar estudo de viabilidade. ▪▪ Revisar especificação de requisitos funcionais e não – funcionais. ▪▪ Auditar rastreabilidade de requisitos. ▪▪ Revisar priorização de requisitos. ▪▪ Revisar arquitetura da aplicação. ▪▪ Revisar nível de componentização. Saiba mais so-

Análise e modelagem

bre componentização de software no artigo escrito pelo professor Antonio Mendes da Silva filho, disponível em:

▪▪ 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.

Quadro 2: Fases dos testes de verificação

24


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!

Teste de baixo nível

Fase da Validação

Teste de unidade

Características

▪▪ 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 profissional de teste. ▪▪ Estratégia de caixa preta. ▪▪ São aplicados no software como um

todo. Teste de alto nível

Teste de sistema

▪▪ Requer ambiente semelhante ao da produção. ▪▪ Executado por um grupo de testes independente. ▪▪ Estratégia de caixa preta. ▪▪ São aplicados no software como um

Teste de aceitação

todo.

▪▪ Requer ambiente semelhante ao da produção. ▪▪ Executado pelos usuários finais.

Quadro 3: Características do testes de validação

Uma nova unidade lhe convida a explorar novos conceitos. Vamos lá?

TESTES DE SOFTWARE

25

Unidade de estudo 3 Seções de estudo Seção 1 - Ciclo de vida de desenvolvimento 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

Processo de teste de software Seção 1

Ciclo de vida de desenvolvimento 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 principais atividades que acontecem durante 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 reconhecimento de um problema ou identificação de uma necessidade. Durante essa fase o projeto é justificado e aprovado no alto nível da organização. As alternativas de solução são exploradas e seleciona-se a solução mais viável e que atenda melhor às necessidades identificadas. Muitas vezes, realiza-se um estudo de custo-benefício para apoiar o processo de decisão.

▪▪ Fase 2 – Análise de requisitos: 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 entendimento do problema. Ainda nesta fase é preparado o Plano de Projeto, que inclui cronograma, recursos, orçamento, produtos intermediários, atividades 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 realizar 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 projeto.

▪▪ 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 programas prontos e testados. Nesses programas devem ser aplicados os testes unitários conforme os planos de teste e os casos de teste preparados.

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 certificação quanto a sua adequação aos requisitos de segurança antes da instalação. E antes de ser certificado, 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 implementado, 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 solicitações de mudanças são usados para facilitar a correção de forma sistemática e a evolução do sistema. Também devem ser executadas medições de desempenho e avaliação das atividades para garantir que o sistema continuará atendendo a seus requisitos.

TESTES DE SOFTWARE

27

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 diminui 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.

28


Script: está relacionado à programas executados dentro de outros programas de forma a estender a funcionalidade deste programa ou controlá-lo.

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 desenvolvido 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 paralelo 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 deverã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.

TESTES DE SOFTWARE

29

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 fluxograma:

30


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 software não poderia ser diferente, não é mesmo? Por isso, na próxima unidade 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!

TESTES DE SOFTWARE

31

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 Seção 4 – Controle dos riscos

Análise de risco Seção 1

Seção 2

Você sabe o que significa a palavra 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, estamos procurando aqueles fatos cujas ocorrências poderão acarretar 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 exemplo, 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 computador do caixa parar. Mas, o que isso tem haver com o teste de software? Encontre a resposta para este questionamento na próxima seção.

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 aumentam 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 determinados defeitos, é necessário um tempo maior de teste com aqueles que podem gerar os maiores problemas.

Definição de risco

Riscos relativos ao teste de software

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 conversamos 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!

TESTES DE SOFTWARE

33

Impacto que o risco causa Alto Médio Baixo

Probabilidade de ocorrência Alta Média Baixa AA AM AB MA MM MB 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 amigá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:

34


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 automaçã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 “problema”. 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!

TESTES DE SOFTWARE

35

Unidade de estudo 5 Seções de estudo Seção 1 – Plano de teste, o que é? Seção 2 – Desenvolvimento do plano de tese Seção 3 – Documentação do teste

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 plano para estes testes, não é mesmo? Da mesma forma que qualquer coisa que é executada em um ambiente industrial, é extremamente importante que haja um planejamento 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 planejamento e alguém se esqueceu de testar alguma coisa? Segundo Bastos et al (2007, p. 113) o plano de teste é uma maneira de documentar o projeto de testes e desse modo, permitir que os mesmos testes possam ser repetidos 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 fazem 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 foram atingi-

dos ou se todos os elementos críticos foram testados? 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 de cobertura dos testes. Essa cobertura 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 processo 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 padrão, apenas com algumas características próprias.

TESTES DE SOFTWARE

37

Para relembrar significa: PMBOK (Project Management Body of Knowledge). Para lembrar significa: PMI = Project Management Institute, criadores do PMBOK.

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 seguintes:

▪▪ Escopo: o escopo define

exatamente a extensão do projeto de teste, até suas interfaces com outros softwares, componentes, elementos de rede ou demais elementos. Deve definir o que será e o que não será coberto pelo teste.

▪▪ Custo: para saber quanto

o 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 gradativamente.

▪▪ Tempo: a elaboração do cro-

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 empresa é 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.

38


▪▪ Qualidade: você sempre deve 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 programa de indicadores, implementado no decorrer do projeto. ▪▪ Integração: a principal integraçã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: a quantidade de homens/hora imaginada para o projeto é estabelecida após a estimativa de seu tamanho. Porém, é necessário definir os recursos envolvidos em cada etapa do projeto. ▪▪ Comunicação: a função dessa etapa é 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 gerenciamento de comunicação para dar suporte aos projetos. ▪▪ Riscos: o projeto de teste implica seus riscos específicos, como o uso de uma nova ferramenta 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: é importante que as necessidades de compra de bens ou serviços sejam atendidas no momento certo. Talvez algumas ferramentas precisem ser compradas ou um ambiente de teste tenha de ser configurado. ▪▪ Conclusão: independentemente de qual modelo você seguirá na elaboração do plano de teste, o importante é que este planejamento seja feito com cuidado e precisão.

▪▪ Especificação de caso de teste: define os casos de teste, com todas as características que você estudou nas seções anteriores. ▪▪ Especificação do procedimento de teste: identifica todos os passos 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 documento separado.

Você sabe quais são os documentos 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 é gasto na documentação do teste. A norma IEEE 829 descreve um conjunto de documentos necessários às atividades de um projeto de software. Veja!

▪▪ Plano de teste: identifica os itens 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.

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 vezes, os requisitos dos softwares não exigem essas características. E como teste custa dinheiro, será preciso conversar com os usuários sobre a necessidade de alguns tipos de teste. Ficou curioso(a) para saber mais sobre o assunto? Vamos lá, siga em frente nos estudos!

▪▪ Especificação de projeto de

teste: trata-se de um detalhamento da abordagem apresentada no plano de teste que identifica as funcionalidades e as características 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.

TESTES DE SOFTWARE

39

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 executada. 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!

TESTES DE SOFTWARE

41

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 corretamente, ok? Lembre-se disso!

Você vai ver agora os diversos métodos para testar uma aplicação, segundo as características de qualidade dos softwares.

▪▪ Teste de autorização (funcionalidade): visa garantir que as regras

de autorização sejam cumpridas. Ninguém pode executar, por exemplo, uma funcionalidade para a qual não está habilitado.

▪▪ Teste de integridade dos arquivos (funcionalidade): garante que

as 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 os procedimentos 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ção

sobre estresse para verificar se o software consegue funcionar corretamente sob grande carga de processamento.

42


▪▪ 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 deve verificar se é possível que pessoas não autorizadas violem as informações. Em geral, o testador não é especialista em segurança, então em alguns casos é necessário contratar técnicos especialistas para a execução deste teste.

▪▪ Inspeções (manutenibilidade): é muito importante testar se será fácil efetuar a manutenção da aplicação no futuro. Para a pessoa que desenvolveu o software, é 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 (conectividade): estes testes devem garantir que a aplicação está se comunicando corretamente com outra.

▪▪ Teste de performance (performance): muitas vezes, as aplicações apresentam alguns critérios de desempenho que precisam ser atendidos, como número de clientes ativos ou transações executadas por hora. ▪▪ Teste operacional (operacionalidade): neste tipo de teste, 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 utilizado na execução dos testes. Este exemplo foi retirado do livro Garantia 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 coleta 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 negociadas com o cliente. Normalmente, nas integrações batch, se você deseja provocar uma situação no sistema, é necessário interagir com outros softwares de forma produzir o resultado desejado.

Manutenibilidade é uma medida para mostrar se o software é fácil de consertar ou ser melhorado. Batch: a tradução direta é lote. No caso de software, essa palavra está relacionada com um arquivo de lote (.bat) utilizado para automatizar tarefas.

TESTES DE SOFTWARE

43

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


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


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


Conferências

▪▪ ▪▪ ▪▪ ▪▪ ▪▪

Mensagem “Alguns pedidos estão em análise há dois dias ou mais!”. Confirmar se o arquivo foi excluído. Confirmar exibição da lista de pedidos com dois dias em análise ao usuário. Confirmar e-mail para o Gerente de Vendas e de Crédito e Cobrança. Confirmar se e-mail possui lista de todos pedidos com dois dias em análise.

Quadro 6: Checklist para execução de testes

44


Na próxima seção você conhecerá modelos de relatório de teste segundo a IEEE 829. Siga em frente!

Seção 3

Relatório de teste segundo a IEEE 829 O líder do projeto deverá elaborar um relatório sobre os testes, ao final do projeto. Nesta seção você estudará alguns relatórios de teste definido pela norma IEEE 829. Estes documentos são:

▪▪ relatório de Log de teste; ▪▪ relatório de Incidentes de

teste;

▪▪ relatório de Sumário de teste. DICA Nas próximas páginas desta seção você estudará cada um desses relatórios.

Relatório de log de teste O log pode ser considerado como um diário de ocorrências da atividade de execução dos testes. O propósito básico é descrever tudo de relevante que ocorre durante o projeto de teste. Confira os itens que devem estar no log de teste:

▪▪ ▪▪ ▪▪ ▪▪ ▪▪ ▪▪

identificação; descrição; atividade e eventos; descrição da execução; resultados;

informação sobre o ambiente de teste;

▪▪ eventos imprevistos.

Exemplo:

▪▪ 28 de setembro de 2001. ▪▪ 10h: Nilton começou a testar

o módulo M do sistema L.

▪▪ 10h15: Nilton usou os dados de teste já existentes conforme o documento AAA. ▪▪ 10h30: ocorreu um cancelamento anormal que foi registrado no documento correspondente e encaminhado ao desenvolvimento. ▪▪ 10h40: Nilton interrompeu o

teste, pois está aguardando o parecer da área de desenvolvimento.

Relatório de incidentes de teste Qualquer ocorrência no projeto de teste que requeira algum tipo de investigação deverá ser registrada no relatório de incidentes. O uso mais comum deste relatório é quando você encontra um defeito ocorrido e tem que transmitir para a equipe de desenvolvimento, para que ela tome alguma providência. O relatório de incidente de teste deve ter o seguinte conteúdo básico:

▪▪ identificador do relatório -

deve ser único em todo o projeto ou processo de teste;

▪▪ sumário da ocorrência - des-

crever em detalhes o que estava sendo feito quando ocorreu o incidente;

▪▪ descrição do incidente - o IEEE sugere que você coloque na descrição os seguintes itens: entradas, resultados esperados, resultados encontrados, problemas, data e hora da ocorrência, sugestões de procedimentos a serem tomados, ambiente, tentativas de contornar o problema, testadores envolvidos e observadores.

Relatório de sumário de teste Neste relatório você deve apresentar as atividades de teste realizadas durante um determinado projeto e mostrar resumidamente as ocorrências durante todas as atividades. Este relatório costuma fechar o projeto de teste. A seguir conheça o conteúdo desse relatório.

▪▪ Identificador: código que

identifica o relatório. Deve ter uma referência ao projeto de teste em questão.

▪▪ Sumário: devem ser mostrados o escopo do trabalho e os documentos básicos usados no projeto, descrevendo resumidamente o trabalho de teste executado. ▪▪ Variações: se algum procedi-

mento foi feito de forma diferente do que está previsto no plano de teste, deve ser listado neste item.

▪▪ Avaliações do processo: qualquer ocorrência que possa causar impacto na qualidade do software liberado para a produção deve ser relatada. Por exemplo, se algum teste foi interrompido por falta de prazo. ▪▪ Sumário dos resultados: neste campo você deve colocar todos os parâmetros que possam quantificar o projeto de teste. Por exemplo, número de casos de teste, número de execuções de cada caso, número de defeitos encontrados etc. ▪▪ Avaliação do teste: você deve

avaliar o projeto de teste e verificar se alguns riscos ainda não resolvidos podem causar problemas no momento da produção.

TESTES DE SOFTWARE

45

▪▪ Sumário de atividades: neste sumário você deve listar as pessoas envolvidas no projeto de teste, o número de horas consumidas no projeto por atividade, tempo total consumido pelo projeto e outras informações relevantes. ▪▪ Aprovações: nome das pessoas responsáveis pela aprovação do

projeto de teste.

A partir do que você já estudou, percebeu a importância da sua dedicação para percorrer a trajetória de aprendizagem? Então, vamos em frente.

Seção 4

Gerenciamento de comunicação do projeto de teste De acordo com o PMBOK, o gerenciamento de comunicação de um projeto deve incluir os processos necessários para garantir a geração, a coleta, a disseminação, o armazenamento e o descarte de todas as informações do projeto. Assim, o gerenciamento de comunicação se divide nas seguintes atividades:

▪▪ ▪▪ ▪▪ ▪▪

planejamento das comunicações; distribuição das informações; relatório de desempenho; encerramento.

E cada uma dessas atividades tem o seguinte conteúdo:

▪▪ entradas; ▪▪ ferramentas e técnicas; ▪▪ saídas.

46


Figura 13: Gerenciamento de comunicações

Em resumo, você pode entender que:

▪▪ as entradas são todos os artefatos necessários para realizar a ativida-

de;

▪▪ as ferramentas e técnicas correspondem a tudo o que é feito sobre as entradas; ▪▪ as saídas correspondem ao resultado final da atividade. Com este assunto você encerra os estudos desta unidade. Porém, a busca por novos conhecimentos não acabou. Pesquise sobre os temas, converse com o professor, discuta com seus colegas, enfim, explore todas as oportunidades de aprendizagem. Agora prepare-se para uma nova jornada.

TESTES DE SOFTWARE

47

Unidade de estudo 7 Seções de estudo 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

Teste de aceitação Seção 1

Definição dos critérios de aceitação O teste de aceitação é de responsabilidade do usuário do software (teste beta). Segundo Bartié (2000, p. 157) “[...] é o último estágio do processo de validação. Trata-se do último processo formal de detecção de erros no sistema, antes de sua disponibilização no ambiente de produção. Nessa etapa, o software é disponibilizado para clientes e usuários com o objetivo de estes validarem todas as funcionalidades requisitadas no início do projeto. Os usuários terão a oportunidade de interagir com um sistema completo, exaustivamente testado pela equipe de testes.”

Esta validação não precisa ser feita apenas no final do processo. Ela pode acompanhar todo o desenvolvimento do projeto. Dessa forma é possível que o próprio usuário detecte problemas mais cedo, podendo negociar novos prazos. Para tanto, tá no início do projeto, quando são elaborados os requisitos, o usuário deve definir quais critérios serão utilizados para a aceitação do software. Ou seja, o que ele irá avaliar no momento do aceite. Normalmente, os requisitos a que o software deve atender podem ser divididos em três categorias:

▪▪ requisitos de funcionalida-

de: relatam as regras de negócio a que o software deverá obedecer;

▪▪ requisitos de performance:

retratam requisitos operacionais, como por exemplo, tempo de resposta, número de transações por hora e outras restrições que deverão ser cumpridas;

▪▪ requisitos de qualidade: definem atributos de confiança, testabilidade, correção e usabilidade etc. DICA A testabilidade indica o quão fácil é escrever os casos de teste para o software.

Você já ouviu falar em plano de aceitação? Vamos ver juntos o que a próxima seção reserva para a contuidade dos seus estudos!

Seção 2

Elaboração do plano de aceitação O plano de aceitação é um documento que define os passos necessários ao teste de aceitação, como estes testes devem ser feitos e diversos requisitos e responsabilidades.

O ideal é que o plano de aceitação seja escrito simultaneamente ao plano geral do projeto e à elaboração dos requisitos. O teste de aceitação vai depender da liberação do software pelos desenvolvedores e testadores. O plano do projeto deverá ter um cronograma de desenvolvimento e teste, para indicar quando os testes de aceitação terão início. O plano de aceitação deve conter as informações seguintes.

▪▪ Descrição do projeto: devem ser especificados o ambiente operacional e as interligações com outros software ou ambientes, além de incluir uma descrição detalhada do projeto, com suas fases e a metodologia utilizada no desenvolvimento. ▪▪ Responsabilidades dos usuários: definir as atividades que os usuários devem fazer durante os testes. Deve incluir sua participação nas etapas do projeto. ▪▪ Procedimentos administrativos: incluir todos os relatórios gerados durante o trabalho de teste. Identificar as áreas envolvidas. Definir critérios de comunicação entre as partes envolvidas. ▪▪ Requisitos cobertos: iden-

tificar a lista dos requisitos que serão cobertos pelos testes de aceitação.

▪▪ Responsável pela elaboração: nomear o responsável pela elaboração do plano. TESTES DE SOFTWARE

49

Agora que você já sabe o que é um plano de aceitaçao, assim como as informações que ele deve conter, que tal aprender a executá-lo? Siga em frente!

Seção 3

Execução do teste de aceitação Os testes de aceitação são executados sobre os produtos entregues durante o ciclo de vida do processo de desenvolvimento. Esses testes serão as últimas oportunidades do usuário para verificar se o produto que encomendou à equipe de desenvolvimento é de fato o produto que lhe está sendo entregue. Assim, você pode empregar o aceite como uma estratégia para reduzir riscos de uma implantação maciça, na qual um erro vital não detectado pode comprometer a imagem da solução como um todo. Os testes de aceitação podem ser divididos em três partes: aceite formal, alpha – teste e o beta – teste. Confira!

Figura 14: Estágios do processo de aceite de um software.

▪▪ Aceite formal: nesta parte do teste de aceitação, os clientes planejam e realizam os testes. É muito utilizado em projetos desenvolvidos para atender a um grupo de empresas, possibilitando a criação de um comitê que atestará a aderência do software às necessidades do grupo. Assim, o processo de aceitação torna-se uma continuação natural dos testes funcionais do sistema. ▪▪ Alpha – teste: o objetivo deste teste é permitir que o usuário atue naturalmente no software, de forma a encontrar defeitos em alguns procedimentos implantados. Para isso, você deve convidar os clientes a operar o software em um ambiente localizado na empresa criadora do software. Neste teste não há formalidades quanto à validação, mas é importante criar um conjunto reduzido de procedimentos. Pode ser que os clientes não sigam completamente estes procedimentos, mas eles funcionarão como um checklist do aceite. ▪▪ Beta – teste: neste tipo de teste de aceitação é feita uma implan-

tação em paralelo. Os clientes vão operar o produto utilizando suas próprias instalações físicas para que o software seja utilizado no ambiente real do dia-a-dia. Você não deve confundir o Beta – teste com a implantação definitiva.

50


Este teste pode ocorrer até que o cliente se sinta seguro em realizar a mudança de aplicativo e durante toda a sua execução, ele contará com o apoio da empresa. Dessa forma a imagem do produto e da empresa não será prejudicada. Agora, você já sabe por que alguns sistemas na internet possuem a palavra “beta”, pequenininha, junto com o nome do sistema. A etapa que trata de “Todos os clientes” indica que o software será implantado definitivamente. Se todas as fases do processo de teste foram bem planejadas e executadas, nesta etapa o software estará atendendo corretamente todos os requisitos funcionais e estruturais indicados pelo cliente. Confira o que preparamos para você na próxima unidade de estudos!

TESTES DE SOFTWARE

51

Unidade de estudo 8 Seções de estudo Seção 1 – Análise do ponto de teste Seção 2 – Estimativa baseada no tamanho e complexidade do caso de uso

Estimativas Seção 1

Análise do ponto de teste Segundo Bastos et al (2007, p. 243), a análise de ponto de teste (APT), é uma técnica de medição de projetos de teste de software.

DICA Lembre - se que toda técnica de medição e estimativa deve levar em consideração o ambiente onde está sendo usada.

Você nunca deve esperar obter resultados exatos na primeira vez que empregar esta análise. Mas com o tempo e o ajuste do modelo, a tendência é que os resultados ficarão cada vez mais precisos. O objetivo da APT é determinar o tempo necessário à etapa de testes. Esta técnica leva em consideração o tamanho do sistema a ser testado a partir das informações coletadas com as equipes de desenvolvimento. Os testes também são afetados pelos seguintes fatores:

▪▪ a qualidade do sistema testado

(o ciclo de reincidência de defeitos);

▪▪ o nível de cobertura esperado com os testes; ▪▪ a experiência e a produtividade da equipe de teste (medidos por meio de indicadores históricos);

Saiba mais sobre análise de ponto de teste em: http://www.testexpert.com. br/?q=taxonomy/term/8 http://qualidadebr.wordpress.com/2009/11/22/estimativa-de-testes-apt/.

▪▪ o grau de automação dos testes; ▪▪ a qualidade do ambiente de

teste, até mesmo a sua capacidade de simular o ambiente de produção;

▪▪ a qualidade da documentação

do sistema e, especialmente dos requisitos. A figura a seguir mostra as etapas necessárias para se chegar ao tamanho do sistema em pontos de teste. Veja!

▪▪ o grau de complexidade do processo de teste; ▪▪ o nível de qualidade que se

pretende alcançar com os testes;

▪▪ o grau de envolvimento dos usuários com os testes; ▪▪ as interfaces que são as

funções testadas têm com os arquivos; Figura 15: Visão geral da Análise de Pontos de Teste.

TESTES DE SOFTWARE

53

Seção 2

Estimativa baseada no tamanho e complexidade do caso de uso De acordo com Bastos et al (2007, p. 246) este tipo de estimativa é simples e necessita de pouco conhecimento em cálculos. Ela utiliza as seguintes entradas:

▪▪ ▪▪ ▪▪ ▪▪

contagem do número de fluxos de um determinado caso de uso; média de passos de cada fluxo (passo do ator e reação do sistema); contagem do número de exceções;

contagem das regras de negócios, classificadas como simples, médias e complexas. Você deve calcular o esforço de teste combinando a complexidade e o tamanho do caso de uso. Por exemplo, quanto tempo é necessário para testar um caso de uso pequeno e de complexidade simples? Esse valor de tempo deve ser corrigido periodicamente (histórico associado à experiência e à maturidade da equipe de teste). Quando existem pessoas com diferentes níveis de experiência, você pode atribuir um fator de correção. Veja a tabela a seguir. Tamanho

Complexidade

Horas

Pequeno

Simples

6

Pequeno

Média

8

Pequeno Médio Médio Médio

Complexa Simples Média Complexa

10 8 12 16

Grande Grande Grande Muito grande Muito grande

Simples Média Complexa Simples Média

12 18 20 16 20

Muito grande

Complexa

28

Tabela 1: Esforço de teste em horas

54


A complexidade deve ser informada pela área de negócio, responsável pela elaboração do caso de uso. Esse valor em horas (complexidade/tamanho) deve ser dividido pelas diferentes fases do ciclo de teste (elaboração, execução, reteste etc). Bastos et al (2007, p. 249) cita os seguintes valores:

▪▪ planejamento + projeto de teste = 35% do tempo total; ▪▪ execução do teste = 60%; ▪▪ 5% restante destinado para o reteste e a conclusão do teste. É importante que você saiba que estes valores podem variar muito de um caso para outro. Eles não são valores fixos, precisam de um ajuste gradativo. E as técnicas, apesar de sólidas, devem ser aplicadas com cuidado, principalmente na hora de transformar tamanho em esforço.

Estamos falando de estimativas, então nada é completamente preciso. Ou seja, é necessário que você entenda que esta análise deve ser aplicada, mas não espere que na primeira vez o resultado será perfeito. Você precisará fazer a análise novamente para o mesmo sistema e para sistemas diferentes, até que a sua prática e conhecimento na área consiga chegar em um valor bastante aproximado da realidade. Neste caso, não se preocupe em acertar da primeira vez. Preocupe- se sim, em continuar melhorando a cada dia.

TESTES DE SOFTWARE

55

Finalizando Parabéns, você chegou ao final de mais uma etapa! Agora você já sabe da importância da busca pela qualidade de software. Também sabe que para atingir a qualidade, é necessário utilizar uma metodologia adequada e principalmente, dentro dessa metodologia, como um processo. Ou seja, deve acompanhar o desenvolvimento desde o início até quando o sistema está rodando na versão beta. Tipos e técnicas existem aos montes para você escolher. É importante que você saiba distinguir o que é melhor para o sistema que está sendo desenvolvido. Lembre-se que testar custa dinheiro e corrigir problemas também. Principalmente se estes problemas são encontrados lá no final do ciclo de vida do desenvolvimento. Então você precisa equilibrar a quantidade de testes com os riscos existentes. Testar o programa do mercado do Seu Zé é diferente de testar o programa de gerenciamento de recursos de um hospital. Lembre- se: você está destinado a ser um ótimo profissional, mas para isso precisa estar preparado em todos os campos. Ser um bom desenvolvedor de software não é apenas fazer um software que funcione. E sim é fazer um software que seja fácil de testar, fácil de se fazer manutenção e que possa ser adaptado à várias condições de uso.

TESTES DE SOFTWARE

57

Referências ▪▪

AGAPITO, Robson. Estimativas de teste. 01 mar. 2010. Disponível em: . Acesso em: 31 out. 2010.

▪▪

BARTIÉ, Alexandre. Garantia da qualidade de software. Rio de Janeiro, RJ: Campus, 2002. ISBN 8535211241.

▪▪

BASTOS, Aderson et al. Base de conhecimento em teste de software. 2. ed. rev. São Paulo, SP: Martins, 2007. 263 p. ISBN 9788599102893.

▪▪

CAMPOS, Fabricio F. de. Estimativa de teste (APT). 22 nov. 2009. Disponível em: . Acesso em: 31 out. 2010.

▪▪

PALMA, Fernando F. O processo de teste de software. 20 out. 2009. Disponível em: . Acesso em: 31 out. 2010.

▪▪

RIOS, Emerson. Gerência do projeto de testes segundo o modelo PMI. 01 out. 2007. Disponível em: . Acesso em: 31 out. 2010.

▪▪

RIOS, Emerson; MOREIRA FILHO, Trayahú R. Teste de software. 2. ed. rev. e ampl. Rio de Janeiro, RJ: Alta Books, c2006. 222 p. ISBN 8576081288.

▪▪

SILVA Filho, Antonio M. da. Componentes de software: componentização no desenvolvimento de software. Ago 2008. Disponível em: . Acesso em: 31 out. 2010.

▪▪

SOMMERVILLE, Ian. Engenharia de software. 8. ed. São Paulo, SP: Addison-Wesley, 2007. xiv, 552 p. ISBN 9788588639287.

TESTES DE SOFTWARE

59

Equipe de Desenvolvimento de Recursos Didáticos Coordenação de Educação a Distância Beth Schirmer Coordenação Projetos EaD Maristela de Lourdes Alves Coordenação de Desenvolvimento de Recursos Didáticos Gisele Umbelino Projeto Educacional Angela Maria Mendes Israel Braglia Projeto Gráfico Daniela de Oliveira Costa Jordana Paula Schulka Juliana Vieira de Lima

Design Educacional Gisele Umbelino Capa, Ilustrações, Tratamento de Imagens D’imitre Camargo Martins Diego Fernandes Luiz Eduardo Meneghel Diagramação Daniela de Oliveira Costa Revisão e Fechamento de Arquivos Daniela de Oliveira Costa Juliana Vieira de Lima Revisão Ortográfica e Normatização FabriCO

Testes Software curso técnico em informatica

Recommend Documents