Teste de Software não é ...

-10

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ô humano 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… Continue lendo

Tester

Entendo como referência um texto que a gente usa como base argumentativa para uma dissertação ou uma opinião…

Você fez uma tradução tirando os elementos que deixavam o texto um pouco mais lúcido e com contexto… :/

Se for para traduzir algum post gringo, deixa claro que você está fazendo isso no começo.

Achei o texto confuso! Assim… Seriam tópicos a serem pensados? Não entendi o propósito.

Patrícia Gonçalves

@marioramos18 disse em Teste de Software não é ...:

“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.

Acredito que este post seja uma referência ao outro post de crítica às ferramentas de teste, então vou direto ao ponto. O teste não pode ser substituído inteiramente por robôs, ou pensamentos robóticos, pois como o texto diz, o testador faz muito mais do que é possível expressar. Porém, esta afirmação não quer dizer que devamos deixar de automatizar. Pense que você tem uma aplicação que fazem vários cálculos e que testar todos os casos seria muito demorado/impossível. O que você faz? Testa tudo, regras bem definidas e questões subjetivas, manualmente, ou automatiza uma enquanto testa manualmente outra?

Acredito que a automação vem para ajudar e não para substituir os testes manuais. Enquanto a gente tiver que testar valores limites, classes de equivalência, campos numéricos com letras, então não teremos tempo de testar o que não pode ser automatizado. Ou será que um banco vai preferir dar prioridade à usabilidade em detrimento dos cálculos?

Uma empresa que começa seu produto tendo testes automatizados tem uma grande vantagem, pois aqueles testes que já estão automatizados, nunca será rodado manualmente, eliminando o tempo do testador com testes de regressão e deixando-o livre para testar coisas novas e fazer testes exploratórios.

10

Mario, você está caindo numa esfera que muitos ou quase todos já caíram, o que não é demérito algum. Pensamento conflitantes são interessantes de serem debatidos. Testar realmente é uma disciplina muito mais complexa que ferramental de automação, mas dado que existem, porque não juntar as duas coisas?

Testes exploratórios são testes que são feitos de forma manual também, e tem técnicas específicas para aplicá-los.

Smoke Tests também são testes feitos de forma manual e também tem técnicas para aplicá-los.

Testes baseados em risco também são feitos de forma manual e também tem técnicas para aplicá-los.

Te dei 3 exemplos de testes que você pode pegar todo esse conceito e conjunto de palavras bonitas dos autores que você usa como referência e aplicar nesses 3 tipos de testes.

Assim como pode-se aplicar técnicas de automação (funcional, unitário, integrados, pentest, etc) para que o conjunto da obra possa ser quase um Bug Zero.

Automação veio não para substituir e sim para agregar a vida do tester, inclusive para aplicar esses conceitos de forma mais precisa. Imagina um cadastro com formulário de 3 páginas que você leva cerca de 5 minutos para executar. É apenas um formulário, você tem que se atentar com campos chaves para que não possam ser repetidos e toda bateria de testes usando esse conceito lindo que você gosta de trabalhar vc terá que passar por pelo menos 3 vezes nesse formulário (3 cadastros diferentes) por exemplo. Você vai levar cerca de 5 minutos para poder fazer cada cadastro, ou seja, 15 minutos para poder aplicar o seu mundo ideal em alguma feature (dado que para fazer sentido, tem que ter um cadastro em cada situação, no caso que citei, 3). O cadastro já está validado, aplicado o seu conceito, será que você não perde muito tempo realizando o mesmo cadastro já validado 3 vezes? E se forem 5 baterias de testes? Estamos falando ai de 1,25 horas apenas em cadastro já validado. Será que não vale a pena pegar esse cadastro que já está validado e automatizar a tarefa que você faz exaustivamente, como um robô, ou como um macaco e reduzir de 5 minutos para 20 segundos por cadastro? Estamos falando ai de apenas 5 minutos de cadastro, 1,20 horas economizadas para você aplicar o seu mundo ideal e assim por diante.

O que você não está entendendo é que tudo que você falou todos nós como QAs aplicamos no dia a dia, apenas utilizamos automação como forma de fazer com que as coisas repetidas e já validadas possam reduzir o meu tempo manual.

