A etapa de testes no processo de desenvolvimento de software ainda é vista com olhos ruins por muita gente. Na verdade, isso existe pelo conflito de interesses: os desenvolvedores de um lado, querendo mostrar que o seu programa é isento de falhas, e a equipe de QA do outro, buscando a qualquer custo encontrar falhas no sistema.
Mesmo que de certa forma tenhamos que trabalhar esses conflitos, é importante ter outra equipe que teste o que foi desenvolvido. Como já disseram por aí, “não existe filho feio para a mãe”, e o programador tem um tendência natural a achar que tudo que desenvolveu está perfeito.
Contudo trabalhar com somente com uma equipe pode não resolver todos os problemas. Ainda que essa seja boa o suficiente para cumprir o seu papel, o usuário é o verdadeiro tester, já que é quem usará o programa no dia-a-dia. Com a ideia do usuário como tester surgem dois conceitos, chamados de Teste Alfa e Teste Beta.
O Teste Alfa é aquele realizado no ambiente do desenvolvedor, mas pelo usuário final do programa. Já o Teste Beta é realizado no ambiente do cliente, sem a presença do desenvolvedor, aonde o próprio cliente relata quais são erros observados que serão posteriormente corrigidos.
Os testes de software podem ainda ser classificados quanto a técnica utilizada. Dentre eles os principais são:
- Teste Caixa Branca: São os testes estruturais, baseando-se na estrutura e procedimentos utilizados no programa, analisando os laços, condições de if/else. Através do código (ou algoritmo) são analisados casos a busca de erros.
- Teste Caixa Preta: O teste caixa preta baseia na especificação de interface do programa, observando-se entradas e saídas, ou seja, se a saída produzida realmente condiz com a saída esperada, em relação ao que foi inserido como dado de entrada.
Existe ainda a Técnica Baseada em Erros, que se baseiam na inclusão de erros propositais (artificiais) como forma de revelar erros existentes previamente (naturais).
Por fim, lembre-se: bons testes de software são aqueles que apresentam maior probabilidade de revelar erros ainda não descobertos!
2 Comentários
Agora imagine quando o infeliz quer que você trabalhe com ele, mas não te fala nem a API (spec pra in/out ne?) da caixa preta. E fala com todas as letras, que não vai nem poder te dar. Daí entra naquela velha questão: “como você quer que eu te ajude? se você não deixa (sabota)?”.
Quem não reconhece o valor de testes, só está perdendo em questão de qualidade de software. E eu já trabalhei uma vez em uma empresa que os desenvolvedores gostou que eu entrei na empresa como analista de testes, pq os problema do software caiam direto para eles, pq muita vezes o suporte não conseguia ajudar os clientes e quem tinha que fazer isso eram eles. Se outros desenvolvedores passassem por isso talvez dariam mais valor a qualidade de software.
Quem tiver precisando de qualidade para seu software @thi_ms 😛
Essa história que programador não gosta de tester é lenda pra mim também…. Eu sou programador e não tenho nada contra eles, pelo contrário: um tester é um profissional que saber relatar falhas melhor que um cliente que é leigo e relata do jeito dele e nem imagina o quanto é importante que eu possa ver o problema acontecendo pra que eu possa corrigir. Afinal, como eu vou saber que as alterações que eu fiz no código estão certas se eu não puder reproduzir os passos que levam ao problema?