Olá, estudante! Tudo bem? Na lição anterior mergulhamos no conceito de engenharia de software, seus conceitos e premissas. Nesta lição, você aprenderá sobre os conceitos e os tipos de testes de software, a gestão de defeitos e planos para se testar softwares. Trata-se de uma lição que lhe colocará no mundo do teste de software, uma área em ascensão dentro da Engenharia de Software e que tem demandado muitos profissionais.

O campo de Teste de Software faz parte da grande área Engenharia de Software e, se considerarmos as nossas discussões anteriores sobre os métodos de desenvolvimento de software, perceberemos que o teste de software se encontra após a etapa de codificação e antes da manutenção (consulte Figura 1).

Relembrando:

Muitos alunos me perguntam em que momento a área de Teste de Software se transforma numa profissão ou é utilizada dentro das organizações. Posso lhes dizer que temos, hoje, especialistas dedicados, única e exclusivamente, a trabalharem como Software Testers (Testadores de Software). Empresas especializadas em desenvolvimento de software (softwares house) devem ter este tipo de profissional porque serão eles quem homologarão o software para implantação, ou serão eles quem realizarão os testes de um incremento, dependendo do método que estiver sendo utilizado para o desenvolvimento do software.

Existem, também, certificações em instituições brasileiras e estrangeiras responsáveis pela formação de profissionais nesta área. A Certified Tester Foundation Level (CTFL) é uma delas. No Brasil, temos a Brazilian Software Testing Qualification Board, especializada em certificações na área. Devido à demanda crescente por este tipo de profissional, é importante conhecermos os conceitos, os tipos e as formas para planejarmos o teste de um software.

Muitas vezes, nas organizações, especialmente nas pequenas e de médio porte, o desenvolvedor do software é também o analista de sistemas, o engenheiro de software e acaba sendo o testador do software (Tester). Este cenário tem grandes chances de produzir softwares com baixa qualidade, e você sabe por quê? Porque os testes de validação do software são realizados pela mesma pessoa e, em 99,9% das vezes, inviabiliza a detecção de erros antes que o software vá para produção.

Você já viu alguma mãe/pai comentar ou identificar defeitos no próprio filho? Difícil né! Esta ótica é válida para o desenvolvimento de software. O desenvolvedor não conseguirá identificar erros ou defeitos naquilo que ele mesmo criou. A tendência é que ele faça o contrário, defenda e tente justificar os problemas em vez de tentar resolvê-los. Assim como uma mãe/pai faz com um filho quando faz algo de errado.

Devido a este cenário que é bastante comum em nossas organizações, recomendo que os testes sejam realizados por outras pessoas não vinculadas ao projeto daquele software, preferencialmente um profissional capacitado para isso. Caso não haja uma equipe ou profissional dedicado a este fim, não incorra em um dos erros mais comuns dos desenvolvedores, você mesmo testar o software e considerar que está “pronto” para implantação no usuário. Este tipo de atitude pode ter diversas implicações que vão desde o aumento no custo do software até a ampliação da resistência do usuário no uso de um software que apresenta erros ou tem defeitos.

A área de teste de software é bastante importante para o campo da Engenharia de Software e para profissionais em análise e projeto de sistemas porque está relacionada diretamente à qualidade do software (PRESSMAN, 2011; PRESSMAN; MAXIM, 2016; SOMMERVILLE, 2011). A literatura de teste de software não é nova, já em 1979 se discutia o teste de software (pesquisar sobre Glenford Myers - The Art of Software Testing) e a necessidade de que quanto mais cedo erros no software forem descobertos, menor será o custo de um projeto (MYERS; SANDLER; BADGETT, 2011). Assim, a área de teste cresce em importância pelo fato de permitir que os projetos tenham um menor custo, mas também haja aceitação maior por parte dos seus usuários. Softwares que apresentam muitos erros ou defeitos (veremos a diferença entre os dois a seguir) tendem a desenvolver nos seus usuários resistência ao seu uso e, muitas vezes, ao não uso.

As atividades de teste, normalmente, requerem os seguintes elementos de entrada (elementos necessários para o teste seja realizado):