Ah … e pode ter certeza que se algum cadastro falhar, a automação pega com certeza, vai tirar print, vai te dar um log, vai falar o erro, e daí pra frente você passa a ter um cadastro com problema que a automação pegou, o que talvez, com tantos testes exaustivos de cadastro, talvez não olharia para esse detalhe.

Não acredito que algum QA possa pegar o conceito básico de qualidade de software e jogar no lixo em prol de uma atividade de automação. Automação envolve disciplina, envolve análise, conhecimento técnico, conhecimento de negócio, percepção, boa escrita (se utilizar BDD).

É isso ai. Meus 50 cents.

-2

@Bruno-Fernandes Concordo com quase tudo que vc comentou! Principalmente no que diz respeito a automação como uma ferramenta de apoio ao teste. Mas não é isso que vejo na comunidade, (tenho repetido isso) o que vejo é apenas ferramenta, ferramenta e ferramenta… elas são colocadas como o centro das atenções em teste e como uma prática inquestionável. Isso perpetua a ignorância de um Tester n pode participar de um time ágil, há n ser que ele saiba programar. Há pouca conversa sobre pensamento crítico, científico… que são habilidades essenciais para quem deseja se tornar um tester de qualidade. A palavrinha chave aqui é o “contexto” meu amigo, assim como vc citou um cenário onde seria interessante usar uma ferramenta para me apoiar nos testes, tb temos cenários onde isso n seria necessário, em um contexto onde o teste automatizado poderia ser caro de criar, caro de fazer manutenção e totalmente desnecessário, onde eu precisaria apenas de alguns minutos com meu cérebro ligado, para realizar um ótimo teste.

Tester

@marioramos18 , Então, vamos lá:

  1. O texto é denso, ele não guia a um final onde se pode, pelo menos, refletir sobre o que foi dito. Existe uma dispersão grande nele (acredito que seja culpa do autor mesmo…)

  2. Essa disruptura que tenta fazer com os seus posts, acredito ser válida, mas com um texto extremamente “fora de foco”, fica difícil de começar uma argumentação ou até questionar.

  3. O questionamento sobre “Automação vs Manual” (que não totalitário, mas é implícito) é como iniciar a famosa discussão da “Bolacha vs Biscoito”.
    TODOS nós temos contexto de trabalho diferente e alguns tem locais de serviço onde podem expandir seu conhecimento. Aí eu te pergunto, conhece alguma empresa que ajude a pessoa a expandir o conhecimento com alguns preceitos ensinados pela Psicologia? (Me baseando que parte da disruptura que anda falando envolve laços que a psicologia ensina…)

Bom, esses foram os pontos que gostaria de falar nesse tópico.

Ps: Antes de mais nada, gostaria de deixar a definição CNV:

"...é baseada nos princípios da não-violência – o estado natural de compaixão quando a não-violência está presente no coração.
CNV começa por assumir que somos todos compassivo por natureza e que estratégias violentas - se verbais ou físicas - são aprendidas ensinadas e apoiadas pela cultura dominante.
CNV também assume que todos compartilham o mesmo, necessidades humanas básicas, e que cada uma de nossas ações são uma estratégia para atender a uma ou mais dessas necessidades."

E algo que li recentemente e achei muito bom:

"se você é incompetente, você não consegue saber que é incompetente (...) 
As habilidades necessárias para fornecer uma resposta correta são exatamente as habilidades que você precisa ter para ser capaz de reconhecer o que é uma resposta correta. 
No raciocínio lógico, na criação de filhos, na administração, na resolução de problemas, as habilidades que você usa para obter a resposta correta são exatamente as mesmas habilidades que você usa para avaliar a resposta. 
Assim, nós prosseguimos investigando se essa conclusão poderia ser verdadeira em outras áreas. E para nossa surpresa, era bem verdadeira. "

@Ramses-Saccol-de-Almeida vou respeitar sua opinião sobre meus posts e refletir sobre como posso melhorar o foco.

Com relação ao item 3 do seu comentário, vc comentou: O questionamento sobre “Automação vs Manual” (que não totalitário, mas é implícito) é como iniciar a famosa discussão da “Bolacha vs Biscoito”.
R: Isso n me diz nada, o que pode parecer implícito pra vc, pode n parecer para muita gente. Achei esse comentário de valor neutro.

