Quem deve testar a aplicação?

Assuntos Gerais
#1

Galera, este é um assunto um pouco quanto recorrente e de opiniões díspares.

Quem é que deve testar a aplicação???

Como desenvolvedores com muitas tarefas agregadas, sempre temos que estar atentos a TODOS os detalhes da aplicação. Desde a especificação, passando pelo desenvolvimento, deploy, até os testes finais.

Acontece que muitas vezes estamos condicionados ao funcionamento de uma específica tarefa do sistema, então tendemos a testar esta funcionalidade de forma mais centrada no que desenvolvemos, já que conhecemos os detalhes da implementação do código. O que acaba passando algumas situações ímpares, não previstas, como por exemplo, ações do usuário, que sempre faz coisas inimagináveis.

E nem sempre dispomos de tanto tempo (ou paciência) para ficarmos testando o sistema, de modo a evitar surpresas para o cliente ou usuário.

Aí é que vem a questão. Quem deveria testar a aplicação?

Na minha consultoria, contrataram uma “tester”, uma pessoas que apenas testa os sistemas e dá o aval para a liberação para o cliente, afim de evitar surpresas.

Como estou num cliente, me surgiu esta procupação após alguns erros bobos aparecerem, como validação de um campo ou layer que deveria sumir da tela no click do mouse, e o responsável do projeto me pediu mais atenção nos meus testes, pois ele confiava no meu trabalho e só queria repassar o programa para implantação, se isentando dos testes finais.

E aí, vocês têm algo a dizer?

#2

Olá Galera,

Eu trabalho especificamente com teste de software.

Acredito (e já foi provado!) que quem desenvolve não deve testar…pois, como o daniel disse, a pessoa que desenvolve está condicionada a testar determinadas funcionalidades que ele desenvolveu e não consegue ver erros bobos que a aplicação apresenta…

O correto é ter uma equipe de testes que está ali para isso…! Testar todas as funcionalidades do programa e se atentar a pequenos detalhes que faz com que o cliente faça cara feia caso esteja errado!

Uma alternativa “mais barata e viável” é que outro desenvolvedor faça o teste…no entanto, não aprovo isso…já que temos dois perfis diferentes: a pessoa que xecuta um teste e a pessoa que desenvolve…nunca um desenvolvedor fará os testes como uma pessoa que tem perfil para isso…

O mercado de testes está crescendo pelos problemas que o Daniel citou…está comprovado que a Qualidade aumenta demais quando existe pessoas independentes testando os programas…o cliente fica mais feliz, pois os erros bobos não passam…! :slight_smile: :wink:

ate mais…

#3

É uma coisa psicológica - quem faz alguma coisa tenta mexer nela de forma que ela funcione, mesmo que seja inconscientemente.

Algumas leis da informática:

1 - Quem escreve código (ou especificação) não deve testar seu próprio código (ou validar a sua própria especificação).

2 - Quem faz código deveria corrigir seu próprio código (falando em palavras mais chulas: “quem fez, limpa”)

O problema é que nem sempre é possível aplicar a lei 2 - às vezes porque quem escreveu não consegue corrigir, pela falta de expertise ou por algum outro problema qualquer (por exemplo, por aquele problema de “cegueira” que ocorre quando a gente fica muito tempo em cima de um problema). A lei 2 pode ser modificada para:

2a - Quem faz código deve receber a correção e ser obrigado a entender a correção de seu código (falando em palavras mais chulas: “esfregar o focinho do seu cachorro na… que ele fez”)

