Organizações Envolvidas com Testes de Software no Brasil (Parte2)

Alats

A Alats (Associação Latino Americana de Testes de Software) é uma associação sem fins lucrativos cujo objetivo é incentivar e divulgar as boas práticas em teste de software.

Alats

 

Fonte: <http://www.alats.org.br/portal/>

A instituição trabalha para aproximar e integrar universidades, organizações empresariais e profissionais de TI, atuando como um facilitador para o desenvolvimento e aplicação de técnicas para atender a demanda e as necessidades da área de testes de software.

A Alats criou a CBTS - Certificação Brasileira de Teste de Software visando qualificar profissionais para atender o mercado brasileiro na área de teste de software.

De acordo com Alats (2017, s/p), o objetivo da CBTS

[...] é estabelecer um padrão em conformidade com os requisitos para uma avaliação da qualificação dos profissionais na área de Qualidade de Software. Adquirir o certificado CBTS para o profissional da área é um grande diferencial, pois indica que o mesmo possui um excelente nível de competência profissional nos princípios e nas práticas de Qualidade de Software, dentre os demais profissionais de TI. Tornar-se um certificado CBTS, significa tornar-se membro de um grupo seleto de profissionais reconhecidos na área de Área de Qualidade de Software. Receber este reconhecimento de sua competência é conseguir uma ascensão potencialmente mais rápida em sua carreira, e uma maior aceitação no mercado.

O certificado é válido por três anos, mas o profissional pode manter-se certificado através da recertificação, seguindo regras específicas. Estas regras, de acordo com informações da instituição, são:

a certificação é válida no ano da prova (a partir da data divulgada da aprovação) e nos 3 anos seguintes completos, terminando sempre em 31/12. O período de aquisição dos PDTS (Ponto de Teste de Software) é correspondente ao período de validade da certificação, ou seja no decorrer dos três anos. 50 PDTS devem ser obtidos neste período para que não seja necessário prestar novo exame. A partir do primeiro período, a cada 3 anos completos, novos 50 PDTS devem ser adquiridos, ou seja o certificado poderá ser validado sem a necessidade de outro exame.

Comparação entre os certificados CTFL e CBTS

As certificações mais conhecidas na área de testes de software no Brasil são a CTFL e a CBTS. Apesar de ambas serem muito conhecidas, as principais diferenças entre elas são desconhecidas pela maioria dos profissionais. Para facilitar a identificação destas diferenças, Findeis (2016) faz um comparativo entre essas certificações que está apresentado no Quadro 2.

É importante ressaltar que a validade do CBTS pode ser sempre revalidada através de aquisição de 50 pontos (PDTS).

Comparativo entre certificações de testes CTFL e CBTS

	CTFL	CBTS
Órgão certificador	BSTQB/ISTQB	ALATS
Validade	Nunca expira	3 anos, Depois tem que refazer
Território de aceitação	Internacional	Exclusiva do Brasil
Material	Apostila de 77 páginas. tem também um glossário de 111 para tirar dúvidas sobre siglas	Livro "Base de conhecimento em teste de Software", com 263 páginas
Valor do material	Gratuito no site	Entre 50 e 80 reais na internet
Simulado oficial	Sim	Não
Simulados variados na internet	Sim	Sim
Língua da prova	Português ou Inglês	Português
Valor da prova	350 reais	90 dólares

Fonte: Findeis (2016)

Observação: Os valores não estão atualizados. Eles são referentes a data de pesquisa da publicação.

Organizações Envolvidas com Testes de Software no Brasil

Certificações em testes de software

De forma similar a outras áreas da engenharia de software, há diversas certificações em teste de software. Uma certificação em testes de software indica que o profissional que a possui adquiriu determinado nível de conhecimento na área. Isso funciona, por um lado, como um facilitador para que as organizações contratantes identifiquem profissionais qualificados e, por outro lado, fornece ao profissional certificado um diferencial que o destaca, aumentando suas chances de contratação.

A disseminação dos processos de testes no Brasil é relativamente nova. Algumas organizações e institutos foram criados com o objetivo de profissionalizar a atividade, realizando avaliações e fornecendo certificação para os profissionais da área.

Dentre as principais instituições certificadoras mundiais estão:

Certificações

 

Fonte: <www.qaiglobalinstitute.com>, <ertifications.bcs.org/>, <testinginstitute.com>

• QAI - Quality Assurance Institute, que oferece a certificação CSTE (Certified Software Tester).
• BSC - British Computer Society, cujas certificações são divididas em Foundation Level, Intermediate Level e Higher Level.
• IIST - International Institute of Software Testing, cujas certificações são divididas em Professional Testing, Agile Testing, Test Automation, Test Management e Mobile Testing.
• ISTQB - International Software Testing Qualifications Board
• Alats - Associação Latino Americana de Testes de Software

Aqui vamos tratar das certificações oferecidas pelo ISTQB e Alats.

BSTQB

O BSTQB (Brazilian Software Testing Qualifications Board) é o representante do ISTQB (International Software Testing Qualifications Board) no Brasil.

BSTQB

 

Fonte: <bstqb.org.br>

De acordo com o BSTQB (2006), a certificação em teste de software começou no Reino Unido em 1998, com a criação de uma comissão de testes de software pela British Computer Society´s Information Systems Examination Board (ISEB) e, em 2002, a Alemanha passou a dar suporte a um sistema de qualificação de testadores.

Foi criado um guia de estudo para orientar os interessados em obter as certificações denominado Syllabus. De acordo com o ISTQB (2011, p. 8), o Syllabus

[...] forma a base de conhecimento para a Qualificação Internacional de Teste de Software no nível Foundation. O International Software Testing Qualifications Board (ISTQB) disponibiliza o Syllabus às comissões nacionais para que elas autorizem os fornecedores de treinamento e também derivem as questões do exame em suas línguas locais. Os fornecedores de treinamento produzirão o material de curso e determinarão os métodos de ensino apropriados para certificação, e o Syllabus ajudará os candidatos em sua preparação para o exame.

Cada certificação possui um syllabus e um glossário. Os syllabi formam a base de conhecimento para a qualificação internacional em teste de software, tanto para o nível fundamental (CTFL) quanto para o nível avançado (CTAL).

A Figura ilustra o rol de certificações oferecidas pelo ISTQB.

Tipos e níveis de certificações ISTQB

 

Fonte: <bstqb.org.br>

Certificações de nível fundamental

Certified Tester Foundation Level - CTFL, que pode ser obtida por qualquer profissional envolvido em teste de software como desenvolvedores e testadores, engenheiros, gerentes, consultores e analistas de testes, mas também se aplica a pessoas interessadas em adquirir conhecimento sobre teste de software, como gerentes de projetos, gerentes de qualidade, analistas de negócios, gestores de TI, consultores etc. Sendo um nível inicial, as pessoas certificadas neste nível poderão buscar níveis mais altos de qualificação na área.

CTFL Agile Tester, que segue os princípios do desenvolvimento ágil de software, em consonância com o Manifesto ágil. Um profissional com esta certificação trabalhará de forma diferente de um testador em um projeto tradicional, pois passa a entender e a seguir os valores e princípios de projetos ágeis.

CTFL Model Based Test, que oferece ao testador com esta certificação conhecimento em modelos inovadores para conduzir a análise e modelagem do teste, complementando o nível CTFL como um módulo de especialização.

Certificações de nível avançado

As certificações de nível avançado iniciam-se por CTAL (Certified Tester Advanced Level). Reúnem um conjunto de certificações destinadas a profissionais que já têm experiência consolidada em teste de software. A certificação CTFL é pré-requisito, e o candidato ainda deve comprovar sua experiência na prática para ser qualificado para o CTAL. As certificações deste nível são:

