Teste de Software não é ...

Teste de Software não é uma atividade que pode ser realizada por robôs insubstituíveis.

Esse post trata-se de um artigo que foi traduzido e citado na referência. É uma boa representação de como penso sobre este tema em Teste de Software.

Eu posso dizer com certeza que esta é uma das declarações mais incorretas em testes e também um dos mais tóxicas. Isso é baseado em suposições falsas e que produz um monte de outras premissas falsas que se tornam popular para a única razão que alguém confia cegamente, sem fazer perguntas. Então, eu dividi essas premissas em dois grupos:

Todos podem testar, testar é fácil . Seu gerente pode testar, o dev pode testar, o designer pode testar, o cliente pode testar, o seus cães gestores podem testar, etc, etc ... Mas, eles não podem fazê-lo, porque eles estão ocupados fazendo outras coisas importantes.
O teste é fácil, porque um teste bem escrito é descrito em um número finito de passos ou instruções , e se estas instruções forem seguidas exatamente você pode testar o problema sem quaisquer impedimentos.

Agora, o que eu quero que você faça é - anote isto em um pedaço de papel, levá-lo para fora e queimá-lo, enquanto canta algum feitiço do mal.

É fácil entender por que esses mitos estão em nosso ofício . Uma razão - é a idosa gestão que não se importa sobre o teste , eles se preocupam com orçamentos e eficiência. Outra razão é não conseguirmos fornecer a verdadeira história por trás de testes, como é eficiente e benéfica para o produto / projeto, se não formos capazes de fazer isso, a culpa é nossa . E terceira razão - existem demasiados fornecedores de ferramentas e cursos de testes de software e academias que têm interesse em vender-lhe "óleo de cobra" - a solução final que vai resolver todos os seus problemas de teste, seja uma ferramenta ou metodologia,

Por que o teste não pode ser realizado por robôs insubstituíveis, e aqui eu quero dizer tanto robô humana agindo como especialista e a atual automação ? Uma boa razão para isso é o fato de que o teste não é baseado em instruções, ele é baseado em interpretações, em interações, no recolhimento de informação simultâneas, avaliação e ação de acordo com essa informação . O teste é experiência , investigação e decomposição de declarações que os outros (desenvolvimento, gestão...) acreditam que são verdadeiras (parafraseando James Bach). Usando tudo isso, temos que fornecer informações relevantes , sobre o risco e o produto em si. Então, como tudo isso se alinha com o "conceito" de seguir instruções?

E há mais uma razão pela qual o teste não pode ser representado através de um conjunto limitado de etapas ou instruções conectadas, o que provoca também a impossibilidade de automatizar totalmente o teste - convertendo estas instruções para instruções de máquina. O motivo é a forma como o conhecimento funciona . Mais especificamente a impossibilidade de converter conhecimento tácito em explícito ou mesmo explicável conhecimento ( Collins, "tácito e conhecimento explícito" ).

Isso pode ser explicado de uma maneira muito simples - todos nós já cozinhamos, às vezes, certo? Bem, todos nós sabemos que as receitas culinárias são de alguma forma uma espécie de algorítmo , passo-a-passo como fazer um X prato. E eles podem ser escrito por um bom especialista, como um mester chef, por exemplo. No entanto, seguindo seu conselho, mesmo ao mais ínfimo pormenor, você pode ser capaz de fazer um prato decente , mas não igual a uma feita pelo perito. Você não iria notar os pequenos ajustes que o chef vai fazer, dependendo de seu ambiente ou do produto que ele usa, ou o frescor das especiarias, tudo baseado em uma "intuição". Por que isso acontece? Vamos chamar isso de experiência ou de rotina , o que ele realmente é - a grande parte subaquática de iceberg de conhecimento , chamado conhecimento tácito .

