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.