• CTAL Test Manager
• CTAL Test Analyst
• CTAL Technical Test Analyst
• CTAL Security Tester
• CTAL Test Automation Engineer

“ISTQB has created the world’s most successful scheme for certifying software testers. As of December 2016, ISTQB® has administered over 700,000 exams and issued more than 500,000 certifications in over 117 countries world-wide. The scheme relies on a Body of Knowledge (Syllabi and Glossary) and exam rules that are applied consistently all over the world, with exams and supporting material being available in many languages.”

“O ISTQB criou o mais bem sucedido esquema de certificação de testadores de software do mundo. Até dezembro de 2016, o ISTQB aplicou mais de 700 mil exames e expediu mais de 500 mil certificações em mais de 117 países do mundo. O esquema é baseado em um Corpo de Conhecimento (composto por Syllabi e Glossário) e regras de exame que são aplicados de forma consistente por todo o mundo, com exames e material de suporte disponíveis em muitas línguas.”

Fonte: <http://www.istqb.org/>, tradução nossa.

Testes no Scrum

No scrum não existe uma fase específica de teste. De acordo com Schwaber e Sutherland (2016, p. 6), no scrum, os times de desenvolvimento

[...] são multifuncionais, possuindo todas as habilidades necessárias, como equipe, para criar o incremento do produto. O scrum não reconhece títulos para os integrantes do Time de Desenvolvimento que não seja o Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa e não há exceções para esta regra. Individualmente os integrantes do Time de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence ao Time de Desenvolvimento como um todo.

Na prática, testes iterativos são executados durante todo o desenvolvimento, como os testes de unidade e os testes de caixa preta. Uma funcionalidade só é considerada concluída quando todos os testes foram executados durante o desenvolvimento. O analista de teste, no scrum, faz parte do time de desenvolvimento e assume várias responsabilidades, como as de líder, arquiteto e responsável pela automatização. Este profissional participa ativamente no levantamento de requisitos e definição de escopo, tratando com grande relevância a necessidade do cliente, considerando os objetivos que o software deve alcançar à medida que ele é entregue. Ao fim de cada sprint, o analista de testes, junto com o time, é responsável por garantir que todos os testes automatizados tenham sido executados sem falhas.

De acordo com Cockburn e Highsmith (2001), para alcançar os resultados adequados, o testador realizará algumas tarefas, como:

• participar das discussões de definição de arquitetura;
• participar das definições de tecnologias utilizadas;
• identificar as necessidades do ambiente de teste;
• identificar restrições tecnológicas;
• identificar ferramentas de teste necessárias para auxiliar na execução do projeto;
• utilizar mapa mental para auxiliar no entendimento das funcionalidades/requisitos;
• identificar os “melhores” analistas de teste para o projeto em questão;
• identificar a necessidade de suporte do time de suporte/operações.
• estimar o tempo de teste.

Este profissional ganha um papel importante na modelagem ágil, pois participará ativamente do desenvolvimento, implantando técnicas eficientes de testes de software, levando em consideração o negócio e suas necessidades.

O time, como um todo, sempre atuará para o benefício do projeto, portanto, o testador, componente agora agregado ao time, integra-se, participando ativamente e colaborando de forma significativa na criação de um software com o mínimo de falhas, defeitos e erros.

De acordo com Duong (2016), o analista de teste, como importante membro do time, participa ativamente de todos os processos, apoiando o scrum master, que faz a mediação, e consultando o product owner para esclarecer eventuais dúvidas. A Figura mostra as principais etapas e membros envolvidos em um projeto scrum:

Metodologia ágil scrum

 

Fonte: Kalakruthi / shutterstock

Como engajar efetivamente os analistas de testes durante uma sprint, uma vez que nada ainda foi construído? De acordo com Hasija (2012), os analistas de testes participam de cerimônias e cumprem suas responsabilidades junto com outros membros do time scrum. Além de criar os casos de teste, os analistas de testes também podem colaborar com o product owner, ajudando-o a escrever os casos de teste de aceitação. Os analistas criam cenários de caso de teste, com base nos requisitos do usuário, identificando e documentando cenários complexos. A participação dos testadores durante o planejamento de entregas e iterações, quando as histórias de usuário estão sendo estimadas, pode ajudar o time a elaborar estimativas mais reais.

Ainda de acordo com Hasija (2012), os analistas de testes devem assumir a responsabilidade de planejar, organizar e envolver o time scrum nos testes. Considerando que poucos desenvolvedores gostam de fazer testes, os analistas e o scrum master devem procurar manter o objetivo e as metas de testes visíveis a todos e manter o time motivado. Todos os membros do time devem estar preparados para participar dos testes, sempre que requisitados. Essa prática mantém a equipe mais equilibrada, divide entre todos a responsabilidade de concluir os testes e dar a velocidade necessária para retornar os testes mais rapidamente, contribuindo para a aumentar a qualidade do produto. O analista de testes também deve registrar o resultado dos testes e reportá-lo ao product owner.

“A automação é o melhor amigo do analista de testes, pois possibilita maior capacidade de repetição, consistência e melhor cobertura dos testes de cada funcionalidade do software. De certa forma, isso é verdadeiro em um projeto Scrum, com ciclos de sprint curtos, de duas a quatro semanas, pois o analista geralmente tem pouco tempo para testar a aplicação. Durante cada sprint de duas semanas, o analista deve desempenhar os testes completos dos novos recursos sendo incluídos durante o sprint, assim como deve desempenhar testes de regressão completos para todas as funcionalidades já implementadas. Como seria esperado, essa responsabilidade cresce significativamente a cada sprint, na mesma proporção que a automação dos testes reduz a pressão sofrida pelos testadores.

Testes automatizados retornam rapidamente resultados, quando o Time implementa o processo de Integração Contínua. Sempre que é necessário construir uma nova versão do produto, os testes automatizados podem ser executados, retornando os resultados imediatamente, tanto para indicar se os novos recursos estão funcionando corretamente, como para dizer se houve problemas em recursos que estavam funcionando em versões anteriores. Sem automação, o analista de testes precisaria realizar esses testes manualmente - uma tarefa monótona e sujeita a erros. A automação dos testes é útil para detectar os defeitos o quanto antes, e para dar ao analista mais tempo para testar os casos limítrofes dos novos recursos sendo desenvolvidos. Por fim, a automação dos testes ajuda o analista a realizar os testes com muito mais eficiência e efetividade”.

Fonte: Hasija (2012).

Integração Contínua como Prática de Testes Ágeis

Saff e Ernst (2003) afirmam que o uso de metodologia ágil incentiva a criação do ambiente de integração contínua, no qual se mantém o código-fonte sempre testado e confiável, diminuindo a alocação de recursos humanos em atividades de teste, pois os métodos ágeis atuam com entregas imediatas, o que exige validação imediata.

A integração contínua é uma prática que normalmente utiliza ferramentas automatizadas, de forma que qualquer alteração no código provoca uma reavaliação de todas as rotinas.

Teste de aceitação

 

Fonte: Bakhtiar Zein

Desta forma, a integração contínua se torna viável com base na utilização de testes automatizados. De acordo com Vidal (2017, p. 221), a automação dos testes deve ser realizada em níveis diferentes. O autor sugere que os testes manuais sejam feitos apenas em casos exploratórios, deixando que a maior parte do trabalho de testes seja realizada de forma automatizada. Além de suportar a integração continuada, esta estratégia fornece agilidade ao trabalho do time e ainda reduz os custos do projeto, pois, uma vez que o teste seja escrito, este pode ser executado tantas vezes quanto for necessário.

