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

 

Teste de Performance com JMeter 1

Já realizei alguns testes de stress e performance com o JMeter e resolvi agora documentar a ‘brincadeira’.
Pensei em criar um passo-a-passo, mas quando iniciei os estudos, percebi que já existem várias pessoas que documentaram como Instalar e Configurar…
Encontrei um artigo que mostra certinho como fazer isso: Tecnociência – Tutorial de instalação e configuração do JMETER

Minha idéia agora é então apresentar algumas funcionalidades mais avançadas do JMeter e como realizar algumas coisas das quais ‘apanhei’ e também algumas dúvidas.

Bom… vamos às dúvidas em primeiro lugar…

Depois de gravar o script utilizando o componente de Proxy, precisamos ‘limpar’ o script de todo o ‘lixo’ que o JMeter gera ao gravar os requests/responses do usuário.
Pesquisei para saber o que eu devia ‘deletar’… não achei muita documentação. Então fui um pouco pela ‘lógica’ daquilo que eu precisava fazer.

Pesquisei sobre o JMeter carregar os javascript da página e eu vi que não tem necessidade desde que não exista nenhum .js que faça uma chamada a uma página.
Então os .js podem ser excluídos do script se a navegação estiver funcionando, mesmo porque ele executa no lado cliente e não no servidor.

O JMeter também grava o download das imagens… ficamos em meio à discussão se elas deviam ser deletadas ou não.
Acredito que é importante acessar a funcionalidade do sistema que tenha mais carregamento de imagens e vale a pena dar uma olhada em como o sistema se comporta.
Mas, dependendo do foco do Teste de Performance, se ele tiver como objetivo procurar falhas de performance no código em si… não vejo porquê mantermos nos scripts todos os downloads das imagens.

Também é altamente recomendável que sejam deletados requests desnecessários, por isso ao gravar o script usando o Proxy, é essencial prestar atenção nos requests importantes para que a aplicação funcione. Eu particularmente fui acompanhando com o JMeter a cada requisição e colocando nos comentários que tipo de chamada era aquela, assim pude excluir chamadas redundantes, quando há.

Testes de alta criticidade em Metodologias Ágeis

Eu resposta ao post do Luiz Gustavo S. Vieira (http://testavo.blogspot.com/)

Eu estava lá com o Luiz Gustavo, no CInTeQ 2011, quando o Bernard Homès fez este comentário um tanto quando ‘bombástico’… olhei perplexa e segui o reciocíonio dele. Concordo que, em partes muito se fala sobre metodologia ágil como ausência de documentação forma. Mas com certeza não ausência de informação para testes.

Trabalhei em uma empresa que utilizava como metodologia a AUP: Agile Unified Process, que é uma versão simplificada do RUP para uma forma de desenvolvimento mais ágil.

E o processo era constituído de um backlog que incluíam as tarefas de teste inclusive. Cada funcionalidade da Sprint a ser entregue era coberto por testes manuais detalhadamente especificados e com cobertura de 98% dos fluxos especificados. Todos os métodos entregues naquela Sprint também eram cobertos por testes automatizados. A cobertura era avaliada por uma ferramenta de análise estática do código que nos mostrava os fluxos dos métodos que não haviam sido cobertos com testes.

Além disso também existiam os testes automatizados de integração e de sistema que faziam parte de outro Backlog, senão o da entrega dos componentes.

Então na minha opinião o que importa na realidade não é se a metodologia é Ágil ou não. O que importa é se são planejadas na Sprint e aplicadas técnicas de teste compatíveis com o nível de criticidade do sistema.

O Luiz Gustavo comentou sobre Pairwise Testing, porque esta técnica não poderia ser planejada no Backlog e aplicada da Sprint?

Talvez neste caso, não se tornaria necessário outro Backlog?

– Um backlog de testes e controle da qualidade das entregas
– Outro backlog para aplicação das técnicas necessárias para garantir a qualidade da entrega do ‘produto’.

Será que isto tornaria o processo menos ágil?

Essa é uma questão que eu gostaria que fosse respondida pelo pessoal que defende as metodologias ágeis… Ter uma visão de como eles organizariam as atividades de teste nessa situação.