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

 

Anúncios

Agile Testing

Na empresa anterior eu trabalhava como Test Engineer em um ambiente cuja metodologia era AUP (Agile Unified Process). O cliente trabalhava com RUP enquanto dentro da empresa essa realidade era adaptada a um ambiente de desenvolvimento Ágil.

Vou registrar brevemente como foi a experiência.

Bom… no nosso caso, era definido um Backlog do produto com todas as tarefas a serem executas e as prioridades.

A iteração era de duas semanas (os ciclos não devem ser muito longos). Então no início de cada uma tínhamos a reunião de Sprint para definir o que entraria na iteração atual, ou seja, o que vai ser entregue ao final de duas semanas.

No nosso caso, definimos um conjunto de casos de uso e deixamos uma margem de tempo para os testes e bug fixing dentro ainda da iteração. O tempo de desenvolvimento incluía também o tempo gasto com testes unitários pelos desenvolvedores.

Quando inicia a iteração, os desenvolvedores começam a implementar os Casos de Uso. Enquanto isso a equipe de teste especifica os Test Cases para os mesmos. A margem para teste serve para os testes de componente que atualmente são executados usando os Test Cases Especificados (na mesma iteração) através de inspeção visual – não automatizamos nada ainda. A idéia futura é justamente automatizar pelo menos a parte de validação de campos para que os testes de regressão não sejam tão maçantes.

Assim que um Caso de Uso terminou de ser implementado, os desenvolvedores constroem os testes unitários enquanto a equipe de teste obtém a versão do sistema mais atualizada e já testa para reportar os bugs o mais rápido possível.

Além disso, esqueci de comentar, que enquanto a equipe de desenvolvimento está definindo no primeiro dia da iteração as estimativas (consequentemente o que vai ser desenvolvido na iteração), é feito o teste de componente “official” do que foi entregue na iteração passada juntamente com os bugs e melhorias a serem planejados para uma próxima iteração.

Temos também as “Daily meeting”, reuniões diárias que servem para expor o que foi feito no dia anterior, o que vai ser feito hoje e os problemas encontrados. Todas estas reuniões são breves, de no máximo 15 minutos, extrapolando para 30 minutos. Isto tudo para não perdermos tempo nem o foco no que precisa ser entregue.

Dentro de um contexto, a equipe local fazia os testes até o nível de componente, no cliente eram feitos os testes em outros níveis para assim lançar uma release do produto. Quando os testes chegam lá, eles usam RUP. Atualmente, não sei como isto ficou definido naquela empresa, então posso apenas afirmar que os testes de componentes não estão mais sendo feitos pela equipe brasileira.

Na realidade, cada empresa tem que se adequar àquilo que vai dar mais ganho de produtividade à equipe e um resultado com melhor qualidade. Cada projeto tem suas particularidades, então resta saber como “rebolar” para usar as melhores práticas de cada metodologia.

É como ir à feira e comprar somente o essencial!
Feira