No cenário de integração contínua, os testes de aceitação, a serem realizados pelo cliente, mantêm-se presentes. Estes testes ajudam a delimitar o escopo das funcionalidades que estão sendo construídas pelo time de desenvolvimento, além de fornecer feedback para decisões a serem tomadas pelo time.

Como já mencionamos quando tratamos dos testes automatizados, também é importante que, em métodos ágeis, os ambientes de desenvolvimento, teste e produção sejam mantidos separados e com condições de infraestrutura adequadas. Isso garante que os ambientes se mantenham controlados, assegurando que o produto não fique fracionado e tenha a qualidade mantida.

Vidal (2017), ainda propõe a criação de uma massa de testes, conforme indica a Figura. Esta massa de testes, além de contribuir para a redução da carga de trabalho, fornece insumos importantes para o time quando for necessário executar testes durante a construção do produto.

De acordo com a Figura, deve-se selecionar no backlog, que reúne as histórias do usuário, as que devem ser implementadas na release. Casos de uso e cenários devem ser criados para as histórias selecionadas, que servirão de insumos para se definirem os casos de teste, formando a massa de testes. Quando forem aplicados os testes de aceitação junto ao cliente, deve ser criada uma massa de dados adequada para a sua execução.

Criação da massa de testes

 

Fonte: Vidal (2017, p. 224)

Definida a massa de testes, é essencial o uso de uma ferramenta de integração contínua para executar os testes automatizados periodicamente, a fim de garantir que todos eles continuem passando, ou seja, funcionando adequadamente.

De acordo com Barbosa (2012), após a escolha da ferramenta de integração, deve-se informar à ferramenta

[...] o repositório no qual o projeto está armazenado (entende-se como repositório a URL em que o projeto está sob um sistema de controle de versão, como SVN, CVS, Git, Mercurial etc) e um conjunto de tarefas que devem ser executadas para garantir que a integração ocorreu com sucesso. Em geral, criam-se tarefas para a realização do build (quando necessário) e execução de um determinado tipo de teste. Por exemplo, se estamos desenvolvendo um projeto fictício chamado XPTO, criamos uma entrada na ferramenta chamada XTPO-Unit que, de tempos em tempos, irá baixar o código do repositório do controle de versão, executar o build e depois executar todo o conjunto de testes unitários existentes no projeto. Caso todos os testes passem, a integração ocorreu com sucesso; caso contrário, não.

Ainda segundo Barbosa (2012), algumas ferramentas de integração permitem a inclusão de plug-ins que fornecem serviços complementares como relatórios que informam quanto do código está coberto por testes, envio de mensagens por e-mail, informando ocorrência de eventuais falhas na integração etc.

As ferramentas automatizadas de integração contínua, na ocorrência de erro, disparam mensagens para os responsáveis, acusando uma integração mal sucedida. No caso de sucesso, também disparam mensagens informando que a operação foi realizada de forma bem sucedida. A isto se aplica um conceito chamado servidor de construção (build). Este servidor de construção atua como “juiz”, julgando ou considerando as alterações, validando-as quando detectado sucesso nos procedimentos. Em suma, integração contínua automatizada envolve a construção de um código e seu teste de forma automática, e em intervalos frequentes, em um servidor de integração.

Tipos de Testes Usados em Métodos Ágeis

Os processos ágeis se destacam dos métodos tradicionais de desenvolvimento, devido principalmente à priorização das funcionalidades através do código executável, ao invés da produção extensa da documentação escrita. Um ponto essencial para garantir a fidelidade das implementações em relação aos requisitos está nos testes executados sobre o código produzido.

Processos ágeis

Fonte: Digital Saint / shutterstock

Hendrickson (2012) afirma que, para a implementação de técnicas ágeis no ambiente de testes, é necessário mudar a maneira que as equipes estão acostumadas a trabalhar. Uma das mudanças necessárias é a introdução ao conceito de colaboração com o cliente, ao invés de se utilizar documentação abrangente, em consonância com o manifesto ágil. Desta maneira, passamos a fazer um trabalho mais próximo com o cliente, e sua participação no processo é peça-chave para que a técnica ágil de testes possa ser adotada. Outro ponto importante é que todos da equipe devem realizar testes, e não apenas o analista de testes. De acordo com a autora, em um método ágil costuma-se dizer que a equipe é contagiada por testes, e desta maneira o sistema é construído para ser testado desde o início do projeto, e não apenas no fim da codificação. A qualidade passa a ser da equipe toda, não somente dos analistas de testes ou profissionais que possuem a palavra “qualidade” nos seus cargos.

Os requisitos de testes para a metodologia ágil não possuem grande diferenciação em processos guiados por planos. O que realmente difere é o grau de importância dado aos testes em cada um dos processos.

Nos processos guiados por planos, existe uma série extensa de artefatos documentais resultantes da análise profunda realizada sobre o sistema a ser desenvolvido. Os testes, neste caso, são apenas mais um artefato produzido pelo processo, visando garantir a detecção de erros antes da liberação da versão final.

O projeto que nasce com cobertura de teste desde início permite a realização de testes de regressão, que implica em se executar testes em todo o sistema, e não apenas na funcionalidade implementada.

Ainda de acordo Elisabeth Hendrickson (2012), um sistema com cobertura de testes desde o início deve realizar o máximo possível de testes automatizados para que o trabalho manual e repetitivo não venha a ocorrer. Isso trará ganho de tempo na execução do teste, e o custo de transformar um caso de teste em automatizado rapidamente se paga. A autora afirma que “[...] eu tenho observado em minhas equipes um custo de 30% a mais na execução e transformação do teste em automatizado, mas após a 3ª vez que eu executo a bateria de testes, eu já vejo como este custo de 30% foi pequeno”. A autora segue dizendo que o tempo de execução do teste automatizado em relação ao manual é incomparável, os ganhos de velocidade de execução e a possibilidade de a qualquer momento realizar um teste de regressão são maiores.

Os testes em métodos ágeis devem seguir o conceito de pequenas interações para que a informação de como o sistema está sendo construído e os erros que são detectados possam ser rapidamente identificados e corrigidos. Ao término de uma interação, todos os testes devem ter sido executados com êxito.

Segundo Erdogmus et al. (2005), os testes nas metodologias ágeis são importantes, e os autores fazem as seguintes considerações em relação aos dois tipos de teste:

• Testes manuais: objetivam utilizar o sistema para tentar encontrar anomalias no funcionamento do software. Geralmente são pouco eficientes, pois dificilmente se conseguiria chegar à exaustão detectando todas as anomalias. Mas, mesmo com pouca eficiência e fragilidade, ainda são utilizados pela facilidade e simplicidade de sua aplicação, já que basta inserir o sistema em ambiente de validação, simular as entradas e considerar os resultados obtidos.
• Testes automatizados: utilizam aplicativos específicos que testam exaustivamente um software através de scripts preconfigurados. O fato de o teste ser automatizado não garante cobertura total, pois algumas falhas só ocorrem com uma combinação específica de entrada de dados. Um script bem definido colaborará muito para a eficácia dos testes, portanto, o profissional que definirá estes scripts é, na verdade, a chave para o sucesso desta atividade. Seu conhecimento e visão abrangente serão decisivos, assim como a análise dos resultados adquiridos versus resultados esperados serão essenciais na busca e identificação de anomalias.

Extreme programming – Metodologia ágil

 

Fonte: <astephan / shutterstock>

A metodologia ágil XP (eXtreme Programming) adota a técnica test-first, em que, para cada nova funcionalidade, a nova estória é interpretada e em seguida se escreve um teste que atenda especificamente esta nova funcionalidade. Na implementação do código, a implementação do teste é realizada, sendo adicionada à bateria de testes que já foram definidos pelas outras implementações. A implementação do código só será aceita após toda a bateria de testes ser realizada. Nesta modalidade, a implementação dos testes antecede a implementação do código da funcionalidade.

