Baixe o app para aproveitar ainda mais
Prévia do material em texto
Testes de Software 1 Testes de Software Prof. José Macedo dos Santos Testes de Software 2 Apresentação 3 Fundamentos de Teste de Software 4 A Busca pela Qualidade 4 Defeitos, Falhas e Erros 4 Fundamentos de Teste de Software 6 Estratégias de Teste 7 Técnicas de Teste 10 Caixa Branca ou Caixa de Vidro 10 Caixa Preta 10 Regressão 11 Outros Tipos de Testes 12 Exercícios do Capítulo 1 14 Automação de Testes 15 Importância dos Testes de Software 15 Ciclo de Vida de Testes de Software 17 Procedimentos Iniciais 18 Planejamento 18 Preparação 18 Especificação 18 Execução 18 Entrega 19 Testes Automatizados 19 Testes manuais ou não automatizados 20 Implementação dos Testes 22 Ambiente de Testes Automatizados 25 Quando executar os testes automatizados 25 Documentação de Teste de software 26 Exercícios do Capítulo 2 28 Testes em Modelagem Ágil 29 Modelos Ágeis e Testes de Software 29 Teste de software no Scrum 30 O analista de testes no Scrum 31 Tipos de Testes Usados na Modelagem Ágil 33 Ferramentas de Testes em Métodos Ágeis 34 TDD – Test-Driven Development 36 Exercícios do Capítulo 3 39 Organizações Envolvidas com Testes de Software no Brasil 40 BSTQB 40 ALATS 41 Normas e Padrões em Testes e Qualidade de Software 42 Exercícios do Capítulo 4 46 Considerações Finais 47 Referências 47 Respostas Comentadas dos Exercícios 49 Capítulo 1 49 Capítulo 2 49 Capítulo 3 50 Sumário Testes de Software 3 Capítulo 4 51 Outros Tipos de Testes de Software - Glossário 51 Testes de Software 4 Apresentação Desde o início do que conhecemos como a Era da In- formação, os profissionais envolvidos com tecnologia enfrentam sérios desafios. Um destes desafios está rela- cionado com a qualidade dos aplicativos desenvolvidos. A grande maioria dos produtos eletrônicos que adquiri- mos hoje possui softwares embarcados que garantem o funcionamento adequado do produto dentro dos padrões exigidos. Agora imagine se um fabricante desses produtos detecta uma grave falha e faz um recall (chamada para re- paração de erros), como estamos acostumados a ver nas montadoras de veículos? Que situação complicada, não? Não é difícil imaginarmos uma falha de software e uma eventual manutenção para regularizar o acerto em um ambiente corporativo no qual há uma equipe dedicada ao desenvolvimento. Mas quando contratamos uma equipe externa ou quando temos estes softwares instalados em ambientes remotos, a situação torna-se muito mais com- plexa. Esta situação atípica apresenta uma necessidade cada vez maior de qualidade de desenvolvimento. Consideran- do que é quase impossível se desenvolver um software perfeito, surge a única alternativa para enfrentar estes desafios: os testes de software. Os testes têm como ob- jetivo eliminar as possíveis falhas de programação e atuar no software de forma a deixá-lo adequado ao negócio que vai atender. Há uma grande necessidade hoje de se discutir os di- versos aspectos que envolvem esta atividade. Comitês já foram criados para padronizar as técnicas adequadas visando identificar as principais causas de defeitos, erros e falhas no desenvolvimento de softwares. Atualmente a globalização e o uso cada vez maior de equipamentos que necessitam de softwares embarcados, obrigam seus desenvolvedores a investir em qualidade. E testar, certa- mente, é a melhor ferramenta para garanti-la. Testar um software pode ser definido de forma sim- ples como a execução de um software em um ambiente controlado e acompanhar seu desempenho para saber se está dentro do esperado ou especificado. Pensar em teste de software nos remete, normalmen- te, para a avaliação das linhas de código para encontrar falhas. Mas não se engane, testar um software tem um objetivo muito mais amplo. O software precisa gerar o re- sultado esperado, então testá-lo envolve analisar tudo o que ele fornece de resposta e sua devida veracidade. Tes- tar um software envolve planejar e controlar a aplicação, além de validar seus resultados. O principal objetivo sem- pre será a busca de qualidade. E entender estes conceitos pode significar a quebra de alguns paradigmas. Caro aluno, proponho que para percorrer o caminho proposto por esta disciplina você esteja aberto a mudan- ças, entendendo a necessidade do planejamento, ge- renciamento e análise do resultado para finalmente nos aproximarmos do sucesso de um desenvolvimento que contribuirá para o sucesso do negócio. José Macedo dos Santos Testes de Software 5 Fundamentos de Teste de Software A Busca pela Qualidade Caro aluno, meditemos um pouco na nossa constan- te busca pela perfeição. Estamos acostumados a valorizar nossos bens que possuem qualidade e desprezar aqueles que por algum motivo não apresentam a qualidade dese- jada. Um carro que quase nunca quebra, por exemplo, é extremamente valorizado, enquanto outro que sempre dá alguma manutenção é descartado o mais breve possível. Se nós estamos acostumados a agir desta forma com nossos bens, porque seria diferente no ambiente corpora- tivo? O mesmo conceito que adotamos com nossos bens pessoais, adotamos para os bens que administramos na corporação. Portanto sempre iremos valorizar aquele hardware ou software que quase nunca dá problema em detrimento daquele que sempre dá alguma manutenção. É lógico então concluir que o sucesso do negócio pode estar ligado à qualidade que os softwares corporativos de- monstram ter, enquanto que o contrário também é lógico, seu negócio pode correr grandes riscos se os softwares não possuem a qualidade desejada. Enfrentamos então o desafio de desenvolver softwa- res que possuem a qualidade esperada e necessária para colaborar com o sucesso do negócio. Afinal, quando se contrata o serviço de desenvolvimento, espera-se sempre o melhor. Mas, mesmo parecendo tão lógica esta questão, por que enfrentamos tantos problemas com a qualidade dos softwares desenvolvidos? Muitos poderiam ser os moti- vos para acirrarmos uma discussão a respeito, mas nos propomos aqui, não a discutirmos as causas da baixa qua- lidade de desenvolvimento, mas técnicas que podem aju- dar a buscar a qualidade dos softwares. Você já ouviu alguma vez a frase: “Ando devagar por- que tenho pressa”? Não raro, a pressa é a principal ini- miga da qualidade. Mas também é ilusório dizer que um prazo dilatado é sinônimo de qualidade para um desen- volvimento. Na verdade, prazo dilatado quase nunca é uma opção para a maioria dos desenvolvimentos. Então somos obrigados a concluir o fato que se impõe no mun- do globalizado: qualidade e velocidade sempre. A aplicação de técnicas de testes de softwares pode conter a ajuda necessária para aproximar os produtos da necessidade imposta pelo mercado. Proponho então que consideremos com atenção os conceitos, quebrando paradigmas e nos ajustando a téc- nicas necessárias para melhorarmos a qualidade no de- senvolvimento de softwares. Defeitos, Falhas e Erros Para começarmos, precisamos entender a diferença entre defeito, falha e erro (veja figura 1). • Defeito: Ocorre quando há uma instrução ou co- mando incorreto. Um veículo, por exemplo, apre- senta defeito quando não obedece ao comando do motorista. Testes de Software 6 • Falha: É um comportamento inconsistente. Em um veículo, por exemplo, quando ocorre uma falha, ele conti- nua funcionando de forma precária, mas não para. • Erro: É um desvio da especificação. Em um veículo, por exemplo, é quando ocorre uma montagem indevida de algum componente. Por que é importante termos bem definidas estas dife- renças? Considere a seguinte frase: “A melhor maneira de tentar construir a confiança é tentar destruí-la”.Parece um paradoxo, concorda? Pois saiba que não apenas parece, é um paradoxo. Na tentativa de destruir a confiança por encontrar de- feitos, falhas ou erros, na verdade estamos construindo uma confiança cada vez mais sólida no produto desenvol- vido. Pense, por exemplo, nos exaustivos testes automo- bilísticos, quando as montadoras literalmente destroem seus veículos para provar a qualidade de seus bens pro- duzidos (veja figura 2). Não concorda que estão provando com isso a segurança que você espera em um momento crítico, como um acidente numa estrada em alta veloci- dade? Figura 1 – Defeito, Falha e Erro Os projetos podem ter uma grande complexidade, en- tão entendemos claramente que será impossível que eles não possuam alguns defeitos, principalmente porque em um grande projeto temos várias cabeças pensantes, com Figura 2 - Test Crash Fonte: http://just4x4sales.com.au/images/crash%20test.jpg Testes de Software 7 formação e lógica diferentes, trabalhando juntos para atingir os objetivos. Vários poderiam ser os motivos para alegar a impossi- bilidade de um software sem qualquer tipo de erro, falha ou defeito, mas não queremos contribuir nem para a bus- ca da perfeição, que não existe, e nem para o relaxamento relacionado à inexistência de perfeição. Hoje não podemos falar de qualidade de software sem falar de desenvolvimento ágil, que tem sido considerado um conceito avançado de desenvolvimento e busca na eli- minação de erros, falhas e defeitos. Caro aluno, para melhor compreensão e acompanha- mento, as definições que abordaremos seguem a termi- nologia padrão para Engenharia de Software do Institute of Electrical and Electronics Engineers (IEEE ,1990). Qualidade, Confiabilidade, Usabilidade, Eficiência, Ma- nutenibilidade e Portabilidade são atributos buscados in- cansavelmente no desenvolvimento de software e o que nos propomos a fazer na consideração deste assunto é como o testador pode contribuir para esta busca quase que inalcançável. O processo de testes é efetivo quando encontra defei- tos e é eficiente quando encontra os defeitos com a me- nor quantidade de recursos possível. Fundamentos de Teste de Software De acordo com Pressman (2010), um software é testa- do para descobrir erros que foram introduzidos inadver- tidamente no momento em que o software foi projetado e construído. Teste é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Um gabarito de testes de software, que é um conjunto de passos no qual podem-se incluir técnicas de projetos de casos de teste e métodos de teste específicos, deve ser definido para o processo de software sendo utilizado no projeto. Fonte: [PRESSMAN, 2010] O autor lista um conjunto de perguntas e respostas que apresentam os principais fundamentos que embasam os testes de software, quais sejam: • Quem faz? O gerente do projeto, os engenheiros de software e especialistas em testes devem desen- volver uma estratégia de testes, de forma a que o projeto tenha um plano formal de testes. • Porque é importante? O teste é a atividade que requer maior esforço de projeto dentro do ciclo de desenvolvimento de software. Se for conduzido ao acaso pode implicar em desperdício de tempo e esforço, além de abrir espaço para a infiltração de erros. Assim, é muito importante que se estabeleça uma estratégia sistemática para o teste de softwa- re. • Quais são os passos? O teste começa nos compo- nentes do software e vai aumentando seu campo de ação de forma a abarcar todo o projeto. Depois que os componentes são testados eles precisam ser integrados até que todo o sistema seja construí- do. A partir deste ponto uma série de testes de alto nível é executada para descobrir erros relativos aos requisitos do cliente. À medida que erros forem en- contrados, é necessário se fazer um diagnóstico e buscar sua correção, através do processo de depu- ração do sistema. Testes de Software 8 • O que é uma especificação de testes? É um do- cumento que relata a abordagem da equipe que realiza os testes, definindo um plano que descreve a estratégia global e um procedimento que define os passos específicos dos testes, bem como quais testes serão realizados. • Como ter certeza que os testes foram feitos cor- retamente? Para se certificar da corretude do teste deve-se realizar uma revisão na especificação do teste antes de realizá-lo, de forma a avaliar a com- pleteza dos casos e das tarefas elencadas. Um pla- no e procedimento de testes efetivos vão levar à construção coordenada do software e à descoberta de erros em cada fase da construção do projeto. Estratégias de Teste De acordo com RUP (2001), uma estratégia para o tes- te de um projeto descreve a abordagem geral e os obje- tivos das atividades de teste. Inclui os estágios de teste (unidade, integração e sistema) que devem ser abordados e os tipos de teste (de função, desempenho, carga, stress, etc.) que devem ser executados. A estratégia deve definir: 9 As ferramentas e técnicas de teste a serem em- pregadas. 9 Os critérios de conclusão e êxito do teste a se- rem usados. Uma estratégia de testes de software integra métodos de projeto de casos de teste em uma série bem planejada de passos que resultam na construção bem sucedida de software. A estra- tégia fornece um roteiro que descreve os passos a serem conduzidos como parte do teste, quan- do esses passos são planejados e depois execu- tados, e quanto de esforço, tempo e recursos serão necessários. Fonte: [PRESSMAN, 2010] Além de enfatizar a importância da estratégia de tes- tes, Pressman (2010) afirma que esta deve ser suficien- temente flexível para criar uma abordagem de teste sob medida para o projeto em desenvolvimento, mas ao mes- mo tempo ser rígida para promover um planejamento adequado e permitir um acompanhamento gerencial à medida em que o projeto progride. O plano de teste deve definir conjuntos de critérios de conclusão para os testes unitário, de integração e de sistema. Pode haver diferentes conjuntos de critérios de conclusão definidos para iterações individuais. Uma estratégia para testes de software pode ser vista no contexto da espiral mostrada na figura 3. O teste de unidade começa no centro da espiral e se concentra em cada componente (trecho de código fonte) do software. O teste progride movendo-se para fora, ao longo da espiral, indo para o teste de integração, que foca no projeto e na construção da arquitetura do software. Seguindo a espiral, para fora, há o teste de validação, no qual os requisitos são validados, ou seja, a especificação dos requisitos é confrontada com o software que acabou de ser construído. Finalmente chega-se ao teste de siste- ma, em que os outros elementos do software são testa- dos como um todo. Testes de Software 9 Sommerville (2007) e Pressman (2010) descrevem, de forma complementar, estes estágios de teste da seguinte forma: • Teste de unidade: é também conhecido como teste unitário. Avalia a menor unidade do código. Seu objetivo é verificar falhas de funcionamento em partes pequenas independentes do software. Possibilita uma análise mais profunda e específica de uma função independente do resto do código, facilitando a descoberta de erros nos limites dos módulos. Este teste tem como base estratégica o teste de caixa branca. Neste teste, os casos são pro- jetados para descobrir erros devido a computações errôneas, comparações incorretas ou fluxo de con- trole impróprio. • Teste de integração: avalia diferentes componen- tes que são desenvolvidos separadamente mas tra- balham em conjunto. Ao avaliar estes componentes de forma isolada,consegue-se encontrar possíveis falhas no resultado apresentado em consequência do mal funcionamento ou erro de algum dos com- ponentes. • Teste de validação: avalia o software em um am- biente específico, considerando os requisitos defi- nidos pelo cliente em uma situação próxima à rea- lidade. Tem como objetivo provar ao cliente que o software atende as solicitações desejadas. • Teste de sistema: este teste tenta impor a visão do cliente, dando normalmente uma perspectiva diferente ao testador. Normalmente executa-se em um ambiente que se assemelha ao ideal. Seu obje- tivo é por o sistema desenvolvido completamente à prova, com todos os elementos adequadamente integrados e realizando suas funções corretamen- te. Em testes de sistemas encontramos pelo menos 4 tipos de testes: o Teste de Recuperação: este procedimen- to avalia a recuperação de uma falha dentro de um tempo especificado em caso de falha. Neste teste, podem ocorrem várias falhas forçadas para verificar a recuperação. Figura 3 - Espiral de Estratégia de Testes Testes de Software 10 o Teste de Segurança: neste caso o testa- dor tenta penetrar no sistema provocando ações que prejudiquem alguém. Ele usa for- mas ilegais ou impróprias simulando condi- ções extremas de violação das informações. o Teste de Estresse: este procedimento cria ambientes extremos para utilização do software. Volumes anormais e frequência ir- regular têm como objetivo forçar falhas por sobrecarga, verificando as possíveis interrup- ções e consequências de paradas anormais por estresse. Os dados, então, são avaliados para ver se não forram corrompidos ou per- didos. o Teste de Desempenho: todo sistema de- senvolvido tem em suas especificação de requisitos o desempenho adequado de fun- cionamento e após a integração dos compo- nentes uma avaliação é indispensável para se obter o seu desempenho real. De acordo com Pressman (2010), do ponto de vista procedimental, o teste no contexto da Engenharia de Sof- tware é uma série de 4 passos que são implementados sequencialmente, conforme mostra a figura 4. Figura 4 - Passos de Teste de Software Testes de Software 11 Inicialmente o teste focaliza cada componente indivi- dualmente, garantindo que ele funcione adequadamente como uma unidade. Em seguida os componentes devem ser montados ou integrados para formar um pacote de software completo. Depois que o software tiver sido in- tegrado um conjunto de testes de alto nível é conduzido, de forma que critérios de validação de requisitos sejam avaliados. O último passo avança para fora dos limites da Engenharia de Software indo em direção ao sistema de computação. O teste de sistema verifica se todos os ele- mentos estão ajustados de forma que a função e o de- sempenho global do sistema sejam alcançados. Técnicas de Teste Caro aluno, se testar é determinar se o objetivo está sendo alcançado, precisamos obrigatoriamente conhecer as técnicas envolvidas. Várias técnicas já existem e outras estão sendo criadas ou aperfeiçoadas de acordo com a necessidade que surge. Em Engenharia de Software encontramos algumas téc- nicas básicas que atualmente estão em prática no merca- do e que é importante conhecermos, pois poderão servir de referência para o desenvolvimento ou aprimoramento de técnicas, são elas: • Caixa Branca • Caixa Preta • Regressão Consideremos mais detalhadamente estas técnicas nas seções a seguir. Caixa Branca ou Caixa de Vidro O teste Caixa Branca possui critérios baseados em Fluxo de Controle e em Fluxo de Dados, portanto avalia a parte estrutural do software. Aplicamos esta prática di- retamente no código do programa, fazendo teste lógico e comportamental. Analisam-se o fluxo de dados e os códi- gos, usados ou não. De acordo com Myers (2004), a técnica de teste de cai- xa branca é conhecida por vários nomes tais como teste estrutural e teste de caixa de vidro. O engenheiro de sis- tema realiza o teste direto no código fonte do software. São determinados os dados de entrada para analisar a ló- gica do software. Lewis e Veerapillai (2005) afirmam que a desvantagem desta técnica está no fato de que não se analisa a especificação, concentrando apenas no código fonte e não se verifica a lógica da especificação. Segundo Pressman (2010) os principais testes de Caixa Branca são: • Teste de caminho básico: determina o conjunto básico de caminhos para a execução dos testes. • Teste de Condição: todas as condições lógicas contidas no código são testadas e avaliadas. É co- mum se deparar com erros de lógica booleana, erro de operadores e de expressões aritméticas. • Teste de fluxo de dados: localiza as variáveis do programa e verifica suas definições. Esta técnica é mais complexa que as outras, portanto exige maior competência na implantação. • Teste de Laços: em todos os laços definidos no programa ocorrerá alguma validação. Caixa Preta O nome Caixa Preta (Black Box) vem do sentido de que nesse tipo de teste não é necessário saber a estru- tura interna, bem como o código ou a tecnologia que foi utilizada. Nesse tipo de análise essas questões são trans- parentes para os analistas de teste. Para que se crie um projeto de teste bem sucedido é necessário usar a técnica de caixa preta junto com o de caixa branca, isto é, deve-se analisar, também, a estrutura interna da aplicação. De acordo com Myers (2004) esta técnica avalia o sof- tware conforme as entradas e saídas. Aplica-se externa- mente no software sem considerar o funcionamento in- terno do mesmo. Os dados de entrada são fornecidos ao Testes de Software 12 sistema que os processa e devolve uma saída previamen- te conhecida pelo testador. Os resultados são compara- dos para validar a efetividade da funcionalidade testada. Este tipo de técnica é baseada na especificação funcional e é recomendada para todas as fases de teste, unitário, integração, sistema e aceitação. Este tipo de teste é particularmente útil para revelar problemas, tais como: 9 funções incorretas ou omitidas; 9 erros de interface; 9 erros de comportamento ou desempenho e 9 erros de iniciação e término. As maratonas de programação geralmente utilizam o teste de caixa preta. Os participantes recebem uma especifica- ção do software a ser desenvolvido e pontuam quando o programa entregue passa pelos testes produzindo as saídas esperadas de acordo com as entradas dadas. Veja: http://www.youtube.com/watch?v=7TrldtG_wWI Segundo Lewis e Veerapillai (2005), e complementado por Pressman (2010), os principais testes de caixa preta são: • Particionamento de equivalência: o programa é dividido em classes, que são testadas com o obje- tivo de eliminar redundâncias ou de se descobrir classes com erros. • Análise de valor limite: nos limites é que encon- tramos a maior parte dos erros, então o testador extrapola os valores suportados pelo sistema para forçar uma situação extrema com o objetivo claro de encontrar erros. • Técnicas de grafo de causa-efeito: servem para oferecer uma representação concisa das condições lógicas e respectivas ações. A técnica compreende 4 passos: 1. causas (condições de entrada) e efeitos (ações) são relacionados em um módulo e atribui-se um identificador para cada; 2. um grafo de causa e efeito é desenvolvi- do; 3. o grafo é convertido em uma tabela de decisão; 4. as regras e tabelas de decisão são conver- tidas em casos de testes. Analista de Teste, Analista de Design ou Testador (Tester) são nomes utilizados para o profissional que identifica os itens de teste-alvo a serem avaliados pelo esforço de teste, define os testes apropriados necessários e quaisquer dados de teste associados,coleta e gerencia os dados de teste e avalia o resultado de cada ciclo de testes. Fonte: BSTQB (Brazilian Software Testing Quali- fications Board) Regressão Na Psicologia, a regressão faz o paciente voltar ao pas- sado avaliando acontecimentos e aprendendo com os er- ros ou acertos obtidos. Pois bem, no método de Regres- são em testes de softwares vamos encontrar o objetivo de avaliar todas as experiências em testes do passado, e a cada nova versão disponibilizada executam-se os testes já realizados anteriormente e que apresentaram sucesso. Pressman (2010) afirma que como o método atua de modo a confirmar a eficiência já obtida em testes realiza- dos em versões anteriores, este tipo de teste é mais rápi- do. Muito embora não seja um método infalível, em vir- tude de mudanças impactantes que possam ter ocorrido no desenvolvimento de uma nova versão, demonstra ser relativamente prático e eficiente. Quando a aplicação é crítica, o testador pode sugerir um novo desenvolvimento e não apenas uma atualização. Testes de Software 13 Outros Tipos de Testes • Caixa Cinza: uma combinação entre teste caixa preta e teste caixa branca. Consiste em analisar a parte lógica mais a funcionalidade do sistema, com- parando o que foi realizado com as especificações previamente estabelecidas. De acordo com Lewis e Veerapillai (2005), o testador, neste método, comu- nica-se com o desenvolvedor para em comum acor- do entender e otimizar o sistema. Esta técnica pode incluir também o uso de engenharia reversa para determinar por exemplo, os limites superiores e in- feriores das classes, além de mensagens de erro. • Teste ad hoc: teste realizado informalmente. Não ocorre preparação formal, não são usadas técnicas reconhecidas de projeto de teste, não há expectati- va para resultados e a arbitrariedade guia a ativida- de da execução do teste. • Teste ágil: prática de teste para projetos que usam metodologias ágeis, como por exemplo, o Extreme Programming (XP), que trata o desenvolvimento como cliente do teste e enfatiza o paradigma de testar antes. Caro aluno, o anexo 1 traz diversos outros tipos de tes- tes existentes no mercado. Confira! Leia mais no artigo da revista Engenharia de Software - Introdução à Teste de Software Disponível em: http://www.devmedia.com.br/artigo- -engenharia-de-software-introducao-a-teste-de-softwa- re/8035#ixzz27Pk4sNNA Testes de Software 14 Prezado aluno, neste ponto, proponho que faça um exercício simples para que possa perceber que para se identificar erros, mesmo em um quadro simples, requer certa con- centração e disposição. Se isto ocorre com uma simples imagem duplicada com alguns erros, imagine um software com milhares de linhas de código. Testes de Software 15 Exercícios do Capítulo 1 1 – Testes são divididos em tipos de testes distintos principalmente porque: a) Cada estágio de teste tem um propósito diferente. b) Podem ser executados testes diferentes em ambientes diferentes. c) É mais fácil lidar com testes em estágios. d) Quanto mais estágios, melhor o teste. e) Ainda não foram desenvolvidos tipos específicos para alguns processos de desenvolvimento. 2 – Um importante benefício de inspeção de códigos é: a) É barato. b) Permite que o código seja testado antes que o ambiente de execução esteja pronto. c) Pode ser feita pelo desenvolvedor somente. d) Ajuda a confirmar a capacidade de desenvolvimento. e) Colabora com a rentabilidade do projeto. 3 – Uma falha: a) Ocorre quando há uma instrução ou comando incorreto. b) É um desvio de especificação. c) É um comportamento inconsistente. d) É uma informação inadequada fornecida. e) Nenhuma das anteriores. 4 – O teste tipo caixa cinza, se refere a: a) Um tipo de teste efetuado com os componentes físicos. b) Um teste de ação retardada, em que o resultado só aparece a médio ou longo prazo. c) Uma referencia a um teste ineficiente. d) Uma combinação entre teste caixa preta e teste caixa branca. e) Um teste de integridade. 5 – Este teste possui critérios baseados em Fluxo de Controle e em Fluxo de Dados, portanto avalia a parte estrutural do software. a) Teste caixa preta. b) Teste caixa cinza. c) Teste ad hoc. d) Teste ágil. e) Teste caixa branca. Testes de Software 16 Automação de Testes Importância dos Testes de Software Caro aluno considere novamente a analogia que fize- mos sobre os recalls que montadoras eventualmente fa- zem. Seria correto afirmarmos que, se uma montadora ad- mite em um recall uma falha em seu carro ou projeto, ela deva ser considerada incompetente ou seu produto ser um péssimo negócio para seus clientes? Com certeza nos sentiremos traídos se uma falha for detectada e escondida para supostamente não denegrir a imagem da empresa. Na verdade esta imagem certa- mente se denegriria se a empresa não tomasse a atitude de admitir o erro, assumir a responsabilidade e corrigir a falha detectada. Então, podemos concluir apropriadamente que encon- trar um erro, uma falha ou mesmo um defeito em um sof- tware desenvolvido, não vai necessariamente expor uma incompetência. Na verdade, como já dissemos, estranha- ríamos muito se não fosse encontrado qualquer proble- ma em um software complexo. Não somos infalíveis, por melhores profissionais que sejamos. Isto é importante compreender e admitir, tanto o desenvolvedor como o testador. Testes automatizados podem fazer a diferença no que diz respeito à confiança que um software desenvolvido pode alcançar. Como qualquer artefato, o código fonte dos testes automatizados e os documentos gerados re- querem qualidade. À medida que se aumenta a comple- xidade do software, os testes automatizados aumentam sua abrangência também. Segundo Pressman (2010), o teste frequente respon- de por mais esforço de projeto do que qualquer outra atividade de engenharia de software. Se é conduzido ao acaso, tempo é desperdiçado, esforço desnecessário é despendido e, ainda pior, erros se infiltram sem serem descobertos. Assim, seria razoável estabelecer uma estra- tégia sistêmica para o teste de software. A figura 5 mostra 2 imagens que apresentam a distri- buição de defeitos de software e o esforço de retrabalho para sua correção e o custo para se corrigir defeitos inse- ridos na fase de análise de requisitos e detectados poste- riormente. Testes de Software 17 Figura 5 – Origem dos defeitos, esforço de retrabalho e custo de correção Fonte: http://tmtestes.com.br/conteudo/show/id/113 Testes de Software 18 Voltando à analogia do recall, entendemos que admi- tir falhas, erros ou defeitos e corrigi-los, contribui para a manutenção da existência de grandes montadoras. Da mesma forma, identificar e corrigir falhas, erros e defeitos em um software, contribuirá para a manutenção da exis- tência de um software desenvolvido. Ciclo de Vida de Testes de Software Segundo Pressman (2010), o teste e a depuração, são atividades diferentes, mas a depuração deve ser acomo- dada em qualquer estratégia de teste. Conforme abordado na seção 1.4. Estratégias de Teste, temos vários estágios na definição da estratégia de testes, no entanto, se considerarmos o seu ciclo de vida ficará mais claro o entendimento e a importância da elaboração de estratégias para a implementação de testes. Uma estratégia de teste deve acomodar testes de bai- xo nível, que atuam na identificação de problemas em um pequeno segmento do código fonte e testes de alto nível, que validam as principais funções do sistema levando em consideração os requisitos do cliente. Uma estratégia for- nece diretrizes aos profissionais e um conjunto de refe- rências para o gestor. Na analogia anterior, nos referimos a admitira possi- bilidade de imperfeição no desenvolvimento de algo, no caso, um veículo. Em teste de software também admiti- mos imperfeições, na verdade não apenas admitimos, mas lutamos abertamente contra elas. Mesmo sabendo que é uma luta impossível de ganhar, é impossível aban- doná-la tal a importância que ela exerce na busca da qua- lidade de desenvolvimento. Neste conceito, temos que considerar a importância do ciclo de vida e compreender a incansável busca pela qualidade e perfeição, mesmo sendo algo quase humana- mente impossível de se alcançar. De acordo com Bastos et al (2007), quanto mais cedo se iniciarem os testes, mais barata será a correção dos er- ros encontrados e, para conquistar este benefício, o pro- cesso de teste, assim como o processo de desenvolvimen- to, deve ter um ciclo de vida, que é definido em fases. Segundo os autores, o ciclo de vida dos testes de sof- tware compreende as etapas que envolvem: procedimen- tos iniciais, planejamento, preparação, especificação, exe- cução e entrega, de acordo com a figura 6. Figura 6 - Ciclo de vida do processo de teste Fonte: [BASTOS et al, 2007] Testes de Software 19 Estas etapas serão detalhadas no que se segue. Procedimentos Iniciais Aprofunda-se, nesta etapa, um estudo sobre os requi- sitos do negócio, de forma a garantir que estejam comple- tos e sem nenhuma ambiguidade. Deve ser traçado tam- bém um pequeno esboço do processo de teste. É preciso elaborar um plano com todas as atividades principais que serão executadas. Planejamento Nesta etapa são realizadas a elaboração da Estratégia de Testes e do Plano de Testes com objetivo de minimi- zar os principais riscos do negócio e fornecer os caminhos para as próximas etapas. Para cumprir esses objetivos, algumas diretrizes são necessárias. Esta etapa deve ser executada em conjunto com as atividades de captação dos requisitos e o planejamento do projeto de desenvol- vimento do sistema a ser testado. Testes de verificação deverão ser executados sobre os requisitos do sistema. Deverá também ser preparada a Análise de Risco do pro- jeto de teste. Preparação Conforme a figura 6, esta etapa ocorre paralelamente às outras etapas. O objetivo básico é preparar o ambiente de teste para que os testes sejam executados corretamen- te, em um ambiente mais próximo ao que o cliente utiliza. Especificação Esta etapa se refere à especi- ficação dos casos e roteiros de teste que são elaborados durante o decorrer do projeto. À medida que a equipe de desenvolvimento conclui alguns módulos ou partes do sistema, são elaborados os ca- sos e roteiros de teste. Execução Executar e registrar os resultados dos testes são tare- fas que precisam obedecer as seguintes diretrizes: • Os testes deverão ser executados de acordo com os casos e roteiros de teste. • Devem ser usados scripts de teste, caso seja empregada algu- ma ferramenta de au- tomação de testes. • Os testes deverão ser executados integral- mente, por regressão, ou parcialmente, sem- pre que surgir alguma mudança na versão dos programas em tes- Testes de Software 20 A reprodução de um teste automatizado inúmeras ve- zes, em situações específicas, garante que passos impor- tantes não sejam esquecidos, e isto, sem dúvida, evitará uma situação indesejável. Além disso, como os casos para verificação são des- critos através de um código interpretado por um compu- tador, é possível criar situações de testes bem mais ela- boradas e complexas do que as realizadas manualmente, possibilitando qualquer combinação de comandos e ope- rações. A magnitude dos testes pode também ser facil- mente alterada. Por exemplo, é trivial simular centenas de usuários acessando um sistema ou inserir milhares de registros em uma base de dados, o que não é factível com testes manuais. Uma prática comum no passado (até a década de 1990) era criar uma função de teste em cada módulo ou classe do sistema que continha algumas simulações de uso da unidade. O problema desta prática estava na falta de organização, já que o código adicional era misturado ao próprio sistema afetando a legibilidade do código. Por isso, surgiram os frameworks que auxiliam e padronizam a escrita de testes automatizados, facilitando o isolamen- to do código de teste do código da aplicação. Consideremos um exemplo para aplicações Java com o auxílio da versão 4 do JUnit. Os testes são organizados em casos de teste definidos através de anotações Java @ Test antes da definição de cada método de teste. O fra- mework também possui uma gama de métodos auxiliares para comparar os efeitos colaterais esperados com os ob- tidos, tais como assertEquals que compara a igualdade do conteúdo de objetos, assertSame que compara se duas referências se referem ao mesmo objeto, assertNull que verifica se uma dada referência é nula, entre outros (veja figura 7). te e nos ambientes de teste preparados, conforme previstos na Estratégia e Plano de Testes. Entrega O projeto de teste é finalizado, sendo concluída e ar- quivada sua documentação. Deve ser recolhida esta do- cumentação e elaborado um relatório gerencial com as conformidades e não-conformidades encontradas. Testes Automatizados Testes automatizados são programas ou scripts simples que exercitam funcionalidades do sistema sendo testado e fazem verificações automáticas nos efeitos colaterais obtidos. A grande vantagem desta abordagem, é que to- dos os casos de teste podem ser facilmente e rapidamen- te repetidos a qualquer momento e com pouco esforço. Fonte: http://silvioqualidade.wordpress.com/ Testes de Software 21 O framework JUnit é uma ferramenta automatizada de teste de software para teste estrutural. De acordo com Sommerville (2007) ele é um grupo de classes na linguagem Java, que podem ser estendidas e então criar um ambiente de testes automatizados. Esta ferramenta é um gerenciador de testes. Delamaro, Maldonado e Jino (2007) ratificam que o JUnit tem aumentado muito a sua quantidade de usuários. Os autores afirmam que o fra- mework tem a possibilidade de escrever e executar au- tomaticamente um conjunto de testes, fornecendo ainda um relatório da forma que cada caso de teste, que não teve seu comportamento de acordo com o especificado, se comportou. Um exemplo prático que demonstra a criação de teste uni- tário em uma classe Java usando o JUnit pode ser vista em: http://youtu.be/f7HvmUmIun4 De acordo com Lages (2010), a escolha dos testes au- tomatizados candidatos, ou seja, os mais críticos, deve ser realizada com base no planejamento de um projeto de automação. O autor afirma que apesar de não existir uma categorização amplamente difundida, a experiência tem mostrado que os testes candidatos são normalmente agrupados nestas 4 áreas: • Smoke Tests: um conjunto mínimo de testes é selecionado com o objetivo de validar um Build ou liberação antes do início de um ciclo de testes; • Testes de Regressão: os testes são selecionados com o objetivo de executar o re-teste de uma fun- cionalidade ou da aplicação inteira; • Funcionalidades Críticas: os testes são seleciona- dos com o objetivo de validar as funcionalidades críticas que podem trazer riscos ao negócio; • Tarefas Repetitivas: os testes são selecionados com o objetivo de reduzir o envolvimento dos tes- tadores em atividades manuais repetitivas e sus- cetíveis a erros, tais como cálculos matemáticos, simulações, processamentos, comparações de ar- quivos ou dados etc. Testes manuais ou não automatizados A automação de testes tem o objetivo de reduzir o en- volvimento humano em atividades manuais repetitivas. Entretanto, isto não significa que a automação de testes Figura 7 - Exemplode teste automatizado com o JUnit 4 Fonte: http://www.ime.usp.br/~kon/papers/EngSoftMagazine-IntroducaoTestes.pdf Testes de Software 22 deve se limitar apenas a fazer o trabalho repetitivo e cha- to. Os casos de testes manuais foram criados num con- texto em que os testes seriam executados manualmente. É muito provável que estes casos de testes manuais não sejam muito eficientes em um contexto em que os testes serão executados automaticamente. Na prática, a automação de 100% dos testes manuais nem sempre é a melhor estratégia. A automação de testes é pouco eficaz quando os testes são complexos e exigem interações inter-sistemas ou validações subjetivas. Além disso, muitas vezes o custo e o tempo para automatizar os testes de um projeto são maiores que o custo e o tempo do próprio projeto de desenvolvimento. Segundo Lages (2010), quando se deseja aplicar a au- tomação na etapa de execução de testes das funcionali- dades de um sistema, vários fatores devem ser avaliados para se identificar se é vantagem ou não se automatizarem os testes. A automação de testes deve ser feita somente quando uma rotina específica de teste for executada vá- rias vezes, pois a automação também demanda tempo de criação e manutenção de scripts. Lages ressalta que “70% dos testes do mercado são manuais. O teste automatiza- do serve basicamente para fazer Teste de Regressão. O que acha erro mesmo é o teste manual”. Existem diversos tipos de testes para detectar a ine- ficiência de um sistema, e antes de muitos deles serem automatizados, são executados por várias vezes em modo manual, para depois de comprovado sucesso na sua utili- zação serem automatizados. Alguns deles são: • Teste de desempenho: teste que determina o desempenho de um sistema. As ferramentas que apoiam os testes de desempenho possuem duas fa- cilidades: geração de carga e mensuração das tran- sações do teste. A geração de carga pode simular múltiplos usuários ou grandes volumes de dados de entrada. Durante a execução, os tempos de respos- ta para determinadas transações são medidos e re- gistrados. As ferramentas de teste de desempenho, normalmente, fornecem relatórios baseados nos registros dos testes e gráficos da carga em função dos tempos de resposta. • Teste de carga: teste que mede o comportamento de um sistema com uma carga crescente, como por exemplo, número de usuários paralelos e/ou nú- meros de transações, para determinar qual a carga que ele pode suportar. Estes testes determinam, também, o tempo de resposta de transações e pro- cessos de negócios com o intuito de determinar se a aplicação está de acordo com as expectativas do- cumentadas e determinadas pelo cliente. • Teste de estresse: teste que avalia a execução de um sistema ou componente no limite (ou aci- ma dele) dos requisitos especificados. Estes testes determinam a carga necessária para que o sistema falhe e avalia seu comportamento em condições anormais. Podem incluir, além de cargas de traba- lho extremas, insuficiência de memória e recursos de processamento limitados. Avaliam também a capacidade que o software tem de se recuperar de uma falha mantendo a integridade dos dados. • Teste de longevidade: neste teste é avaliado o funcionamento do sistema em médio e longo pra- zo. Seu objetivo é detectar influências externas ao software, principalmente de hardware ou sistema operacional. Fatores como grandes volumes arma- zenados, tamanho ou limpeza do cache podem ser decisivos na eficiência em médio e longo prazo de um software. • Teste de desempenho: muitos problemas de desempenho que podem surgir após o sistema ser submetido à carga extrema durante um longo período de tempo, só podem ser detectados num ambiente controlado. Existem tipos de testes de desempenho, como os testes de configuração, que da mesma forma que o teste de longevidade, visam identificar configurações otimizadas de hardware e software para a correta execução da aplicação, e os testes de contenção, que avaliam a forma como o sistema gerencia demandas para um mesmo recur- so computacional (memória, dados, processador, etc.). • Teste de Segurança: os testes de segurança nor- malmente requerem uma infraestrutura similar ao Testes de Software 23 do ambiente de produção, pois se espera que este exponha as vulnerabilidades do sistema no am- biente adequado. Garantem a confidencialidade, Integridade e disponibilidade das informações. Um dos problemas relacionados a este teste é o buffer overflow, ou a necessidade maior de capacidade de armazenamento. • Teste de correção: os testes de correção (unida- de, integração, aceitação, etc) não necessitam das mesmas dependências.Têm como objetivo revelar a presença de erros, e descobrem o maior número possível de erros. Implementação dos Testes Uma vez que o software tenha sido elaborado é ne- cessário fazer a implementação de testes manuais ou automatizados. Isto pode exigir conhecimento multidisci- plinar, ou seja, conhecimento de programação, conheci- mento de testes de software, conhecimento de linguagem de negócio e conhecimento de ferramentas específicas. Portanto, o profissional responsável pelos testes automa- tizados normalmente é diferenciado. Segundo Schach (2007), “implementação é o processo de converter o projeto detalhado em código. Quando isso é feito por um único indivíduo, o processo é relativamente bem compreendido. Porém, hoje em dia, a maioria dos produtos são muito grandes para serem implementados por apenas um programador dentro das restrições de tempo. Em vez disso, o produto é implementado por uma equipe, com todos trabalhando ao mesmo tempo em di- ferentes componentes do produto.” O trabalho colaborativo não indica na necessidade de todos realizarem tarefas semelhantes, indica apenas a integração de ideias que naturalmente ocorre em uma equipe integrada. De acordo com Pressman (2010), na década de 1970, McCall, Richards e Walters categorizaram os fatores que afetam a qualidade, relacionados com três áreas distintas: operação, transição e revisão. Entre as menções de Mc- Call encontramos 3 conceitos que são muito importantes para o sucesso na implantação e manutenção dos testes de software. São elas: comunicação, transparência e cla- reza. • Comunicação: O bom comunicador não é aque- le que possui o “dom da palavra”, mas sim aquele não retém informações a respeito de sua atividade dentro de uma equipe. Você já prestou atenção al- guma vez à atitude de alguns jogadores de futebol dentro de campo? É muito comum pegá-los con- versando todo o tempo de paralisação ou tentando prever alguma ação de ataque ou contra-ataque. Esta situação faz com que o entrosamento se torne constante, mesmo nos jogos mais complicados ou difíceis. Portanto, durante um jogo, ou um desen- volvimento, é extremamente importante que haja comunicação durante o desenvolvimento de todas as atividades do projeto. • Transparência: É um princípio que se exige da- queles a quem se delegam responsabilidades. Este conceito se torna muito mais importante quando envolve trabalho em equipe. Portanto, ser colabo- rativo significa ser transparente ao revelar dados, transferir conhecimentos e atuar como uma equipe no objetivo comum de elaborar um software com a menor quantidade de erros, falhas ou defeitos. Fonte: http://expressaorp.files.wordpress.com/2011/08/comunicacao_ corporativa1.jpg?w=300&h=225 Testes de Software 24 • Clareza: Ser claro é ser simples e objetivo. Muito embora tenha relação com transparência, a clareza está relacionada não apenas com a divulgação cor- reta da informação, mas a não deixar margem para um entendimento dúbio. Ser claroé respeitar os componentes da equipe em suas atividades e inte- ressar-se pelo cumprimento das metas da equipe, colaborando de modo aberto e espontâneo com o atingimento do objetivo comum. É manter os ca- nais de comunicação sempre abertos. Fonte: http://3.bp.blogspot.com/-RG2nG0zSkGg/T49EtJxzdMI/AAAAAAA Fonte: http://etiquetagem.blogspot.com.br/2010/05/comunicando.html Testes de Software 25 O texto abaixo é da autoria de Abraham Shapiro e ilustra como a comunicação, quando existe falha, pode proporcionar resultados desastrosos. “Clareza tem tudo a ver com resultados”. Meia vida, ou mais, se perde por falta de entendimento claro sobre as coisas. E bastante dinheiro vai junto. Observe como isto é certo. Você solicita algo a um de seus funcionários. Em seguida pergunta: “Entendeu?” Como ninguém admite limitações pessoais e geralmente têm um ego elevado, as pessoas respondem sempre: “Entendi, sim senhor!” Em seguida, elas saem, fazem as coisas de seu próprio modo, e só ao retornar descobrem que não haviam entendido nada do que você lhes pediu. Falhas de comunicação viram erros e defeitos com grande facilidade e frequência. Imagine cada funcionário da sua empresa cometendo erros. E eles cometem! Todos os dias. Erros que não são contabilizados. E quem paga? Vá conferir. E de quem é a culpa? Quer saber? É da falta de habilidade na comunicação. Isto pode mudar, se você quiser. É possível aprender a se comunicar bem. Para começar, olhe para o fato de que você não nasceu sa- bendo nada do que mais domina hoje. Teve de aprender tudo. Como aprende? Mudando comportamentos. Agora se defronta com a realidade de que promover novas mudanças será mais barato do que continuar gastando com retrabalho. E há outro agravante. Você não encontra profissional completo ou pronto. Parte da formação desejável no perfil ideal do candidato que você busca, terá de ser completada dentro empresa, depois de contratado. Sem isso, não há como salvar os seus funcionários do amadorismo. E sobre a comunicação? O que fazer? Comece questionando mais. Substitua a frase: “Você entendeu?” por um pedido para que o colaborador diga com suas próprias palavras o que pretende praticar após sair de sua sala. Você verá nisso uma atitude que irá pro- duzir mais acertos, poupando prejuízos e dores de cabeça. “ Para finalizar, veja o que ocorre nesta cena. O sujeito entra num bar e o garçom chega dizendo: - Boa noite, o que o senhor toma? O fulano responde: - Eu tomo vitamina C pela manhã, o metrô para ir ao serviço e uma aspirina para dor de cabeça. O garçom, paciente, retifica: - Desculpe senhor. Acho que não fui claro. Quis saber o que o senhor gostaria? - Tudo bem! – diz o cliente – Eu gostaria de ter uma Ferrari, uma linda namorada e um milhão de dólares na conta. - Não é nada disso, cavalheiro! - continua o garçom. - Eu só preciso saber o que o senhor deseja beber. - Agora sim! - diz o sujeito - Bem... então me diga o que é que você tem? E o garçom: - Eu? Nada, não! Imagine. Só estou um pouco chateado porque o meu time perdeu para o Corinthians hoje à tarde! Viu só? Imagine como não deve ser nas empresas por aí!” Fonte: http://etiquetagem.blogspot.com.br/2010/05/comunicando.html Testes de Software 26 Ambiente de Testes Automatizados Cada tipo de teste possui restrições próprias relaciona- das com o ambiente, que podem ter como dependência a flexibilidade e portabilidade das tecnologias utilizadas. Fa- tores externos de software ou hardware também podem influenciar a definição de onde executar os testes. Um ambiente compartilhado de testes ou ambiente de homologação, que é um ambiente criado para replicar todas as condições do ambiente de produção, contribui para a eficiência na execução dos testes e qualidade final da entrega. Não é fácil a criação e manutenção deste am- biente, então, quando ele já está em uso, deve ser usado de forma abrangente. Com o tempo, é comum esta infraestrutura do am- biente de homologação correr o risco de ficar desatua- lizada, e neste momento a equipe deve buscar mostrar aos responsáveis da área técnica a importância da manu- tenção de um ambiente de homologação atualizado. Este ambiente deve espelhar o máximo possível o ambiente de produção, de forma a buscar garantir sucesso na execução dos testes. Existem várias alternativas para criar ou montar este ambiente de homologação, entre elas encontramos, por exemplo, a virtualização, que quando usada eficazmen- te pode gerar um ambiente adequado e de baixo custo. Quando há uma grande quantidade de testes sendo exe- cutados neste ambiente simultaneamente, pode haver uma sensível queda de desempenho do sistema, o que normalmente não compromete confiabilidade dos testes. De acordo com Delamaro, Maldonado e Jino (2007), os testes de desempenho, de carga, de estresse e de longevidade requerem um ambiente de testes similar ao ambiente de produção, porque os resultados obtidos estão diretamente relacionados com o ambiente. Os tes- tes de segurança normalmente requerem, também, uma infraestrutura similar ao do ambiente de produção, pois espera-se que estes testes exponham as vulnerabilidades do sistema no ambiente adequado. Os testes de correção (unidade, integração, aceitação, etc) não necessitam dos mesmos ambientes, produção ou homologação, portanto há maior flexibilidade, pois pode-se usar até mesmo em um hardware local ou a máquina do desenvolvedor. Quando executar os testes automatizados Existem testes rápidos e alguns mais demorados para serem realizados. A definição de prioridades é essencial para o sucesso na execução dos testes. Bernardo e Kon (2008) alegam que não é uma tarefa fácil alcançar uma boa qualidade em um software, pois os mesmos são complexos, e envolvem problemas no processo de desenvolvimento, como questões humanas, técnicas, burocráticas, de negócio e políticas, Pressman (2010) garante que o teste de software é um fator decisivo para garantir a qualidade de um programa. Ainda de acordo com Pressman (2010), alguns testes, por sua simplicidade, podem ser executados a todo o mo- mento, como os testes de desempenho e longevidade. Há outros que devem ser programados, como os testes de segurança e desempenho, os quais geram invariavelmen- te lentidão pode causa das ferramentas que necessitam utilizar. Outros tipos de testes, como carga e estresse, não precisam ser executados a todo o momento, pois avaliam a infraestrutura e esta normalmente não é alterada com frequência. O custo da criação destes testes automatizados nor- malmente é bem maior do que a dos testes manuais, principalmente por causa da estrutura por trás deste am- biente. Saff e Ernst (2003) afirmam que o uso de metodologia ágil incentiva a criação do ambiente de integração contí- nua, no qual se mantém o código fonte sempre testado e confiável, diminuindo a alocação de recursos humanos Testes de Software 27 em atividades de teste, pois este framework atua com en- tregas imediatas, o que exige validação imediata. Importante destacar que executar testes com frequ- ência é fundamental. É mais vantajoso executar baterias pequenas e frequentes de testes do que uma rara e gran- de bateria. Além disso, as baterias de testes que não são executadas com frequência podem se tornar obsoletas, correndo o risco de ficarem desatualizadas e, consequen- temente, não acompanharem a evolução natural dos componentes relacionados. É importante destacar que quanto mais obsoleto se torna um teste, mais caro fica, comprometendo recursos e podendo, no momento mais importante, não atender à solicitação de seus usuários. Também a não execução periódica causa acúmulos de erros ou falhas que pode tornar a implementação de melhorias incompatível como cumprimento de prazos estabelecidos. Há softwares gratuitos que podem dar uma base ou referência para testes integrados de software. Veja alguns exemplos: 9 JMeter: http://jakarta.apache.org/jmeter 9 Selenium-IDE: http://selenium-ide.openqa.org 9 SUnit: http://sunit.sourceforge.net 9 JUnit: http://www.junit.org 9 TestNG: http://testng.org 9 JSUnit: http://www.jsunit.net 9 CppTest: http://cpptest.sourceforge.net 9 csUnit: http://www.csunit.org 9 Eclipse: http://www.eclipse.org 9 Selenium: http://selenium.openqa.org 9 Selenium RC: http://selenium-rc.openqa.org Além destas ferramentas, também existem linguagens específicas que podem ser usadas, como: 9 DOM- Document Object Model que é uma lin- guagem para permitir que programas acessem e modifiquem dinamicamente objetos de um do- cumento HTML: http://www.w3.org/DOM/ 9 XPath - XML Path Language que é uma lingua- gem para identificar trechos específicos de um arquivo XML: http://www.w3.org/TR/xpath Conheça a ferramenta de Teste de Software CruiseControl, que é um gerenciador de build de código aberto e gratuito, escrito em Java, muito utulizada como uma ferramenta de teste contínuo: http://cruisecontrol.sourceforge.net/ Documentação de Teste de software O IEEE - Institute of Electrical and Electronic Engineers, organização sem fins lucrativos responsável por promover o conhecimento nas áreas de Engenharia Elétrica, Eletrô- nica e Computação, define padrões para diversas áreas e práticas presentes na Engenharia de Software. O padrão IEEE 829 está relacionado com o processo de testes. Sua abrangência vai desde testes unitários até testes de aceitação e inclui a definição de documentos consistentes e adequados capazes de definir, registrar e prover condições de análise dos resultados obtidos ao longo do processo de testes de software. Esta norma descreve um conjunto de 8 documentos que cobrem as tarefas de planejamento, especificação e relatórios de testes. São eles: • Plano de Teste: é um documento que apresenta o planejamento para a execução do teste e identifi- ca os itens e as funcionalidades a serem testados, bem como as tarefas e os riscos associados com a atividade de teste. Testes de Software 28 • Especificação de testes: é composta por 3 docu- mentos (Especificação de Projeto de Teste, Espe- cificação de Caso de Teste e Especificação de Pro- cedimento de Teste) que identificam os casos e os procedimentos de teste, critérios de aprovação, definem dados de entrada e resultados esperados, além de especificar os passos para a execução dos testes. • Relatórios de testes: são compostos por 4 docu- mentos (Diário de teste, Relatório de Incidente de Teste, Relatório-Resumo de Teste e Relatório de Encaminhamento de Item de Teste) que visam re- gistrar detalhes relevantes, eventos que ocorrem durante os testes e resultados das atividades. Bossi (2010) destaca que esta norma separa as ativida- des de teste em três etapas: preparação do teste, execu- ção do teste e registro do teste. A autora afirma que mais do que apresentar um conjunto de documentos, esta nor- ma apresenta um conjunto de informações necessárias para teste de produtos, independentemente do tamanho ou complexibilidade do software. Em sua proposta, a norma IEEE-829 descreve um mé- todo para implantação do processo de teste de software em alguns documentos, cujo teor principal está relaciona- do abaixo. • Guia para Elaboração de Documentos de Teste de Software: tem o propósito de servir como referên- cia para criação de documentos de teste. • Processos para a Elaboração de Documentos de Teste de Software: apresenta os processos que abrangem a preparação, a execução e o registro dos resultados do teste, estabelecendo uma orientação geral. No site http://www.testexpert.com.br/?q=node/1666 Fábio Martinho (2010) disponibiliza templates da norma IEEE- 829 para download. Os templates disponibilizados são: 1. Master Test Plan Template - Plano de Testes Mestre 2. Test Case Specification Template - Especificação de Casos de Teste 3. Test Design Specification Template - Especificação de Design(Projetos) de Teste 4. Test Incident Report Template - Relatório de Incidente de Teste 5. Test Log Template - Log de Teste 6. Test Procedure Specification Template - Especificação de Procedimento de Teste 7. Test Status Report Template - Relatório de Status de Teste 8. Test Summary Report Template - Relatório de Sumário de Teste 9. Unit-Integration Test Plan Template - Plano de Teste para Testes Unitários e Integrados Recomenda-se que, independentemente da forma como os documentos da norma sejam adaptados para a docu- mentação dos testes, é importante que incluam o planejamento, o projeto, os casos de teste e os procedimentos de teste. Além disso, os resultados e incidentes ocorridos durante o teste devem ser adequadamente registrados e con- densados num relatório final. Isso garantirá que todo o processo de testes possa ser adequadamente realizado e bem documentado. Testes de Software 29 Exercícios do Capítulo 2 1 - Identifique que conceito não é importante para o sucesso na implantação e manutenção dos testes de sof- tware: a) Clareza b) Comunicação c) Transparência d) Economia e) Nenhuma das anteriores 2 - Um dos problemas relacionados a este teste é o buffer overflow, ou a necessidade de maior capacidade de armazenamento. a) Segurança b) Longevidade c) Estresse d) Integração e) Sistema 3 - Tem como objetivo revelar a presença de erros. Descobre o maior número possível de erros, alguns, depen- dendo do desenvolvimento previamente já identificado para comprovar a eficiência do teste. a) Sistema b) Correção c) Estresse d) Integração e) Nenhuma das anteriores. 4 - São programas ou scripts simples que exercitam funcionalidades do sistema sendo testado e fazem verifica- ções automáticas nos efeitos colaterais obtidos. a) Testes oficiais b) Testes de equivalência c) Testes Automatizados d) Testes frequentes e) Testes Manuais 5 - Podemos afirmar sobre testes de baixo nível: a) São testes realizados no fim do projeto. b) São testes de hardware, por isso de baixo nível. c) São testes completos do sistema. d) Atuam nos problemas complexos do programa. e) Atuam na identificação de problemas em um pequeno segmento do código fonte. Testes de Software 30 Testes em Modelagem Ágil Modelos Ágeis e Testes de Software Como vimos na disciplina Métodos Ágeis de Programa- ção, a modelagem ágil pode ser definida como “um fra- mework para o cotidiano”. Esta definição de modelagem ágil é uma realidade para as empresas que necessitam de desenvolvimento eficiente. A modelagem ágil estabelece um conjunto de práticas no desenvolvimento de software que está cada vez mais se tornando habitual. Mas, dife- rente do que muitos pensam, não existe um modelo pré- -definido ou um conjunto de regras a serem adotados. Na modelagem ágil cada equipe, dentro de suas atri- buições e de acordo com as características dos projetos da empresa, adota uma forma ágil mais adequada para aten- der suas demandas. Isto quer dizer que em modelagem ágil, apenas é mostrado o caminho e a equipe adota as práticas mais adequadas dentro do conceito ágil. Não há procedimentos ideais pré-estabelecidos apenas princípios adotados a partir da necessidade particular do negócio. Segundo Highsmith & Cockburn (2001), a novidade nos modelos ágeis não está nos métodos ágeis, e sim no envolvimento de pessoas que participam no sucesso do projeto e que estão focados na capacidade de gestão do negócio. Uma das importantes fases da modelagem ágil são as histórias que são relatadas principalmente pelo product owner, responsável porrepresentar o cliente dentro da equipe de desenvolvimento. Estas histórias determinarão o caminho ideal a ser seguido na modelagem e são cha- madas de Story-Writing Workshops. A modelagem ágil visa colocar em prática o conjunto de valores que o negócio já possui. Vamos imaginar um brainstorm, no qual todas as ideias são apresentadas e depois colocadas em uma desafiadora sequência de ações e procedimentos. A modelagem ágil começa a ser aplica- da desta forma. Durante este procedimento de implan- tação encontramos os procedimentos relacionados aos testes de softwares. Vamos voltar a um conceito antigo relacionado à lógi- ca de programação. Os mais experientes se lembram de que muito antes de começar a desenvolver um programa, o programador desenhava um diagrama de fluxo de da- dos estruturado do sistema e somente depois começava a programação em si. Estes profissionais mais experientes entendiam que se você soubesse passar por esta fase an- tes da programação, a linguagem de programação seria apenas um detalhe. Assim, você poderia escolher qual- quer linguagem, pois a lógica de funcionamento seria a mesma. Na modelagem ágil ocorre o mesmo, a linguagem é um detalhe que pode ser pensada e adotada depois do entendimento dos requisitos que o software precisa aten- der. Em teste de software, encontramos a figura do tes- tador que atua junto com a equipe de desenvolvimento estabelecendo técnicas ou definindo conceitos que serão aplicados durante o desenvolvimento para testar a inte- gridade e validar os resultados. O testador não precisa ser um componente externo, pois dependendo das definições prévias, ele poderá ser um dos integrantes de dentro do time ou grupo. Este tes- tador será um componente valioso e, como tal, participa- rá ativamente no apoio para as entregas consecutivas que ocorrem neste modelo de desenvolvimento. De acordo Beck (2012), o Manifesto Ágil diz que “Esta- mos descobrindo maneiras melhores de desenvolver sof- tware fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar: • Indivíduos e interação entre eles mais que pro- cessos e ferramentas • Software em funcionamento mais que documen- tação abrangente Testes de Software 31 • Colaboração com o cliente mais que negociação de contratos • Responder a mudanças mais que seguir um pla- no” Caros alunos, como vimos no nosso estudo de méto- dos ágeis, nos modelos ágeis os seguintes princípios são seguidos: 9 maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado; 9 mudanças nos requisitos são bem-vindas, mes- mo tardiamente no desenvolvimento. 9 entregar frequentemente software funcionan- do, de poucas semanas a poucos meses, com preferência à menor escala de tempo; 9 pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto; 9 projetos devem ser construídos em torno de in- divíduos motivados; 9 o método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desen- volvimento é através de conversa face a face; 9 o software funcionando é a medida primária de progresso; 9 os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo cons- tante indefinidamente; 9 a contínua atenção, a excelência técnica e o bom design aumenta a agilidade; 9 a simplicidade e a arte de minimizar a quantida- de de trabalho não realizado são essenciais; 9 as melhores arquiteturas, requisitos e design emergem de equipes auto organizáveis. Em intervalos regulares, a equipe deve refletir sobre como se tornar mais eficaz e então refinar e ajustar seu comportamento de acordo. Portanto, podemos perfei- tamente concluir que as condições ideais existentes que levam um negócio a implantar o modelo ágil também são ideais para se implantar os testes de software de forma muito eficiente. Assim, o mesmo princípio de modelo ágil se aplica em teste de software: não existe uma fórmula mágica padro- nizada e ideal, cada empresa, de acordo com suas neces- sidades específicas adotará o procedimento ideal. E se este modelo não existir, deve ser criado um que atenda as suas necessidades. Teste de software no Scrum No Scrum encontramos o ambiente ideal para a ativi- dade de teste de software. Como vimos na disciplina “Métodos Ágeis de Progra- mação”, Scrum é o nome de uma jogada derivada do Ru- gby, como mostra a figura 8. No Scrum todas as equipes, como as responsáveis pela Configuração, Instalação, Ne- gócios, Teste, Desenvolvimento, entre outras, fazem parte de um mesmo Time. Com a fusão das equipes no mesmo Time, o Scrum permite que todos trabalhem de forma integrada facilitando a comunicação e gerando um am- biente de parceria na empresa. Figura 8 - Scrum no Rugby Fonte: http://blog.castsoftware.com/wp-content/uploads/2011/05/rugby- scrum-kbear65-flickr-300x200.jpg Testes de Software 32 Desta forma, a equipe de teste não é vista pela equipe de desenvolvimento como adversária, mas como parcei- ra. Assim, existe uma grande interação entre os profissio- nais que atuam no desenvolvimento, tornando possível encontrar o verdadeiro espírito de equipe. Esta condição elimina naturalmente algumas barreiras comumente en- contradas em equipes que são submetidas a testes e ava- liações por componentes externos. No Scrum há diversas entregas a serem feitas e o con- ceito do que está “pronto” para ser entregue, pode ser diferente, pois um determinado item pode estar pronto dependendo do conceito de conclusão/término estabele- cido pela equipe. No caso do Scrum, um item “pronto” para ser entregue, associado a testes de software, pode significar: 9 Codificação + Teste concluído 9 Codificação + Teste + Integração concluída 9 Codificação + Teste + Regressão concluída 9 Codificação + Teste + Integração + Regressão + Instalação concluída No Scrum não existe um fase específica de teste fora da etapa de implementação. Na prática testes iterativos são executados durante todo o desenvolvimento, como os testes de unidade e os testes de caixa preta. Uma fun- cionalidade só é considerada concluída quando todos os testes foram executados durante o desenvolvimento. O analista de teste, no Scrum, faz parte do time e assume várias responsabilidades, como líder, arquiteto e respon- sável pela automatização. Ele participa ativamente no levantamento de requisitos e definição de escopo. Ele trata com grande relevância a necessidade do cliente con- siderando os objetivos que o software deve alcançar na medida em que ele é entregue. Ao fim de cada Sprint, o analista de testes, junto com o Time, são responsáveis por garantir que todos os testes automatizados tenham sido executados sem falhas. De acordo com Highsmith & Cockburn (2001), para al- cançar os resultados adequados, o testador realizará algu- mas tarefas, como: 9 Participar das discussões de definição de arqui- tetura; 9 Participar das definições de tecnologias utiliza- das; 9 Identificar as necessidades do ambiente de tes- te; 9 Identificar restrições tecnológicas; 9 Identificar ferramentas de teste necessárias para auxiliar na execução do projeto; 9 Utilizar mapa mental para auxiliar no entendi- mento das funcionalidades/requisitos; 9 Identificar os “melhores” analistas de teste para o projeto em questão; 9 Identificar a necessidade de suporte do time de suporte/operações. 9 Estimar o tempo de teste. Sua participação na definição de usuários e tarefas será de grande contribuição para que a equipe continue com sua atuação integrada. Este profissional ganha um papel importante na mo- delagem ágil, pois participará ativamente do desenvol-vimento, implantando técnicas práticas e eficientes de testes de software, levando em consideração o negócio e suas necessidades. A equipe, como um todo, sempre atuará para o bene- fício do projeto, portanto, o testador, componente agora agregado ao time, se integra, participando ativamente e colaborando de forma significativa na criação de um sof- tware com o mínimo de falhas, defeitos e erros. O analista de testes no Scrum De acordo com Duong (2009), o Analista de Teste, como importante membro do Time, participa ativamente de todos os processos, apoiando o Scrum Master, que faz a mediação, e consultando o Product Owner para escla- recer eventuais dúvidas. A figura 9 mostra as principais etapas e membros envolvidos num projeto Scrum. Testes de Software 33 Na primeira parte do Planning Meeting (Reunião de Planejamento) o Product Owner define a meta da Sprint e divulga para o Time os itens prioritários do Product Ba- cklog. O Time estima os itens e seleciona o que vai ser feito. O Analista de Teste participa dessa fase para garan- tir que os itens selecionados estejam de acordo com as metas do projeto de testes, analisa os indicadores de de- sempenho, gerencia os riscos encontrados e define quais serão os tipos de teste (Sistema, Aceitação, Regressão) necessários. Na segunda parte da Planning Meeting o Time obtém mais detalhes dos itens do Select Product Backlog e os divide em tarefas gerando o Sprint Backlog. O Analista de Teste participa desta fase definindo o nível de regressão de teste de acordo com a priorização dos itens/tarefas do Sprint Backlog, atualizando a matriz de teste por funcio- nalidade e atualizando o mapa mental. Após a definição da Sprint, o quadro de acompanha- mento é preparado. Este quadro vai sendo alterado de acordo com as necessidades do projeto. O Analista de Figura 9 – Projeto Scrum Fonte: http://alanbraz.wordpress.com/ Teste é a pessoa que aprova. Nada é considerado “pron- to” em um Sprint até que ele diga que está. É responsável por ficar focado na meta da Sprint. Durante a execução da Sprint o Analista de Teste realiza as seguintes atividades: 9 Monta e configura o ambiente e infraestrutura de teste; 9 Executa testes; 9 Automatiza casos e tarefas de teste; 9 Auxilia os desenvolvedores na elaboração dos testes unitários automáticos; 9 Mostra os resultados dos testes; 9 Acompanha os defeitos encontrados. Na reunião diária (Daily Scrum) de 15 minutos, o Time ganha visibilidade de como está o caminho para a meta e planeja o dia seguinte de trabalho. Embora o Scrum Master seja o facilitador, o Analista de Teste também par- ticipa dessas reuniões contribuindo com a elaboração e atualização dos seguintes documentos: relatório de teste; Testes de Software 34 evidência de teste; gráfico S-Curve; lista de defeitos; lista de impedimentos; quadro Kanban. O Analista de Teste participa de outras 2 reuniões: reu- nião de Revisão, que possui o propósito de apresentar o que foi feito para o Product Owner e convidados e reu- nião de Retrospectiva que possui o objetivo de represen- tar o espírito de Inspeção – Adaptação dentro do Scrum. Na reunião de Revisão é realizada uma apresentação por todo o Time e o Product Owner avalia se a meta foi al- cançada e faz anotações que podem ser transformar em novos itens para o Product. A reunião de Retrospectiva é facilitada pelo Scrum Master e nela são apresentadas as lições aprendidas. O Time avalia o que foi bom na última Sprint, o que deve ser melhorado e quem está no contro- le. Assim, como pudemos ver, o Analista de Teste partici- pa de todas as fases do Scrum, pois ele faz parte de um Time. Não existe Time de Teste ou Time de Desenvolvi- mento no Scrum, mas como vimos, Time do Scrum. Tipos de Testes Usados na Modelagem Ágil Os processos ágeis, como vimos, se destacam dos métodos tradicionais de desenvolvimento, devido prin- cipalmente à priorização das funcionalidades através do código executável, ao invés da produção extensa da do- cumentação escrita. Um ponto essencial para garantir a fidelidade das implementações em relação aos requisitos está nos testes executados sobre o código produzido. Hendrickson (2012) afirma que para a implementa- ção de técnicas ágeis no ambiente de testes é necessá- rio mudar a maneira que as equipes estão acostumadas a trabalhar. Uma das mudanças necessárias é a introdu- ção ao conceito de colaboração com o cliente, ao invés de se utilizar documentação abrangente, em consonân- cia com o manifesto ágil. Desta maneira passamos a fazer um trabalho mais próximo com o cliente, e sua partici- pação no processo é peça chave para que a técnica ágil de testes possa ser adotada. Outro ponto importante é que todos da equipe devem realizar testes e não apenas o analista de testes. De acordo com a autora, em um mé- todo ágil costuma-se dizer que a equipe é infectada por testes e desta maneira o sistema é construído para estar testado desde o início do projeto e não apenas no fim da codificação.A qualidade passa a ser da equipe e não ape- nas dos analistas de testes ou profissionais que possuem a palavra “qualidade” nos seus cargos. Os requisitos de testes para a metodologia ágil não possuem grande diferenciação em processos guiados por planos. O que realmente difere é o grau de importância dado aos testes em cada um dos processos. Nos processos guiados por planos, existe uma série extensa de artefatos documentais resultantes da análise profunda realizada sobre o sistema a ser desenvolvido. Os testes, neste caso, são apenas mais um artefato produ- zido pelo processo, visando garantir a detecção de erros antes da liberação da versão final. O projeto que nasce com cobertura de teste desde iní- cio permite a realização de Teste de Regressão, que impli- ca em se executar testes em todo o sistema e não apenas na funcionalidade implementada. Ainda de acordo Elisabeth Hendrickson (2012) um sis- tema com cobertura de testes desde o início deve reali- zar o máximo possível de testes automatizados para que o trabalho manual e repetitivo não venha a ocorrer. Isso trará ganho de tempo na execução do teste e o custo de transformar um caso de teste em automatizado rapida- mente se paga. A autora afirma que “eu tenho observado em minhas equipes um custo de 30% a mais na execução e transformação do teste em automatizado, mas após a 3ª vez que eu executo a bateria de testes, eu já vejo como este custo de 30% foi pequeno”. A autora segue dizendo que o tempo de execução do teste automatizado em rela- ção ao manual é incomparável, os ganhos de velocidade de execução e a possibilidade de a qualquer momento re- alizar um teste de regressão são maiores. Testes de Software 35 Os testes em métodos ágeis devem seguir o conceito de pequenas interações para que a informação de como o sistema está sendo construído e os erros que são detec- tados possam ser rapidamente identificados e corrigidos. Ao término de uma interação, todos os testes devem ter sido executados com êxito. Segundo Erdogmus et al (2005), os testes nas meto- dologias ágeis, são importantes e os autores fazem as se- guintes considerações em relação aos tipos de teste: • Testes Manuais: objetivam utilizar o sistema para tentar encontrar anomalias no funcionamento do software. Geralmente são pouco eficientes, pois di- ficilmente se conseguiria chegar à exaustão detec- tando todas as anomalias. Mas, mesmo com pouca eficiência e fragilidade, ainda são utilizados pela facilidade e simplicidade de sua aplicação, já que basta inserir o sistema em ambiente de validação, simular as entradas e considerar os resultados obti- dos. • Testes Automatizados:
Compartilhar