Perceba que são necessários elementos que discutimos em lições anteriores e que, agora, serão importantes para que o teste seja realizado com sucesso. Anteriormente, eu falei que o teste tem uma relação com a qualidade do software, mas devemos entender quais elementos envolvem um software com qualidade para ser testado:

A realização de um teste de software tem alguns atributos genéricos, como:

Há um erro muito comum com quem trabalha com teste de software que é “comemorar” quando erros ou defeitos NÃO são encontrados durante o teste de um software. Isso é um ERRO porque bons testes devem encontrar erros ou defeitos. Dificilmente (menos de 0,01% de chance), um software é produzido sem erros ou defeitos e é colocado em produção sem que nenhum problema ocorra. Pode ocorrer com softwares muito pequenos, mas softwares de médio ou grande porte esta é uma regra. Assim é importante sabermos como realizar os testes de um software. Quais estratégias podemos aplicar para o teste de softwares? Vamos lá!

Estratégias e teste de software

De acordo com Pressman e Maxim (2016, p. 456) um teste é “uma rede de segurança que pegará todos os erros que ocorrem por causa de práticas inconsistentes de engenharia de software. Enfatize qualidade e detecção de erros ao longo de todo o processo de software”. O importante, após o desenvolvimento de um código fonte de um software, é a realização de testes para que ERROS sejam encontrados, pois bons testes encontram erros. Isso é feito antes que o software entre em operação. É importante diferenciarmos erros de defeitos.

Destaco que podem ocorrer conflitos em ambiente de desenvolvimento de software. Quando digo conflitos, estou me referindo a discussões ou discordâncias entre os envolvidos no desenvolvimento, quem usa o software e os testadores, vamos conhecer alguns desses conflitos que geralmente ocorrem:

• Conflito de interesses: quem construiu o software tentará mostrar que o programa funciona. O teste procura identificar justamente o que não é funcional. Assim, testadores e desenvolvedores podem entrar numa discussão acerca da validade do teste ou da não validade da funcionalidade implementada pelo programador.
  COMO resolver esse tipo de conflito: o gerente de projetos deve mediar essas discussões e deixar claro que a etapa de teste é fundamental para um software de qualidade e com menor custo. O retrabalho pode ter um maior custo para o projeto e identificar erros ou defeitos é bom. Os desenvolvedores precisam compreender isso para que os problemas apontados pelos Testers sejam aceitos e corrigidos. Eventualmente, testadores e programadores podem discutir em conjunto os problemas e entrarem num consenso. A união da equipe é importante para que o teste ocorra com sucesso. Conflitos internos sempre prejudicam o andamento do desenvolvimento de um software.

• Desenvolvedores não testam o software que fizeram. Os desenvolvedores no máximo realizam testes unitários e podem participar de testes de integração (veremos esses tipos de teste a seguir).
  COMO resolver esse tipo de conflito: pode acontecer de o desenvolvedor realizar, por conta própria, alguns testes no software e sugerir a sua implantação sem que um testador realize os seus testes. É uma péssima prática a mesma pessoa que desenvolveu também testar o software. Mas por que isso? Digo isso porque o desenvolvedor já estará “viciado” no código. Ele já passou muito tempo trabalhando naquele código e realizando as entradas de dados que não perceberá problemas. Uma boa prática é envolver um testador na homologação do software ou incremento. Caso não haja um testador de software na empresa, convide um colega programador que não participou do projeto para realizar os testes.

•  Apenas depois que a arquitetura do software está finalizada que um grupo independente de teste pode se envolver.
  COMO resolver esse tipo de conflito: pode ocorrer o envolvimento de grupos de testadores ou uma única pessoa durante a definição da arquitetura do software. Este envolvimento não é sugerido porque um testador com conhecimentos prévios da arquitetura do software pode prejudicar o seu próprio trabalho. Talvez, devido a conhecimentos prévios, ele deixe de executar determinados procedimentos por considerar que já conhece aquela funcionalidade. Os testadores só se envolvem após a arquitetura definida.

 Diversos tipos de testes são realizados para a homologação de um software, estas técnicas podem ser classificadas segundo a origem das informações de acordo com a Figura 2.

