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
Barbara Cabral's Blog 
Olá Bárbara,
Muito bom o post. Ainda coloco o seguinte, quanto a maturidade com relação a testes em empresas menores isso é um fator importante, mas que poucas empresas possuem este nível de maturidade, até pela própria visão dos gestores, que estão muito mais preocupados com indicadores financeiros/comerciais do que propriamente com a qualidade do produto. Até acredito que eles pensam em qualidade, mas não é primeiro passo, e isso se espalha para os desenvolvedores que estão mais preocupados com as entregas e não tanto novamente com a qualidade, aliado ao alto nível de estresse que sofrem com estas entregas apertadas muitas vezes.
Os testes em empresas pequenas é um desafio ainda maior por tudo que você colocou no post, além disso uma maneira para isso disseminar a importância dos testes poderá ser através de treinamentos para a equipe de desenvolvedores, comunicação como envio de artigos, notícias sobre indicadores de melhoria do produto e importância dos testes.
Outra coisa encontrar todas as falhas na aplicação é um tanto ilusório, até porque o nível alto de qualidade irá requerer um nível alto de investimento e se tratando de empresas menores isso é pouco provável.
O nível de qualidade melhora quando os testes são feitos desde o ínicio do projeto e percorra todo ciclo de desenvolvimento, em uma empresa seja qual tamanho for, precisa ter a cultura do analista de negócio se aproximar muito da qualidade, caso isso não ocorra, a qualidade irá sofrer com isso. E o analista de negócio deve entender muito bem isso e deve também explicitar as regras de negócio através de ferramentas apropriadas como um exemplo BPM.
Mas era isso, gostei muito do seu post, parabéns.
Charles
CurtirCurtir