Em outra abordagem do XP, há o test-last. Neste caso, o mesmo conceito do test-first é aplicado, com apenas uma diferença: a implementação desses testes ocorre depois da implementação do código, sem alteração no restante do processo.

Testes em Métodos Ágeis

Métodos ágeis e testes de software

A modelagem ágil é uma realidade para as empresas que necessitam de desenvolvimento eficiente. Os métodos ágeis estabelecem um conjunto de práticas no desenvolvimento de software que está cada vez mais se tornando habitual. Mas, diferente do que muitos pensam, não existe um modelo predefinido ou um conjunto de regras a serem adotadas.

Desenvolvimento ágil

Fonte: Trueffelpix / shutterstock

Na modelagem ágil, cada equipe, dentro de suas atribuições e de acordo com as características dos projetos da empresa, adota uma forma ágil mais adequada para atender suas demandas. Isto quer dizer que, em modelagem ágil, apenas é mostrado o caminho, e a equipe adota as práticas mais adequadas dentro do conceito ágil. Não há procedimentos ideais preestabelecidos apenas princípios adotados a partir da necessidade particular do negócio.

Segundo Highsmith e Cockburn (2001), a novidade nos modelos ágeis não está nos métodos ágeis, mas no envolvimento de pessoas que participam no sucesso do projeto e que estão focadas na capacidade de gestão do negócio.

A modelagem ágil visa colocar em prática o conjunto de valores que o negócio já possui. Vamos imaginar um brainstorm no qual todas as ideias são apresentadas e depois colocadas em uma desafiadora sequência de ações e procedimentos. A modelagem ágil começa a ser aplicada desta forma. Durante este processo é que definimos os procedimentos relacionados aos testes de software.

Vamos voltar a um conceito antigo relacionado à lógica de programação. Os mais experientes se lembram de que, muito antes de começar a desenvolver um programa, o programador desenhava um diagrama de fluxo de dados estruturado do sistema e somente depois começava a programação em si. Estes profissionais mais experientes entendiam que, se você soubesse passar por esta fase antes da programação, a linguagem de programação seria apenas um detalhe. Assim, você poderia escolher qualquer linguagem, pois a lógica de funcionamento seria a mesma. Na modelagem ágil ocorre o mesmo: a linguagem é um detalhe que pode ser pensado e adotado depois do entendimento dos requisitos que o software precisa atender.

Em teste de software, encontramos a figura do testador, que atua junto com a equipe de desenvolvimento estabelecendo técnicas ou definindo conceitos que serão aplicados durante o desenvolvimento para testar a integridade e validar os resultados.

De acordo com Nogueira (2016), uma equipe ágil reúne basicamente dois times:

• o time do cliente, que representa os que estão do lado do negócio no projeto e tem a responsabilidade de escrever histórias e funcionalidades que fornecem os requisitos que o time de desenvolvimento utiliza para a criação do produto;
• o time de desenvolvimento, que reúne todos os programadores, com papeis que variam conforme as necessidades do projeto, responsáveis por transformar as histórias do time do cliente em software.

Seguindo as práticas ágeis, esses dois times trabalham próximos na maior parte do tempo e colaboram para que o resultado do trabalho resulte em um produto que agregue valor para a organização. Muitos times ágeis não possuem membros com a função de testadores. Entretanto, o time de desenvolvimento precisa de alguém que ajude na tarefa de escrever testes, verificar se as histórias estão de acordo com os requisitos e automatizar os testes de regressão, que são essenciais para que haja um feedback rápido e contínuo sobre a qualidade do produto sendo desenvolvido.

Assim, Nogueira (2016, s/p) define o testador ágil como

[...] aquele profissional que abraça as mudanças, colabora com pessoas técnicas e de negócio e entende o conceito de usar testes para documentar requisitos e guiar o desenvolvimento. Esse profissional tende a ter bons conhecimentos técnicos para colaborar com o time de desenvolvimento a automatizar os testes e também para explorar o sistema à procura de comportamentos, erros e problemas.

O testador não precisa ser um componente externo, pois, dependendo das definições prévias das funções do time, ele poderá ser um dos integrantes de dentro do time de desenvolvimento. Este testador será um membro valioso e, como tal, participará ativamente no apoio para as entregas consecutivas que ocorrem no método ágil de desenvolvimento.

“Equipes de desenvolvimento ágil trabalham com testes automatizados. Ter agilidade e não contar com as atividades específicas automatizadas não condiz com o mundo real. O que aconteceria se todos os testes tivessem que ser aplicados manualmente pela equipe a cada incremento de código? Acredito que você saiba a resposta: desperdício de tempo, retrabalho e falta de qualidade.”

Fonte: Vidal (2017, p. 220).

O Manifesto ágil (BECK et al., 2001, s/p, tradução nossa) diz que:

Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:

- Indivíduos e interação entre eles, mais do que processos e ferramentas

- Software em funcionamento, mais do que documentação abrangente

- Colaboração com o cliente, mais do que negociação de contratos

- Responder a mudanças, mais do que seguir um plano

Seguindo os princípios ágeis, em intervalos regulares, o time deve refletir sobre como se tornar mais eficaz e então refinar e ajustar seu comportamento de acordo. Portanto, podemos perfeitamente concluir que as condições ideais existentes que levam um negócio a implantar o modelo ágil também são ideais para se implantar os testes de software de forma muito eficiente.

Assim, o mesmo princípio de modelo ágil se aplica em teste de software: não existe uma fórmula mágica padronizada e ideal, cada empresa, de acordo com suas necessidades específicas, adotará o procedimento ideal. E se este modelo não existir, deve ser criado um que atenda as suas necessidades.

Desta forma, exposto o cenário em que os métodos ágeis se aplicam, podemos chegar à definição do que são os testes ágeis.

Documentação de Teste de Software

O IEEE (Institute of Electrical and Electronic Engineers), organização sem fins lucrativos responsável por promover o conhecimento nas áreas de Engenharia Elétrica, Eletrônica e Computação define padrões para diversas áreas e práticas presentes na engenharia de software.

IEEE - Advancing Technology for Humanity

Fonte: <ieeekerala.org>

O padrão IEEE 829 está relacionado com o processo de testes. Sua abrangência vai desde testes unitários até testes de aceitação e inclui a definição de documentos consistentes e adequados capazes de definir, registrar e prover condições de análise dos resultados obtidos ao longo do processo de testes de software.

Esta norma descreve um conjunto de oito documentos composto por: plano de testes (test plan), especificação de projeto de teste (test design specification), especificação de caso de teste (test case specification), especificação de procedimento de teste (test procedure specification), log de teste (test log), relatório de incidentes de teste (test incident report), relatório de encaminhamento de item de teste (test item transmittal report) e relatório de sumário de teste (test summary report).

Padrão IEEE 829 e documentos associados

Fonte: Barriviera (2013)

Os documentos indicados cobrem as tarefas de planejamento, especificação e relatórios de testes:

• Plano de teste: é um documento que apresenta o planejamento para a execução do teste e identifica os itens e as funcionalidades a serem testados, bem como as tarefas e os riscos associados com a atividade de teste.
• Especificação de testes: é composto por três documentos (especificação de projeto de teste, especificação de caso de teste e especificação de procedimento de teste) que identificam os casos e os procedimentos de teste, critérios de aprovação, definem dados de entrada e resultados esperados, além de especificar os passos para a execução dos testes.
• Relatórios de testes: são compostos por quatro documentos (log de teste, relatório de incidente de teste, relatório-resumo de teste e relatório de encaminhamento de item de teste) que visam registrar detalhes relevantes, eventos que ocorrem durante os testes e resultados das atividades.

