Nos últimos anos, o termo “teste shift-left” (teste de mudança à esquerda) entrou no vernáculo de engenharia de software. Resumindo isso significa realizar mais testes de software durante a fase de desenvolvimento de software.

O teste de mudança à esquerda é frequentemente usado para descrever um maior envolvimento de engenheiros de garantia da qualidade (QA) durante a fase de desenvolvimento, em um esforço para detectar defeitos o mais cedo possível, antes que os engenheiros de software entreguem o software à equipe de QA para testes mais completos. Na maioria das vezes, isso significa desenvolver e executar mais testes automatizados da interface do usuário e das APIs.

No entanto, existem algumas etapas básicas e essenciais do teste de software que todo desenvolvedor de software deve executar antes de mostrar o trabalho a outra pessoa, seja para testes formais, testes ad hoc, mesclagem e integração de códigos ou apenas chamar um colega para dar uma olhada rápida. O objetivo deste teste básico é detectar os erros óbvios que aparecem imediatamente. Caso contrário, você entra em um ciclo caro e desnecessário de descrever o problema para o desenvolvedor, que deve reproduzi-lo, depurá-lo e resolvê-lo antes de tentar novamente.

Aqui estão as etapas essenciais de teste de software que todo engenheiro de software deve executar antes de mostrar seu trabalho a outra pessoa.

1. Teste de funcionalidade básica

Comece certificando-se de que todos os botões em todas as telas funcionem. Você também precisa garantir que você possa inserir texto simples em cada campo sem travar o software. Você não precisa experimentar todas as diferentes combinações de cliques e caracteres, ou condições de limites, porque é isso que seus testadores fazem – e eles são realmente bons nisso. 

O objetivo aqui é o seguinte: não deixe que outras pessoas toquem no seu trabalho se ele falhar assim que inserirem seu próprio nome no campo de nome de usuário. Se o recurso for projetado para ser acessado por meio de uma API, você precisará executar testes para garantir que a funcionalidade básica da API funcione antes de enviá-lo para testes mais intensivos. 

Se o seu teste básico de funcionalidade detectar algo que não funciona, tudo bem. Apenas diga a eles que não funciona, que você está ciente disso, e que eles não deveriam se incomodar em tentar. Você pode corrigi-lo mais tarde, apenas não deixe nenhuma surpresa lá.

2. Revisão de código

Outra pessoa olhando para o código-fonte pode descobrir muitos problemas. Se sua metodologia de codificação exigir revisão por pares, execute esta etapa antes de entregar o código para teste. Lembre-se de fazer seu teste básico de funcionalidade antes da revisão do código.

3. Análise de código estático

Existem ferramentas que podem executar análises no código fonte ou no bytecode sem executá-lo. Essas ferramentas de análise de código estático podem procurar muitos pontos fracos no código-fonte, como vulnerabilidades de segurança e possíveis problemas de concorrência. 

Use ferramentas de análise de código estático para impor padrões de codificação e configure essas ferramentas para serem executadas automaticamente como parte do processo de compilação.

4. Teste de unidade

Os desenvolvedores escreverão testes de unidade para garantir que a unidade (seja um método, classe ou componente) esteja funcionando conforme o esperado e testará uma variedade de entradas válidas e inválidas. 

Em um ambiente de integração contínua, os testes de unidade devem ser executados toda vez que você confirma uma alteração no repositório de código-fonte e também na máquina de desenvolvimento. Algumas equipes têm metas de cobertura para seus testes de unidade e falharão na construção se os testes de unidade não forem suficientemente extensos.

Os desenvolvedores também trabalham com objetos simulados e serviços virtualizados para garantir que suas unidades possam ser testadas independentemente. Se seus testes de unidade falharem, corrija-os antes de permitir que outra pessoa use seu código. 

Se, por algum motivo, você não puder corrigi-los agora, informe a outra pessoa sobre o que falhou, para que não seja uma surpresa quando se deparar com o problema.

5. Teste de desempenho de usuário único

Algumas equipes têm testes de carga e desempenho integrados em seu processo de integração contínua e executam testes de carga assim que o código é verificado. Isso é particularmente verdadeiro no código de back-end. Mas os desenvolvedores também devem olhar para o desempenho de usuário único no front-end e garantir que o software seja responsivo quando apenas eles estiverem usando o sistema.

Se estiver demorando mais do que alguns segundos para exibir uma página da Web tirada de um servidor da Web local ou emulado (e, portanto, responsivo), descubra qual código do lado do cliente está atrasando as coisas e corrija-o antes que você permita que outra pessoa o veja.

Encontrar o equilíbrio certo
Reserve um tempo para executar o maior número possível desses testes antes de entregar seu código a qualquer outra pessoa, pois deixar erros óbvios no código é uma perda de tempo e do tempo dos colegas. 

Obviamente, você precisará encontrar o equilíbrio entre escrever código e testar que combina com você. “Aqui está o mix que funcionou para mim”, disse Igor Markov, gerente de P&D do LoadRunner da HP Software. “40% do meu tempo é gasto projetando e escrevendo código; 5% são gastos em revisão e análise estática de códigos; 25% em testes de unidade e testes de integração; e 30% em testes básicos de funcionalidade e testes de desempenho de usuários únicos”.

Deixar erros óbvios no código também não fará bem à sua reputação. “Um desenvolvedor que não encontrar os defeitos óbvios nunca vai brilhar”, continuou Markov. “Os desenvolvedores precisam produzir software funcional que seja fácil de usar. Ninguém quer desenvolvedores que apenas fazem codificação pura. O que me ajudou a desenvolver minha carreira foi o fato de eu sempre investir mais tempo projetando, revisando e testando meu código do que realmente escrevendo.” 

A produção de software funcional fácil de usar requer exatamente esse tipo de equilíbrio. Como você equilibra seu tempo entre projetar, revisar e testar código?

Este texto é uma adaptação livre do artigo publicado por Malcolm Isaacs em https://techbeacon.com/app-dev-testing/5-key-software-testing-steps-every-engineer-should-perform

Se você precisa implantar um processo de testes completos e eficiente nós podemos te ajudar. Clique aqui.