Os testes têm como objectivo de encontrar erros e não as suas razões. Portanto, a actividade de teste não inclui nenhuma correcção de bugs ou implementação de funcionalidades. Um tester não deve modificar o código que está a testar, sob circunstância alguma! Isso tem que ser feito pela equipa de desenvolvimento com base nos relatórios de testes que vão sendo executados. Para qualquer tester existe um conjunto de características que se deve ter sempre em atenção, características essas indicadas a seguir.
- Testes revelam a presença de defeitos – O teste pode mostrar que um produto falha, isto é, que existem alguns defeitos, mas não consegue provar que o software não possui defeitos. Um conjunto de testes apropriados reduzem a probabilidade que defeitos escondidos subsistam no software e transitem para o cliente. Mesmo quando nenhuma falha é encontrada durante o processo de testes, isto não é uma prova que não há nenhum defeito.
- Testar exaustivamente é impossível - Um teste exaustivo onde se avaliem todas as possibilidades, todas as entradas e suas combinações de modo a verificar o seu correcto funcionamento seria impossível. Na prática testar a totalidade do software, exigiria um número elevado de situações de teste, para o qual necessitaríamos de muito tempo o que a maioria dos projectos não dispõe. Por este motivo cada plano de testes contém apenas uma amostra das possibilidades existentes. O esforço de testar deve, consequentemente, ser controlado tendo em consideração o risco e as prioridades de cada funcionalidade.
- As actividades de teste devem começar tão cedo quanto possível - As actividades de teste devem começar o mais cedo, quanto possível, no ciclo de vida de software e devem centrar-se sobre os objectivos definidos. Uma abordagem deste tipo contribui em muito para que se possam encontrar defeitos mais cedo no ciclo de vida do desenvolvimento. Estes devem começar logo no momento em que os requisitos estejam estáveis, de modo a identificar problemas na elaboração destes antes ainda de se efectuar o design e implementação dos mesmos. Geralmente quando se encontra um defeito numa aplicação que pode ser rastreado até um requisito, a sua correcção acaba maioritariamente por dar origem a mais problemas.
- Aglomeração de defeitos - Frequentemente, a maioria de defeitos são encontrados apenas em algumas partes do objecto de teste. Os defeitos não são distribuídos uniformemente, assim se vários defeitos são detectados no mesmo local, geralmente existem mais defeitos por perto. Estas situações geralmente acontecem quando existem algoritmos de alguma complexidade a implementar ou em áreas cuja especificação não foi clara o suficiente, ou mesmo desenvolvimentos feitos por pessoas ainda inexperientes.
- O Paradoxo do Pesticida - Quando os mesmos testes são repetidos, vezes sem conta, tendem a reduzir a sua eficácia. Os defeitos previamente não detectados não são descobertos com novas execuções do mesmo teste. Assim, a fim manter a eficácia dos testes e lutar este paradoxo situações novas de teste devem ser desenvolvidas. As partes do software que não foram testadas até aqui, ou as combinações que ainda não tenham sido utilizadas serão executadas então, e um novo conjunto de defeitos pode ser encontrado.
- Os Testes são dependentes do contexto - O teste deve ser adaptado aos riscos inerentes no uso e no ambiente da aplicação. Consequentemente, dois sistemas diferentes não devem ser testados exactamente da mesma maneira. Para cada sistema de software os critérios da saída do teste, o conjunto de testes a efectuar, o tipo de testes a efectuar ou mesmo o tempo a dispensar. Devem ser decididos individualmente, dependendo de seu ambiente de uso. Os sistemas críticos como software de gestão bancária, ou controlo do suporte de vida numa urgência hospitalar exigem diferenças na maturidade dos testes em relação a por exemplo aplicações do comércio electrónico. Geralmente aplicações criticas obrigam a um período de testes muito mais alargado e rigoroso.
- Falácia de não encontrar erros - Encontrar falhas e corrigir defeitos não garante que o sistema desenvolvido vá de encontro ao conjunto de expectativas e necessidades do utilizador. A aplicação pode efectuar o que é pedido mas ser demasiado lenta, possuir uma usabilidade fraca. Aqui a participação adiantada dos utilizadores das aplicações no processo de desenvolvimento e no uso dos protótipos desenvolvidos são medidas preventivas que ajudam a evitar este tipo de problemas. Pelo que geralmente não chega verificar apenas o que é escrito no requisito. Por exemplo ninguém está à espera que uma página web demore cinco minutos a carregar, não faz sentido. Esta situação é claramente um problema, mesmo que não exista explicitamente um requisito que o indique. Aqui os testes aos requisitos criados até poderiam estar todos bem mas existiria claramente um problema de performance.
O facto de se possuir sempre estes princípios em mente (entre muitos outros existentes), irá levar a melhorias na eficácia de uma equipa de testes.
Bom, até à próxima.
