Por muitas vezes refleti se as pessoas, que trabalham com testes de software, devem ter habilidades de desenvolvimento. Não nego que possuir conhecimento do negócio é necessário para o profissional da área de testes. Mas, entender sobre a estrutura do que é testado, que antes de tudo é um software, também é importante.
James Whittaker, que já trabalhou com testes na Microsoft e atualmente trabalha na Google, escreveu um livro que demonstra algumas técnicas para se “quebrar” um software. As falhas exibidas são bem interessantes, e possíveis de serem atingidas em abordagem caixa-preta.
Como testador, pude experimentar algumas técnicas mencionadas no livro. Vou relatar sobre a aplicação de uma dessas técnicas em um projeto que trabalhei. No software desenvolvido, um usuário poderia criar menus que seriam acessados através de um servidor. Quando acessado um determinado item do menu, uma ação seria acionada. Uma das ações disponíveis era verificar o usuário que estava acessando o item e direcionar para outra ação.
Na imagem acima, quando um usuário A acessa o ITEM 2 do MENU, a ação 2 é chamada. Uma vez que a AÇÃO 2 identifica que é o usuário A, a AÇÃO 3 é acionada. Olhando para este exemplo, tendo em vista que uma ação de decisão envolve processamento, já é possível reproduzir a falha. A idéia é forçar um processo a ser executado várias vezes. Imagine uma ação parecida com a AÇÃO 2 no lugar da AÇÃO 3, apontando para AÇÃO 2 quando o usuário for A.
Agora, imagine o usuário A acessando o MENU pelo servidor. Ele tenta acessar uma vez o ITEM 2, vai para a AÇÃO 2, que o direciona para AÇÃO 3. A AÇÃO 3 o manda de volta para AÇÃO 2, que o manda mais uma vez para AÇÃO 3. Vai para AÇÃO 2… Deu pra entender que nunca vai parar? Bastaram algumas requisições feitas com o usuário A para ser necessário reiniciar o servidor, pois o serviço havia ficado indisponível.
No livro “How to Break Software”, James Whittaker demonstra falhas que podem ser provocadas tanto pela interface com o usuário como através de outro software. Ele ainda fala que muitos têm dificuldade em entender o ambiente em que o software funciona. Na experiência que tive com testes de software até o momento, me deparei com vários testadores que somente interagiam com a porção de botões, ou outros componentes visuais, que lhe eram oferecidos através de especificações. Tais testadores desconsideravam sistema de arquivos, componentes externos, sistema operacional, rede, relacionamento com outras funcionalidades, etc.
Com esse post, pretendo incentivar uma briga.
Testadores, aprendam onde os desenvolvedores deixam os bugs. Acreditem, boa parte das falhas de um software estão no código! Estudem formas diferentes de se encontrar os problemas. Entenda o sistema operacional, analise o código fonte do software, entenda de redes, estude as falhas dos frameworks utilizados, avaliem a segurança do produto (não usem a desculpa de que segurança é um requisito não-funcional), estudem tudo o que for válido para certificar a qualidade do software.
Desenvolvedores, vocês vão deixar? Vejam o que esses testadores poderão fazer com o código produzido por vocês! Se aproximem do pensamento dos testadores, vejam como eles agem. Desenvolvam o senso crítico. Dêem seu máximo para que falhas comuns não aconteçam. Estudem onde os bugs aparecem para poder evitá-los!
No final, essa disputa saudável, entre evitar e encontrar os bugs, é uma forma de se obter um software de qualidade e uma equipe em evolução contínua.
Bytes don't Bite! 
Muito Bom Edwin esse incentivo ao conhecimento.. E quanto a turma de desenvolvimento.. Lembrar sempre de usar as técnicas preventivas como diria Borba!! **TDD** . Quando você testa antes de desenvolver já prevê algumas falhas evitando o erro!!
Abraço Jovem !!
PS:Eu conheço esse exemplo de algum lugar??!? kkkkkk
Afinal de contas, TODOS devem trabalhar juntos para uma maior qualidade do Software!
Muito bom o post.
Parabéns, Edwin!
Conhecer a estrutura do sistema, sua arquitetura, seus pontos de conexão são um ótimo indicador de possíveis pontos de falha. Testar sob um ponto de vista mais amplo é essencial para a boa qualidade de um software.
Ótimo post!
Meu Caro Edwin, gostei do post! 🙂
… entretanto tenho alguns questionamentos (que talvez até saiam do contexto do seu post), mas estão na minha cabeça no momento …
1) Será que uma só pessoa conseguiria ter a visão de testador e de desenvolvedor em um mesmo poduto? e mais ainda, em uma mesma funcionalidade?
2) O que vocês acham de antes de testar funcionalmente, o testador fosse no código tentar gerar testes automáticos ( seria meio que um TDD reverso, num contexto onde não existe TDD). Concordo que o cenário ideal seria termos TDD, mas essa não é a prática comum que vemos no dia-a-dia, então será que algo como esse “TDD Reverso” partindo dos engenheiros de testes não seria interessante? ou estou viajando? kkkkk
Parabens! e seja bem-vindo ao blog!
PS. Sou um fã do mundo dos testes e concordo com virgina quando ela disse que TODOS estão trabalhando para aumentar a qualidade do software/hardware sendo desenvolvido.
Opa, Burgos. Respondendo aos pontos que você mencionou:
1) Sim, acredito que é possível um engenheiro de testes possuir conhecimentos de desenvolvimento. Também acredito ser possível um desenvolvedor ter a perspectiva de testador do produto. Cada uma dessas atividades é, basicamente, questão de estudo e exercício. Conheço algumas pessoas que possuem tal perfil.
2) A questão de colocar os engenheiros de teste para escrever os testes automáticos (nesse caso que você falou, acredito que sejam unitários) é algo que (na minha opinião) ainda precisa ser analizado. Mas já vi acontecer algumas vezes.
Em um post de James Withakker ele menciona que pessoas de teste podem auxiliar os desenvolvedores a testar (“The job of the tester is to make sure they have the automation infrastructure and enabling processes that support this self reliance. Testers enable developers to test.“).
Um ponto importante, que vale ser mencionado, é que TDD sem saber testar pode não valer de muita coisa, ou apenas certificar um caminho feliz. O desenvolvedor tem que possuir a capacidade de gerar diferentes cenários para colocar em prova o código desenvolvido. Novamente, questão de estudo e exercício. As mesmas técnicas do livro podem servir para desenvolvedores que querem escrever testes mais eficientes. O desenvolvedor, em certos casos, pode recorrer a outras técnicas como pairwise, classe de equivalência, valores limite, etc. Esse tipo de conhecimento normalmente é buscado por pessoas da área de testes, mas também pode ser útil para desenvolvedores.
Não sei se respondi bem ao que tu perguntou.
No meio dessa conversa sobre pessoas com visão de testes e desenvolvimento acho bem interessante essa série de posts do blog de testes do google(http://googletesting.blogspot.com/2011/01/how-google-tests-software.html#links), onde eles explicam como funcionam as coisas lá, e o quanto eles valorizam a ideia de equipes com uma relação dev X testers cada vez maior, como indicador de alta qualidade, e a própria estrutura de equipes que eles montam com: software engineers, software engineer in testing e software testers
Acho que essa sugestão de Edwin tem muito a ver com inovação e quebra de regras que nem sempre fazem sentido ou contribuem para uma maior qualidade. Há muito que se diz que testers não devem participar de reuniões de com desenvolvedores e que não devem se preocupar com o que está no código. Esse exemplo que Edwin deu aqui é um case de sucesso onde houve a quebra de uma regra, uma evidente inovação e um resultado mais que satisfatório.
Grande Edwin, primeiramente gostaria de parabênizá-lo pelo post e dizer que concordo plenamente com tudo que você falou. Porém Edwin, acredito que pelo cenário atual essa realidade aqui no Brasil está muito distante de acontecer, lembro-me quando comecei a faculdade e alguns colegas que obviamente não chegaram a terminá-la falaram que estavam ali para aprender técnicas de como tratar imagens no photoshop de melhor forma ou que ali gostriam de aprender técnicas de como “fuçar” a conversa dos outros do msn ou quebrar senhas de orkut . Diante disso, me perguntei inicialmente: “Meu deus, o que estou fazendo aqui? Espero que esses pedidos nunca sejam atendidos, pois se eu demorar 4 anos e meio para aprender isso eu assino meu atestado de burro e ignorante e vou fazer qualquer outra coisa”. Meus pedidos foram atendidos, o que foi ensinado, tirando alguns professores trogloditas que realemnte tentaram fazer isso, foram coisas muito mais interessantes e que evnvolviam os conceitos de Sistemas Operacionais, Arquitetura de Computadores, Sistemas Embaracados (Sistemas de Tempo Real e Sistemas Críticos). Mas infelizmente, os professores, são pessoas e também erram deixando formar-se gente que não entende esses conceitos e vão para o mercado produzir sistemas que envolvem exigem pessoas capacitadas para tal, resultando assim em um cenário de profundo pandemônio e fazendo com que nossa profissão seja extremamente desacreditada e mal-remunerada. Acredito, Edwin que é devido a esses profissionais, que, na hora que estavam pagando as disciplinas, estudavam apenas com o objetivo de passar e não de aprender realmente. Acredito que somos hoje em dia mal remunerados de forma geral pois existe pessoas que sabem que não têm a competência necessária para ocupar os cargos que ocupam e se submetem a tal salário. Espero do fundo do meu coração que consigamos tirar essas pessoas do mercado a fim de moralizar a nossa profissão. Porém por enquanto acho isso uma grande utopia. Por isso acredito que estamos distantes de ter um cenário no mercado nacional semelhante ao descrito em seu post.
Abração meu amigo e continue assim pois precisamos de profissionais como você pra dá jeito nessa situação.
Concordo! Eu, como desenvolvedor, sou um péssimo testador. Mas sei da importância de prever os testes, e trabalhar mais com TDD.
[…] anteriormente da importância, para uma pessoa que trabalha com testes de software, de se ter conhecimentos sobre […]
Parabéns Edwin, é uma boa idéia.