Testes de software em Pequenas Empresas

Quando entrei para a área de testes de software, saída de um ambiente de programação, eu comecei com testes unitários em uma empresa cujo cliente era da Bélgica. Então realizei também testes de componentes, mas sempre trabalhando com a equipe de desenvolvimento em um ambiente ágil.

Foi aí que eu conheci Scrum e entendi conceitos de Backlog, Sprint, etc…

Era um ambiente maduro onde todos estavam sempre preocupados com a qualidade da entrega. O ambiente era de integração contínua onde os builds da aplicação deveriam sempre estar  funcionando. Ou seja, a qualquer momento que eu subisse a aplicação ela estaria funcionando para realizar os testes de interface e qualquer outro teste. Além disso, todos os testes unitários, de componente e de integração deveriam estar “passando” também.

Mas este era um ambiente atípico do ambiente que tenho trabalhado nos últimos 3 anos, costumo trabalhar em empresas pequenas porque há mais “liberdade” (entre aspas mesmo) para realizar os testes no sistema. Eu faço esta observação porque não existe uma consciência da importância dos testes de software. Geralmente as equipes são imaturas e não compreendem que testar é exercitar o software e não apontar os defeitos da equipe de desenvolvimento e muito menos os erros de cada desenvolvedor individualmente.

O foco de um testador é, e sempre deve ser, atacar o software. Ainda mais, desvendar sua complexidade, colocá-lo à prova e realizar  a melhor cobertura de testes possível em cada entrega.

O problema maior é que quando um testador adentra uma empresa pequena ele também leva junto muitos desafios… o primeiro deles é ser incompreendido pelos demais membros da equipe. Para tal é necessário que ao menos o Gerente ou o Líder Técnico conheça um pouquinho sobre testes de software para que haja uma conversa sensata. Se isto não for possível… é necessário um esforço maior em disseminar o conhecimento acerca da área de teste de software, identificar quais os maiores riscos da aplicação e promover um estratégia para aplicação dos testes.

É necessário que todos estejam cientes de como serão realizados os testes e qual seu critério de saída… ou seja, irei parar de realizar os testes assim que: todos os Test Cases planejados sejam executados + os itens do checklist estejam verificados + os testes exploratórios (talvez limitado por tempo) sejam executados.

Outro desafio é deixar transparente a todos em qual nível o teste de software esta sendo aplicado. Exemplo: serão feitos testes de aceitação? Serão realizados testes de sistema? Será realizados testes de componente e de integração pela equipe de testes? A usabilidade também será avaliada? É um erro achar que o teste de software irá encontrar todos as falhas na aplicação, principalmente porque apesar de naturalmente os testadores terem um conhecimento maior sobre as regras de negócio, mas o domínio é geralmente do Product Owner(no caso das metodologias ágeis) ou do Analista de Negócio se extendendo ao cliente.

O importante é que se a empresa não tem um papel central de uma pessoa que tenha domínio do negócio para passar as informações mais importantes ao testador, então o testador deveria participar das reuniões com o cliente para poder verificar o que é realmente importante para ele e o que não é. Já vi clientes dizerem que o mais importante para eles era que as informações da tela estejam auto-explicativas porque estava sendo gasto muitos recursos em suporte técnico… e quanto mais a aplicação tivesse usabilidade e menos complexidade de informações na tela, isto evitaria um gasto muito maior.

Há aplicações que o fator crucial é a parte financeira… para um sistema de cartões de crédito onde de cada transação é aplicado um conjunto de taxas a ser debitada do estabelecimento credenciado, ou onde as vendas com juros é debitada do portador, o mais importante é que os cálculos estejam absolutamente corretos e prestar atenção também em arredondamento de valores, na precisão de cada operação dentro do sistema. Imagine que eu vá em um supermecado e compre apenas um chocolate de R$ 1,50, mesmo assim todas as taxas devem ser cobradas de maneira correta.

Então é realmente complicado definir quais os testes devem ser realizados para cada tipo de aplicação quando não se sabe ao certo quais são os itens de maior risco e importância para o cliente e, principalmente, quando não há ninguém na empresa que constrói o software para responder este tipo de pergunta. Na minha opinião, neste caso a empresa deveria abrir o relacionamento da área de testes junto às reuniões com o cliente.