A mesma coisa se ​​aplica a qualquer área, inclusive o Teste. "Podemos saber mais do que podemos dizer" (Polanyi), portanto, em teste podemos fazer muito mais do que podemos realmente colocar em palavras , cenários, casos, etapas, scripts ou seja o que você diga. O teste é um processo intelectual e tem natureza orgânica , é normal ser inexplicável e nós a termos certos problemas para descrevê-la ou documentá-lo. É assim que a ciência e o conhecimento trabalham.

A razão para isso não é uma crença compartilhada no teste mainstream, é o fato de que muitos consultores e programas de certificação gostariam de dar uma história curta e emocionante em "como você pode se tornar grande tester, seguindo este simples conjunto de regras". E é "vendido" para nós sob a cobertura de palavras como"melhores práticas" , que significa "Não tenho nada a provar para você, isso é o que todo mundo está usando". Bem, newsflash, esta é a comunidade de testes, você faz uma declaração aqui , você tem que estar pronto para defender sua posição , ninguém se importa quanto de um guru ou um perito você é.

REFERÊNCIAS


http://mrslavchev.com/2016/05/02/software-testing-not-part-3/


http://www.satisfice.com/blog/archives/1509

Quando os programadores fazem o seu trabalho!

Algumas das tarefas mais importantes no papel de um testador é identificar interpretações alternativas de declarações aparentemente claras e simples. Um tempo atrás uma pessoa escreveu a seguinte mensagem no Twitter "Quando os programadores fazem o seu trabalho, os testadores não encontram nada e, portanto, não tem nada de útil para contribuir ". Eu prefiro pensar que sua intenção foi lembrar os programadores de assumirem a responsabilidade pela integridade e qualidade do seu trabalho, e não a pequenos testadores.

Como testador, parte do meu trabalho ajuda a reduzir a chance de que as declarações poderiam ser mal interpretadas ou tomadas de uma forma demasiada simplista. Eu acho que a pessoa provavelmente mencionou apenas o primiero item da lista das várias interpretações que essa frase pode fornecer  (e espero que ele esteja de acordo com também com as interpretações que deixo aqui):

Quando os programadores fazem o seu trabalho, os testadores não encontram nada que assume a forma de erros de codificação flagrantes .
Quando os programadores fazem o seu trabalho, os testadores não encontram nada inconsistente com o que os programadores foram convidados a fazer, embora os testadores possam descobrir problemas no projeto ou nos requisitos que foram dados aos programadores para implementar.
Quando os programadores fazem o seu trabalho, os testadores não encontram nada que indica que o programador tenha sido negligente ou descuidado , embora até mesmo os melhores programadores não são perfeitos.
Quando os programadores fazem o seu trabalho, os testadores não encontram nada que torna o produto difícil de testar, em vez disso, eles recebem um produto altamente testável que fornece acesso a coisas como arquivos de log e interfaces testáveis.
Quando os programadores fazem o seu trabalho, os testadores não encontram problemas , embora possam descobrir o valor inesperado do produto.
Quando os programadores fazem o seu trabalho, os testadores não encontram nada que interfira com o teste de profundidade. Procurando problemas raros, ocultos, sutis, ou relacionados com a plataforma que poderia escapar mesmo com programadores mais diligentes.
Quando os programadores fazem o seu trabalho, os testadores não encontram nada que lhes atrasa no desenvolvimento de uma compreensão mais abrangente das necessidades do negócio , tornando seu teste mais relevante.
Quando os programadores fazem o seu trabalho, os testadores não encontram nada que leva tempo para desenvolver idéias ricas de teste, cenários e experiências que geram um profundo conhecimento do produto e os seus comportamentos emergentes.
Quando os programadores fazem o seu trabalho, os testadores não encontram nada mais que pedir em termos de ferramentas úteis que ajudariam.