Farias (2014) destaca que esta norma separa as atividades de teste em três etapas: preparação do teste, execução do teste e registro do teste. A autora afirma que, mais do que apresentar um conjunto de documentos, esta norma apresenta um conjunto de informações necessárias para teste de produtos, independentemente do tamanho ou da complexibilidade do software.

Em sua proposta, a norma IEEE-829 descreve um método para implantação do processo de teste de software em alguns documentos, cujo teor principal está relacionado abaixo.

• Guia para elaboração de documentos de teste de software: tem o propósito de servir como referência para criação de documentos de teste.
• Processos para a elaboração de documentos de teste de software: apresenta os processos que abrangem a preparação, a execução e o registro dos resultados do teste, estabelecendo uma orientação geral.

Recomenda-se que, independentemente da forma como os documentos da norma sejam adaptados para a documentação dos testes, é importante que incluam o planejamento, o projeto, os casos de teste e os procedimentos de teste. Além disso, os resultados e incidentes ocorridos durante o teste devem ser adequadamente registrados e condensados em um relatório final. Isso garantirá que todo o processo de testes possa ser adequadamente realizado e bem documentado.

Automação de Testes

Testes manuais ou automatizados

A automação de testes tem como um dos objetivos diminuir o envolvimento direto das pessoas em atividades repetitivas. Mas, como vimos, a automação de testes não se restringe ao trabalho repetitivo e chato. Na prática, a automação de 100% dos testes manuais pode não ser a melhor estratégia. A automação de testes é pouco eficaz quando os testes são complexos e exigem interações intersistemas ou validações subjetivas. Além disso, em vários casos o custo e o tempo para automatizar os testes de um projeto são maiores que o custo e o tempo do próprio projeto de desenvolvimento, inviabilizando a iniciativa.

Segundo Lages (2010), quando se deseja aplicar a automação na etapa de execução de testes das funcionalidades de um sistema, vários fatores devem ser avaliados para se identificar se é vantagem ou não a automação dos testes. Ela deve ser feita somente quando uma rotina específica de teste for executada várias vezes, pois a automação também demanda tempo de criação e manutenção de scripts. Lages ressalta que “[...] 70% dos testes do mercado são manuais. O teste automatizado serve basicamente para fazer Teste de Regressão. O que acha erro mesmo é o teste manual”.

Existem diversos tipos de testes para detectar a ineficiência de um sistema, e antes de muitos deles serem automatizados, são executados por várias vezes em modo manual para, depois de comprovado sucesso na sua utilização, serem automatizados.

Implementação dos testes

Uma vez que o software tenha sido elaborado, é necessário fazer a implementação dos testes manuais ou automatizados. Isto pode exigir conhecimento multidisciplinar, ou seja, conhecimento de programação, de testes de software, de linguagem de negócio e de ferramentas específicas. Portanto, o profissional responsável pelos testes automatizados normalmente é diferenciado.

Segundo Schach (2010, p. 463),

[...] implementação é o processo de converter o projeto detalhado em código. Quando isso é feito por um único indivíduo, o processo é relativamente bem compreendido. Porém, hoje em dia, a maioria dos produtos são muito grandes para serem implementados por apenas um programador dentro das restrições de tempo. Em vez disso, o produto é implementado por uma equipe, com todos trabalhando ao mesmo tempo em diferentes componentes do produto.

O trabalho colaborativo não indica a necessidade de todos realizarem tarefas semelhantes. Indica apenas a integração de ideias que naturalmente ocorre em uma equipe integrada.

De acordo com Pressman e Maxim (2016, p. 417), na década de 1970, McCall, Richards e Walters categorizaram os fatores que afetam a qualidade do software, relacionados com três áreas distintas: operação do produto, transição do produto e revisão do produto.

Fatores de qualidade de McCall

Fonte: Pressman e Maxim (2016, p. 417).

Ambiente de testes automatizados: homologação

Vamos recordar as diferenças entre os ambientes de desenvolvimento, de testes e de produção. O ambiente de desenvolvimento é utilizado pelos desenvolvedores para construir o software, reunindo máquinas nas quais o código é implementado. O ambiente de homologação corresponde ao ambiente de testes, no qual o desenvolvedor publica o software para submetê-los aos testes alpha. O ambiente de produção corresponde à que leem que os usuários finais utilizarão o software.

Ambientes de desenvolvimento, teste e produção

Fonte: Vidal (2017, p. 221).

Cada tipo de teste possui restrições próprias relacionadas com o ambiente que podem ter como dependência a flexibilidade e portabilidade das tecnologias utilizadas. Fatores externos de software ou hardware também podem influenciar a definição de onde executar os testes.

Um ambiente de testes ou ambiente de homologação, que é um ambiente criado para replicar todas as condições do ambiente de produção, contribui para a eficiência na execução dos testes e qualidade final da entrega. Não é fácil a criação e manutenção deste ambiente, então, quando ele já está em uso, deve ser usado de forma abrangente.

Com o tempo, é comum a infraestrutura do ambiente de homologação correr o risco de ficar desatualizada, e a equipe deve buscar mostrar aos responsáveis da área técnica a importância da manutenção de um ambiente de homologação atualizado. Este ambiente deve espelhar o máximo possível o ambiente de produção, de forma a buscar garantir sucesso na execução dos testes.

Existem várias alternativas para criar ou montar este ambiente de homologação. Entre elas encontramos, por exemplo, a virtualização, que, quando usada eficazmente, pode gerar um ambiente adequado e de baixo custo. Quando há uma grande quantidade de testes sendo executados neste ambiente simultaneamente, devem-se tomar cuidados para garantir recursos suficientes para que não haja uma sensível queda de desempenho do sistema, de forma a não comprometer a confiabilidade dos testes.

Conforme vimos, os testes de desempenho, de carga, de esforço/estresse e de longevidade requerem um ambiente de testes similar ao ambiente de produção, porque os resultados obtidos estão diretamente relacionados com este ambiente. Os testes de segurança normalmente requerem, também, uma infraestrutura similar ao do ambiente de produção, pois espera-se que estes testes exponham as vulnerabilidades do sistema no ambiente adequado.

Exemplo de teste automatizado com JUnit: FizzBuzz

Vamos apresentar aqui um exemplo de teste automatizado utilizando o JUnit, com base na abordagem TDD (Test Driven Development). De acordo com Santos Filho e Oliveira (2014), o TDD segue duas regras simples: a primeira é que um novo teste só deve ser escrito se um teste automatizado falhar, e a segunda é que deve-se buscar eliminar duplicidade. Apesar de simples, essas regras geram um complexo comportamento expresso pelo ciclo red-green-refactor (vermelho-verde-refatora), que é baseado em:

• Vermelho: escrever um teste que não funciona;
• Verde: fazer o teste passar, escrevendo uma pequena mudança no código, mesmo que não seja a mais adequada;
• Refatora: melhorar o código, eliminando todas as duplicidades e mantendo-o verde.

“‘…TDD é simplesmente você escrever o teste do seu programa antes de codificá-lo de fato. Teste nesse contexto seriam os testes unitários.’

Ao meu ver a essência está correta, porém talvez faltasse deixar claro que TDD não se trata apenas de escrever testes antes do código. Esta é a primeira visão que a maioria dos iniciantes têm sobre desenvolvimento orientado a testes: que basta escrever todos os testes antes e pronto. Isto é compreensível, já que escrever testes antes do código já causa um choque por si só. Porém, TDD foi definido pelo Kent Beck com a seguinte fórmula:

