Simplificando Teste de Software: Compartilhando experiências (Portuguese Edition)

Citation preview

SIMPLIFICANDO TESTE DE S O F T WA R E Compartilhando experiências

Anne Caroline Rocha

Copyright © Anne Caroline Oliveira Rocha, 2023 Todos os direitos reservados.

1ª edição – Julho 2023 Revisão: Farlley Derze

Aos meus pais – Pelos ensinamentos que possibilitaram a me tornar quem sou. Ao meu esposo – Por complementar minha vida e partilhar experiências. Aos meus filhos – Por me ensinarem a ser mãe. Aos meus irmãos – Pelas alegrias que marcaram a minha infância.

Sumário Sobre o livro PARTE I - Conceitos sobre teste de software 1. O que é um software? 2. O que é teste de software? 2.1. Como alcançar qualidade em um software? 3. Em que momento os testes são realizados? 3.1. Processo de desenvolvimento tradicional 3.2. Processo ágil de desenvolvimento de software 4. Quais são os tipos de teste de software? 4.1. Teste funcional 4.2. Teste não funcional 4.3. Teste estrutural 4.4. Teste relacionado à mudança 5. Como identificar os diferentes níveis de teste? 5.1. Nível de Teste de unidade 5.2. Nível de Teste de integração 5.3. Nível de Teste de sistema 5.4. Nível de Teste de aceite 6. O que é pirâmide de automação de teste? 7. Como elaborar um Roteiro de Teste? 7.1. Localização 7.2 Objeto de teste 7.3. Caso de teste 8. Técnicas de teste 8.1. Classe de equivalência 8.2. Análise de valor limite 8.3. Tabela de decisão 8.4. Diagrama de transição de estados 8.5. Fluxograma 8.6. Teste de cobertura

8.7. Descoberta de erro 8.8. Teste exploratório 9. Onde utilizar as técnicas de teste? 10. Como reportar defeitos? 10.1. Taxonomia do defeito 10.2. Ciclo de vida do defeito 11. Como entrar na carreira de teste de software? 11.1. Gerente de testes 11.2. Analista de teste manual 11.3. Analista de automação de teste 12. Como planejar uma estratégia de teste? 12.1. Escopo 12.2. Lista de requisitos 12.3. Recursos 12.4. Cronograma 12.5. Prioridades 12.6. Indicadores PARTE II - Relatos de experiência em teste de software 13. Como decidir se vale a pena ou não investir em teste de software? 14. Processo de desenvolvimento ágil ou tradicional? 15. A origem de um defeito e seu impacto no processo de desenvolvimento 16. Por que testar é importante? 17. Dicas para ter mais eficiência nos testes 18. Quando os testes podem ser automatizados? 19. Vale a pena investir em testes estruturais para sistemas legados? 20. O futuro dos testes e onde os testadores podem investir? Glossário Referências Agradecimentos

Sobre o livro

Esta foto foi feita em meio à pandemia de 2020. Era um dos cenários que eu via todos os dias no meu apartamento. A imagem representa as vezes que vi o sol nascer, quando acordava bem cedinho, dedicada a escrever mais um capítulo deste livro. Me surpreendi com a cena, todos os dias eram diferentes: o céu mudava de cor, as nuvens tinham formatos distintos, um presente para mim. Mesmo cansada, estava focando no meu objetivo maior: compartilhar conhecimentos com as pessoas da minha área profissional - Qualidade de software. Escolhi essa foto porque se eu pensar de forma abstrata, consigo imaginar os prédios como um teste caixa-preta (se você não conhece este termo, vai aprender neste livro) e quem sabe aquele pixel vermelho em uma das janelas possa ser um bug na edição da foto. Além disso, fotografar é uma das minhas paixões, poder compartilhar um pouco da minha arte nesse livro é gratificante. Tentei escrever este livro de forma que a leitura ficasse simples, para que mesmo quem esteja iniciando na área consiga compreender os conceitos e colocá-los em prática. Fiz questão de montar um glossário com as palavras mais técnicas, também com o mesmo objetivo de facilitar a leitura. Quando penso em testes de software, lembro-me dos desafios iniciais na minha carreira quando, em 2007, na empresa onde eu trabalhava, passei de estagiária a Líder de Controle de

Qualidade logo após ter concluído a graduação em Ciência da Computação. Apesar de não saber muito sobre o assunto, aceitei o desafio e tive que aprender o máximo que pude em pouco tempo, para começar a liderar uma equipe de 5 pessoas. Estudar naquela época já era um hábito, pois estava me formando na universidade, então isso não foi um problema. A maior dificuldade que tive foi encontrar materiais em português que eu pudesse utilizar nos meus estudos. Naquela época, não havia muita coisa, apenas livros não acessíveis. Os que consegui ter acesso eram bem teóricos, ótimos para responder questões de provas, mas não para aplicar no meu trabalho. À medida que eu ia estudando, sempre tinha o hábito de fazer anotações e resumos. Então, aproveitei esse conteúdo e iniciei minha escrita compartilhando conceitos e técnicas em um blog sobre Teste de Software, o Grupo de Testadores de Software - GTSW [16]. Com isso, desde essa época, vem crescendo em mim a vontade de escrever um livro sobre Teste de Software. A decisão veio a partir do momento que voltei a ensinar em um curso de teste de software de forma online durante a pandemia de 2020, pois percebi que meus alunos tinham muitas dúvidas sobre o assunto. Logo, pensei em um livro que reunisse assuntos da área com uma linguagem simples, para pessoas que estão iniciando na carreira de TI. Um livro sem muita formalidade, apenas para transferir ao leitor alguns conhecimentos que adquiri com minha experiência profissional. Além do conhecimento geral, sobre os principais conceitos na área de qualidade de software, este livro também contém relatos de experiências vivenciadas tanto no mundo acadêmico, durante o mestrado em Ciência da Computação, quanto como Analista de Qualidade em empresas privadas e no serviço público. Cada capítulo, deste livro, apresentará conceitos que poderão ser necessários nos capítulos seguintes, desta forma uma leitura contínua é essencial para compreender melhor cada assunto. Aproveite! Anne Caroline Rocha

PARTE I - Conceitos sobre teste de software

1. O que é um software? Antes de saber o que é teste de software, precisamos compreender o que é um software. O software é todo e qualquer aplicação que roda em uma máquina (computador ou celular). No computador, os softwares são conhecidos como aplicações e são utilizados para diversas finalidades, por exemplo: a calculadora, o bloco de notas, o navegador, etc. No celular, os softwares são chamados de aplicativos, os quais facilitam nosso dia a dia quando precisamos pedir comida, fazer uma ligação, trocar mensagens, assistir vídeos, entre outros. É provável que você conheça algumas dessas palavras presentes na Figura 1.1.

Figura 1.1: Nomes de softwares de computadores ou celulares.

Um software é construído pelo desenvolvedor através de uma linguagem de programação, que é a forma que eles conseguem se comunicar com uma máquina, passando comandos lógicos para elas realizarem. As linguagens são escritas em formato de texto, como se o desenvolvedor pudesse escrever uma carta para a máquina, essa carta é chamada de código-fonte. Há diversas linguagens de programação, como: Java, C, Cobol, Python, Ruby, JavaScript, etc. A escolha de uma dessas linguagens vai depender da finalidade do software que será construído e do ambiente em que ele será executado, ou seja, se será uma aplicação para um computador, um aplicativo para celular ou até mesmo uma aplicação web, que dependerá da internet para funcionar. A Figura 1.2 apresenta um protótipo de um aplicativo de celular, no qual as pessoas apoiam um determinado projeto através de doações. Como podemos observar nessa imagem, os softwares geralmente possuem uma interface intuitiva, para que os usuários consigam explorar todas as funcionalidades do aplicativo através de cliques em botões e preenchimento de formulários.