Na mesma linha, James Bach ressaltou que, mesmo quando os programadores fazem o seu trabalho, os testadores verificam se o produto está fazendo seu trabalho, e que os testadores encontram verdades importantes sobre o produto. Nenhuma delas é exatamente "nada". Então ...
Quando os programadores fazem o seu trabalho, os testadores brilham na luz sobre como exatamente o quão bem os programadores têm feito o seu trabalho.
Quando os programadores fazem o seu trabalho, os testadores identificam maneiras em que outras pessoas podem ter diferentes interpretações de um trabalho bem feito.
Quando os programadores fazem o seu trabalho, os testadores ter mais tempo para comparar nosso produto com os produtos dos concorrentes, apontando áreas de pontos fortes e fracos de cada um.

Os programadores também estão no negócio de esclarecer interpretações equivocadas. Eu postei uma versão mais simples de uma das idéias acima no Twitter:

"Quando os programadores fazem o seu trabalho, os testadores encontram profundos, raros, ocultos, sutis, ou relacionados problemas com a plataforma."

Vou acrescentar que mesmo os melhores testadores, exatamente como os melhores desenvolvedores são humanos, e limitado, e pode ocasionalmente perderem problemas.

Assim: Testadores (e programadores) que se concentram na excelência, habilidade e colaboração irão ajudar uns aos outros, e tendem a encontrar problemas que podem ser resolvidos antes que o produto seja liberado e tenderá a produzir produtos mais valiosos, como resultado.

REFERÊNCIAS

http://www.developsense.com/blog/2014/12/when-programmers-and-testers-do-their-jobs/

http://www.satisfice.com/tools/htsm.pdf

Contratando um profissional de teste!

Resumo: Contratar as pessoas certas para um trabalho é difícil e muitas vezes trabalhoso. Quando eu olho para as ofertas de emprego para testadores eu vejo um monte de lixo e isso me deixa irritado. Acho que esses anúncios de emprego mostram que ainda há muita incompreensão sobre teste, testadores e o que fazem. Isso faz com que seja mais difícil de encontrar as pessoas certas para o trabalho. Neste artigo vou compartilhar alguns pontos e destacar o que eu acho que é importante quando as empresas tentam contratar profissionais na área de teste.
O processo de contratação de um profissional de teste não é muito diferente da contratação de qualquer outa pessoa de TI , a diferença é que as habilidades, conhecimentos e experiência que você está procurando são específicos.

Quem são os "profissionais"?

Costumo falar sobre testadores e habilidades de teste. Podemos fazer uma distinção entre "testadores profissionais" e "testadores de profissão". A última categoria são de pessoas que trabalham principalmente porque é uma maneira de ganhar a vida e eles não agem como um verdadeiro profissional. Eles sabem pouco sobre o que eles fazem e não estudam seu ofício.

Eles nunca leram literatura profissional e só querem fazer cursos se o patrão está pagando. Eles apenas fazem o seu trabalho e vão para casa querendo esquecê-lo, porque eles realmente não apreciam o que fazem. Testadores de profissão apenas fazem algo que parece estar trabalhando e não podem explicar o valor efetivo dos seus testes.

As empresas sempre querem contratar o melhor testador possível, mas isso na maioria das vezes não é possível já que testadores profissionais são uma minoria. O teste é uma profissão difícil, complexa e exigente. É por isso que as empresas devem tomar muito cuidado ao contratar pessoas para trabalhar na área de teste. Testadores profissionais têm as características certas: conhecimento, habilidades, experiência, atitude, ética e valores.

O truque na contratação de testadores profissionais é saber reconhecer um profissional e combinar a mistura certa de acordo com as características do trabalho. Parece simples né? Mas não é tão simples quanto parece. Mais tarde neste artigo vou apresentar algumas heurísticas para reconhecer um testador profissional.

A solução dos problemas

Gosto de tratar o recrutamento como uma resolução de problema. Pense assim: quando você quer contratar um testador, você tem um problema. Está escasso de pessoas, você precisa de habilidades diferentes ou talvez você precise de pessoas melhores? O primeiro passo é reservar um tempo para definir qual é o problema que você precisa resolver .