TDD = Test-First + Design Incremental

E a parte do design incremental ficou um pouco confusa na continuação do texto:

‘…O processo de desenvolvimento usando TDD é muito simples:

1 - Escolha a classe e o método que você que codificar e pense em todos os testes possíveis para ela;

2- Antes de escrever a classe, codifique os testes que você pensou…’

Seguindo estas instruções (escrever todos os testes possíveis antes) pode-se perder um pouco de um dos maiores benefícios de TDD, que é prover feedback rápido sobre o que está sendo implementado. Aí que entra o design incremental. A ideia é que a solução seja criada em pequenos passos (Baby Steps), seguindo a rotina descrita no livro TDD by Example:

1 - Escreva um pequeno teste que falhe, e talvez até mesmo sequer compile inicialmente;

2 - Faça o teste passar da maneira rápida, cometendo qualquer ‘pecado’ durante este processo;

3 - Refatore: elimine toda duplicação criada para fazer os testes passarem.

Desta forma, não é preciso pensar na solução completa (sequer numa classe inteira) antes de começar, basta pensar em um teste apenas e fazê-lo passar. Com o conhecimento adquirido é possível então passar para o próximo teste com mais segurança, e assim avançar até que a solução esteja completa.

Outra noção comum é pensar que TDD trata apenas de testes de unidade.

DD faz bastante uso de testes unitários. Porém, embora a maioria dos exemplos mostra TDD sendo feito através deste tipo de teste, isto não significa que a técnica está restrita a eles. Escrever testes de aceitação simples antes do código existir também pode colaborar na hora de desenvolver com TDD, já que com eles também pode-se obter feedback sobre a solução.

Embora sejam bem pontuais, observar estes detalhes pode ajudar no uso mais eficiente de TDD.”

Para iniciar o planejamento dos testes, temos que partir de um problema específico e usaremos um caso clássico denominado problema FizzBuzz. O FizzBuzz consiste em exibir uma lista de 1 a 30, um em cada linha, e filtrar todos os números respeitando as regras:

Retorno do Fizz Buzz

números divisíveis por 3 devem retornar “Fizz”
números divisíveis por 5 devem retornar “Buzz”
números divisíveis por 3 e 5 devem retornar “FizzBuzz”
Fonte: Elaborado pela autora

Antes de começar a escrever os testes, é preciso definir o que precisa ser testado, para isso deve-se criar uma lista com todos os testes que sejam necessários. No nosso utilizaremos a seguinte lista para os testes:

[1] Retornar 1 ao passar 1;

[2] Retornar 2 ao passar 2;

[3] Retornar Fizz ao passar 3;

[4] Retornar 4 ao passar 4;

[5] Retornar Buzz ao passar 5;

[6] Retornar Fizz ao passar 6;

[7] Retornar 7 ao passar 7;

[8] Retornar 8 ao passar 8;

[9] Retornar Fizz ao passar 9;

[10] Retornar Buzz ao passar 10;

[11] Retornar FizzBuzz ao passar 15;

[12] Retornar FizzBuzz ao passar 30.

O teste [1] da lista deve ser implementado e retornar 1 quando passado 1 como parâmetro. O método que executa este teste é:

@Test
public void retornaUmParaUm(){
Fizzbuzz fizzbuzz = new Fizzbuzz();
assertEquals("1", fizzbuzz.verificaFizzbuzz(1));
}

Ao executar o teste é apresentado o seguinte resultado:

Nenhum teste passou, 1 teste causou 1 erro (0,99 s)
retornaUmParaUm causou um Erro: Uncompilable source code – Erroneous tree type: <any>

Na primeira tentativa, o teste não vai passar porque não existe a classe Fizzbuzz nem o método verificaFizzbuzz(). Assim, o próximo passo é fazer o teste passar com o mínimo de código. Para isto, deve ser implementada a classe Fizzbuzz e o método verificaFizzbuzz retornando 1, atendendo ao teste [1] da lista.

public class Fizzbuzz {
public String verificaFizzbuzz(Integer numero){
   return "1";
   }
}

Como resultado da execução do teste [1], obtém-se a seguinte saída:

O teste passou (0,98 s)

Agora é necessário implementar o teste [2] da lista, que retorna 2 quando passado 2 como parâmetro.

@Test
public void retornaDoisParaDois(){
Fizzbuzz fizzbuzz = new Fizzbuzz();
assertEquals("2", fizzbuzz.verificaFizzbuzz(2));
}

Ao executar esse teste, é apresentado um erro, pois o método verificaFizzbuzz vai retornar sempre 1. Executando o teste, é apresentado o seguinte resultado:

   1 teste passou, 1 teste falhou. (0,123 s)
   retornaDoisParaDois Falhou: expected <[2]> but was <[1]>

É necessário refatorar o código para fazê-lo passar. As mudanças apresentadas são:

public String verificaFizzbuzz(Integer numero){
return numero.toString();
}

Com essas mudanças, o teste [2] passou. Como resultado da execução foi apresentada a seguinte saída:

Ambos os testes passaram. (0,108 s)

Automação de Testes

Testes automatizados

Testes automatizados são programas ou scripts simples que exercitam funcionalidades do sistema sendo testado e fazem verificações automáticas nos efeitos colaterais obtidos. A grande vantagem desta abordagem é a de que todos os casos de teste podem ser fácil e rapidamente repetidos a qualquer momento e com pouco esforço.

A reprodução de um teste automatizado inúmeras vezes, em situações específicas, garante que passos importantes não sejam esquecidos, e isto, sem dúvida, evitará uma situação indesejável.

Além disso, como os casos para verificação são descritos através de um código interpretado por um computador, é possível criar situações de testes bem mais elaboradas e complexas do que as realizadas manualmente, possibilitando qualquer combinação de comandos e operações. A magnitude dos testes pode também ser facilmente alterada. Por exemplo, é trivial simular centenas de usuários acessando um sistema ou inserir milhares de registros em uma base de dados, o que não é factível com testes manuais.

Fonte: Kalakruthi

Uma prática comum no passado (até a década de 1990) era criar uma função de teste em cada módulo ou classe do sistema que continha algumas simulações de uso da unidade. O problema desta prática estava na falta de organização, já que o código adicional era misturado ao próprio sistema afetando a legibilidade do código. Por isso, surgiram os frameworks, que auxiliam e padronizam a escrita de testes automatizados, facilitando o isolamento do código de teste do código da aplicação.

De acordo com Lages (2010), a escolha dos testes automatizados candidatos, ou seja, os mais críticos, deve ser realizada com base no planejamento de um projeto de automação. O autor afirma que apesar de não existir uma categorização amplamente difundida, a experiência tem mostrado que os testes candidatos são normalmente agrupados nestas quatro áreas:

• Smoke tests ou testes de fumaça, em que um conjunto mínimo de testes é selecionado com o objetivo de validar um build antes do início de um ciclo de testes.
• Testes de regressão: os testes são selecionados com o objetivo de executar o reteste de uma funcionalidade ou da aplicação inteira.
• Funcionalidades críticas: os testes são selecionados com o objetivo de validar as funcionalidades críticas que podem trazer riscos ao negócio.
• Tarefas repetitivas: os testes são selecionados com o objetivo de reduzir o envolvimento dos testadores em atividades manuais repetitivas e suscetíveis a erros, tais como cálculos matemáticos, simulações, processamentos, comparações de arquivos ou dados etc.

Vidal (2017, p. 220) afirma que

[...] a automação dos testes exige a complementação do modelo com os requisitos de software configuration management (SCM) e quality assurance (QA), pois estes requisitos incorporam qualidade e já deixam a infraestrutura preparada para suportar os testes automatizados e de regressão.