É que muitas vezes (principalmente em fábricas de software) o que se vê é que tem algum fulano que faz as correções, mas elas não retornam ao autor original do código. Portanto o que acaba acontecendo é que o autor do código fica repetindo sempre o mesmo erro, até morrer (ou ser promovido a gerente da fábrica… :wink:

#4

Até onde eu sei, quando encontra-se um erro, quem corrige é o dono do código…onde eu trabalho, JAMAIS o codigo de um vai para outro corrigir… :slight_smile:

ate mais…

#5

Hmmm, não é bem assim. Desenvolvedor não só pode como deve testar aquilo que produz. Mas ele não pode testar sozinho e também não deve fazer os testes funcionais (e aí é onde entram os testadores profissionais).
O desenvolvedor deve testar o tempo todo o código que escreveu e assegurar que seu código tem a menor quantidade de bugs possível antes dele ser usado. Tem que garantir também que o seu código não vai influenciar negativamente o código produzido por outros desenvolvedores. Tem que, obviamente, garantir que o seu código faz tudo aquilo a que ele se propõe fazer.
Mas, como fazer isso? Usando TDD e integração contínua (claro, quando isso for possível). Elas não são milagrosas, mas quebram altos galhos e ajudam a dar uma maior segurança para usar o código que você está desenvolvendo (uma vez que os testes de unidade feitos sobre cada função desenvolvida lhe asseguraram que seu código funciona). Além disso, diminui a chance de se encontrar bugs “poltergeist” na hora de integrar tudo e botar o treco para funcionar :slight_smile:

#6

Concordo com o Quirino, quem faz tem q testar, mas isso ñ deve se a unica coisa apra se validar um fonte, afinal de contas td mundo q cria se condiciona com as nuances de formatos dos campos, obrigatoriedades e coisas do tipo.
Mas na IMHO, os testes deveriam ser feitos em conjunto c o cliente/usuario do sistemae o desenvolvedor.

#7

Olá

Não vou falar de testes unitários e TDD porque entendo que estamos falando de testes funcionais.

Ter alguém ou uma equipe de testes (QA) é muito bom. Acho melhor ainda quando o QA participa das mesmas reuniões de análise porque assim ele entende exatamente o que precisará ser testado e prepara sua bateria de testes antes mesmo do código atingir o status de entregável.

Acho bom também que haja uma boa integração entre o QA e o criador da GUI porque uma das funções do QA é estressar a GUI.

Em um projeto grande que participei, o QA acumulava também as funções de configuration manager. Este nome bonito era dado ao cara responsável pelo CVS e também pelo deployment.

[]s
Luca

#8

Concordo com o que foi dito!

O desenvolvedor deve claro testar o que ele fez!

Só não pode ficar o teste apenas para o desenvolvedor…deve haver outra pessoa para testar…dai entra o meu cargo… :smiley: :slight_smile:

ate mais…

#9

O teste deve ser contínuo, e não deixar para uma semana antes de entregar o produto. IMHO, o que deveria ter, é uma pequena equipe, de 2 a 3 pessoas, que examinariam as funcionalidades das telas, o design, a forma de iteração entre as telas, o padrão, entre outras coisas de IHC. Seguindo um conjunto de heurísticas ou simplesmente por percuso cognitivo (se eu clicar eu vou pra onde? Aaaaa legal!).

E em períodos regulares, deveriam ser chamados clientes reais do programa, e mandassem ele dizer tudo que acham de bom, e de ruim. (Eu acho aqui, caso eu não preencha esse campo, deveria aparecer uma janela dizendo que eu sou obrigado e preenche-lo, e não um texto em vermelho.)

Agora o que tem muito, como alguém já falou, é pedir para programadores testarem essas coisas. Uma empresa de vergonha, tem sua equipe de testes. Até porque, não é só pq fazemos programas, que temos que saber testa-lo. Não é bem por ae.

Se eu fugi um pouco do assunto do principal, foi mal.

Mais fica ae minha dica: Tem que haver uma equipe de IHC, que devem ter um método próprio de testes, ou utilizar de alguns conhecidos, como Percurso Cognitino, Uso de Heurísticas, Guidelines, … E os desenvolvedores, tem que entender o seu papel (pq eles podem dizer assim: Eu, isso não ta legal dessa maneira. Assim fica melhor!)

#10