Recrutamento leva muito tempo e pode ser caro. Você quer ter certeza de que você está resolvendo seu problema contratando o testador certo. Mas você realmente está precisando contratar um novo testador? Qual problema você precisar resolver? Quais são as características que você está procurando?

Características de trabalho vagos não ajudam

Muitos anúncios de emprego são muito vagos e mal escritos. Não existem características claras mencionada da pessoa que eles estão procurando e a atitude que eles esperam desta pessoa. Isso é um sinal de alerta de qual a visão da empresa com relação ao teste. Se você tem uma descrição fraca do trabalho, não se surpreenda se os candidatos fracos responder e tentar conseguir o emprego que você está anunciando. Seja muito específico no que você está está buscando, não tenha medo de que apenas algumas pessoas irão demonstrar interesse. Ser específico vai ajudar também os próprios candidatos a avaliarem se estão aptos para a vaga.

Maus exemplos

1 - "Bacharel em Ciência da Computação ou áreas afins , ou experiência de trabalho equivalente"
diz ao candidato que isso é o suficiente. Sugiro descrever também por que isso é importante.

2 - "Garantir que as entregas do projeto estejam livres de defeitos"
diz ao candidato que a empresa realmente não entende a causa do teste.

3 - "Certificação: ISTQB/BSTQB, ALATS... " pode dizer ao candidato que a certificação é mais importante do que qualquer outra habilidade do testador ou que o recrutador não é capaz de descrever quais habilidades são importantes para o trabalho.

4 - "O desenvolvimento , implementação e execução de casos de teste", conta ao candidato que é só mais um trabalho de teste qualquer, sem muitos desafios.

Seja claro no que você espera

Buscar o candidato certo cria uma expectativa clara do que você está procurando. Todos os aspectos da pessoa que você procura deve estar lá : conhecimentos, habilidades, experiência, atitude, ética e valores. Também adicionar algo em sua descrição sobre o porquê de o testador querer trabalhar para você. Pode ser um produto desafiador, a cultura da empresa ou até oferecer grandes benefícios.

Bons exemplos

Empresa A anuncia:
"Testes exploratórios- queremos testes qualificados , exploratório estruturado, e não apenas um teste pobre. Você já ouviu falar ou ler uma obra de Cem Kaner, James Bach e outros? Isto indica claramente o conhecimento que você espera.

Empresas americanas, europeias e salve meia dúzia de brasileiras tem descrições de trabalho onde eles descrevem de forma clara os valores da empresa: "Nós valorizamos disciplina e curiosidade", o que eles esperam do candidato: "Compartilhe a sua paixão pelo seu trabalho, internamente e externamente" e dizem-lhe como essas atitudes e valores vão traduzir em um comportamento esperado: "Preocupe-se com a empresa, a qualidade do produto e da experiência do usuário" desafios épicos que vão empurrar você para fora de sua zona de conforto. "A empresa também pode indicar o que eles esperam de um testador e o que pode se esperar de seus colegas: "Você sabe como convencer um desenvolvedor sobre uma melhoria no software e fazê-lo pagar uma bebida depois" e "Você testa tudo em sua vida, o seu novo telefone, seu carro novo, um pedaço de código e a rota mais rápida para o seu novo emprego."

Seleção: adicionando um desafio extra

Depois de definir o problema e descrever a solução para se resolver o problema, a diversão realmente começa. Gostaria de recomendar a adição de um desafio extra para pessoas que se mostraram interessadas na vaga. Deixá-los escrever uma carta de apresentação em que eles têm que descrever por que eles acham que se encaixam com a descrição da vaga. Isso também lhes dá a chance de explicar por que estariam aptos para a vaga. Uma outra maneira é adicionar um desafio no processo. Pedir ao candidato que teste alguma coisa e enviar um relatório para você ou fazer perguntas como: "Descreva teste e qualidade com suas próprias palavras" ou "Como é que você testaria um aplicativo grande e complexo tendo apenas um dia para testá-lo?" e ele lhe envia as suas respostas juntamente com seu currículo. Colocando um limite extra pode ajudar de duas formas: desencorajar as pessoas que não são realmente sérias ou preguiçosas e também lhe dar uma ideia do nível de habilidade dos candidatos.