Mas… nem sempre é assim. #fato

 

Estratégias de Testes

Existem várias estratégias que podemos adotar para implantar testes de software em projetos. As estratégias de teste servem para nos guiar a um objetivo em comum: eliminar o máximo possível de bugs e desvios de implementação. Basicamente, entregar ao cliente exatamente o que ele requisitou e funcionando.

Para tal podemos adotar alguns tipos de abordagem:

  • Preventiva ou Reativa (em relação ao tempo em que os testes iniciam) e;
  • Analítica ou Heurística (em relação às fontes de informação disponíveis).

Preventiva VS. Reativa

Abordagem Preventiva
Equipe de Testes é envolvida desde o início: planejando as atividades de teste e especificando as atividades de teste são cedo quando possível. Isto pode ocasionar a otimização das atividades de teste e consequente redução de custo, já que os bugs de expecificação e projeto serão encontrados cedo, gerando menos retrabalho. Aplicação de revisão e análise estática antes do desenvolvimento pode contribuir para prevenir defeitos em tempo de execução de testes. Desta forma, pode-se reduzir os custos com execução de testes e retrabalho.

Abordagem Reativa
São atividades nas quais a equipe de testes é envolvida muito tardiamente e a abordagem preventiva não pôde ser escolhida. Nesta situação a análise e projeto do sistema já foi concluído, de tal forma que a equipe de testes precisará ‘explorar’ as funcionalidades a ser entregues. Testes exploratórios são baseados na experiência dos testadores e têm como objetivo executar diversas possibilidades de execução e de avaliação.

Analítica VS. Heurística

Abordagem Analítica

O planejamento dos testes é baseado em dados ou na análise destes dados. O critério de saída (critério que mapeia quando os testes devem parar) é quantificado e sua correlação será modelada. Ex: os testes serão finalizados quando atingirem 90% de cobertura.

A quantidade e a intensidade dos testes serão escolhidos de acordo com múltiplos parâmetros individuais (custo, tempo, cobertura, etc).

Abordagem Heurística

O planejamento de testes é baseado na experiência dos experts em testes (de dentro ou de fora do projeto) e/ou nas regras repassadas pelos papéis-chave do projeto. O motivo é porque os dados não estão disponíveis, a modelagem de dados para testes é muito complicada, ou porque é necessário conhecimento do negócio.

Abordagem Analítica e Heurística na prática

Na prática, a abordagem utilizada é um meio-termo entre os extremos e utiliza diferentes graus de elementos analíticos e estáticos:

Testes “model-based”

Utiliza modelos funcionais abstratos do software sob testes para o projeto de Test Cases para encontrar o “test exit criteria” (critério de encerramento dos testes), e para medir a cobertura dos testes (que ocorre contra o modelo).

Testes estatísticos ou “stochastic (model-based)”

Utiliza modelos estatísticos sobre a distribuição de falhas no objeto sujeito a testes, taxa de defeitos durante o uso do software ou distribuição estatística de casos de uso (bem como perfis operacionais); baseando-se nesta distribuição o esforço de testes é alocado.

Testes baseados em Risco

Utiliza informações do risco do projeto e do produto, e direciona o teste para áreas de maior risco.  Os riscos do projeto são tratados frente à capacidade de entrega do produto. Segundo os padrões I3E para Quality Assurance, gerenciamento de risco comprende:

  • Avaliação do que pode dar errado (avaliação de riscos)
  • Priorização dos riscos identificados
  • Implementação de ações para mitigar ou eliminar estes riscos (Ex. partes críticas do software devem ser testadas mais criteriosamente)
Testes orientados a padrões ou processos

Utiliza regras, recomendações e padrões (como o modelo-V) como cookbock.

Testes orientados a Reuso

Testes em ambientes de reutilização de testes existentes e materiais. O objetivo é configurar os testes mais facilmente para o máximo reuso.

Testes baseados em checklists (ou metódicos)

Utiliza listas de falhas e defeitos desde cedo nos ciclos de teste, listas de defeitos em potencial ou riscos, ou prioriza o critério de qualidade e outros métodos menos formais.

Testes baseados em experiência

Utiliza a experiência do profissional e o feeling dos especialistas envolvidos (para a tecnologia utilizada e o domínio da aplicação)