Figura 1.2: Exemplo de aplicativo de celular. (Fonte: https://br.freepik.com/)

Quando pensamos em um aplicativo que trata de recursos financeiros, a primeira coisa que um usuário pensará antes de realizar a doação é sobre a segurança das transações que serão realizadas nele. Será que um aplicativo que apresenta mensagens de erros ou dados que desaparecem durante o seu uso, vai trazer confiança para seus usuários?

2. O que é teste de software? Afinal, o que é testar? Esta palavra aparece em vários contextos da nossa vida cotidiana. Certamente você já ouviu falar de um teste específico chamado test drive, que é realizado por uma pessoa antes de comprar um carro, quando quer descobrir se vai gostar da dirigibilidade do carro, da visibilidade dos retrovisores, do câmbio da marcha, da partida, do acelerador, do arcondicionado, etc. Todos estes itens podem ser verificados no test drive de um carro. Se o carro “passou” no teste do possível comprador, então existe a chance de ele comprar o carro, caso contrário ele provavelmente escolherá outro carro. Assim como os carros são lançados em diferentes versões e modelos todos os anos, recebendo mais e mais aperfeiçoamentos, os softwares também são lançados em versões. Uma nova versão de um software pode conter um novo conjunto de funcionalidades desenvolvidas (como um carro que agora tem um motor mais potente), ou pode adicionar apenas correções de defeitos anteriores, pré-existentes (como um recall, que realiza reparos nos carros vendidos). Exatamente para diminuir ao máximo a necessidade e ocorrência de recalls automotivos (que têm um custo alto para a fabricante), muitos testes são feitos pelos engenheiros antes do lançamento dos carros no mercado. De forma análoga, testes de software são necessários e importantes para evitar um custo muito maior depois, quando um software estiver sendo usado pelo usuário. Para saber se um software será aceito após o seu lançamento, há testes que podem ser feitos pelo próprio usuário em uma versão do software, chamada de versão beta. Os testes realizados na versão beta, geralmente por um subconjunto de usuários reais, servem para verificar se há defeitos no software e corrigi-los, antes de ele ser disponibilizado para um público maior. Algumas vezes, os dados criados na versão beta são mantidos e já estão valendo para a versão final do software. O que precisa ficar bem claro para os usuários é que aquela versão pode conter defeitos e que eles fazem parte de um grupo seleto de pessoas que terão a oportunidade de usar o software em primeira mão. Talvez você já tenha utilizado algum aplicativo ou jogo em sua versão beta. Assim como existe o teste beta, existe também o teste alfa. E quando ele é realizado? O teste alfa é realizado por um ou mais usuários em um ambiente controlado, onde os dados realizados no teste não são reais, ou seja, os dados não serão mantidos posteriormente. Quando um usuário recebe uma versão do software para realizar o teste alfa ou beta, é importante que outros testes sejam feitos anteriormente, durante o desenvolvimento do software, de forma que a aplicação não possua falhas graves durante os testes dos usuários. Pois a “imagem” do software é construída desde seu primeiro uso. Nota: Lembra do test drive mencionado no início do capítulo? Embora seja realizado pelo usuário final (o futuro motorista), qualquer defeito identificado ou opinião relatada não volta para os engenheiros originais para o aperfeiçoamento do carro, como ocorreria se fosse um teste beta. O carro já está “pronto” nesta versão para venda. Dessa forma, os test drives automotivos têm objetivo de auxiliar no processo de compra do usuário, assemelhando-se às versões trial dos

softwares. Teste de software é a arte de realizar uma simulação em um software, com o objetivo de encontrar defeitos [1]. Caso a intenção de um testador, ao realizar os testes, seja garantir que a aplicação não possua defeitos, esse pensamento irá revelar-se uma atividade exaustiva e sem sucesso, pois os testes de um software só conseguem identificar a presença dos defeitos e não a ausência deles [2]. Dependendo do software, o defeito encontrado pode ter um impacto maior ou menor para o usuário final. Quando se trata de softwares que envolvem transações monetárias (como aplicações bancárias ou de investimentos), que podem trazer prejuízos financeiros, ou aplicações médicas, que podem afetar a saúde do paciente, um defeito pode ter um impacto alto na vida dos usuários. No entanto, em jogos, utilizados para lazer, um defeito pode não trazer muitos prejuízos para o usuário (talvez frustração seguida de um desabafo energético sobre a má qualidade dele). “Um software é considerado confiável à medida que o número de defeitos diminui durante o seu uso.” - Myers [1] Diferenciar os termos erro, defeito e falha pode ser essencial para entender melhor o que é testar. Testar é uma atividade realizada para encontrar defeitos. Esses erros de programação fazem a execução do software falhar: em vez de se comportar como esperado, a aplicação para abruptamente ou apresenta um resultado incorreto. O software então possui um defeito. Em resumo, um erro do desenvolvedor no código-fonte do software pode causar uma falha durante a sua execução. Logo, através de testes, o defeito da aplicação será detectado. Em um software, as vulnerabilidades podem ser causadas por erros ou pela ausência de programação que previna certos incidentes, como: falta de segurança (quando o software está vulnerável a ataques); falta de disponibilidade (quando o software não suporta a quantidade de usuários simultâneos); falta de acessibilidade (quando o software não consegue ser utilizado por usuários com baixa visão), entre outros. Nota: Há muitos defeitos em softwares que não são identificados, os quais podem só causar falhas na aplicação depois de muito tempo de uso. Somente quando a falha ocorre é que o defeito se torna aparente e poderá ser corrigido. Às vezes, um software que não apresentava falhas pode começar a aparecer pelo fato de passar a ser utilizado em contextos diferentes do convencional. Para refletir: Se a execução de um software falhasse caso ele fosse usado de uma forma bem específica (Ex.: clique no botão X, depois role a janela até o final duas vezes e por fim mova o celular no sentido norte-sul), porque geralmente não é usado dessa forma, o software realmente tinha um defeito ou foram os usuários que “criaram” os defeitos ao causarem falhas na aplicação com a sua criatividade?

2.1. Como alcançar qualidade em um software? Teste de software faz parte de uma área mais abrangente chamada de Garantia da Qualidade de Software, cujo objetivo é verificar se todos os procedimentos relacionados à construção do

software estão de acordo com os padrões de qualidade estabelecidos. De acordo com Myers, testes continuam sendo a “arte das trevas” do desenvolvimento de software, pois ele percebeu que era comum profissionais de TI entregarem software sem a realização de testes [1]. Costuma-se pensar que a qualidade de um software pode ser conquistada ao realizar testes. Entretanto, testes por si só não garantem qualidade nenhuma [3]. A qualidade só é alcançada quando os defeitos reportados forem corrigidos. Com isso, fica claro que testes é uma atividade puramente de desenvolvimento de software. Quando isso for realmente percebido pelas equipes de teste e de desenvolvimento, os softwares poderão começar a ser mais confiáveis e a ter mais qualidade. Uma aplicação pode conter um conjunto de funcionalidades que determinam como um software deverá ser executado. No caso de uma aplicação ter várias funções, ela é chamada de sistema de informação. Um exemplo de sistema de informação é um aplicativo para realizar compras (Figura 1.3), que tem funcionalidades para selecionar produtos, criar um carrinho, realizar pagamento, gerenciar informações do cliente, gerenciar entrega e devolução dos produtos.

Figura 1.3: Aplicativo para compras online. (Fonte: https://br.freepik.com/)

Quando pensamos em uma documentação de sistema, pode não ficar claro quais informações ela deve possuir. Geralmente não há um padrão formal de documentação para os sistemas. Todavia, a documentação é tão importante quanto as regras para um jogo. Testar um sistema sem documentação é como tentar descobrir como se joga um jogo sem suas regras. Nota: Para ilustrar a complexidade, até hoje historiadores discutem como se joga o Senet, jogo de mais de 4 mil anos atrás popular no Antigo Egito — ninguém ainda descobriu, mesmo tendo o conhecimento claro do tabuleiro e das peças que constituem o mesmo!

Em uma documentação de sistema é essencial definir os possíveis cenários que o usuário poderá executar no software e as regras que restringem as operações dos usuários em cada tela [4]. Essas restrições são chamadas regras de negócio, que descrevem o que o usuário pode ou não fazer, quais campos são obrigatórios ou não e as partes do sistema que estarão disponíveis para os usuários. Quando não há uma documentação formal do sistema, no entanto, os testes podem ser realizados de forma exploratória, baseando-se na experiência do testador. Mesmo nos testes exploratórios é possível utilizar um checklist genérico, que pode ser encontrado na seção 8.7 do capítulo 8 deste livro, para guiar o testador durante a realização dos testes, pois alguns sistemas possuem componentes semelhantes. Que componentes são esses? Componente é uma palavra genérica, mas quando falamos de um sistema web, pensamos em um sistema que é acessado através de um navegador, que pode possuir formulários de cadastro, alteração e remoção com campos de data, CPF, e-mail, com alguns links ou botões, etc. Os campos, links e botões são os componentes. Além dos checklists genéricos, que seriam uma documentação mais informal, a documentação formal de teste consiste em roteiros de teste. Esses roteiros são compostos por um conjunto de casos de teste, que descrevem todos os passos necessários para executar alguma funcionalidade do sistema, e o resultado esperado após a execução dos passos. A elaboração de um roteiro de teste será mais bem descrita no capítulo 7 deste livro. Um exemplo de funcionalidade nos sistemas é a autenticação de usuários, ao permitir que apenas usuários autorizados acessem a aplicação. A fim de reduzir o esforço na elaboração de roteiros de teste, é possível criar casos de teste genéricos. Por exemplo, independente do tipo de sistema, na autenticação de usuários pode-se criar testes para: ● validar entrada com senha incorreta; ● validar entradas de campos obrigatórios; ● verificar autenticação com sucesso. Os testes podem também ser automatizados. Desta forma, é possível repetir uma mesma execução várias vezes, depois do esforço inicial da primeira execução pelo testador. Para criá-los e executá-los, é necessário o uso de alguma ferramenta durante a execução dos testes. Apesar de automáticos, todavia, eles não eliminam a necessidade de um testador ou de algum teste de forma manual. Durante a automatização dos testes, à medida que o sistema evolui, o testador precisa manter os testes atualizados e rodá-los continuamente. A cada modificação do código do sistema, deve haver também alteração nos casos de teste automatizados, para que eles continuem testando o sistema. Dessa forma, é necessário a existência de testadores mais experientes, que configuram os testes para detectar o maior número de defeitos e que sejam mais simples de serem mantidos. Exemplo: A depender das necessidades e das características de cada sistema a ser testado, é importante identificar quais tipos de testes de software serão realizados. Para exemplificar, caso haja uma demanda de realização de testes de segurança em um sistema web, há várias estratégias que poderiam ser utilizadas, com diferentes tipos, níveis e técnicas de teste.

Os próximos capítulos irão apresentar mais detalhes de como o teste de software pode ser realizado na prática. Como pode ser observado no exemplo do Quadro 2.1, é importante compreender que o teste de software pode ser classificado conforme: ● O que será testado: está relacionado ao objetivo que se quer alcançar após a realização dos testes, conforme descrito no capítulo 4 sobre os tipos de teste. ● Onde irá testar: está relacionado à parte do sistema e ao ambiente onde os testes serão realizados, conforme descrito no capítulo 5 sobre os níveis de teste. ● Como irá testar: está relacionado à maneira que os testes serão realizados, conforme descrito no capítulo 8 sobre as técnicas de teste. Quadro 2.1: Exemplo identificando o tipo, nível e técnica de teste.

O que?

Tipo de teste

Esse teste tem o objetivo de identificar vulnerabilidades no sistema e prevenir ataques.

Teste não-funcional.

Onde será testado?

Nível de teste

A interface do sistema através de um navegador.

Teste de sistema

Como será testado?

Técnica de teste

Será utilizado um checklist com diversos testes de invasão.

Baseado na experiência

3. Em que momento os testes são realizados? As atividades de testes de software são realizadas durante a construção e manutenção de um sistema. Para que essas atividades sejam realizadas de forma planejada é importante seguir um processo. Um processo define um conjunto de atividades que podem ser executadas por cada membro de uma equipe durante o desenvolvimento de um produto. O processo de teste de software é parte do processo de desenvolvimento de sistemas, o qual pode ser um processo tradicional ou ágil.

3.1. Processo de desenvolvimento tradicional O processo de desenvolvimento tradicional contempla de forma detalhada cada uma das atividades. Com isso, os artefatos produzidos por esse tipo de processo são mais completos e requerem mais conformidade entre eles. Desta forma, a codificação do sistema só acontece após a documentação ser revisada e aprovada. As atividades relacionadas à qualidade podem começar a partir do momento em que há documentos sobre o sistema que será desenvolvido, como pode ser observado na Figura 3.1.

Figura 3.1: Processo Tradicional de Desenvolvimento de Sistema.

Na linha referente ao papel Testador, a primeira atividade de revisar documentos pode ser realizada através de uma revisão, inspeção ou com um checklist predefinido. Ela tem como objetivo verificar se o documento está em conformidade com os modelos estruturais (diagramas de classe, diagramas de caso de uso etc.) e os requisitos do sistema. Essas técnicas são conhecidas como testes estáticos, já que não é necessário a presença do sistema em execução para a realização desta revisão.

Em seguida, com a aprovação desses documentos, será realizada a atividade de criar roteiros de teste para cada requisito do sistema. Esses roteiros de teste são compostos por vários casos de teste. Quando uma parte do sistema estiver codificada e testada, via testes unitários e revisão de código, os desenvolvedores disponibilizam um ambiente de teste para que os testadores possam executar os testes de sistema, onde são realizados os testes dinâmicos. O resultado das execuções dos testes é registrado em relatórios de defeitos, que indicam se os testes passaram ou não. Esses relatórios de defeitos são passados para os desenvolvedores do sistema, para que eles corrijam os defeitos encontrados. Após a correção dos defeitos, eles são homologados pelos testadores, que confirmam se os defeitos foram corrigidos. Algumas vezes, nessa atividade de homologação, novos defeitos são encontrados e precisam ser adicionados ao relatório de defeitos. Além da confirmação dos defeitos encontrados no teste de sistema, o cliente e os usuários também homologam o sistema, através do teste de aceitação (teste alfa e beta). Quando o sistema passa nos testes e os requisitos foram implementados, ele pode ser enviado para a produção, que é quando uma versão do sistema será disponibilizada para uso geral. Nem sempre um roteiro de teste cobre 100% das funcionalidades do sistema, por isso há técnicas de elaboração de roteiros, que melhoram a qualidade deles reduzindo o número de casos de teste. Essas técnicas de elaboração de roteiros podem ser vistas no capítulo 8. O modelo tradicional de desenvolvimento de software tem muito em comum com outras áreas de construção, como a Engenharia Civil. No entanto, a facilidade relativa com que um software pode ser modificado, aliado com sua finalidade muito específica, fazem com que um novo modelo de desenvolvimento necessite ser elaborado, o qual será abordado na próxima seção.

3.2. Processo ágil de desenvolvimento de software Considerando que os sistemas mudam de acordo com a necessidade de seus usuários, nos processos tradicionais essas mudanças nos requisitos, que representam as fases iniciais do processo, causam impactos diretamente nos prazos de entrega e nos custos do projeto. Com os processos ágeis de desenvolvimento tornou-se possível lançar um produto viável mínimo (MVP) já no início do projeto, para que ele pudesse ser validado antes mesmo de se gastar recursos para construir uma solução completa, quando ainda não se tem a certeza de que ele realmente atenderá as necessidades dos usuários. A metodologia Scrum é uma das mais utilizadas nos processos ágeis de desenvolvimento de software, pois ela descreve de forma precisa os papéis, artefatos e eventos produzidos em cada etapa [14]. Por isso ela será utilizada para ilustrar esse tipo de processo, como pode ser observado na Figura 3.2 abaixo:

Figura 3.2: Processo Ágil de Desenvolvimento de Sistema (Scrum).

A principal diferença entre uma metodologia ágil e uma tradicional é que na primeira uma versão mínima do sistema já é entregue a cada ciclo e na segunda o sistema só é entregue quando ele for completamente desenvolvido. Com isso, no Scrum, a documentação, a codificação e os testes são realizados em cada ciclo com o objetivo de colocar em produção uma parte estável do sistema. Dessa forma, as atividades de teste são essenciais e precisam ser simplificadas, para que seja possível realizar os testes em um curto espaço de tempo, no caso do Scrum, onde a duração de cada ciclo varia entre 1 e 4 semanas. Em processos ágeis, algumas vezes a documentação não é bem detalhada e contempla apenas o mínimo necessário para que se saiba o que precisa ser desenvolvido e testado [12]. No Scrum, o time (equipe que pode ser composta por desenvolvedores e testadores) e o líder (SM Scrum Master) se reúnem com cliente ou gerente de produto (PO - Product Owner) antes de cada ciclo (Sprint), para coletar os requisitos da parte do sistema que será desenvolvida. O conhecimento sobre os requisitos do sistema não fica apenas com os analistas de requisitos, como se observa no processo tradicional. Dessa forma, todo o time tem acesso ao cliente e eles sabem exatamente o que precisa ser desenvolvido [12]. Devido ao curto espaço de tempo para realização dos testes em cada ciclo, para os testes manuais ou automatizados pode-se criar casos de teste que foquem nas funcionalidades que provavelmente possuem mais risco para o usuário final (ver técnicas de criação de roteiro no capítulo 7). Dessa forma, há uma redução do custo na produção dos roteiros de teste, mas não precisa deixar de criá-los. As funcionalidades menos críticas também precisam ser testadas e para elas pode-se utilizar a técnica de teste exploratório [13]. A gestão de equipes em times ágeis pode ser mais simples do que em processos tradicionais, pois o time ágil possui conhecimento de todas as etapas do processo, porque ele participa de cada uma delas [14]. No processo tradicional, cada membro da equipe é especializado em suas tarefas e conhece profundamente as etapas que ele participa e superficialmente as outras etapas. No entanto, o Scrum Master no processo ágil precisa ter ciência diariamente sobre o

andamento do projeto, os impedimentos e o que está sendo produzido através de reuniões diárias com o time. Essa é uma forma de garantir que o prazo de cada ciclo será cumprido. O papel do testador em um time ágil nem sempre é especializado, ou seja, qualquer membro do time de desenvolvimento pode realizar as atividades de teste. No entanto, quando existe um ou mais membros do time que compõem pessoas especializadas em teste de sistema, a chance de realizar testes mais eficientes é maior, ou seja, testes que permitem encontrar mais defeitos. No cenário em que o time ágil é dividido em desenvolvedores e testadores, é importante que os testadores participem das reuniões de planejamento com o cliente, para que possuam conhecimento intrínseco sobre o projeto, pois nem sempre há uma documentação detalhada sobre o sistema. Testadores em um time ágil podem ter muita influência no processo de desenvolvimento, e mais ainda no produto desenvolvido [12]. “Não sente e espere que as coisas venham até você. Seja proativo! Nós testadores não podemos esperar que as tarefas de teste cheguem até nós. Nós temos que nos aproximar de desenvolvedores e clientes, nos envolver com o projeto e procurar o que fazer.” - L. Crispin e J. Gregory [13] Vale ressaltar, que para uma maior garantia de qualidade na realização de testes em processos ágeis, é importante que testes automatizados sejam criados durante o desenvolvimento do sistema [11]. Pois, por haver curtos ciclos de entrega de versão dos sistemas, seria inviável realizar testes de regressão de forma manual a cada ciclo. Logo, os testes unitários e de integração podem ser utilizados também para essa finalidade, ou seja, garantir que o que estava correto, em versões anteriores, continuará funcionando [1]. Veja mais detalhes sobre isso no capítulo 6 sobre a pirâmide de teste.

4. Quais são os tipos de teste de software? As exigências por softwares com maior qualidade têm motivado a definição de métodos e técnicas para o desenvolvimento de softwares que atinjam os padrões de qualidade impostos. O ideal seria obter uma estratégia de teste com baixo custo de aplicação, mas ao mesmo tempo com grande capacidade em revelar defeitos [5]. O interesse pela atividade de teste de software aumenta à medida que a ausência dela influencia diretamente no custo final de um software produzido [5]. Esses custos podem ser percebidos quando há um elevado número de defeitos detectados pelo usuário final, os quais precisam ser corrigidos de forma imediata porque atrapalham o desenvolvimento de versões futuras do sistema, além de impactar na imagem dele. Uma forma de identificar quais tipos de testes podem ser realizados em um sistema é tentar perceber o ponto de vista do usuário final, considerando os seguintes critérios: ● se o sistema apresenta informações claras para desempenhar uma tarefa; ● se as informações são corretas e consistentes, ou seja, não mudam à medida que o sistema é utilizado; ● se o sistema é seguro o suficiente, quando há dados sensíveis e que não devem ser expostos; ● se o sistema possui um tempo de resposta satisfatório durante a transferência de dados, entre outros. Esses mesmos e outros critérios podem ser explorados no momento do planejamento dos testes, com a expectativa de tornar os testes cada vez mais robustos e de identificar antecipadamente o maior número de defeitos possível. Contudo, podemos observar no exemplo anterior que nem todos os critérios são relativos a falhas de execução no sistema. Dessa forma, embora falhas causem defeitos que os testes podem revelar, os testes também conseguem identificar outras características indesejadas relativas aos requisitos de segurança, disponibilidade do sistema, usabilidade, entre outros. Cada critério descrito anteriormente pode ser verificado através dos seguintes tipos de teste: ● teste funcional (caixa-preta); ● teste não funcional; ● teste estrutural (caixa-branca); ● teste relacionado à mudança (caixa-cinza). Vale ressaltar que cada tipo de teste pode ser executado em diferentes fases do desenvolvimento do sistema e engloba diferentes técnicas de teste, as quais podem ser realizadas de forma automatizada ou manual.

4.1. Teste Funcional O teste funcional tem como objetivo realizar testes em um sistema como se ele fosse uma caixa-preta, como pode ser observado na Figura 4.1. Para este tipo de teste, os mecanismos

internos dele não são relevantes: ao passar certos valores de entradas, o sistema precisa retornar resultados esperados. Esses resultados podem ser confirmados através da documentação de requisitos do sistema.

Figura 4.1: Modelo representando a execução de um teste funcional.

Dessa forma, o teste funcional tem o objetivo de verificar se o sistema faz o que deveria fazer de acordo com os requisitos elencados pelo cliente. Esses testes são realizados simulando o uso do sistema, da mesma forma que o usuário final faria. Com isso, não há necessidade de acessar o código do sistema durante a execução desse tipo de teste [5]. O teste funcional pode ser realizado utilizando técnicas de teste de forma manual ou automatizada. O custo para executar os testes funcionais é alto, até mesmo se eles forem realizados de forma automatizada. O motivo é que esse tipo de teste depende de uma interface do sistema para ser executado, logo qualquer alteração nela impacta diretamente os casos de testes, deixando os roteiros de teste obsoletos, por isso precisam de atualização periódica [3].

4.2. Teste não funcional O teste não funcional permite verificar se o sistema tem o comportamento esperado em determinadas condições e ambientes, de acordo com os requisitos não-funcionais especificados. Esses requisitos definem: ● onde o sistema estará disponível em navegadores e será responsivo às telas de celular; ● a taxa de indisponibilidade, quando é aceitável que o sistema fique fora do ar para manutenção; ● o nível de segurança desejável; ● a capacidade de usuários e de tráfego de dados, que o sistema precisa suportar; ● o tempo de resposta máximo para qualquer operação do sistema; ● a facilidade de realizar uma função no sistema em termos de número de cliques ou facilidade de aprendizado, entre outros. Dessa forma, é possível realizar diferentes técnicas de teste para verificar cada tipo de requisito descrito. Esse tipo de teste pode ser realizado de forma manual ou automatizada, isso vai depender da técnica de teste utilizada. Podemos citar as seguintes finalidades dos testes nãofuncionais (Figura 4.2), que geralmente são feitos por testadores durante o desenvolvimento do

sistema:

Figura 4.2: Modelo representando testes não funcionais.

O teste de desempenho tem o objetivo de identificar o desempenho do sistema quando submetido a diferentes quantidades de carga. Essa carga pode estar relacionada com o número de usuários simultâneos acessando o sistema ou à quantidade de dados que trafegam pelo sistema em um determinado instante. O teste de segurança tem o objetivo de detectar falhas de segurança que possam existir no sistema. Esse teste previne que o sistema possa ser invadido por usuários mal-intencionados. Dessa forma, tenta identificar vulnerabilidades no sistema durante uma autenticação ou prevenir que dados sensíveis dos usuários sejam roubados. O teste de usabilidade tem o objetivo de verificar se o usuário tem dificuldade em utilizar um sistema pela primeira vez. Para essa técnica de teste não é necessária uma documentação do sistema, pois o que importa é a impressão do usuário durante seu uso. Geralmente é disponibilizado para o usuário, que irá testar um conjunto de tarefas, de modo que ele verifique se consegue ou não realizar cada tarefa. Além disso, ele pode informar se teve dificuldade em finalizar alguma delas. Um teste de usabilidade mais robusto pode gravar a tela e o rosto do usuário, para perceber suas expressões durante o teste e ter um feedback mais completo sobre o sistema.

4.3. Teste estrutural O teste estrutural é conhecido como caixa-branca por depender do código-fonte do sistema para que possa ser realizado, como pode ser observado na Figura 4.3. Pois o objetivo desse tipo de teste é encontrar defeitos durante a programação do software. Dessa forma, pode-se testar uma parte isolada do sistema ou um conjunto de componentes integrados entre si.

Figura 4.3: Modelo representando a execução de um teste estrutural.

A premissa é que uma função do sistema continue retornando valores corretos, mesmo que o sistema evolua e novas funcionalidades sejam adicionadas. Esse tipo de teste pode ser realizado pelo desenvolvedor, no próprio código-fonte do sistema, mas nada impede que esse teste seja aprimorado por membros da equipe de testes. Neste caso, novos casos de teste podem ser criados para abranger outros cenários passíveis de erros e melhorar a cobertura dos testes. O custo de realização do teste estrutural é baixo, pois o sistema ainda se encontra em desenvolvimento. Além disso, quanto maior for o número de casos de teste realizados, com diversos tipos de entradas, ele será mais eficiente. Pois pode-se abranger muitos cenários em um curto tempo de execução, por se tratar de um teste automatizado [1].

4.4. Teste relacionado à mudança O teste relacionado à mudança geralmente é realizado após a correção de algum defeito ou após a adição de uma nova funcionalidade no sistema, quando ele já está sendo utilizado pelos usuários (Figura 4.4). Seu objetivo é garantir que nenhum novo defeito seja acrescentado ao sistema após a sua modificação ou evolução.

Figura 4.4: Modelo representando execução de testes relacionados à mudança.

De nada adianta testar um sistema, verificar que ele não possui defeitos para um conjunto de casos de teste e após modificações no sistema, não verificar se aqueles casos de teste continuam sem identificar defeitos. O teste relacionado à mudança pode utilizar técnicas de teste funcional ou estrutural. Por isso, ele é conhecido como teste caixa-cinza. Para facilitar a realização desses testes, é relevante a utilização de testes automatizados. Entretanto, em técnicas de teste estruturais o custo de automação é menor do que em testes funcionais, pois este depende da interface gráfica do sistema para ser executado e requer uma frequência maior de atualização dos casos de teste [3]. As técnicas de teste que podem ser utilizadas são: teste de confirmação e teste de regressão. O teste de confirmação pode ser realizado por testadores ou por membros de uma equipe de atendimento ao cliente. Essa técnica tem o objetivo de verificar se um defeito encontrado no sistema foi corrigido corretamente, antes de uma nova versão ser entregue para o usuário final. O teste de regressão é realizado durante o desenvolvimento e geralmente é executado antes da entrega de uma nova versão do sistema. A finalidade dessa técnica é garantir que, à medida que o sistema evolui, o que já foi testado continua funcionando. Chamamos de regressão, porque temos que testar novamente funcionalidades que já foram testadas antes.

5. Como identificar os diferentes níveis de teste? Durante o ciclo de vida do desenvolvimento de um software, diferentes tipos de atividades de teste podem ser realizadas. Independente do processo de desenvolvimento ser tradicional ou ágil, os testes podem ser realizados em diferentes níveis. Os níveis de teste podem ser mais bem observados em um modelo V, onde há uma associação entre as atividades de desenvolvimento e as atividades de teste conforme o modelo V da Figura 5.1. Na lateral direita, há 4 tipos de níveis de teste: teste de unidade; teste de integração; teste de sistema; e teste de aceite. Esses níveis correspondem aos 4 tipos de nível de desenvolvimento, presentes na lateral esquerda: requisitos, especificação, projeto de software e codificação.

Figura 5.1: Modelo V que descreve os níveis de teste.

Os níveis de teste podem ser identificados de acordo com: onde o teste será realizado, quem o realiza, o ambiente onde os testes são executados e os tipos de defeitos que eles identificam.

5.1. Nível de Teste de unidade O teste de unidade é realizado durante a codificação e tem a finalidade de testar cada entidade do sistema de forma independente. Por exemplo, em um sistema de calculadora científica, os testes para cada operação matemática seriam realizados separadamente. O nível de teste referente ao teste de unidade tem como objeto de teste: ● Código-fonte: código que descreve o que o sistema deve fazer. ● Classes: o código-fonte pode ser dividido em diferentes classes de acordo com as entidades relacionadas ao sistema. ● Módulos: as classes do sistema podem ser divididas em módulos, os quais

agrupam o mesmo contexto. Esse nível de teste precisa ter acesso ao código-fonte, então o teste de unidade é realizado pelo desenvolvedor em um ambiente de desenvolvimento. Após os testes de unidade serem executados, geralmente são encontrados defeitos dos seguintes tipos: ● Funcionalidade: quando há erros relacionados a regras de negócio do sistema. ● Dados inconsistentes: quando houve divergência de dados em diferentes partes do sistema. ● Lógica incorreta: quando o sistema possui erros relacionados à lógica de programação. ● Exceções: quando o sistema não faz tratamento de um caso excepcional e para a execução.

5.2. Nível de Teste de integração O teste de integração é um nível de teste que complementa o teste de unidade, pois permite realizar testes combinando diferentes componentes, para garantir que elas continuem funcionando de forma integrada. A integração do sistema pode estar relacionada à comunicação com um banco de dados local ou remoto, entre sistemas, com diferentes interfaces, entre outras formas. O nível de teste de integração tem como objeto de teste: ● Interfaces internas: quando um módulo do sistema precisa se comunicar com outras interfaces internas (classes) do mesmo sistema. ● APIs (interfaces externas): quando a interface do sistema precisa se comunicar remotamente com outra aplicação, para recuperar dados e exibir para o usuário. Esse nível de teste de integração pode precisar ter acesso ao código-fonte ou não para ser realizado, por exemplo, uma interface interna. Quando realizado pelo desenvolvedor em um ambiente de desenvolvimento, a mesma ferramenta de teste unitário pode ser utilizada para realizar esses testes, porém com objetivos diferentes. Caso o teste de integração seja realizado por um testador, em um ambiente de teste, poderá ser necessário utilizar alguma ferramenta para automatizar os testes, nesse caso o testador fará a verificação a partir de interfaces externas, por exemplo, APIs, que se comunicam com cada parte do sistema. Há ferramentas que os testadores utilizam para realizar esses testes de integração. Esses testes são escritos em linguagens de programação específicas da ferramenta selecionada, por exemplo Supertest ou Cypress, que usam JavaScript. Como os testes realizados nestas ferramentas usam como interface uma API, então o código de teste pode ser feito em uma linguagem de programação independente da linguagem de programação utilizada no desenvolvimento da API. Uma técnica utilizada nesse tipo de teste de integração de interfaces internas são os objetos mock. Eles têm a finalidade de simular partes do sistema que ainda não foram implementadas ou

serviços que ainda não estão disponíveis. Por exemplo, pode haver um objeto mock que simula um cadastro de usuário, onde os dados são gravados em arquivos temporários do sistema ou mesmo mantidos apenas na memória RAM do computador. Dessa forma, os testes podem ser criados como se tudo estivesse funcionando. No momento que aquela parte do sistema estiver disponível, basta trocar o objeto mock pela classe do sistema equivalente e executar novamente os testes. No caso das interfaces externas, elas podem se comunicar diretamente com a interface gráfica do próprio sistema. Por exemplo, um serviço que lista todos os dados para serem exibidos em uma tabela da aplicação. Assim, o sistema se comunica com algum serviço externo, como: Web Service ou API REST. Por exemplo, um serviço que realiza a autenticação do usuário, onde o usuário passa os dados de entrada, e outro sistema valida se é possível ou não autenticar. Quando o sistema é separado por interfaces externas (ex. APIs REST) chamamos a camada do sistema referente à interface gráfica de Frontend e a camada do sistema referente ao negócio e acesso aos dados chamamos de Backend. Dessa forma, uma API consegue realizar a comunicação entre essas diferentes camadas. Após os testes de integração serem realizados, geralmente são encontrados defeitos dos seguintes tipos: ● Falhas de comportamento: quando o sistema apresenta uma exceção e termina a execução. ● Erros de regra de negócio: quando houve erros relacionados ao que o sistema deveria fazer. ● Inconsistência de dados: quando houve divergência de dados durante a transferência de dados na integração. ● Falhas de comunicação: quando não há comunicação entre a interface e o sistema que fornece os dados.

5.3. Nível de Teste de sistema O teste de sistema é realizado por testadores, sejam eles usuários finais ou membros da equipe de testes. O objetivo deste teste é identificar falhas relacionadas às regras de negócio especificadas para o sistema ou falhas de execução do sistema. Quando os testes de sistema são realizados por usuários finais, são disponibilizados ambientes de teste, que podem ser alfa ou beta. O nível de teste de sistema tem como objeto de teste: ● Sistema em desenvolvimento: verificar se o sistema faz o que deveria fazer. Esse nível de teste não necessita ter acesso ao código-fonte para ser realizado. Por isso ele pode ser realizado por testadores, em um ambiente de teste. Após os testes de sistema serem executados, geralmente são encontrados defeitos dos seguintes tipos: ● Falhas de comportamento: quando o sistema apresenta uma exceção e termina a execução.

● ● ●

Erros de regra de negócio: quando houve erros relacionados ao que o sistema deveria fazer. Inconsistência de dados: quando dados são corrompidos ou não são exibidos corretamente. Problemas de ambiente: quando há erros específicos para uma plataforma, ou seja, navegadores, sistemas operacionais, etc.

5.4. Nível de Teste de aceite O teste de aceitação pode ser realizado pelo cliente, após o desenvolvimento, para verificar se o que foi solicitado está realmente presente. Nesse nível de teste nem sempre é necessária uma documentação, pois o cliente irá identificar se o que foi solicitado faz parte do sistema. Além disso, geralmente é disponibilizado um ambiente de testes chamado "homologação" para o cliente. Nesse ambiente, o cliente poderá executar o sistema livremente sem utilizar dados de produção, ou seja, dados reais. O nível de teste de aceitação tem como objeto de teste: ● Sistema em homologação: verificar se o sistema faz o que foi solicitado. Esse nível de teste também não necessita ter acesso ao código-fonte para ser realizado. Com isso, ele também pode ser realizado por testadores, clientes ou usuários finais. Quando o teste de aceitação é realizado em um ambiente de homologação, por clientes ou usuários selecionados, chamamos de Teste alfa. Ele também pode ser realizado em produção por usuários finais selecionados, nesse caso chamamos de Teste beta. Após os testes de aceitação serem realizados, geralmente são encontrados defeitos dos seguintes tipos: ● Falhas de comportamento: quando o sistema apresenta uma exceção e termina a execução. ● Erros em regras de negócio: quando há erros relacionados ao que o sistema deveria fazer. ● Inconsistência de dados: quando dados são corrompidos ou não são exibidos corretamente. ● Dificuldades de uso: quando o usuário não consegue realizar uma funcionalidade com facilidade. ● Falhas não funcionais: quando os erros são relacionados à segurança, disponibilidade, tempo de resposta, etc. Assim, cada nível de teste tem seu objetivo e sua relevância, identificando falhas de diferentes aspectos nos sistemas. Com isso, a realização de um nível de teste não anula a necessidade de realizar os outros níveis. É importante observar que diferentes técnicas podem ser realizadas em cada nível, inclusive se o modo de execução dos testes será automatizado ou manual.

6. O que é pirâmide de automação de teste? Como foi definido no capítulo anterior, durante o desenvolvimento de um software podemos ter diferentes níveis de teste, cada um com seus objetivos. Além disso, vimos no capítulo 3, que em processos ágeis o ideal é possuir um maior número de testes automatizados, já que os ciclos de entrega do software geralmente ocorrem em poucas semanas, então fazer testes de regressão manualmente seria inviável. No entanto, apenas conhecer os níveis de teste não nos dá uma noção da quantidade de testes que deveria ser realizada em cada nível. Os níveis de unidade e integração podem ser feitos de forma automatizada. Já os níveis de sistema e aceitação podem ser feitos de forma manual ou automatizada. No entanto, nem sempre a automação de todos os níveis de teste é vantajosa quando percebemos que o custo pode ser alto à medida que os testes se aproximam da interface gráfica [12]. Por exemplo, os testes de sistema, ao serem automatizados possuem os seguintes atributos menos favoráveis: ● Quebram com facilidade: a cada alteração da interface gráfica, pode ser necessário atualizar os testes para que eles continuem funcionando. ● Alto custo para escrever: requer muito tempo para escrever os testes automatizados, pois eles são complexos, já que precisam funcionar inspecionando as telas do sistema. ● Muito tempo para execução: geralmente os testes automatizados da interface gráfica demoram para serem executados por depender que o sistema seja executado por completo durante os testes. Levando em consideração os atributos menos favoráveis do teste de sistema automatizado, Mike Cohn sugeriu que a quantidade de testes automatizados realizados em cada nível de teste fosse baseada em uma pirâmide de teste, conforme a Figura 6.1 a seguir [12].

Figura 6.1: Modelo da pirâmide de testes automatizados.

Dessa forma a pirâmide seria composta por 3 camadas:

●

●

●

Testes de unidade: ficam na base da pirâmide por serem realizados na linguagem de programação do sistema, dessa forma são fáceis de escrever, e o tempo de execução é em fração de segundos. Assim, a quantidade de testes unitários deveria ser a maior parte. Testes de integração: ficam no meio da pirâmide e têm a finalidade de integrar as camadas de desenvolvimento com o banco de dados. Esse teste pode ser feito simulando algum serviço externo, que fornece dados para o sistema, ou interno que integra os componentes do sistema. Esses testes também são fáceis de escrever, pois podem ser escritos na mesma linguagem de programação do sistema e possuem um alto desempenho de execução. Testes de sistema: ficam no topo da pirâmide, indicando que devem ser feitos em menor quantidade do que os demais testes, pois são testes vulneráveis, por dependerem da interface gráfica e são lentos durante a execução.

Um aspecto importante da pirâmide de teste é que os testes não precisam ser duplicados ou triplicados em cada camada. À medida que os testes das camadas inferiores da pirâmide já cobrem grande parte das funcionalidades do sistema, não é necessário refazer os mesmos testes nas camadas superiores, que possuem um custo maior. Por exemplo: um teste de integração poderia contemplar o cadastro de usuários no banco de dados e o retorno de uma mensagem de sucesso. Até mesmo a validação dos dados de entrada pode ser verificada (CPF, Data, etc.) e retornando suas respectivas mensagens de erro. Com isso, o teste de sistema poderia ser realizado apenas para identificar se os elementos da interface estão presentes, bem formatados e as mensagens para o usuário não possuem erros de ortografia. Com isso, além dos testes automatizados previstos na pirâmide de teste, é importante que testes de sistema manuais sejam executados de forma exploratória e em menor quantidade, pois nem todo tipo de teste de interface pode ser automatizado, por exemplo a verificação de ortografia, usabilidade, etc. Além deles, os testes de aceitação, também podem ser feitos de forma manual por clientes e usuários. Se necessário, dependendo do tipo de sistema, outros testes não-funcionais podem ser requeridos. No caso dos testes unitários não serem bem escritos pelos desenvolvedores, isso pode levar à necessidade de criação de mais testes nas camadas de integração e de sistema. Com isso a pirâmide pode ser invertida, transformando-se em um cone, como pode ser visto na Figura 6.2 abaixo, demandando mais custo de realização dos testes. Quando não há tempo hábil para automatização desses outros testes, é comum que sejam realizados apenas testes de sistema manual de forma exploratória [11].

Figura 6.2: Modelo do cone de testes automatizados.

Uma boa prática seria capacitar a equipe de testes para investir na criação de testes automatizados na camada de integração. Esses testes podem ser criados antes mesmo de todo o sistema ser implementado, através de objetos mocks, descritos no capítulo anterior, garantindo que os requisitos macro do sistema serão atendidos. Esses testes de integração podem ser feitos em uma interface do sistema que se comunica com a interface gráfica. Há algumas ferramentas de teste que podem ser utilizadas para os testes de integração com API REST, como: Postman e Cypress. Isso foi explicado no capítulo 5, onde é possível realizar os testes de integração mesmo sem conhecer a linguagem de programação do sistema. Em desenvolvimentos ágeis, utilizar o modelo de pirâmide de testes pode ser uma escolha, quando se deseja ter uma integração contínua do sistema, já que para isso testes automatizados são essenciais. A integração contínua é uma forma de disponibilizar futuras versões do sistema à medida que novas funcionalidades são criadas, minimizando o risco das funcionalidades das versões anteriores pararem de funcionar. Veja na Figura 6.3 abaixo um modelo de integração contínua. Nela, observa-se que a cada etapa de desenvolvimento, os testes automatizados são executados e uma nova versão é lançada.

Figura 6.3: Fluxo de integração contínua simplificado.

Para que a integração contínua seja efetiva, os testes automatizados são executados para impedir ou permitir a integração de uma nova funcionalidade. Dessa forma, eles podem melhorar a qualidade e reduzir o tempo para validar e lançar novas atualizações do sistema.

7. Como elaborar um Roteiro de Teste? Roteiro de teste é um documento descrito pela equipe de testes, que contém um conjunto de casos de teste necessários para realizar os testes de um determinado requisito de um sistema. Um caso de teste é composto por uma sequência de passos a serem seguidos no sistema e um resultado esperado. Segue no Quadro 7.1 abaixo um exemplo de caso de teste para a autenticação de um usuário, conforme a Figura 7.1.

Figura 7.1: Tela de autenticação que permite a entrada de um usuário. Quadro 7.1: Exemplo de caso de teste.

CT 01 - Realizar autenticação de usuário Precondição: Usuário possuir um cadastro. Passos:

1. Informar o e-mail do usuário 2. Informar senha do usuário 3. Clicar no botão ‘Entrar’

Resultado esperado: 1. Usuário consegue entrar no sistema.

Os testes funcionais, quando realizados de forma manual, podem necessitar da elaboração de um roteiro de teste. A qualidade desses roteiros influencia diretamente na eficiência em detectar

falhas em um sistema. Portanto é possível melhorar a qualidade dos casos de teste através de alguns pontos importantes, descritos a seguir, que podem ser levados em consideração. Quando um roteiro de teste é escrito de forma objetiva, ele é facilmente executado pelo testador. Uma prática que pode tornar um roteiro de teste mais objetivo é realizar revisões, com a finalidade de detectar problemas de compreensão ou irrelevância nos casos de teste. Roteiros de teste eficientes são aqueles que atingem a maior cobertura de requisitos do sistema possível e encontram o maior número de defeitos. Um caso de teste objetivo é aquele que possui passos referentes a uma única funcionalidade. Um caso de teste deve ser também autossuficiente, nele deve estar contida toda a informação necessária para executá-lo, ou seja, deve haver uma descrição sobre a precondição do sistema para que o teste seja realizado. É importante evitar casos de teste exaustivos, com um número muito grande de passos. Testes grandes, que tomam muito tempo, tendem a causar dispersão no testador e assim ele acaba perdendo o foco principal do teste. Outra questão importante é manter a equipe de testes sempre informada sobre o andamento dos projetos, principalmente a respeito da mudança de requisitos. Quando há uma nova versão do documento de especificação do sistema, precisa haver atualização no roteiro de teste daquele determinado caso de uso. Ao aplicar boas práticas durante a elaboração de um roteiro de teste, é possível obter uma melhoria significativa na execução dos testes. Pois os casos de teste se tornam mais consistentes e possuem informações completas para auxiliar os testadores durante a execução. Outro benefício é a possibilidade de reutilizar os casos de teste em outros roteiros semelhantes. Um roteiro pode ser elaborado a partir dos documentos de especificação de um determinado requisito do sistema, como: especificação funcional, guia de interface e modelagem do banco de dados, etc. Roteiros de teste podem ter outras nomenclaturas, como: Projeto de Teste, Plano de caso de teste, Especificação de Teste ou Script de Teste. Os roteiros são importantes no momento da execução dos testes, pois o testador consegue realizar uma sequência de passos de forma prática, sem a necessidade de consultar todos os documentos de especificação no momento da realização dos testes. Em geral um roteiro de testes é composto por um conjunto de Casos de teste, mas além deles pode haver também as seções de Localização e Objeto de Teste, descritas na Figura 7.2 a seguir.

Figura 7.2: Estrutura de um roteiro de teste.

7.1. Localização Essa seção do roteiro de teste serve para agrupar um conjunto de casos de teste à localização da tela do sistema, na qual os testes serão executados. A localização pode ser escrita da seguinte forma: Tela inicial > Tela cadastro de usuário

7.2 Objeto de teste Uma localização pode conter 1 (um) ou mais objetos de teste, onde este pode ser definido como a ideia global de um conjunto de casos de teste. Por exemplo, na localização descrita anteriormente, Tela inicial, um possível objeto de teste seria o Cadastro de usuário no sistema. Outro objeto de teste para esta mesma localização poderia ser Autenticação de usuário no sistema. Dessa forma o objeto de teste pode agrupar 1 (um) ou mais casos de teste.

7.3. Caso de teste Um caso de teste é composto por uma descrição, por uma precondição, pelo procedimento e pelo resultado esperado, que podem ser observados abaixo: ● ●

Na descrição está a ideia específica do caso de teste; A precondição é um requisito para o comportamento do sistema antes da execução do caso de teste;

● ●

Nos passos estão os passos para a execução do caso de teste, que não deve fugir do foco exposto na descrição do caso de teste; O resultado esperado descreve como o sistema deveria se comportar após a execução do procedimento do caso de teste.

Exemplo: Um modelo de roteiro de teste, pode ser visualizado no Quadro 7.2: Quadro 7.2: Modelo de roteiro de casos de teste. Localização:

Tela inicial > Tela cadastro de usuário

Objeto de teste:

Cadastrar usuários

Caso de Teste:

Verificar campos obrigatórios

Precondição:

Sistema estar disponível

Passos: 1. Entrar na tela: Inicial > Cadastro 2. Não preencher os campos obrigatórios 3. Clicar no botão ‘Cadastrar’ Resultado esperado: 1. O sistema exibe uma mensagem solicitando o preenchimento de campos obrigatórios. Caso de Teste:

Verificar cadastro com sucesso

Precondição:

Sistema estar disponível

Passos: 1. Entrar na tela: Inicial > Cadastro 2. Preencher os campos obrigatórios 3. Clicar no botão ‘Cadastrar’ Resultado esperado: 1. O sistema exibe uma mensagem de sucesso. Localização:

Tela inicial > Tela autenticação de usuário

Objeto de teste:

Autenticar usuário

Caso de Teste:

Verificar login com sucesso

Precondição:

Usuário possuir cadastro

Passos: 1. Entrar na tela: Inicial > Entrar 2. Preencher o e-mail e senha válidos 3. Clicar no botão ‘Entrar’ Resultado esperado: 1. O sistema realiza a autenticação do usuário.

Cada execução do roteiro deve ser guardada como histórico, para que o líder de teste tenha o conhecimento do número de defeitos encontrados no sistema e criar indicadores e métricas de teste para o sistema. Alguns pontos positivos sobre a criação de roteiros de teste, são: ● É possível ter controle sobre quais requisitos do sistema foram testados.

● ●

É possível criar estratégias de teste para realizar testes mais eficientes. É possível selecionar um subconjunto de casos de teste para serem testados em um teste de regressão.

Alguns pontos negativos sobre os roteiros de teste, são: ● Dependem de uma especificação de requisitos do sistema. ● Requerem um tempo de análise dos requisitos do sistema para que seja possível criar o roteiro. ● Ficam desatualizados a cada alteração na especificação de requisitos. Quando a equipe de testes possui muitos membros, é importante que os roteiros sejam compartilhados, para que toda a equipe tenha acesso aos artefatos de teste. Para isso existem ferramentas que permitem criar roteiros de teste, identificar cada atualização e gerenciar a execução de cada roteiro de teste. Uma ferramenta gratuita e de código livre, que contém todos esses atributos é o TestLink [17].

8. Técnicas de teste Durante a criação de roteiros de teste, nem sempre é possível criar casos de teste para todos os cenários existentes. Além disso, nem sempre há tempo hábil para executar uma grande quantidade de casos de teste manualmente. É importante considerar e avaliar diferentes técnicas de roteiros de teste a fim de criar um roteiro mais eficaz. Pode-se categorizar essas técnicas de acordo com a seguinte estrutura presente na Figura 8.1:

Figura 8.1: Classificação das técnicas de teste.

●

●

●

Técnicas baseadas na especificação: ○ Classes de equivalência; ○ Análise de valor limite; ○ Tabela de decisão; ○ Diagrama de transição de estados. Técnicas baseadas na estrutura: ○ Fluxograma; ○ Teste de cobertura. Técnicas baseadas em experiência: ○ Descoberta do erro; ○ Teste exploratório.

Para compreender melhor a relação entre uma especificação de requisitos e as estratégias de criação de roteiros de teste pode-se observar a Figura 8.2 abaixo:

Figura 8.2: Relação entre especificação e técnicas de criação de roteiros de teste.

Uma documentação de caso de uso, por exemplo, contém informações relevantes durante a criação de casos de teste. A interação entre cada caso de uso, com base nas pré e pós-condições, pode ser modelada em um diagrama de estados. A descrição dos fluxos principais, alternativos e de exceção podem ser modelados em um diagrama de fluxograma e em cada caminho possível desse fluxo um caso de teste poderá ser criado. Ainda na especificação dos dados que trafegam pelo sistema, como: tipo, limite, obrigatoriedade, etc. Pode-se utilizar as técnicas de classes de equivalência ou valor limite na criação de casos de teste. Por fim, a definição de regras de negócio do sistema pode ser modelada em uma tabela de decisão, a qual pode ser convertida em diferentes casos de teste. Cada uma dessas técnicas será

detalhada a seguir, nas subseções deste capítulo.

8.1. Classe de equivalência A técnica classe de equivalência é utilizada para reduzir o número de casos de teste a um nível controlável. Dessa forma, todas as combinações de possíveis dados de entrada são divididas em classes. Assim, o objetivo da criação das classes de equivalência é cobrir o maior número de requisitos com um menor número de casos de teste [5]. Observe na Figura 8.3 uma abstração da divisão de classes.

Figura 8.3: Classes de equivalência de forma abstrata.

Uma forma de compreender melhor as classes de equivalência pode ser observando o Quadro 8.1: Quadro 8.1: Exemplo de classes de equivalência. Intervalo de valores 1 classe válida

1 classe inválida

Casos de teste

Valores permitidos

Classes

Entradas

Tipo da classe

CT01

18 a 60 anos

18 a 60

Idade = 40

Válida

CT02

< 18

Idade = 10

Inválida

CT03

> 60

Idade = 100

Inválida

No exemplo acima, considerando os valores permitidos, em um campo ‘idade’ do sistema, foram definidas 2 (duas) classes de equivalência: valores válidos e valores inválidos. Como pode ser observado, restringiu-se aos casos de teste CT01, CT02 e CT03, os quais são equivalentes a realizar testes com qualquer valor dentro de cada classe. Desta forma, em vez de criar 100 casos de teste foram criados apenas 3 representativos para as classes de equivalência.

8.2. Análise de valor limite

Considerando a técnica de classe de equivalência, é possível explorar os limites dos valores e criar casos de teste mais eficientes. A técnica de análise de valor limite foi elaborada por perceberem que havia uma maior chance de erros quando as entradas são referentes ao limite do domínio [5]. Assim, no momento de escolher os valores para cada classe de equivalência, eles serão guiados pelo valor limite. Observe na Figura 8.4 os valores do limite da fronteira no intervalo numérico.

Figura 8.4: Apresenta valores limite em um intervalo.

Dessa forma, é possível aumentar o número de casos de teste, para que eles se tornem mais eficientes, por terem uma maior chance de encontrar erros. No Quadro 8.2, há um exemplo de múltiplas entradas para as idades, onde o número de casos de teste foi expandido de 3 (três) para 6 (seis) casos de testes. Quadro 8.2: Exemplo de análise de valor limite. Casos de teste

Valores permitidos

Classes

Entradas

Tipo da classe

CT01 CT02 CT03 CT04

18 a 60 anos

18 a 60

Idade = 18 Idade = 19 Idade = 59 Idade = 60

Válida

CT05

< 18

Idade = 17

Inválida

CT06

> 60

Idade = 61

Inválida

Além destes 6 (seis) valores de entrada, é possível realizar um refinamento dos casos de teste e criar outros casos de teste baseados na técnica de probabilidade de um erro ocorrer com as seguintes entradas, conforme será apresentado no Quadro 8.3: Quadro 8.3: Exemplo de análise de valor limite por probabilidade do erro. Casos de teste

Valores permitidos

Classes

Entradas

Tipo da classe

CT01 CT02 CT03 CT04

18 a 60 anos

18 a 60

Idade = 18 Idade = 19 Idade = 59 Idade = 60

Válida

CT05

< 18

Idade = 17

Inválida

CT06

> 60

Idade = 61

Inválida

CT07

Zero

Idade = 0

Inválida

CT08

Negativo

Idade = -18

Inválida

CT09

Branco

Idade = Nula

Inválida

CT10

Inválido

Idade = ABC

Inválida

Após adicionar os casos de testes referente à técnica de probabilidade do erro, no total foram criados 10 casos de teste. Com isso, evitou-se realizar testes para cada entrada válida ou inválida, sendo necessário apenas um subconjunto equivalente dessas entradas.

8.3. Tabela de decisão A tabela de decisão é uma técnica que define quais ações serão executadas pelo sistema quando houver um conjunto de entradas predeterminado. Dessa forma as regras de negócio do sistema podem ser descritas em uma tabela, cujas colunas representam diferentes cenários. Cada célula da tabela possui N valores de entrada (condições) e 1 saída (ações), como pode ser observado no Quadro 8.4: Quadro 8.4: Tabela de decisão com 4 regras. Exemplo: critério de decisão para aplicar desconto na mensalidade dos discentes. Regra 1

Regra 2

Regra 3

Regra 4

Casado?

Sim

Sim

Não

Não

Bom aluno?

Sim

Não

Sim

Não

60

25

50

0

Condições

Ações Desconto (%)

A técnica de tabela de decisão pode ser utilizada para criar casos de teste de forma simples. Basta trocar as colunas que contêm as regras por casos de teste. Em seguida, trocar as condições por entradas e as ações por resultados esperados. Um exemplo desse tipo de tabela, representando casos de teste, pode ser observada neste Quadro 8.5: Quadro 8.5: Tabela de decisão convertida em casos de teste. CT001

CT002

CT003

CT004

Casado?

Sim

Sim

Não

Não

Bom aluno?

Sim

Não

Sim

Não

Entradas

Resultados esperados Desconto (%)

60

25

50

0

8.4. Diagrama de transição de estados O diagrama de transição de estados é uma técnica similar à tabela de decisão, no entanto o foco é na transição dos comportamentos e não nas saídas do sistema. Assim, casos de testes são baseados nas possíveis entradas que causam uma mudança de comportamento no sistema. A Figura 8.5 apresenta um diagrama de estados para um sistema de bonificação para clientes, os quais podem ganhar cupons de acordo com suas ações no sistema.

Figura 8.5: Diagrama de estados representando sistema de cupons para clientes.

Ao observar as possíveis entradas e as mudanças de estado do sistema, é possível transformar cada situação em casos de teste, como pode ser observado no Quadro 8.6: Quadro 8.6: Casos de teste baseados em um diagrama de estados. Caso de Teste

Função

Evento/Entrada

Resultado Esperado

CT01

Convite amigos

Amigo aceita

Cupom bônus

CT02

Convite amigos

Amigo não aceita

Sem cupom

CT03

Cupom bônus

Cupom usado

Desconto

CT04

Cupom bônus

Não usa em 10 dias

Cupom expira

Nesta tabela pode-se observar que cada estado foi representado como uma função do

sistema, as transições são as entradas dos casos de teste e o novo estado após a transição é o resultado esperado.

8.5. Fluxograma A técnica de fluxograma permite criar um caso de teste para cada caminho completo do fluxo. Assim, se o fluxo possui vários caminhos possíveis, cada caminho será transformado em diferentes casos de teste. Por isso, pode-se considerar que essa técnica é baseada na estrutura, ou seja, nos componentes que compõem todo o sistema. Um exemplo de fluxograma de um sistema pode ser observado na Figura 8.6:

Figura 8.6: Fluxograma de um cadastro de discentes em sistema acadêmico.

Nesse caso, pode-se usar também uma tabela para representar o conjunto de casos de teste para esse fluxograma. Para cada caminho do fluxo pode-se criar um ou mais casos de teste, como descrito neste Quadro 8.7. Quadro 8.7: Transformando um fluxograma em casos de teste. Caso de Teste

Perfil de Usuário

Caso de Uso

Fluxo

Resultado Esperado

CT01

Coordenador

Cadastrar Discente

Principal

Cadastrado com sucesso

CT02

Coordenador

Cadastrar

Alternativo

Operação

Discente

cancelada

CT03

Diretor

Alterar Discente

Principal

Alterado com sucesso

CT04

Diretor

Alterar Discente

Alternativo

Operação cancelada

8.6. Teste de cobertura O teste de cobertura tem a finalidade de criar uma quantidade de casos de teste para garantir que o sistema seja amplamente testado, de acordo com um percentual predefinido. A cobertura geralmente é calculada investigando o código-fonte do sistema, onde após a realização dos testes, identificam-se quais partes do código foram testadas e quais não foram. Há ferramentas automáticas para calcular esse percentual, que são instaladas na própria ferramenta de desenvolvimento do sistema, como pode ser visto na Figura 8.7.

Figura 8.7: Ferramenta que calcula o percentual de cobertura dos testes realizados em um código-fonte.

Ao final da realização dos testes, partes do código ficam marcadas nas cores verde, amarelo e vermelho. Verde indica que passou completamente pela linha de código, amarelo indica que não testou todas as condições em uma determinada linha e vermelho indica que os testes não

entraram naquele trecho.

8.7. Descoberta de erro Na técnica de descoberta de erro, os testes são baseados nas experiências anteriores de um testador. Os casos de teste selecionados contêm os testes que têm uma maior probabilidade de detectar defeitos. Durante os testes, entradas inválidas são inseridas nos campos com o intuito de verificar se o sistema é robusto o suficiente em condições anormais [5]. Apesar de não ser necessário criar roteiros de teste específicos para cada sistema, os testadores podem se basear em um checklist genérico para aplicações que possuem determinadas características. A lista do Quadro 8.8 possui exemplos de testes genéricos que podem ser utilizados no contexto acima. Quadro 8.8: Lista com 21 casos de teste genéricos para aplicações web. Casos de teste genéricos 1. Layout

2. Campos obrigatórios

3. Máscara

4. Valores permitidos

5. Valores nulos

6. Valores limite

7. Caracteres especiais

8. Espaços em branco

9. Ortografia

10. Perfil de usuário

11. Autenticação

12. Eventos do mouse

13. Clique duplo

14. Navegador

15. Responsividade

16. Tempo de resposta

17. Formatação de tabela

18. Alerta de confirmação

19. Direção dos links

20. Descrição de legenda

21. Intervalo de datas

1. Layout: identifique a presença ou ausência de elementos no layout de cada tela do sistema. 2. Campos obrigatórios: verifique se os campos obrigatórios estão sendo corretamente tratados. Por exemplo: ao deixar um campo obrigatório em branco, o sistema exibe uma mensagem. 3. Máscara: verifique se os campos estão sendo preenchidos com suas respectivas máscaras. Por exemplo: o campo CPF deve ser preenchido com a máscara NNN.NNN.NNN-NN 4. Valores permitidos: verifique se os campos estão sendo validados no caso de receberem valores não permitidos. Por exemplo: campos numéricos não devem aceitar caracteres especiais e/ou letras. 5. Valores nulos: verifique se um campo que só pode aceitar valor maior que zero, está aceitando valor menor ou igual a zero. 6. Valores limite: verifique qual o valor máximo e mínimo permitido para cada campo. Por exemplo: ao inserir um valor fora do limite, o sistema exibe uma mensagem. 7. Caracteres especiais: verifique se os campos de texto estão aceitando caracteres

especiais indevidos. Pois se o sistema processar um código HTML ou SQL, o sistema pode ficar vulnerável a ataques. 8. Espaços em branco: num campo obrigatório, preencha com espaços em branco e verifique se o sistema detecta que o campo estava sem nenhuma informação. 9. Ortografia: verifique a ortografia de todo e qualquer texto do sistema, inclusive de mensagens de alerta e textos dos ícones. 10. Perfil do usuário: há sistemas que possuem diferentes perfis de usuários com diferentes privilégios. Neste caso, é importante criar diferentes casos de teste considerando na pré-condição o perfil do usuário. Inclusive deve haver casos de teste considerando que um usuário comum pode não ter acesso às funcionalidades de um administrador do sistema. 11. Autenticação: quando o sistema possuir autenticação do usuário, é importante criar casos de testes para não permitir que um usuário não autenticado acesse o sistema. 12. Eventos do mouse: realize testes que copiam textos com o mouse e colam para verificar se estes campos estão sendo validados corretamente. 13. Clique duplo: ao criar um roteiro de teste para uma tela de cadastro, incluir um caso de teste que verifique o comportamento do sistema quando o usuário clica duas vezes no botão Salvar. Neste caso, o sistema não deve incluir os 2 registros, apenas 1 deles. 14. Navegador: os sistemas web geralmente possuem comportamentos diferentes quando são visualizados em diferentes navegadores. Com isso é importante criar um caso de teste para executar o sistema nos principais navegadores, por exemplo, Edge, Chrome, Firefox e Safari. 15. Responsividade: os sistemas web também podem ter exibições diferentes dependendo da tela do dispositivo do usuário. Neste caso, é importante que seja criado um caso de teste para verificar o comportamento do sistema nas principais resoluções. 16. Tempo de resposta: verifique se o tempo de resposta para carregar uma página ou um combo box não ultrapassa o tempo máximo esperado. No caso de listas, pode ser necessário incluir paginação para melhorar o tempo de resposta. 17. Formatação de tabela: verifique se o texto contido em uma tabela possui alguma ordenação, paginação, se o alinhamento dos campos está de acordo com o padrão especificado. 18. Alerta de Confirmação: é importante que haja alertas de confirmação em botões, cuja ação é de excluir ou cancelar uma operação. Criar casos de teste que verifiquem se ao clicar em ‘Não’, o sistema realmente “Não exclui” o elemento. 19. Direção dos links: verifique se os links de sistemas web estão sendo direcionados para telas corretas de acordo com sua descrição. Além disso, pode se verificar se após o clique os links continuam visíveis. 20. Descrição de legenda: em sistemas que possuem ícones para representar botões ou legendas, é importante verificar se há um texto que descreva aquele ícone, seja visível ou quando passamos o mouse.

21. Intervalo de datas: quando o sistema permite filtrar dados através de um intervalo de datas, verifique se a data inicial não pode ser maior que a data final.

8.8. Teste exploratório Na técnica de teste exploratório, os testes são realizados sem a presença de um roteiro. Esses testes podem ser usados em equipes de teste de processos ágeis, quando nem sempre há especificação detalhada do sistema ou quando não há tempo hábil para criar roteiros de teste. Essa técnica depende da experiência do testador, pois cada teste executado é projetado na mente do testador durante a execução dos testes. Uma desvantagem desse tipo de teste é que não é fácil ter controle do que já foi testado. Durante esses testes, diferentes técnicas descritas neste capítulo podem ser utilizadas, como: tratamento de entradas com classes de equivalência e valor limite; cobertura dos requisitos com fluxograma e diagrama de transição; ou validação das entradas com a técnica descoberta de erro.

9. Onde utilizar as técnicas de teste? Compreender cada técnica de teste descrita no capítulo anterior é importante para decidir em que momento do desenvolvimento do sistema elas podem ser utilizadas. Essa decisão pode depender do tipo de especificação do sistema, do nível de teste a ser testado, algumas dependem da arquitetura do sistema e outras dependem apenas da experiência do testador. Quando essa análise não é feita, pode-se gastar tempo e custo do projeto e não ter o retorno esperado. O Quadro 9.1 descreve o grau de dependência de cada técnica com os critérios definidos. Quadro 9.1: Exemplo de tomada de decisão sobre cada técnica de teste. Técnica

Depende de especificação

Experiência do testador

Nível de testes

Equivalência

Sim

Média

U/I/S/A

Valor limite

Sim

Média

U/I/S/A

Tabela de decisão

Sim

Média

U/I/S/A

Técnica

Depende da Documentação

Experiência do testador

Nível de testes

Transição de estados

Sim

Média

I/S/A

Fluxograma

Sim

Média

I/S/A

Cobertura

Não

Alta

U/I/S/A

Técnica

Depende da Documentação

Experiência do testador

Nível de testes

Descoberta de erro

Não

Alta

S/A

Exploratório

Não

Alta

S/A

Legenda: U= Unidade; I = Integração; S = Sistema; A = Aceite.

Algumas dessas técnicas podem ser utilizadas tanto na construção de testes manuais como também em testes automatizados e em diferentes níveis de teste. Por exemplo, pode-se utilizar as técnicas de classe de equivalência ou análise do valor limite em testes unitários. As técnicas de tabela de decisão, diagrama de estados e fluxograma podem ser utilizadas em testes de integração. Logo, a verificação da cobertura dos testes em teste automatizados é desejável. Portanto, quanto mais casos de testes automatizados forem realizados, menor será o número de testes manuais necessários. Para os testes funcionais, pode-se combinar várias dessas técnicas para criar os roteiros de teste ou utilizar as técnicas de testes exploratórios e descoberta de erro, que simulam o sistema do ponto de vista do usuário final.

10. Como reportar defeitos? Encontrar defeitos é o principal objetivo dos testes de software, contudo não é o único. Os testes também podem ser utilizados para indicar melhorias na interface ou confirmar que um sistema é seguro. No momento em que um defeito é detectado, é de suma importância que seu cadastro seja realizado. Já que os erros podem não existir mais à medida que novos dados são inseridos na aplicação ou novas versões são lançadas. Dessa forma, após o defeito ser registrado, é uma boa prática tentar reproduzir a falha novamente, a fim de perceber se a descrição do defeito é suficiente para ser corrigido pelo desenvolvedor. O uso de imagens com marcações na tela é relevante para o entendimento do erro. Quando houver uma documentação, vale a pena verificar se existe alguma regra de negócio que confirme a existência do defeito. Isso permite que o testador tenha mais credibilidade sobre o erro reportado. No momento da descrição dos defeitos, há 6 características que ajudam no momento do registro do defeito: ● Objetivo: o defeito precisa ser claro e objetivo, para aumentar a chance de ele ser corrigido. ● Precisão: tente garantir que é realmente um erro e não um falso-positivo. ● Neutralizar: ao descrever os defeitos, escreva apenas fatos. Evite humor ou emoção. ● Reproduzir: sempre que possível, reproduza o defeito ao menos 1 vez antes de submeter para a equipe de desenvolvimento. ● Impacto: observe qual o impacto desse defeito e identifique a prioridade de correção. ● Evidência: apresentar uma imagem e um texto com os passos para execução do defeito pode ser essencial para que os desenvolvedores consigam corrigir o defeito.

10.1. Taxonomia do defeito As taxonomias representam um diagnóstico do estado do defeito detectado. Os defeitos podem ser caracterizados de acordo com 4 taxonomias da Figura 10.1:

Figura 10.1: Taxonomia dos defeitos.

● ● ● ●

Categoria: indica o tipo de defeito identificado. Situação: indica o ciclo de vida de um defeito. Prioridade: indica o momento que é esperado que o defeito seja corrigido. Severidade: indica o impacto que o defeito causa no sistema caso ele não seja corrigido.

10.2. Ciclo de vida do defeito A Figura 10.2 apresenta o fluxograma referente ao ciclo de vida de um defeito durante o desenvolvimento do software. Esse ciclo inicia quando um defeito é encontrado. Em uma ferramenta de gerenciamento de defeitos, o estado da tarefa que descreve o defeito ficará como “Aberto”. Dessa forma, cada etapa que ele passar até ser corrigido precisa ser respeitada para que se tenha um maior controle sobre os erros que já foram corrigidos ou não.

Figura 10.2: Ciclo de vida do defeito.

No momento em que o defeito inicia a sua correção, o seu estado fica “Em andamento”, onde há 3 chances de estado seguinte, que são: ● Rejeitado: quando o desenvolvedor não consegue reproduzir o defeito. ● Feedback: quando o desenvolvedor possui alguma dúvida sobre o defeito e não consegue corrigir. ● Resolvido: quando o erro é corrigido e precisa de uma nova revisão do testador para poder fechar ou abrir novamente o defeito. O Quadro 10.1 abaixo apresenta um modelo de reportar defeitos, independente se for manual ou utilizando alguma ferramenta para gerenciar os defeitos. Quadro 10.1: Modelo de descrição de defeitos. Localização:

Menu principal > Cadastro > Obras

Descrição do defeito:

O sistema não exibe mensagem de erro quando campos obrigatórios não são preenchidos.

Precondição:

O usuário ter realizado autenticação no sistema.

Perfil: Engenheiro da obra Passos:

1. Entrar na tela de Cadastro de Obras e clicar em ‘Adicionar’ 2. Não preencher os campos obrigatórios. 3. Clicar no botão ‘Cadastrar’ Evidência do erro: 1. O sistema não está exibindo uma mensagem de erro solicitando o preenchimento dos campos obrigatórios. Resultado esperado: 1. Exibir mensagens solicitando o preenchimento de campos obrigatórios. Imagem/vídeo: anexar uma imagem ou vídeo que represente a falha no sistema.

A imagem deve ser descritiva de forma que o desenvolvedor consiga perceber a evidência do erro rapidamente. Para que não haja dúvidas sobre o que deve ser corrigido. Como pode ser observado na Figura 10.3, a imagem pode ser editada incluindo textos e destaques para referenciar os pontos de ajuste.

Figura 10.3: Exemplo de imagem que representa um bug.

Durante a detecção de um erro, mais importante que encontrá-los é garantir que o desenvolvedor irá conseguir reproduzir e corrigir corretamente a falha. Além disso, é importante que o defeito tenha sua validade com base em algum documento de especificação, o qual poderá ser referenciado na descrição da “Evidência do erro”. Outra informação que pode ser relevante na descrição do defeito é informar os dados de entrada ou perfis de usuários utilizados durante a falha na execução do caso de teste.

11. Como entrar na carreira de teste de software? E quem pode testar um sistema? A resposta é simples, qualquer pessoa que esteja envolvida com o sistema. Assim, os prováveis candidatos a testador dos sistemas são: desenvolvedores, testadores, clientes e usuários finais. Cada tipo de testador analisará o sistema de uma ótica diferente. O cliente irá identificar se o sistema faz o que foi solicitado. O usuário final testará a usabilidade do sistema. O desenvolvedor verificará se o código continua funcionando a cada atualização. Já o testador poderá analisar todas essas verificações que os outros fazem, sendo que de forma antecipada, reduzindo custos para o projeto, utilizando técnicas e metodologias predefinidas. “O custo de um bug encontrado no início do projeto é bem menor do que quando ele é detectado pelo usuário final.” - Myers [1] Para quem está querendo seguir uma carreira na área, o perfil de um testador pode ser identificado pela sua precisão em analisar os sistemas, geralmente eles são minuciosos e atentos a todos os detalhes. O testador tem que conseguir interpretar bem os textos da documentação do sistema e ser responsável por atividades dentro do processo de desenvolvimento que garantem a qualidade do sistema que está sendo desenvolvido. Além disso, é essencial que o testador goste de se comunicar, pois ele estará em contato com todos da equipe, seja o cliente no levantamento dos requisitos ou desenvolvedores no momento de reportar um bug do sistema. Quando o testador possui conhecimentos em lógica de programação de software, ele terá habilidades desejáveis no momento de pensar em casos de testes mais robustos e que têm maior probabilidade de encontrar defeitos. No entanto, não é necessário saber programar para conseguir testar um sistema. As vagas de emprego descrevem a carreira com os seguintes requisitos: ● Gerente de testes ● Analista de teste manual ● Analista de automação de teste

11.1. Gerente de testes O gerente de testes é um papel necessário para planejar os tipos de testes que serão realizados em cada projeto e irá se comunicar com os gerentes dos projetos para alinhar-se com as novas demandas e planejar as atividades de teste da equipe. Além disso, o gerente de testes define um plano estratégico de como os testes serão realizados, quais ferramentas serão utilizadas, quais tipos de testes serão necessários. Ele também consegue realizar métricas sobre o andamento dos testes e criar relatórios para a alta gestão da empresa com esses dados coletados.

11.2. Analista de teste manual O analista de teste manual tem como responsabilidade conhecer o negócio do sistema, revisar documentação e identificar conflitos nos requisitos. Além disso, ele deve criar casos de teste e executá-los a fim de identificar defeitos. À medida que defeitos são encontrados, ele deve reportar e gerenciar todo o ciclo de vida desses defeitos até o seu encerramento.

11.3. Analista de automação de teste O analista de automação de teste tem como responsabilidade criar scripts de teste automatizados e mantê-los à medida que o sistema evolui. Além disso, ele precisa ter conhecimento sobre os novos requisitos do sistema como também cada atualização, para que os scripts de testes continuem sendo executados a cada iteração. Quando necessário, os defeitos identificados pelos testes automatizados podem ser reportados e gerenciados até o seu encerramento.

12. Como planejar uma estratégia de teste? O plano estratégico de teste será usado durante o desenvolvimento de um software. Ele pode ser descrito em um documento padrão ou pode ser definido em uma ferramenta de gerenciamento de projetos. Geralmente, esse planejamento das estratégias é responsabilidade do líder de testes. No entanto, quando não há uma equipe de testes no projeto, o plano pode ser criado pelo líder de desenvolvimento. As principais seções que compõem o plano de estratégias de teste são: escopo, lista de requisitos, recursos, cronograma, prioridades e indicadores, como ilustrado na Figura 12.1.

Figura 12.1: Modelo de plano de estratégico de teste resumido.

12.1. Escopo Define quais funcionalidades deverão ser testadas em nível macro até a entrega de uma parte do produto. Além disso, o escopo também pode descrever o que não será testado (escopo negativo). As informações contidas no escopo podem ser coletadas no plano do projeto, em uma reunião com o cliente ou com o analista de sistemas.

12.2. Lista de requisitos Define os requisitos funcionais e não-funcionais que devem ser testados. ● Requisitos funcionais: casos de uso. ● Requisitos não-funcionais: desempenho, segurança, interface, etc. Para cada requisito definido, é necessário descrever a técnica de teste que será utilizada, para garantir que o sistema seja testado de forma eficiente, mas atendendo os custos do projeto.

12.3. Recursos Os recursos necessários para realizar os testes de software em um projeto precisam ser definidos. Os recursos podem ser do tipo:

●

●

●

Recursos humanos: ○ Gerente de teste; ○ Analista de teste; ○ DevOps. Ambientes: ○ Ambiente de teste; ○ Ambiente de homologação. Ferramentas de teste: ○ Open source; ○ Proprietárias.

12.4. Cronograma O cronograma define o tempo que será necessário para realizar todas as atividades de teste dentro de um projeto e os prazos relacionados. O cronograma da equipe de testes deve estar alinhado com o do projeto. O cálculo do esforço para realizar as atividades de teste depende de métricas coletadas a partir de estimativas e da base histórica. Essas métricas precisam ser retroalimentadas à medida que novas atividades são realizadas e os números mudam periodicamente. Uma recomendação que o líder de teste pode fazer é solicitar que sua equipe registre as horas trabalhadas em cada atividade. Além do tempo gasto por cada atividade, é importante ter o conhecimento do tamanho do projeto, pois cada atividade de teste pode variar de acordo com o tamanho da especificação de cada funcionalidade do sistema. Exemplo: Uma funcionalidade sobre a autenticação do usuário em um sistema pode requerer cerca de 5 casos de teste. Mas uma funcionalidade de transação bancária pode necessitar de 20 casos de teste. Logo, o tempo para elaborar o roteiro de teste varia de acordo com o tamanho da funcionalidade. Esse tamanho pode ser percebido através da quantidade de regras de negócio que há no caso de uso. Geralmente é necessário um ou mais casos de teste para cada regra de negócio. Assim, no caso de haver uma métrica para o tempo de criação de um caso de teste, será possível estimar mais facilmente o tempo para elaboração de um roteiro de teste para uma determinada funcionalidade. As métricas que podem ser utilizadas para calcular o cronograma de testes são: ● Tempo de elaborar o roteiro de teste: esse tempo varia de acordo com o número de casos de teste criados para o roteiro. ● Tempo de executar os testes: esse tempo varia de acordo com o tamanho do roteiro e com o tipo de técnica de teste que será utilizada. ● Tempo de reportar defeitos: esse tempo depende da existência de erros no sistema. Nesse caso, pode-se utilizar uma base histórica para saber o número médio de erros que são encontrados em cada funcionalidade do sistema. ● Tempo de homologar um defeito corrigido: esse tempo varia de acordo com o número de defeitos reportados.

12.5. Prioridades A prioridade deve ser criada para definir o que precisa ser testado ou não, pois há projetos que possuem curto prazo e baixo custo. Logo, fica inviável realizar testes funcionais manuais em todo o sistema. Dessa forma, pode-se encontrar uma estratégia de priorização das funcionalidades que precisam de testes funcionais, utilizando roteiros de teste, e definição das funcionalidades que podem ser testadas utilizando a técnica de testes exploratórios, que possuem baixo tempo e custo de realização. As prioridades podem ser feitas com base nos requisitos do sistema. Para isso, deve-se avaliar o risco de uma falha acontecer no sistema. Assim quanto maior for o risco, mais bem elaborados devem ser os testes. A análise de riscos define risco através dos seguintes parâmetros: ● Impacto da falha sobre o sistema ● Probabilidade da ocorrência da falha Assim, o risco é calculado pela fórmula: Risco = Impacto x Probabilidade

As prioridades também podem ser utilizadas na ordenação dos casos de teste de acordo com o risco. Dessa forma, no momento de um teste de regressão, pode-se definir os casos de teste que serão testados ou não. No Quadro 12.1, foram considerados os valores “2”, “5” e “9” para definir se a probabilidade ou o impacto é baixo, médio ou alto, respectivamente. Quadro 12.1: Análise de risco para casos de teste. CASO DE TESTE

IMPACTO

PROBABILIDADE

CT001

2

2

RISCO

4

CT002

9

2

18

CT003

9

5

45

Nota: Uma análise de risco pode ser feita pelo líder de projetos durante a elaboração do Plano de Projeto. Nesse caso, diferentes riscos podem ser analisados, como: custo elevado do projeto, equipe desqualificada, novas tecnologias, falta de gerência de configuração, curto prazo para o projeto, requisitos inconsistentes, etc. Nos quadros 12.2, 12.3, 12.4 e 12.5, por exemplo, foram analisados os riscos associados aos requisitos de um sistema em desenvolvimento: Quadro 12.2: Análise de risco para regras de negócio. ATIVO - REGRAS DE NEGÓCIO AMEAÇA (RISCO)

VULNERABILIDADE (CAUSA)

Regras de negócio mudam a cada iteração PROBABILIDADE

IMPACTO

Cliente indeciso GRAU DO RISCO

3

4

12

ACEITAR O RISCO

MITIGAR (AÇÃO)

REALIZADO

Iniciar desenvolvimento após aprovação de regras

Sim

Sim

Quadro 12.3: Análise de risco para corretude dos documentos. ATIVO - CORRETUDE DOS DOCUMENTOS AMEAÇA (RISCO)

VULNERABILIDADE (CAUSA)

Documentação com requisitos incorretos

Falta de revisão na documentação

PROBABILIDADE

IMPACTO

5

4

GRAU DO RISCO

20

ACEITAR O RISCO

MITIGAR (AÇÃO)

REALIZADO

Sim

Incluir tempo no projeto para revisar todos os requisitos

Sim

Quadro 12.4: Análise de risco para completude dos documentos. ATIVO - COMPLETUDE DOS DOCUMENTOS AMEAÇA (RISCO)

VULNERABILIDADE (CAUSA)

Falta documentação para o sistema

Pouco tempo para produzir documentação completa

PROBABILIDADE

IMPACTO

4

5

GRAU DO RISCO

20

ACEITAR O RISCO

MITIGAR (AÇÃO)

REALIZADO

Não

Incluir tempo no projeto para documentar todos os requisitos

Não

Quadro 12.5: Análise de risco para consistência dos documentos. ATIVO - CONSISTÊNCIA DOS DOCUMENTOS AMEAÇA (RISCO)

VULNERABILIDADE (CAUSA)

Há divergência entre as especificações e o código do sistema

Documentação desatualizada

PROBABILIDADE

IMPACTO

5

4

GRAU DO RISCO

20

ACEITAR O RISCO

MITIGAR (AÇÃO)

REALIZADO

Não

Incluir tempo no projeto para atualizar todos os documentos

Não

Como pode ser observado no exemplo acima, para cada ameaça (risco) é importante analisar a vulnerabilidade (causa) existente que pode contribuir para cada risco acontecer. Após calcular o valor do risco, é importante definir as ações que serão tomadas para mitigar, ou seja, reduzir a chance daquele risco ocorrer. Dica: Uma boa prática é transformar os quadros de análise de risco em um checklist, que pode ser atualizado periodicamente, na coluna “Realizado”, a fim de identificar os riscos que já foram mitigados ou não. Alinhando a análise de riscos para ajudar na priorização dos testes, é possível também aplicar a técnica para os casos de uso do sistema, a fim de definir a prioridade de criação de roteiros de teste para aqueles casos de uso. Dessa forma, cada caso de uso é analisado de acordo com os critérios: impacto, probabilidade, visibilidade, complexidade e modificações frequentes. ● Impacto (IM): se a funcionalidade possuir algum erro ou parar de funcionar, os usuários vão ser gravemente impactados? ● Visibilidade (VI): o número de usuários que acessam essa funcionalidade do

sistema. ●

Complexidade (CO): a funcionalidade possui muitas regras de negócio, aumentando a chance de erros no sistema. Modificações frequentes (MF): a funcionalidade precisa ser modificada com frequência, seja por novos requisitos ou por erros recorrentes no sistema. Probabilidade (PB): existe uma probabilidade maior ou menor de existir erros nessa funcionalidade.

● ●

Quadro 12.6: Cálculo do fator de risco para casos de uso. FATOR DE RISCO UC 001 - CADASTRAR CURSO IMPACTO VISIBILIDADE

5

104

COMPLEXIDADE

ATUALIZAÇÕES

PROBABILIDADE

3

5

3

5

Quadro 12.7: Cálculo do fator de risco para casos de uso. FATOR DE RISCO UC 002 - CADASTRAR TURMA IMPACTO VISIBILIDADE

7

174

COMPLEXIDADE

ATUALIZAÇÕES

PROBABILIDADE

6

5

5

7

Quadro 12.8: Cálculo do fator de risco para casos de uso FATOR DE RISCO UC 003 - MATRICULAR ALUNO IMPACTO VISIBILIDADE

10

259

COMPLEXIDADE

ATUALIZAÇÕES

PROBABILIDADE

9

5

8

10

Conforme pode ser observado nesses quadros acima, cada critério foi definido através de uma escala de 0 a 10 pontos. Como há características mais críticas do que outras, a fórmula que calcula o fator de risco utiliza a média ponderada, na qual cada critério tem seu peso específico. FATOR DE RISCO = (IM x P1) + (VI x P2) + (CO x P3) + (MF x P4) + (PB x P5)

Esses pesos podem mudar de acordo com cada projeto. No exemplo acima, os pesos definidos para P1 a P5 foram 3, 10, 3, 3 e 5, nessa ordem. Outro ponto importante é definir uma legenda para o fator de risco final, que varia entre alta, média e baixa. Assim, cada caso de uso pode ser priorizado de acordo com seu risco. Após identificar o fator de risco de cada caso de uso, é necessário tomar a decisão de quais tipos, níveis e técnicas de teste serão realizados em cada situação.

12.6. Indicadores Os indicadores de teste podem ser traçados se forem observados os fatores de risco de cada

caso de uso, dessa forma os seguintes critérios podem ser definidos: ● Prioridade em se testar os casos de usos de acordo com o valor do fator de risco. ● Alta: maior que 150 ● Média: de 115 a 149 ● Baixa: menor que 115 ● Quantidade de casos de teste por casos de uso. ○ Acima de 30: maior que 200 ○ Até 30: de 150 a 115 ○ Até 20: menor que 115 ● Casos de uso que podem ser testados com teste exploratório. ○ Não: maior que 150 ○ Sim: menor que 150 ● Casos de uso que precisam de teste de regressão. ○ Sim: maior que 115 ○ Não: menor que 115 ● Cobertura dos testes automatizados para os casos de uso. ○ Acima de 70%: maior que 200 ○ Até 70%: de 150 a 115 ○ Até 50%: menor que 115 Além disso, os fatores de risco podem guiar para os tipos de teste a serem realizados: ● Quanto maior for ○ Impacto: então Teste de Sistema. ○ Visibilidade: então Teste de Carga. ○ Complexidade: então Teste Unitário. ○ Atualizações: então Teste de Regressão. Ao definir os tipos de teste que serão realizados para cada caso de uso, é possível definir também o modo de execução: ● Teste de Sistema – requisitos funcionais. ○ Modo: Manual. ○ Abordagem: Caixa-preta. ● Teste de Carga – requisito não-funcional de desempenho. ○ Modo: Automática. ○ Abordagem: Caixa-preta. Ao concluir cada seção do plano estratégico de testes, ele deverá ser revisado periodicamente, para verificar se as estratégias de teste, escopo, recursos e cronograma continuam valendo para o estado em que o projeto se encontra. Pois há casos em que os requisitos mudam, tornando necessário atualizar o plano para os novos critérios.

PARTE II - Relatos de experiência em teste de software

13. Como decidir se vale a pena ou não investir em teste de software? Ter ou não ter testadores para a equipe de desenvolvimento de um software é uma dúvida de muitas empresas e líderes de projeto no momento de criar suas equipes para desenvolver um novo sistema. Muitos ficam na dúvida se é realmente necessário contratar um testador especializado em vez de usar um desenvolvedor da equipe para realizar os testes. Outra dúvida recorrente, quando se resolve investir em teste de software, é sobre a necessidade de contratar testadores para cada sistema ou testadores para todos os projetos da empresa. Quando a equipe de desenvolvimento realiza testes automatizados em seus códigos (teste caixa-branca), eles ficam em dúvida se ainda é necessário um testador para fazer os testes de sistema (teste caixa-preta). E quando há poucos recursos financeiros para desenvolver um sistema, muitos se perguntam se investir algum recurso em teste é realmente necessário. Para todas as dúvidas descritas anteriormente a resposta seria: Depende! O primeiro critério a ser analisado é a criticidade do sistema, ou seja, a empresa está disposta a pagar pelo prejuízo causado por um defeito no sistema? Um defeito pode custar muito caro dependendo da especialidade do sistema. Uma boa planilha de gerenciamento de riscos pode dar essa resposta. Um modelo de planilha de riscos para auxiliar nos testes pode ser visto no capítulo 12. O mais importante a ser levado em consideração é que em todos os casos, testes sempre serão necessários. O que pode mudar é a forma em que se realizam esses testes. Assim como há muitos tipos de testes de software, há também muitas estratégias que podem ser adotadas dependendo do tipo de sistema e do processo que se está desenvolvendo. Essas estratégias podem ser descritas em um Plano de estratégias de testes, criado antes mesmo de iniciar o desenvolvimento do software. No Plano de estratégias de testes pode-se definir se haverá testes de unidade realizados pelos desenvolvedores ou não. No caso de haver testes de unidade, ainda assim existe a necessidade de realização dos testes de sistemas, pois como foi visto no capítulo 5, cada nível de teste tem sua finalidade e deve ser realizado de acordo com cada projeto. Com alguns exemplos será possível entender melhor os critérios que devem ser levados em consideração no momento de tomar uma decisão sobre os testes em um projeto. Em um cenário em que a empresa possui 3 ou mais projetos sendo desenvolvidos paralelamente, pode-se decidir ter pelo menos 1 testador por projeto ou ter uma equipe de testes especializada em testar todos os projetos da empresa. Os dois casos são viáveis dependendo do processo de desenvolvimento (ver capítulo 3) que é adotado pelos projetos. Em um processo de desenvolvimento ágil, onde entregas são realizadas em curtos períodos e novas funcionalidades podem ser incrementadas ao projeto à medida que novas versões são

disponibilizadas para o cliente, é um contexto que vale a pena possuir pelo menos um testador por projeto. Pois, nesse cenário, com entregas tão rápidas, garantir que o testador estará disponível para testar o sistema no momento exato antes de cada entrega pode ser desejável. Além disso, quando o testador é parte de apenas um projeto, ele consegue se envolver mais com os requisitos e poderá participar mais facilmente de todas as reuniões com o cliente. No caso de um processo de desenvolvimento tradicional, em cascata por exemplo, os requisitos do sistema são documentados logo após a abertura do projeto, ou seja, antes de iniciar a etapa de desenvolvimento do sistema. Além disso, as entregas, para o cliente, são planejadas e possuem prazos bem maiores do que em processos ágeis. Nesse contexto, dependendo do tamanho do projeto, pode haver pelo menos um testador por projeto, como também pode ter uma equipe de testes especializada para testar todos os projetos da empresa, paralelamente, à medida que os projetos solicitam. No caso de haver uma equipe de testes, um processo de teste de software bem definido é necessário, para que a equipe de testes consiga gerenciar bem as demandas de cada projeto, garantindo os prazos planejados pelo líder de cada projeto. Quando há uma equipe de testes para todos os projetos da empresa, será necessário um Líder de Testes para se comunicar com cada líder dos projetos e definir as atividades e estratégias de teste que serão adotadas em cada projeto. No caso de haver um ou mais testadores em cada projeto, quem será responsável por definir atividades e gerenciar os testes será o próprio Líder do Projeto. Os quadros 13.1 e 13.2 apresentam um comparativo entre ter testadores por projetos ou uma equipe de testes para todos os projetos de acordo com vários critérios. Na coluna “Testador por Projeto”, foi considerado apenas 1 testador por projeto e na coluna “Equipe de Testes” foram considerados 1 Líder de Teste e pelo menos 2 testadores. Quadro 13.1: Critérios de decisão para 1 testador por projeto.

Testador por projeto Possibilidade de haver testadores experientes e capacitados. Testadores com conhecimento detalhado sobre o projeto. Maior facilidade em cumprir prazos específicos do projeto. Risco alto para o projeto quando sair o testador da empresa. Risco alto para o projeto quando o testador entrar de férias. Maior controle sobre o momento da realização dos testes. Maior chance de haver roteiros de teste com casos de teste viciados, onde ambiguidades na coleta dos requisitos podem

esconder defeitos no sistema. Maior custo com recursos humanos, quando houver mais de 6 projetos na empresa. Quadro 13.2: Critérios de decisão para equipes de teste.

Equipe de Testes Possibilidade de haver testadores experientes e capacitados. Compartilhamento de conhecimento de testes dentro do projeto. Possibilidade de maior rotatividade de testadores. Maior chance de encontrar defeitos, considerando que o roteiro é criado para outro testador executar. Necessidade de um Líder de Teste. Necessidade de documentação detalhada do projeto. Maior chance de haver roteiros de teste revisados. Como pode ser observado nesses quadros, nos dois cenários há vantagens e desvantagens, sendo que cada critério terá mais impacto dependendo da criticidade de cada projeto, dependendo do processo de desenvolvimento adotado pela empresa e dependendo da quantidade de recursos humanos a empresa pretende investir. Nos dois casos, investimento em capacitação na área de teste de software é essencial para garantir uma maior eficiência na realização dos testes, tanto com relação à qualidade dos roteiros de teste, quanto à velocidade em realizar as atividades de teste e à quantidade de defeitos que os testadores poderão identificar. A eficiência do testador em realizar os testes pode ser fundamental para garantir um menor risco para o projeto.

14. Processo de desenvolvimento ágil ou tradicional? Durante o planejamento da construção de um software, processos de desenvolvimento precisam ser definidos para atender melhor à necessidade do projeto. Um projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo [19]. Um projeto pode ter diferentes necessidades dependendo do tipo de software que será desenvolvido. Antes de pensarmos qual o melhor processo de desenvolvimento que devemos utilizar, precisamos primeiro compreender que tipo de software será produzido. Um processo de desenvolvimento pode ser inadequado para certos tipos de projetos de software. Uma decisão errônea pode causar transtorno em todas as pessoas envolvidas, já que a probabilidade de o projeto não ser bem executado é alta, causando alta rotatividade na equipe, pessoas desmotivadas, atrasos nas entregas, aplicação instável, clientes insatisfeitos, etc. [20] Os processos de desenvolvimento tradicionais são recomendados para aplicações construídas a partir de normas estabelecidas, cujos requisitos variam com o tempo de forma lenta. Logo, é possível identificar os requisitos funcionais e não funcionais desde o início do projeto. Isso permite a criação de um projeto de desenvolvimento com escopo e prazo bem definidos, pois não haverá tantas surpresas e mudanças recorrentes durante a construção do software. Já os processos de desenvolvimento ágeis são recomendados para aplicações que não possuem um escopo bem definido no início do projeto. A aplicação será adaptada de acordo com a necessidade dos usuários à medida que versões do software forem lançadas. Geralmente, este tipo de software tem relação com algum tipo de inovação. A inovação pode ser observada em diferentes contextos: melhorar os procedimentos internos de uma empresa, criar um aplicativo para uma nova técnica, modificar a forma de relacionamento entre as pessoas, etc. Dessa forma, não existe melhor processo de desenvolvimento, existe sim o melhor processo para cada necessidade. Então, decidir que processo de desenvolvimento do software será utilizado durante a realização do projeto está diretamente ligado ao tipo de aplicação que será construída. O Quadro 14.1 apresenta um resumo das características de cada tipo de processo. Quadro 14.1: Características dos processos tradicionais e ágeis. Características

Processos tradicionais

Escopo flexível

Processos ágeis X

Escopo rígido

X

Custo final definido de acordo com escopo inicial

X

Requisitos bem definidos no início do projeto

X

Erros críticos identificados nas fases iniciais do projeto

X

Entregas parciais

X

No entanto, nem tudo está escrito em pedra, pois aplicações para a área de direito, que trata de leis e normas, podem ser desenvolvidas em processos ágeis, quando o software tiver o propósito de inovar. Imagine uma rede social para profissionais de direito, cujo objetivo é alcançar um público a nível nacional. Uma aplicação desta natureza, vai requerer, antes mesmo de seu desenvolvimento, uma análise de mercado, análise do público-alvo, já que para construir esta aplicação haverá custos variados dependendo do escopo da aplicação. Fazer uma escolha de processo de desenvolvimento errada e não realizar nenhuma mudança ou adaptação é corroborar com o fracasso do projeto. Quanto antes essa mudança puder ser realizada, menores serão os custos desse projeto. Um dos principais pontos de decisão pode ser na percepção se uma entrega parcial do software pode atender ao seu usuário final de forma satisfatória. Você consegue se imaginar utilizando um aplicativo do banco que realiza transações financeiras, mas não exibe o saldo da conta? Nesse contexto, um aplicativo de banco poderia ser desenvolvido em uma metodologia ágil caso as entregas parciais não fossem disponibilizadas para o usuário final, mas fosse entregue apenas para o responsável em validar cada versão do software. O desenvolvimento continuaria sendo realizado em ciclos, mas sem impactar o cliente do banco. Então, quando a aplicação atingisse o escopo adequado, ela seria entregue para os clientes do banco. Vale refletir se nesse cenário realmente foi adotado um processo ágil, já que os clientes do banco só teriam contato com a aplicação quando ela estivesse pronta. Se a aplicação não atender às necessidades de seus clientes, devido a erros ou mudanças de requisitos no software, essa metodologia ágil realmente foi executada? Já que as entregas parciais para o usuário final não foram realizadas, será que era apenas uma metodologia tradicional mesclada com ágil?

15. A origem de um defeito e seu impacto no processo de desenvolvimento Durante o processo de desenvolvimento de um software, independente do modelo de processo utilizado, podemos identificar defeitos em cada uma de suas etapas. De forma generalizada, um processo contempla as seguintes etapas descritas na Figura 14.1:

Figura 14.1: Etapas de um processo de desenvolvimento de software.

●

● ●

● ●

Definição dos requisitos do software: o analista de requisitos documenta o sistema a ser desenvolvido, criando a documentação e protótipo do que será entregue. Implementação do software: o desenvolvedor define a arquitetura do software, desenvolve o sistema e realiza os testes estruturais. Validação do software: o analista de qualidade e o cliente realizam testes para verificar e validar se o sistema não possui defeitos e se atende às necessidades dos usuários. Entrega do software: o usuário final utiliza o sistema desenvolvido e verifica se ele atende às suas necessidades. Manutenção do software: todos os papéis envolvidos durante o processo de desenvolvimento farão a manutenção do sistema, para realizar melhorias e correções que possam ocorrer.

Apesar da origem de um defeito ocorrer em qualquer uma dessas etapas, em cada etapa o defeito terá um esforço e um impacto diferente para o processo de desenvolvimento. O esforço pode ser mensurado pelo custo de identificação e de correção do defeito. Já o impacto pode ser mensurado através do efeito colateral causado por aquele defeito, por exemplo, confiabilidade do software após a entrega. O gráfico da Figura 14.2 apresenta a relação entre o impacto de um defeito e o esforço para mitigá-lo nas diferentes etapas do processo de desenvolvimento.

Figura 14.2: Gráfico de impacto x esforço de um defeito nas etapas do processo de desenvolvimento de software.

Na etapa de definição de requisitos, quando o software ainda está sendo documentado, defeitos podem ser identificados através de técnicas de inspeção, revisão, elaboração de cenários de teste e criação de protótipos de tela. Estas técnicas podem garantir uma melhor compreensão do sistema. Pois é possível realizar uma simulação antes mesmo do sistema ser desenvolvido, trazendo um feedback dos usuários e corrigindo os defeitos ainda na primeira etapa. Isso leva a um menor esforço e impacto para o processo. Na etapa de implementação do software, defeitos podem ser identificados pelo desenvolvedor, através de técnicas de revisão de código ou de testes estruturais. Desta forma, os defeitos são corrigidos dentro da mesma etapa e não se propagam para outras etapas do processo. Neste caso, o esforço para correção do defeito não é tão alto quanto nas etapas posteriores e o impacto é reduzido já que o sistema ainda não foi entregue para o usuário final. Na etapa de validação do software, o esforço de correção de um defeito é maior que nas etapas anteriores, mas existe uma diferença neste esforço dependendo se é um erro que ocorre em alguma parte nova do sistema ou se ocorre em uma parte que já tinha sido desenvolvida. No primeiro caso, o defeito será corrigido de forma mais rápida, já que o desenvolvedor tem total controle do código produzido. No segundo caso, aquele defeito pode demorar um tempo para ser corrigido, pois ele precisa ser planejado e priorizado, além disso o desenvolvedor não terá muita familiaridade com aquele código. O impacto daquele defeito ainda é menor do que quando o defeito é encontrado nas etapas posteriores a esta.

Na etapa de entrega do software, o defeito geralmente é encontrado pelo usuário final. Logo, o impacto é bem maior que nas etapas anteriores, já que nesta etapa um defeito pode representar uma falta de confiança no sistema, por parte dos usuários. Com relação ao esforço de correção, ele é alto, pois aquele defeito poderá atrasar a entrega de novas funcionalidades, já que ele precisará ser priorizado, por ter sido detectado pelo usuário. Na etapa de manutenção do software, o defeito poderá ser encontrado por todos os envolvidos nas etapas de desenvolvimento do software. O esforço e o impacto são bem maiores do que nas etapas anteriores. Pois esse defeito irá impactar no cronograma de entrega do sistema, poderá trazer prejuízos para o usuário final e ser difícil de ser corrigido, necessitando de atualização do código-fonte do sistema já desenvolvido. Ao compreender a origem de um defeito e o impacto no processo de desenvolvimento, percebemos o quanto é importante detectá-los nas primeiras etapas do processo, por serem mais fáceis de serem resolvidos. Já que para os defeitos identificados após a etapa de entrega não existe um momento previsto para sua correção, eles precisarão ser priorizados e impactar diretamente nas futuras entregas do sistema. Logo, utilizar técnicas de teste que possam ser realizadas para detectar o maior número de defeitos até a etapa de validação é a melhor saída para garantir a qualidade e menor custo para construção daquele sistema.

16. Por que testar é importante? Algumas vezes as atividades de teste não são valorizadas. Isso porque os testes geralmente são feitos apenas após o desenvolvimento do sistema e nem sempre a equipe de testes tem conhecimento das alterações dos requisitos ou das novas funcionalidades que surgem durante o desenvolvimento. Com isso, alguns defeitos ou sugestões de melhoria não são atendidos, por já terem sido descartados durante o desenvolvimento. Os defeitos que realmente são aceitos se transformam em tarefas fora do escopo, pois não tinha como prever a quantidade de defeitos que o sistema iria possuir na versão, podendo causar um atraso na entrega do sistema para o cliente. Para que um testador consiga demonstrar a importância dos testes de software, é necessário que ele: ● tenha conhecimento aprofundado sobre testes, para que ele consiga argumentar sobre a importância dos testes; ● perceba que testes fazem parte da etapa de desenvolvimento, de forma que o testador se envolva com todas as etapas iniciais de aquisição do sistema, desenvolvimento, como também entrega e feedback dos usuários. Quando o conhecimento sobre testes é aprofundado, ele percebe que há muitos tipos de teste e que cada um serve para uma finalidade diferente. Além disso, os testes podem ser realizados em diferentes níveis do desenvolvimento. Durante o desenvolvimento do sistema, os testes podem ser realizados pelos desenvolvedores, através dos testes unitários. Os testadores podem se envolver com os testes de integração, antes mesmo dos desenvolvedores implementarem as funcionalidades do sistema, utilizando objetos mocks. Dessa forma, haverá uma parceria entre testadores e desenvolvedores, pois os testes podem ajudar na construção de sistemas corretos, reduzindo o retrabalho de corrigir defeitos que só iriam aparecer quando o sistema já estivesse implementado [3]. Quando um software é entregue para o cliente sem testes, ele pode causar problemas em diferentes contextos. Abaixo estão alguns argumentos para motivar a realização de testes: 1. Quando um produto não é testado, há uma chance deste produto possuir defeitos, assim este produto pode não satisfazer às necessidades do cliente. 2. O cliente quando não está satisfeito com o produto pode não contratar novamente a empresa. 3. Quando não há qualidade no produto, a empresa fica com imagem negativa, logo é necessário mais investimento em marketing. 4. Se os erros são encontrados pelo cliente, o custo para corrigir estes erros é muito maior do que quando o sistema ainda está em desenvolvimento [1]. 5. Com os testes, novos clientes poderão ficar interessados em seus sistemas devido às recomendações. 6. Com os testes, os desenvolvedores, apesar de parecer que não, ficam bem

satisfeitos e motivados com os elogios ao sistema feitos pelo cliente, já que ele não encontra muitos defeitos. 7. Com os testes, minimiza-se a necessidade de atender telefones e responder demandas para ajudar os usuários a utilizarem o sistema, logo, menor custo com central de atendimento ao usuário. Assim, quando há uma equipe de teste para testar o sistema, todos saem ganhando: o dono da empresa (menos gastos com marketing e mais prestígio para a empresa), o cliente (satisfação e confiança no sistema), os usuários (conseguem usar o sistema de forma confiável), os desenvolvedores (motivados com o trabalho por criarem sistemas com qualidade) e os testadores (mais reconhecimento). Como foi relatado nos capítulos anteriores, o custo para corrigir um defeito após o desenvolvimento do sistema é bem mais alto, pois quando um sistema é entregue para o cliente sem ser verificado pela equipe de testes, o sistema passará para a etapa de 'manutenção'. Nesta etapa, geralmente, a equipe que desenvolveu o sistema já pode ter sido alocada para um novo projeto. Como não é possível prever a demanda de defeitos futuros que podem ocorrer no sistema, é provável que haja uma sobrecarga de novas tarefas para os desenvolvedores de projetos antigos. Assim, o novo projeto poderá atrasar, pois parte da equipe terá que ser alocada novamente ao projeto antigo. Além disso, se parte da equipe que desenvolveu o sistema não trabalhar mais na empresa, então o custo para corrigir aquele defeito será ainda maior, pois um outro desenvolvedor pode ter uma certa dificuldade para corrigir esses defeitos, logo isso poderá demandar mais tempo e consequentemente mais custo para a empresa.

17. Dicas para ter mais eficiência nos testes Realizar testes de software é uma atividade que requer criatividade. Dessa forma, encontrar técnicas que auxiliem na eficiência dessa atividade pode trazer bons resultados na identificação de defeitos nos sistemas. A seguir foram descritas algumas dicas que podem servir como orientação para a tomada de decisão em diversas situações: 1. A atividade de um testador pode iniciar o quanto antes com a revisão da documentação do sistema. Isso pode diminuir bastante o custo do projeto final, evitando bugs futuros. Além disso, preparar os roteiros de teste antes do software estar pronto pode economizar tempo valioso no final do projeto. 2. O tipo de teste a ser realizado em um projeto deve ser adequado ao processo de desenvolvimento. A escolha da melhor técnica e nível de teste vai depender de diferentes aspectos, como: tamanho do sistema, quantidade de desenvolvedores, o risco para o negócio, o prazo do projeto, etc. 3. Analise se a equipe de testes na sua empresa não é suficiente para garantir a qualidade de todos os projetos, ou se o líder de projeto acha que não será necessário testar o sistema por falta de tempo e prioridade. 4. Uma vez que dispomos de recursos humanos finitos alocados em tempo finito para os projetos, a atividade de testes deve ser delimitada. Temos que garantir que o “custo da realização de testes” seja bem menor do que o “custo de um defeito aparecer para o usuário”. Vamos analisar as seguintes listas de custos referentes a defeitos nos sistemas: a. Custos da realização dos testes: ● ● ● ● ●

Alocação de pessoal especializado; Manutenção de documentação, roteiro de testes, testes automatizados executáveis, etc.; Correção dos defeitos encontrados pela equipe de desenvolvedores (se não for para corrigir, não há sentido em ter testado); Custo referente ao maior prazo de entrega do produto; Custo adicional referente ao risco de inserção de novos defeitos pelos desenvolvedores durante as correções de defeitos citados no item anterior, dentre outros;

b. Custo de um defeito aparecer para o usuário: ● ● ● ●

Custo da atividade da área fim interrompida; Custo de imagem que o sistema vai sofrer com o usuário; Custo de atendimento e tempo de solução dele; Custos de correção de inconsistências no banco de dados referentes ao defeito, dentre outros;

Assumindo que os testadores irão testar as funcionalidades mais críticas e importantes primeiro, é natural que haja um “ponto de corte” a partir do qual “não vale a pena” testar mais. Se o custo de realização dos testes está ficando alto demais, reavalie qual a melhor técnica de teste para aquele cenário ou considere encerrado o trabalho de testes. “Custo convertido em qualidade que realmente atende à necessidade do cliente é investimento. Custo convertido em qualidade que o cliente não precisa é desperdício.” Ricardo Vargas [18] 5. Às vezes não é possível testar tudo de um software quando ele possui muitas funcionalidades, então é importante criar alguma regra de prioridade para as funcionalidades a serem testadas. Análise de risco e a frequência do uso das funcionalidades é uma boa maneira de priorizar os requisitos. 6. Para justificar a necessidade de testes em um projeto, é importante saber qual é o custo e quão eficiente é a equipe de testes. Para ter este conhecimento, é necessário analisar e mensurar. Métricas são informações que podem ser colhidas durante o desenvolvimento do projeto, como: número de cenários, número de defeitos encontrados, tempo gasto para executar um roteiro de teste, entre outros. Quanto antes for iniciada a medição dos dados melhor será a avaliação dos resultados. 7. À medida que um software evolui e testes são realizados antes do lançamento de cada versão, a tendência é que os defeitos comecem a diminuir e o sistema comece a ser considerado mais confiável. Se nenhum critério tiver sido definido, os testadores irão continuar seus testes mesmo quando defeitos raramente forem encontrados, tornando o custo dos testes maior do que o necessário. Isso significa dizer que pode existir um ponto de "estabilidade" no sistema, devido à sua qualidade ou devido à diminuição do ritmo de manutenção dele. Se isso ocorrer, considere orientar os testadores para realizar os testes apenas nos cenários mais críticos do sistema. 8. Organize bem os roteiros de teste e gerencie cada atualização deles, pois é bem provável que eles serão reutilizados na fase de manutenção e evolução do software. Isto poderá economizar parte do esforço de realizar o teste de regressão. 9. Assegure que a comunicação entre os membros das equipes de desenvolvimento e teste de software seja clara e objetiva, para evitar que erros sejam cometidos por falta de entendimento sobre uma funcionalidade. Defina padrões na descrição dos bugs, para evitar que cada membro da equipe faça de outra forma e coloque menos informações que o necessário para o defeito ser reproduzido pelo desenvolvedor e para aumentar a legibilidade do texto. Utilizar uma ferramenta de gerenciamento de bugs é importante para conseguir priorizar os bugs e perceber o ciclo de vida de cada bug, desde sua abertura até o encerramento. 10. Compartilhe conhecimentos com os outros membros da equipe, documentando cada processo ou atividade de teste, garantindo que todos os membros da equipe saibam o que precisam fazer. Como garantir a qualidade dos sistemas, se não há qualidade nos processos

internos da equipe de testes? Difícil, não acha? Sempre que possível, capacite sua equipe. Assim, ela irá trazer melhores resultados e ficará mais motivada para continuar trabalhando com teste de software. 11. Quando não se souber qual o melhor tipo de teste ou técnica que deverá ser utilizada num projeto, a melhor forma é começar pelo mais simples, ou seja, fazer o mínimo de atividades possível para atender às necessidades do projeto. Por exemplo, se não há documentação suficiente para criação de roteiros de teste, então a estratégia pode ser realizar testes exploratórios. Além disso, o processo não deve ser cansativo para a equipe de teste, ou seja, muitas atividades repetitivas e que não trazem eficiência para os testes. Escolher a melhor abordagem é essencial para garantir a qualidade dos sistemas desenvolvidos e reduzir o custo para realizar os testes.

18. Quando os testes podem ser automatizados? Há muitas maneiras de automatizar o teste de software, a primeira e mais comum é através do teste estrutural, no nível de teste unitário. Este tipo de teste geralmente é realizado pelo desenvolvedor. Ele é útil para garantir que um componente do sistema não parou de funcionar quando uma nova parte do sistema foi desenvolvida. No entanto, é possível automatizar o teste funcional também. Ele tem a finalidade de verificar se o sistema, do ponto de vista do usuário final, não apresenta defeitos em seu funcionamento. Assim, esse tipo de teste é realizado a partir das telas, campos e botões do sistema. É comum imaginar um mundo ideal quando pensamos em um sistema que tenha todos os seus testes automatizados. Então o trabalho de realizar testes se resumirá apenas à máquina. Contudo, dependendo do sistema, é necessário planejar o momento certo de realizar esses testes funcionais automatizados. Se num cenário em que o sistema está sendo desenvolvido e possui algumas versões em produção, e o cliente está sempre trazendo novas funcionalidades, melhorias na interface, retirando outras funcionalidades, então este não será o melhor momento para automatizar os testes funcionais. Pois, neste caso, a interface do sistema sofrerá constante alteração, logo os testes terão que ser atualizados frequentemente, gerando um grande retrabalho em manter esses testes [3]. Neste cenário, é recomendável os testes estruturais automáticos, com testes unitários feitos pelos desenvolvedores e testes de integração que podem ser feitos por desenvolvedores e testadores. Dessa forma, o melhor momento para realizar os testes funcionais automáticos será com o objetivo de realizar teste de regressão. Isso ocorre quando se tem um sistema que já está em uso, com versões estáveis e com poucos defeitos. Pois, nesse caso, a interface do sistema irá sofrer poucas alterações, então o custo de manter os testes automatizados funcionais será menor. Há ferramentas para realizar os testes funcionais automatizados, para isso é necessário verificar quais as tecnologias de suas interfaces: desktop, web ou dispositivos móveis. Antes de utilizar qualquer ferramenta para automatizar os testes, é necessário analisar vários fatores que irão definir o sucesso ou não dos testes. Algumas ferramentas possuem limitações e não conseguem testar a interface de algumas aplicações, neste caso não faz sentido utilizá-las. É importante destacar que o teste automatizado pode ter um baixo custo de execução (ex. no nível de unidade), mas em todos os níveis há um alto custo de manutenção. Pois para que ele se mantenha executando durante o ciclo de vida do sistema, ele precisa estar atualizado. Quando essa manutenção não ocorre, muitas vezes os testes são descartados, pois passam a detectar erros que não são erros, são apenas testes desatualizados. Para garantir eficiência e manutenção desses testes automatizados é importante que eles sejam adicionados a um ciclo integrado e de entregas contínuas de sistemas (CI/CD - Continuous

Integration / Continuous Delivery). Em um processo de desenvolvimento com integração contínua, os testes não são esquecidos e podem ser executados antes do lançamento de uma nova versão do sistema. Mesmo que um teste esteja desatualizado, haverá uma demanda de atualização dele, já que o sistema só será disponibilizado quando aqueles testes automatizados passarem. Além da importância do CI/CD, há outros fatores críticos [7] que melhoram a elaboração e manutenção dos testes automatizados: 1. Implementar códigos de testes reusáveis, com orientação a objeto, com polimorfismo, métodos bem escritos, um código limpo e de fácil compreensão. 2. Equipe de testes integrada com a equipe de desenvolvimento, que está atenta a todas as mudanças no sistema. 3. Conhecer bem a ferramenta ou linguagem de programação utilizada para automatização do teste. 4. Compreender conceitos de banco de dados para conseguir elaborar testes mais completos, capazes de alterar e remover dados utilizados nos testes, e permitir a execução contínua deles. Assim estes e outros fatores podem ser considerados no momento de decidir se os testes funcionais serão automatizados ou manuais. É bom sempre lembrar que o principal objetivo de um caso de teste (automatizado ou não) é encontrar defeitos no sistema. Se a probabilidade de encontrar defeitos em uma funcionalidade for baixa, devido à simplicidade do requisito, talvez não seja necessário criar um teste automatizado para isso, já que o custo de manter esses testes não é baixo. A diferença principal entre o teste manual e o teste automatizado é que o primeiro detecta defeitos no sistema no presente momento e o segundo detecta futuros defeitos. Já que o teste automatizado é criado para passar (sempre verde), ele depende disso para se manter executando continuamente.

19. Vale a pena investir em testes estruturais para sistemas legados? Sistemas legados é um gargalo que algumas empresas possuem e ficam anos mantendo sistemas, que algumas vezes possuem tecnologias antigas e sem documentação. Ao pensarmos nesse tipo de abordagem, dos sistemas legados, precisamos analisar que tipo de teste poderia ser utilizado. Se tenho uma sugestão para este cenário, talvez sim, mas para cada caso, teria que se analisar as diferentes variáveis para tomar uma decisão mais assertiva. Algumas variáveis que podem ser analisadas seriam: ● tecnologia do sistema legado; ● arquitetura do sistema; ● tempo de vida útil do sistema; ● quantidade de recursos humanos para realizar esses testes, sem prejudicar os novos sistemas da empresa; ● número de usuários que ainda usam este sistema; ● número de erros recorrentes no sistema; ● necessidade de atualização do sistema; ● custo de se construir um sistema novo, com novas tecnologias; ● custo de realização e manutenção dos testes, entre outras. Depois de uma análise de todo esse contexto, seria possível dizer se vale a pena ou não realizar algum tipo de teste. Tendo em vista que os testes estruturais geralmente são realizados pelos desenvolvedores, utilizando a linguagem de programação do sistema, dependendo dessa linguagem, pode não haver equipe capacitada para criar esses testes. No caso de haver uma equipe capacitada, o custo para criar testes unitários para todo o sistema pode ser alto, por demandar muito tempo. Caso o sistema esteja em constante atualização, uma abordagem seria criar testes unitários para cada novo código criado nesse sistema. Além disso, para as partes do sistema que não mudam, testes de integração poderiam ser criados para as interfaces de comunicação de cada camada do sistema. As desvantagens de realizar esses testes automatizados seriam: ● alto custo para criação de testes; ● risco de o sistema ser descontinuado em curto prazo. As vantagens de realizar esses testes automatizados seriam: ● garantir a qualidade contínua durante a atualização do sistema; ● aumentar a performance dos testes de regressão; ● reduzir a quantidade de testes manuais. Portanto, decidir se vale a pena ou não criar testes estruturais para sistemas legados não é trivial. Uma escolha errada pode trazer altos custos para a empresa e ter baixos resultados em termos de qualidade baseada em testes.

20. O futuro dos testes e onde os testadores podem investir? A tendência é que sistemas sejam criados para as mais diversas finalidades e estejam cada vez mais presentes em nossas vidas. Já existem até sistemas que programam outros sistemas. Com IoT (Internet das coisas), a interface entre o sistema e o usuário não fica restrita a uma tela de dispositivo, pois de repente o sistema se comunica com uma cafeteira ou com o portão de uma casa. Quando combinamos IoT com Inteligência Artificial, os sistemas podem ser parte do drone que entrega pizza ou até mesmo um carro autônomo que dirige pela cidade. Dessa forma, a confiabilidade do sistema torna-se um dos principais requisitos. Logo, a qualidade não se resume apenas em encontrar defeitos em uma aplicação, mas sim à segurança delas. Sistemas seguros podem garantir a vida e os bens de seus usuários. Empresas, para se manterem no mercado, precisam estar em constante atualização e informatização de seus processos [15]. Mesmo as empresas que já possuem sistemas de informação precisam ficar atentas às novas tecnologias dos dispositivos de seus clientes, pois nem todos os sistemas rodam em versões antigas ou mais recentes desses dispositivos. Portanto, os sistemas precisam ser atualizados frequentemente, para que continuem atendendo a esses requisitos. Considerando as tendências das novas tecnologias, a qualidade dos sistemas terá um papel importante, logo a necessidade de testes automatizados será cada vez maior. Pois nem sempre será possível realizar os testes manuais na velocidade requerida em um ambiente de desenvolvimento, considerando os cenários de um usuário final. Assim como os sistemas estão evoluindo, os testes também estão. Já existem ferramentas para realização de testes utilizando inteligência artificial. Além disso, as ferramentas de testes automatizados estão cada vez mais integradas com os repositórios dos sistemas. Isso garante a qualidade contínua das novas atualizações dos sistemas. Os testadores têm que perceber, ao realizarem testes manuais, que a atividade exercida por ele é um serviço. Entretanto, quando realizam testes automatizados, cada caso de teste escrito será um produto que poderá ser utilizado novamente sempre que necessário ou refinado para se manter em funcionamento. Então para as empresas é mais vantajoso contratar funcionários que possuam o conhecimento mais amplo, que realizem tanto os testes manuais quanto os automatizados. Assim, capacitação em testes automatizados é uma prioridade dos testadores que queiram seguir uma carreira na área de qualidade de software. Quando pensamos em automação, manipular dados pode ser um diferencial na realização de testes, pois nada se compara a criar modelos de teste para um conjunto de 10 itens com testes para um cenário de milhares desses itens. Nesse contexto, encontrar profissionais com técnicas de automação para o Big Data Testing pode ser um requisito desejável das empresas.

Outra tendência para os softwares é a necessidade de segurança das aplicações. Quem faz parte da área de qualidade de software pode também investir na área de segurança, pois apesar de haver profissionais de segurança da informação, nem sempre eles identificam vulnerabilidade nos sistemas. Dessa forma, uma capacitação em testes de segurança de sistemas pode ser um diferencial para o profissional da área de testes.

Glossário Ambiente de homologação: é um ambiente utilizado para verificar o sistema antes dele ser disponibilizado para o usuário final. Ambiente de desenvolvimento: é um ambiente utilizado pelos desenvolvedores enquanto desenvolvem o sistema. API: Interface de Programação de Aplicação. Artefato: é o produto de trabalho bem definido e tangível, consumido, produzido ou modificado pelas tarefas. Automação: é um sistema automático pelo qual os procedimentos são realizados sem a necessidade da interferência humana. Banco de dados: repositório para armazenar os dados do sistema. Caso de teste: é o conjunto de passos que precisam ser realizados para realizar um teste no sistema. Checklist: é uma lista de itens a serem verificados durante uma revisão de artefatos dos sistemas. Ciclo de vida: descreve as etapas de um processo do início até o seu encerramento/manutenção. Ciclo ou Sprint: é o tempo de realização e finalização de um conjunto de atividades dentro da metodologia ágil Scrum. Cobertura: é uma técnica que demonstra o percentual de testes executados para uma determinada finalidade. Código-fonte: documento em formato de texto escrito em uma linguagem de programação que será interpretado por um computador. Componente: é o termo utilizado para descrever o elemento de software que encapsula uma série de funcionalidades. Um componente é uma unidade independente, que pode ser utilizado com outros componentes para formar um sistema mais complexo. Defeito: é uma falha na execução de um software, que foi detectada. Desenvolvedor: também conhecido como programador, é o profissional que trabalha na área de TI responsável por construir um software através da criação do código-fonte. Desenvolvimento de software: é a atividade de construção de um software realizada por um

desenvolvedor. Documentação: são os documentos que descrevem sistemas, processos, desenvolvimento e testes. Entidade: pode ser uma classe do sistema, uma tabela do banco de dados ou um componente do sistema. Erro em sistema: comportamento inesperado do sistema em um determinado cenário. Especificação funcional: é um documento que descreve os requisitos funcionais do sistema. Falha em sistema: é quando um erro ocorre durante a execução do sistema. Funcionalidade: informações sobre o sistema que representam o funcionamento de uma parte do software. Guia de interface: protótipo de tela do sistema em forma de imagem que define as principais funcionalidades do sistema. Integração contínua: quando o sistema evolui, novas versões são lançadas periodicamente, logo cada mudança precisa ser registrada em um repositório de versionamento. Homologação: etapa de um processo de construção de um software, onde o sistema é avaliado para aprovação ou reprovação. Mock: são componentes que simulam o comportamento de componentes reais de forma controlada. Modelagem de banco de dados: são modelos que definem como serão construídas as estruturas de dados que darão suporte aos sistemas. Navegador: é um software que nos permite acessar páginas pela internet, exibindo imagens, textos, vídeos e demais informações. São softwares como Microsoft Edge, Google Chrome, Safari, Firefox, IE, etc. Nível de teste: define onde os testes serão realizados, ou seja, se os testes serão feitos no código, na interface, etc. Nível macro: nível de abstração das informações sobre um sistema, ou seja, informações de alto nível, sem muito detalhamento. Pirâmide de teste: definição em forma de pirâmide para a proporção sobre a quantidade de testes automatizados realizados em cada nível de teste. Processo de desenvolvimento de software: define um conjunto de atividades que podem ser executadas por cada membro de uma equipe durante o desenvolvimento de um software.

Produção: etapa de um processo de construção de um software, onde o sistema é disponibilizado para os usuários. Product owner: papel definido pela metodologia Scrum, responsável por coletar informações sobre o produto que será desenvolvido. Qualidade de software: define padrões para que sejam verificados durante a construção do software. Recall: é o procedimento gratuito pelo qual a empresa convoca o cliente para sanar os defeitos encontrados em produtos vendidos ou serviços prestados. Regra de negócio: definem como o negócio funciona, podem abranger diversos assuntos como políticas, interesses, objetivos, compromissos éticos e sociais, obrigações contratuais, decisões estratégicas, leis e regulamentações entre outros. Requisito de software: descreve as regras de negócio de um software, definindo as condições e as restrições nas quais o sistema deve funcionar. Roteiro de teste: determina o contexto em que um conjunto de casos de testes precisam ser executados. Scrum: metodologia ágil utilizada para o desenvolvimento de softwares que ainda não possuem todo o escopo definido no início do processo. Scrum master: papel definido pela metodologia Scrum que é responsável por liderar o time de desenvolvimento do software que será construído. Software: são todas as aplicações que rodam em uma máquina (computador ou celular). Sprint: ciclo de cada etapa do desenvolvimento de um software que utiliza a metodologia Scrum, cada ciclo pode durar de 1 a 4 semanas. Testador: profissional que trabalha na área de TI responsável por testar um software. Teste alfa: teste realizado em um software antes do lançamento para o público geral. Teste beta: teste realizado em um software durante o lançamento para um público específico. Teste caixa-cinza: abordagem de teste que combina os testes caixa-branca e testes caixa-preta. Teste de confirmação: abordagem para verificar se um defeito encontrado no sistema foi corrigido corretamente. Teste de regressão: abordagem para garantir que, à medida que o sistema evolui, o que já foi testado continua funcionando. Teste dinâmico: abordagem para realizar a verificação em um software que esteja em execução.

Teste estático: abordagem para realizar verificação em busca de erros em um artefato de software sem a necessidade de que ele esteja em execução. Por exemplo, revisão do códigofonte. Teste estrutural ou caixa-branca: abordagem que depende do código-fonte para ser realizado, por isso tem o objetivo de encontrar defeitos durante a programação do software. Teste exploratório: abordagem onde os testes são realizados sem a presença de um roteiro de teste. Teste funcional ou caixa-preta: abordagem onde os testes são realizados simulando o uso do sistema, da mesma forma que o usuário final faria, sem a necessidade de ver o código-fonte. Teste não funcional: abordagem para garantir que os requisitos não funcionais foram atendidos pelo software, como segurança, usabilidade, disponibilidade, etc. Teste relacionado à mudança: abordagem para garantir que nenhum novo defeito seja acrescentado ao sistema após a sua modificação ou evolução. Test drive: é a condução de um automóvel para aferir a sua dirigibilidade e estado geral de funcionamento. Versão alfa: é a primeira versão do produto, geralmente uma fase em que ele ainda está em testes e desenvolvimento. Versão beta: é a versão que já pode ser disponibilizada para um subconjunto de usuários, mas que ainda possui erros e necessita de melhorias. Versão trial: é uma versão final do produto que é disponibilizada para teste por um período determinado (7 dias a 1 mês). Versionar: ato de criar versões para documentos em geral. Web Service: é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes.

Referências [1] Myers, G. J. The Arts of Software Testing - 2nd. ed. John Wiley & Sons, Inc., USA, 2004. [2] Dijkstra et al. Software Engineering Techniques. Nato Software Engineering Conference, Itália, 1969. cap. 3 pág 16. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF [3] Rätzmann, M. e Young, C. Galileo Computing Software Testing and Internationalization. ed. Lemoine International, USA, 2003. [4] Syllabus. Certified Tester Syllabus. BSTQB, CTFL 3.1, 2018 [5] Marchesi, M., Succi, G e Williams, L. Traditional and Agile Software Engineering Software. Addison Wesley, 2003. cap. 8. [6] Olegario, P. e Bandeira, L. Boas práticas adotadas em um Projeto de Design de Testes – Um relato de experiência. Artigo publicado no II EBTS, Recife, 2007. [7] Oliveira, J., Gouveia, C., Gouveia e Filho, R. A way of Improving Test Automation CostEffectiveness. Artigo publicado no CAST'06, Indianápolis, EUA, 2006. [8] Pressman, R. S. Engenharia de Software. 5 ed., McGraw-Hill, 2002. [9] Adrion, W. R; Branstad, M. A and Cherniavsky, J. C. Validation, Verification and Testing of Computer Software, published at ACM, p. 159–192, New York, 1982. [10] Hailpern, B. and Santhanam, P. Software debugging, testing, and verification at http://www.research.ibm.com/journal/sj/411/hailpern.html [11] Fowler, M. The practical test pyramid. 2018 https://martinfowler.com/articles/practical-testpyramid.html [12] Cohn, M. Succeeding with Agile. 2009 http://1.droppdf.com/files/AFvTS/succeeding-withagile-mike-cohn.pdf [13] Crispin, L. and Gregory, J. Agile Testing: A Practical Guide for Testers and Agile Teams, Addison-Wesley Professional, 2009 em https://agiletester.ca/ [14] Valente, M. T. Engenharia de Software Moderna: Princípios e Práticas para Desenvolvimento de Software com Produtividade. 2020 [15] Magaldi, S. e Salibi Neto, J. Gestão do amanhã. ed. Gente, 2018 [16] Rocha, A. C. O. GTSW - Grupo de Testadores de Software, blog em https://medium.com/gtsw

[17] TestLink - Ferramenta de gerenciamento de testes de software. Open source, 2022 em http://testlink.org/ [18] Vargas, R. Curso de gerenciamento de projetos. 2022 em https://ricardo-vargas.com/pt/ [19] PMI, Project Management Institute. PMBOK Guide. 2022 em https://www.pmi.org/pmbokguide-standards/foundational/pmbok?sc_camp=8A8BABF66EF9499DB5CCD1C1044CB211 [20] DevMedia. Processo de teste ágil x tradicional. 2022 em https://www.devmedia.com.br/processo-de-teste-agil-x-tradicional/36854

Agradecimentos Agradeço a Deus, por me abençoar em cada etapa da minha vida. A elaboração deste livro não seria realizada sem o apoio de pessoas que contribuíram direta ou indiretamente durante todo o processo. Agradeço aos meus pais, Wagna e Vital, por acreditarem em mim e sempre me apoiarem nos meus sonhos, confiando que eu conseguiria concluir este livro, me incentivando inúmeras vezes. Agradeço ao meu esposo, Bruno, que esteve sempre ao meu lado, me apoiando nos meus projetos, inclusive revisando esta obra e fazendo críticas construtivas. Agradeço aos meus filhos, Renan e Martim, por contribuírem dia após dia, me ajudando a priorizar minhas atividades e a organizar melhor meu tempo. Agradeço à minha irmã, Karina, por estar sempre ao meu lado, desde os primeiros passos de vida, até mesmo nos tempos mais difíceis da universidade, me apoiando em todos meus projetos e sonhos. Agradeço ao meu irmão, Vital, pela amizade e alegrias compartilhadas desde a infância. Agradeço aos meus outros familiares, por me ajudarem em cada momento da minha vida, sem medir esforços e por todas as alegrias partilhadas: Anete Araújo, Marcos Guedes, Deise Araújo, Dante, Sara, Iris, Kivia Meira, Alex Araújo, Vinícius, Théo, Guilherme, Anna Paula e Uriel Max. Agradeço aos meus amigos, com os quais compartilhei momentos de alegria: Mara Caroline Kelmer, Rafaela Morais, Rodrigo Nóbrega, Denise Vaz, Rodrigo Souza, Natália Lins, Uirá Assis, Geysa Oliveira, André Santos, Rodrigo Azevedo, Pauliane Sampaio, Maria de Lourdes Nascimento, Arthur Nóbrega, Tareb Edson, Marceli Souza e Augusto Dantas. Agradeço aos meus colegas de trabalho, desta trajetória na área de teste de software: Rafaela Batista, Thenio Silva, Jessé Maia, Eduardo Arruda, Flavio Córdula, Alan Bonifácio, Danielle Souza, Júlia Queiroz, Tália Almeida, Tairine Ferraz, Kelly Trajano, Geysa Jerônimo, Ana Paula Vale, Manuela Andrade, Emanuella Soares, Amanda Lopes, Amanda Silva, André Caldas, Alex Martins, Laércio Bezerra, Tullio Henrique, Kivio Grangeiro, Karolline Mota, Jackson Alves, Murilo Augusto Souza, Daniel Damasceno, Nickson Chagas, Issias Silva, Allisson Fernando e Cecília Andrade. Agradeço ao Raphael Patrício, por sua liderança impecável, por sempre confiar no meu trabalho, permitindo implementar melhorias nos processos e inovações em qualidade de software. Agradeço às demais pessoas, que trabalharam comigo, compartilhando experiências e me motivaram com suas ideias, que de alguma forma fazem parte deste livro: Felipe Guedes, Iza Magna, Ricardo Barbosa, Fabiana Nascimento, Jackeline Gomes, Max Carvalho, Georgenes Lima, Rony Rodrigues, Creusa Lucena, Cristina Ferreira, Ana Cláudia Silva, Anderson Clayton, Sandro Lopes, Arthur Santos, Alan Araújo, Natália Bezerra, Dalila Azevedo, Luiz Cerqueira, Ramon Xavier, Felipe Rosas, Cesar Peres, Vinícius Migliorança, Jessica Freitas, Júlia Vita, Thamirys Gameiro, Ruan Campelo, Daniel Coelho, Verônica Antunes e Luanna Peixoto.

Agradeço ao Vitor Cardoso por ter me incentivado a continuar com a escrita desta obra, mesmo que de forma indireta, quando me convidou para escrever um capítulo para o livro “Debugando sua carreira”. Percebi o quanto era simples o processo de publicação de um livro e pouco tempo depois, recebi o livro dele em casa, a sensação foi tão maravilhosa que comecei a me imaginar recebendo o meu livro também. Agradeço ao revisor Farlley Derze por ter aprimorado o texto com seu senso crítico e analítico, o que me deixou mais confiante durante a publicação desta obra. Agradeço aos colaboradores, que sugeriram ideias para os capítulos do livro através do blog Grupo de Testadores de Software: Maurício Gamarra, André Leite, Gilson Júnior, André Luiz Moraes, Eglom Sostenes, Osmar Leandro, Leiany Duarte, Marcus Silva e JJ. Agradeço aos queridos futuros leitores, que já demonstraram interesse antes mesmo do lançamento deste livro, me motivando na escrita e publicação: Dayana, Glaucia Conie, Caio, Wederson Oliveira, Benjamim Rodrigo, Gislaine Oliveira, Gisele Cerqueira, Rony Correia, Bruno Silva, Tatty Cassilha, Eduardo, Josué Moraes, Eliel Sousa, Diego, Victória, Diego Spotti, Everton Mendonça, Ana Flávia Ramos, Maria Margarida Silva, Lucas de Miranda, Rosana, Ana, Antônio Araújo, Edson Junior, Gabriela, Alex Lins, Bruno Iglesias, Karoline Pacheco, Fernando Jordão, Jaqueline Santos, Amauri, Giseane Macedo, Felipe Espíndola, Luiz Ukan, Shirlane Lima, Ana Alessandra, Luana, Soraia Silva e Roberta Moraes.