A entrevista: "prática é o que pega"

A coisa que me impressiona mais, é que só muito raramente os candidatos pedem para testar alguma coisa. Eu acho que é uma maneira muito arriscada de contratar pessoas. Como você pode ter certeza de que eles são bons em teste e não somente bons em falar sobre o assunto? deixe um candidato criar, apresentar e defender uma estratégia de teste e depois testar um pedaço do software durante a entrevista. Não pise na armadilha de pensar que vai demorar muito tempo para trabalhar com eles. Tire um tempo para deixá-los testar ! Deixá-los explicar como eles pensam, pois é sua forma de pensar umas das principais coisas que nos interessa .

Também fazer perguntas buscando por evidências do que eles acreditam ser certo: fazer perguntas como: "Você pode me dar um exemplo de como você aplicou a técnica de teste X ou método Y ? ". É interessante perguntar a forma de como o candidato aprende. Um aspecto muito importante do teste é o aprendizado sobre o produto e aprendizagem é essencial para testadores profissionais. Após as entrevistas oficiais, eu tento planejar algo para a equipe conhecer o candidato, para que passem um tempo juntos, tenham a oportunidade de conhecerem uns aos outros e dar ao candidato a chance de conhecer melhor a organização.

Adequação cultural na organização e da equipe é uma das coisas mais importantes que você deseja assegurar. Se a pessoa não se encaixa na cultura, não importa o quão qualificado seja , você terá um problema sério no final.

Lembre-se que o recrutamento vem de dois lados: você tem que se certificar que o candidato se enquadra no perfil e também se os candidatos realmente querem trabalhar para sua empresa. Apressando as entrevistas de emprego você vai ter o problema não resolvido com a pessoa errada contratada. Gastar mais tempo na definição do problema e selecionar com calma o candidato deverá pagar o investimento a longo prazo e ter um ajuste adequado para a sua organização .

Conclusão

Contratar um testador é difícil e muitas vezes dará muito trabalho. Para atrair as pessoas certas se certificar de que o problema que precisa ser resolvido foi definido de forma clara e o trabalho descrito de forma explícita.
Testar os candidatos sérios vai ajudar você a contratar o melhor, quem realmente quer trabalhar para você e que é uma combinação perfeita para a vaga que você tem. Lembre-se que um testador profissional vai evoluir e ficar ainda melhor, mesmo que ele tenha sido contratado enquanto testador júnior.

Cuidado! Caso de teste pode levá-lo a cegueira.

Dois conceituados testers Katrina Clokie e Aaron Hodder testaram uma teoria para destacar a cegueira por desatenção que pode ocorrer durante a execução de casos de teste com script.

O conceito era simples. Eles escreveram um conjunto de oito casos de teste detalhados que instruem o testador em verificar se a função de ordenação de um site de compras funcionava como deveria. Cada testador (ou par de testers) tiveram exatamente o mesmo conjunto de oito casos de teste, idêntico em todos os detalhes. Deram 20 minutos para executá-los e após a conclusão, pediu-lhes o número de bugs que haviam encontrado, bem como o número de testes que tinha passado, que não passaram ou que não foram feitos.

O resultado mostrou que, quando pedimos diferentes pessoas a seguir os mesmos casos de teste, acabamos recebendo muitos resultados diferentes.

Alguns grupos não encontraram bugs. Um grupo encontrou cinco. A maioria encontrou dois bugs, mas com base na discussão subsequente estes não eram necessariamente os mesmos dois bugs. O mesmo fenômeno ocorreu quando os testadores foram convidados para alocar passe preto ou branco / reprovação adjudicação para seus testes. Em alguns casos, a presença de erros parecia resultar no caso de teste que falha. Em outros, o testador identificou um bug, mas ainda sentia que o teste tinha passado.