Quando executar os testes automatizados

Existem testes rápidos e alguns mais demorados para serem realizados. A definição de prioridades é essencial para o sucesso na execução dos testes automatizados. Mas deve-se tratar esta questão com cuidado, pois o custo da criação dos testes automatizados normalmente pode ser bem maior do que a dos testes manuais, principalmente por causa da estrutura por trás deste ambiente.

É importante ressaltar, ainda, que executar testes com frequência é fundamental. É mais vantajoso executar baterias pequenas e frequentes de testes do que uma rara e grande bateria. Além disso, as baterias de testes que não são executadas com frequência podem se tornar obsoletas, correndo o risco de ficarem desatualizadas e, consequentemente, não acompanharem a evolução natural dos componentes relacionados.

Ainda é importante destacar que quanto mais obsoleto se torna um teste, mais caro fica, comprometendo recursos e podendo, no momento mais importante, não atender aos objetivos dos testadores. Também a não execução periódica pode causar acúmulos de erros ou falhas que podem tornar a implementação de melhorias incompatível com o cumprimento de prazos estabelecidos.

Há softwares gratuitos que podem ser utilizados, oferecendo uma base ou referência para a execução de testes automatizados de software. Alguns exemplos, em ordem alfabética, são:

• CppTest: <http://cpptest.sourceforge.net>
• csUnit: <http://www.csunit.org>
• Eclipse: <http://www.eclipse.org>
• JMeter: <http://jakarta.apache.org/jmeter>
• JSUnit: <http://www.jsunit.net>
• JUnit: <http://www.junit.org>
• Selenium: <http://www.seleniumhq.org/>
• SUnit: <http://sunit.sourceforge.net>
• TestNG: <http://testng.org/doc/>

Além destas ferramentas, também existem linguagens específicas que podem ser usadas, como:

• DOM (document object model), que é uma linguagem para permitir que programas acessem e modifiquem dinamicamente objetos de um documento HTML: <http://www.w3.org/DOM/>
• XPath - XML path language é uma linguagem para identificar trechos específicos de um arquivo XML: <http://www.w3.org/TR/xpath>

Para ilustrar o uso de uma destas ferramentas, consideremos um exemplo para aplicações Java com o auxílio do JUnit. Os testes são organizados em casos de teste definidos através de anotações Java @Test antes da definição de cada método de teste. O framework também possui uma gama de métodos auxiliares para comparar os efeitos colaterais esperados com os obtidos, tais como assertEquals, que compara a igualdade do conteúdo de objetos, assertSame, que compara se duas referências se referem ao mesmo objeto, e assertNull,que verifica se uma dada referência é nula, entre outros.

Exemplo de teste automatizado com o JUnit

Fonte: <ime.usp.br>

Ciclo de vida de testes de software

O teste e a depuração são atividades diferentes, mas a depuração deve ser associada a uma estratégia de teste. Há vários estágios na definição da estratégia de testes, no entanto, se considerarmos o seu ciclo de vida, ficará mais claro o entendimento e a importância da elaboração de estratégias para a implementação de testes.

Quanto mais cedo se iniciarem os testes, mais barata será a correção dos erros encontrados e, para conquistar este benefício, o processo de teste, assim como o processo de desenvolvimento, deve ter um ciclo de vida, que é definido em fases.

Fonte: Adaptado de Bastos et al. (2012).

Estas etapas são detalhadas no que se segue.

Procedimentos iniciais

Aprofunda-se, nesta etapa, um estudo sobre os requisitos do sistema relacionados ao negócio, de forma a garantir que estejam completos e sem nenhuma ambiguidade. Deve ser traçado também um pequeno esboço do processo de teste. É preciso elaborar um plano com todas as atividades principais que serão executadas.

Planejamento

Nesta etapa são realizadas a elaboração da estratégia de testes e do plano de testes com objetivo de minimizar os principais riscos do negócio e fornecer os caminhos para as próximas etapas. Esta etapa deve ser executada em conjunto com as atividades de captação dos requisitos e o planejamento do projeto de desenvolvimento do sistema a ser testado. Testes de verificação deverão ser executados sobre os requisitos do sistema. Deverá também ser preparada a análise de risco do projeto de teste.

Preparação

Esta etapa ocorre paralelamente às outras etapas. O objetivo básico é preparar o ambiente de teste para que os testes sejam executados corretamente, em condições mais próximas às da utilização pelo cliente.

Especificação

Esta etapa se refere à especificação dos casos e roteiros de teste que são elaborados no decorrer do projeto. À medida que a equipe de desenvolvimento conclui alguns módulos ou partes do sistema, são elaborados os casos e roteiros de teste.

Execução

Executar e registrar os resultados dos testes são tarefas que precisam obedecer as seguintes diretrizes:

• Os testes deverão ser executados de acordo com os casos e roteiros de teste.
• Devem ser usados scripts de teste, caso seja empregada alguma ferramenta de automação de testes.
• Os testes deverão ser executados integralmente, por regressão ou parcialmente, sempre que surgir alguma mudança na versão dos programas em teste e nos ambientes de teste preparados, conforme previstos na estratégia e plano de testes.

Entrega

O projeto de teste é finalizado, sendo concluída e arquivada sua documentação. Deve ser recolhida esta documentação e elaborado um relatório gerencial com as conformidades e não-conformidades encontradas.

Casos de Teste

Os casos de teste funcionam como um roteiro a ser seguido para que os testes sejam realizados. De acordo com Farias (2014), um caso de teste é projetado para resolver um determinado objetivo e reúne um conjunto de condições que especificam os valores de entrada, precondições de execução, resultados esperados em função das entradas e pós-condições de execução. Os casos de teste podem ser positivos ou negativos:

• Caso de teste positivo: representa as ações previstas, buscando confirmar que o sistema faz aquilo que deveria mesmo fazer. É chamado de “caminho feliz do software”.
• Caso de teste negativo: representa as ações imprevistas, quando o software não faz aquilo que deveria fazer ou faz o que não deveria ser feito. É chamado de “caminho infeliz do software”.

É muito usual que os casos de teste sejam apresentados através de diagramas de caso de uso da UML.

Defeitos, Falhas e Erros

Qual a diferença entre defeitos, falhas e erros de um software?

Pressman e Maxim (2016, p. 432) fazem a seguinte distinção entre esses termos em relação ao software:

• Erro: um problema de qualidade encontrado antes que o software seja entregue aos usuários finais. Pode ser fruto de instruções ou comandos incorretos.
• Defeito: um problema de qualidade encontrado depois que o software foi entregue aos usuários finais. Pode ser fruto de inconsistência em relação à especificação.
• Falha: um problema que ocorre no software já em produção. Pode se revelar como um comportamento inconsistente em função de entradas de dados distintas.

Os autores argumentam que não há consenso entre os especialistas em relação à distinção entre estes três termos, principalmente em desenvolvimento com base em metodologias ágeis, em que pré e pós-entrega não são conceitos bem definidos. Mas é fato que cada um destes problemas pode causar diferentes impactos financeiros e humanos no negócio. As pessoas envolvidas no desenvolvimento querem evitar defeitos para que não fiquem com sua imagem manchada.

Mas é possível argumentar a favor das diferenças entre os termos. Considere a seguinte frase: “A melhor maneira de tentar construir a confiança é tentar destruí-la”.

Parece um paradoxo, concorda?

Pois saiba que não apenas parece, é um paradoxo.

Na tentativa de destruir a confiança por encontrar defeitos, falhas ou erros, na verdade estamos construindo uma confiança cada vez mais sólida no produto desenvolvido.