R:Já respondendo a sua pergunta, não conheço nenhuma empresa no Brasil que contribua com o conhecimento e ensinamentos voltados para a área da Psicologia na área de software. Mas e daí? assim como não conheço nenhuma empresa que ajude as pessoas em tantas outras áreas que julgo importante para os mais variados profissionais. Não precisamos de empresas para nos dizerem o que precisamos fazer para que possamos ser profissionais melhores certo?. Até pq a grande maioria n compreende o Teste em sua plenitude. Quanto mais vc se aprofunda em uma determinada área (isso n é válido somente para Teste de Software), mais vc se distância dela (irônico) e começa a ter consciência de que precisa abraçar outros campos para refinar seu desenvolvimento. Eu só consegui evoluir de forma considerável quando eu parei de ler artigos e livros sobre Teste de Software, e passei a ler e pesquisar outros campos (psicologia, ciências sociais, pensamento crítico…inclusive tem um livro: The Psychology of Testing Software do John Stevenson que indico) e vendo como elas poderiam agregar valor em Teste de Software.

Um último comentário , é incrível como qualquer post que soe algo contra automação (ferramentas) que muitos “especialistas”, “quase programadores” ou “programadores” defendem aqui (nunca falei que sou contra automação) tem quase que total reprovação neste fórum.

Tester

@marioramos18 Obrigado pela sua resposta.

Em relação ao 3 item que mencionei, quis levantar essa questão por que:

a ) Na área de desenvolvimento de software, existem sim empresas que te auxiliam para o teu aumento de capacidade técnica. Pois elas querem te fazer crescer como profissonal (ou, na pior das hipoteses, te explorar a um baixo custo). Ponto. Se tu te imaginar como empresa, será que conseguiria dispor de custo para fazer algo como citei? isso é um tópico delicado a nivel empresarial. Mas por que falo das empresas? Pois boa parte da nossa vida envolve estar nelas, produzir para elas e evoluir (ou não heheh) com elas. No sistema capitalista que vivemos, não temos como fugir disso. (acho que por isso empreendedorismo é tão “high topic” por esses anos). Como já falei anteriormente (em outros tópicos teu) Acho que o foco que procura é algo mais acadêmico, e as pessoas que estão lá podem ajudar a fomentar melhor o conteúdo o qual está falando.
E foi somente por isso que resolvi falar sobre esse 3 item. (E se ficou confuso o nexo desse item, podemos abrir ele a conversação.)

b ) "Até pq a grande maioria n compreende o Teste em sua plenitude" : E o que o ser humano entender em sua plenitude? Acho que nem a morte entendemos…Então tentar chegar algo em sua “plenitude” é meio que entrar na falácia da perfeição…(minha opinião e apenas isso). E acho o seu exemplo, do quanto mais se aproxima, mais se afasta, um pouco engraçado. Pois se pensar, temos pessoas aqui que sabem muito de automação. Por essa lógica elas devem estar se afastando disso…Penso eu…(A parte de achar graça, não envolve ofensa direta, é algo que acho. )

c)The Psychology of Testing Software do John Stevenson : Iniciei uma leve leitura sobre esse livro, e se notar, Algumas coisas se encontram em partes da Psicologia em si. Me parece (preciso ler ele todo, ou seja, arranjar tempo para isso) que ele faz um apanhado sobre a área de testes e alguns tópicos da psicologia (Se estiver errado, me perdoe, não terminei de ler ele…)

Ps: Um último comentário , é incrível como qualquer post que soe algo contra automação (ferramentas) que muitos “especialistas”, “quase programadores” ou “programadores” defendem aqui (nunca falei que sou contra automação) tem quase que total reprovação neste fórum.

Isso acontece em qualquer local. Vai e um fórum de java e fala que python é melhor…Se conseguir lidar com a “treta”, vai ver que aqui até é bem mais “politizada” que em outros locais…
E acredito que levantou a questão, é por que queria conversação sobre a mesma. O nível é que pode sair como “tiro pela culatra…”

No demais, bons testes…Boa cerveja e não fica grilado com esses debates…Acontecem…hehehe

Log in to reply

Looks like your connection to Agile Testers was lost, please wait while we try to reconnect.