Para mim, isso destaca duas coisas realmente importantes.

A primeira é a cegueira por desatenção que pode ocorrer durante a execução de casos de teste. Este é o fenômeno que ocorre quando você está a se concentrar em uma coisa específica, isso significa que é provável que você perca outras coisas que podem estar acontecendo bem na frente de seus olhos. O exemplo mais famoso é o ” business ilusão macaco “.

Nesse exercício, e na execução de testes de scripts, cegueira por desatenção significa que uma vez que o procedimento documentado está focando sua atenção em uma linha específica de investigação, você está sujeito a perder erros ou comportamentos interessantes que ocorrem em torno das funções que o script especificamente destaca. Quero destacar isso para os testadores que estão lendo esse artigo fiquem cientes da falibilidade do método e podem fatalmente se desfocar regularmente durante a execução de um caso de teste, perdendo de encontrar bugs importantes.

Os casos de teste não refletem verdadeiramente o esforço cognitivo e temporal dos testes que ocorreram, em vez disso, ele reduz esse esforço  tornando todos equivalentes.

Em segundo ficou expresso também o perigo inerente de casos de teste e o nível implícita de equivalência que representam. Um grande número de testadores alegremente informaram sobre seus testes através da contagem do número de testes que passaram e o número que falhou. Esta é uma maneira extremamente redutora de representar uma informação que o teste deveria estar fornecendo, através da representação de todos os casos de teste como iguais

Tive um coordenador da Qualidade que sempre dizia muito empolgado ” Por que um dia, vamos especificar casos de teste para os implementadores” ele achava isso a solução de todos os problemas com bugs, mas desde aquela época eu já ficava com a pulga atrás da orelha e isso acabou se confirmando tempos depois, claro que dentro do meu contexto, não podemos de forma alguma generalizar. Mas isso me faz pensar se realmente especificar casos de teste para desenvolvedores é um bom negócio, já que eles poderiam ser presas fáceis para cegueira por desatenção, isso pode explicar também a dificuldade que alguns desenvolvedores tem em testar uma implementação com base na especificação e até mesmo alguns testadores. Modelos mentais e testes pareados podem ser de grande ajuda contra a cegueira por desatenção, além de economizar um tempo absurdo, que seria usado para escrever massantes casos de teste.

Muitos testadores  elaboram casos de teste como uma forma de demonstrar sua produtividade, apresentando ao final de cada sprint o número de casos de teste que passaram e por ai vai, números que não dizem absolutamente nada, muitos gerentes e coordenadores são culpados nisso, pois tatuaram em suas mentes que a forma de medir a produtividade de um testador é através do número dos casos de teste e acabam impondo essa farsa, isso quando não vem de consultores de teste terceirizados.

É uma cultura que se alastrou e que ainda vai permear por muito tempo. Se você como testador aceita isso passivamente e acha que teste de software se resume a casos de testes que comparam um resultado esperado com o resultado final, não se ache no direito de reclamar do seu salário, da falta de interesse do seu coordenador e desenvolvedores no seu trabalho na equipe.

Os casos de teste podem fazer parte do teste, assim como as inúmeras técnicas e ferramentas que nos auxiliam, mas jamais podem ser encarados como um teste por si só. Em vez se ficar no país das maravilhas com seus casos de testes, mostre aos seus colegas de equipe como os mapas mentais podem facilitar a construção de bons testes,  realize testes pareados com o intuito de demonstrar e ensinar testes com qualidade, use heurística, testes baseados em sessão, demonstre sua experiência adquirida ao longo do tempo como testador para encontrar bugs importantes de forma rápida, essa é uma das formas de demonstrar como você é um testador diferenciado e que realmente agrega valor dentro da equipe.