Os testes funcionais ou caixa-preta baseiam-se na lista de requisitos funcionais (caso tenha dúvida, você pode ver lição sobre Engenharia de Requisitos) e nos documentos do projeto para verificar se as funcionalidades descritas estão realmente operacionais (PFLEEGER, 2004; PRESSMAN; MAXIM, 2016). Neste tipo de teste, são verificadas as entradas e saídas de dados (ex.: formulários que o usuário entra com dados ou relatórios que são gerados pelo sistema), base de dados (ex.: se os dados estão sendo gravados, adequadamente, na base de dados) e a integridade dos dados (ex.: se os dados gravados na base de dados estão no formato que deveriam estar).

Os testes estruturais ou caixa-branca baseiam-se na lógica interna, testam laços de repetição, condições lógicas e o fluxo dos dados dentro do código. Esse tipo de teste pode, muitas vezes, ser automatizado por ferramentas específicas (apresentarei algumas mais à frente).

Os testes de caixa branca podem ser:

Realizados os testes de unidade, que identificam erros ou falhas em unidades específicas do software, parte-se para o teste de integração. O objetivo desse teste é semelhante ao de unidade, porém os sistemas que foram testados, separadamente, serão testados como se fossem um só (integrados). Esse tipo de teste pode seguir dois caminhos, integração descendente ou ascendente, vamos ver cada um deles:

O teste de validação é dividido em dois tipos, teste alfa e beta:

Outro tipo de teste é o de Sistema, trata-se de uma série de testes cuja finalidade principal é usar por completo o software. Os tipos de teste de sistema mais comumente realizados são os seguintes:

Na sequência, apresento as estratégias para testes de aplicativos móveis. Apesar de os mesmos testes para os demais sistemas serem aplicados, às aplicações móveis exigem algumas abordagens específicas.

Estratégias de teste para aplicativos móveis

Os aplicativos móveis podem ser considerados um novo desafio para a Engenharia de Software, apesar de que a grande maioria dos recursos são aplicáveis a qualquer tipo de software, os aplicativos possuem algumas particularidades, inclusive, para serem testados. Pode-se considerar sete tipos de testes especializados para os aplicativos, vamos conhecê-los:

A seguir, apresento alguns sistemas que podem realizar testes automatizados em sistemas Web ou WebApps.

Algumas ferramentas para sistemas desktops são encontradas dentro dos próprios ambientes de desenvolvimento de software, como é o caso do Visual Studio e do Eclipse ou NetBeans que podem utilizar o JUnit (https://junit.org/junit5/). Mais detalhes sobre o JUnit podem ser encontrados em: https://www.devmedia.com.br/junit-tutorial/1432.

Nesta lição sobre teste de software, tivemos uma base conceitual que podemos utilizar em praticamente todo tipo de projeto de software. Testes sempre existirão e são uma peça fundamental na qualidade de um software. Comentei que, hoje, temos certificações especializadas em teste de software, devido à sua importância e complexidade.

Chamo muito a sua atenção para as fases em que um teste de software deve ser realizado. A sequência correta de ações é importante para o sucesso desse processo. Inicie sempre pelo teste de unidade, siga para o teste de integração destas unidades, passe ao teste de validação e, por fim, o teste de sistema. Tenha em mente que a forma como o teste será feito depende do tipo de processo de desenvolvimento de software (prescritivo/clássico ou ágil) que foi definido pelo gerente de projeto/engenheiro de software. Discutiremos mais à frente que o teste na metodologia ágil é realizado quase que imediatamente, há um envolvimento maior do usuário, enquanto nos processos clássicos há fases claras a serem seguidas.

Antes de mais nada, entenda os métodos de desenvolvimento de software (clássico ou ágil) e siga o caminho recomendado por cada um. A indefinição do método (forma) de desenvolvimento de software implicará erros em todas as fases, inclusive, nos testes, o que resultará em software de baixa qualidade. Espero ter sido uma lição esclarecedora e satisfatória de ler.