Pense, por exemplo, nos exaustivos testes automobilísticos, quando as montadoras literalmente destroem seus veículos para provar a qualidade de seus bens produzidos. Não concorda que estão provando com isso a segurança que você espera em um momento crítico, como um acidente de colisão frontal em uma estrada em alta velocidade?

Os projetos podem ter uma grande complexidade, então entendemos claramente que será impossível que eles não possuam alguns defeitos, principalmente porque em um grande projeto temos várias cabeças pensantes, com formações e lógicas diferentes, trabalhando juntas para atingir os objetivos.

Vários poderiam ser os motivos para alegar a impossibilidade de um software sem qualquer tipo de erro, falha ou defeito, mas não queremos contribuir nem para a busca da perfeição, que não existe, nem para o relaxamento relacionado à inexistência de perfeição.

Hoje não podemos falar de qualidade de software sem falar de desenvolvimento ágil, que tem sido considerado um conceito avançado de desenvolvimento e busca na eliminação de erros, falhas e defeitos.

Qualidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade são atributos buscados incansavelmente no desenvolvimento de software e o que nos propomos a fazer na consideração deste assunto é como o testador pode contribuir para esta busca quase que inalcançável.

O processo de testes é efetivo quando encontra defeitos e é eficiente quando encontra os defeitos com a menor quantidade de recursos possível.

Fundamentos de teste de software

De acordo com Pressman e Maxim (2016), um software é testado para descobrir erros que foram introduzidos inadvertidamente no momento em que foi projetado e construído.

“Teste é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Por esta razão deverá ser definido para o processo de software, um modelo para o teste, que é um conjunto de etapas no qual podem ser empregadas técnicas específicas de projetos de casos de teste e métodos de teste.” (PRESSMAN; MAXIM, 2016, p. 466).

Pressman e Maxim (2006, p. 467) listam um conjunto de perguntas e respostas que apresentam os principais fundamentos que embasam os testes de software, quais sejam:

• Quem realiza? O gerente do projeto, os engenheiros de software e especialistas em testes devem desenvolver uma estratégia de testes, de forma que o projeto tenha um plano formal de testes.
• Porque é importante? O teste é a atividade que requer maior esforço de projeto dentro do ciclo de desenvolvimento de software. Se for conduzido ao acaso, pode implicar em desperdício de tempo e esforço, além de abrir espaço para a infiltração de erros. Assim, é muito importante que se estabeleça uma estratégia sistemática para o teste de software.
• Quais são as etapas envolvidas? O teste inicia no pequeno e segue para o grande, ou seja, começa em um componente ou em um grupo de componentes relacionados; depois estes são integrados de forma a abarcar todo o sistema. A partir deste ponto, uma série de testes de alto nível é executada para descobrir erros relativos aos requisitos do cliente. À medida que erros forem encontrados, é necessário fazer um diagnóstico e buscar sua correção através do processo de depuração do sistema.
• Qual é o artefato? Uma especificação de teste documenta a abordagem da equipe que realiza os testes, definindo um plano para a estratégia global e um procedimento que designa as etapas específicas de testes e os tipos de testes que serão realizados.
• Como garantir que o trabalho de testes foi feito corretamente? Para se certificar da corretude do teste, deve-se realizar uma revisão na especificação do teste antes de sua execução para avaliar a integralidade dos casos de teste e das tarefas planejadas. Um plano e um procedimento de testes eficazes levarão à construção coordenada do software e à descoberta de erros em cada fase da construção do produto de software.

Fato:

Samsung suspende fabricação e venda do Galaxy Note 7

“A Samsung suspendeu a fabricação do telefone Galaxy Note 7, informou a agência sul-coreana de notícias Yonhap, citando como fonte uma fornecedora da empresa. A iniciativa ocorre após um recall de 2,5 milhões de aparelhos no mundo todo por conta do risco de explosão da bateria.

A empresa também anunciou que ordenou a suspensão das vendas e trocas de unidades do Galaxy Note 7 enquanto acontecem as investigações sobre os problemas recentes.

O caso

Fabricante número 1 de smartphones no mundo, a Samsung enfrenta tempos difíceis desde que, em 2 de setembro de 2016, semanas após o lançamento antecipado do Galaxy Note 7, teve de anunciar o recall de 2,5 milhões de unidades vendidas em 10 países. O motivo era que as baterias podiam explodir.

A decisão de suspender temporariamente a produção foi tomada em coordenação com as autoridades de proteção ao consumidor da Coreia do Sul, Estados Unidos e China, informou a fonte, que pediu anonimato, à agência.

A AT&T e T-Mobile anunciaram a interrupção das vendas do Galaxy Note 7, à espera de investigações adicionais.

‘Estamos tentando ajustar os volumes de produção para melhorar o controle de qualidade e permitir investigações mais profundas após as crescentes explosões do Galaxy Note 7’, afirmou o grupo em um comunicado.

As imagens de telefones carbonizados inundaram as redes sociais de todo o mundo nas últimas semanas. Os incidentes com aparelhos que já haviam sido substituídos agravaram ainda mais a situação da Samsung.

A crise ocorre num momento que não podia ser pior. Após os anos excepcionais de 2012 e 2013, a Samsung começou a sofrer com o avanço da Apple e dos grupos chineses. O grupo sul-coreano contava com este smartphone para sustentar seu crescimento até o fim do ano, em um mercado cada vez mais competitivo. Os analistas consideram que o custo deste recall pode chegar a US$ 2 bilhões.

‘É novamente algo muito grave’, declarou S. R. Kwon, analista da Dongbu Securities. ‘Podem chegar a retirar o Note 7 do mercado. O mais inquietante é que as coisas não parariam por aí.’ ‘Isso vai danificar a imagem de marca da Samsung e penalizará as vendas de outros smartphones Galaxy’, previu.”

Fonte: <g1.globo.com>

Princípios do teste de software

De acordo com o Syllabus, em ISTQB (2011, p. 14, adaptado), há sete princípios que fornecem um guia geral para o processo de teste de software:

Princípio 1 – Teste demonstra a presença de defeitos

O teste pode demonstrar a presença de defeitos, mas não pode provar que eles não existem. O teste reduz a probabilidade que os defeitos permaneçam em um software, mas mesmo se nenhum defeito for encontrado, não prova que ele esteja perfeito.

Princípio 2 – Teste exaustivo é impossível

Testar tudo (todas as combinações de entradas e pré-condições) não é viável, exceto para casos triviais. Em vez do teste exaustivo, riscos e prioridades são levados em consideração para dar foco aos esforços de teste.

Princípio 3 – Teste antecipado

A atividade de teste deve começar o mais breve possível no ciclo de desenvolvimento do software ou sistema e deve ser focado em objetivos definidos.

Princípio 4 – Agrupamento de defeitos

Um número pequeno de módulos contém a maioria dos defeitos descobertos durante o teste antes de sua entrega ou exibe a maioria das falhas operacionais.

Princípio 5 – Paradoxo do Pesticida

Pode ocorrer de um mesmo conjunto de testes que são repetidos várias vezes não encontrarem novos defeitos após um determinado momento. Para superar este “paradoxo do pesticida”, os casos de testes necessitam ser frequentemente revisados e atualizados. Um conjunto de testes novo e diferente precisa ser escrito para exercitar diferentes partes do software ou sistema com objetivo de aumentar a possibilidade de encontrar mais erros.

Princípio 6 – Teste depende do contexto

Testes são realizados de forma diferente conforme o contexto. Por exemplo, softwares de segurança crítica são testados diferentemente de um software de comércio eletrônico.

Princípio 7 – A ilusão da ausência de erros

Encontrar e consertar defeitos não ajuda se o sistema construído não atende às expectativas e necessidades dos usuários.