James Bach: A medição da qualidade, experiência em testes e sua evolução como testador.
Autores: Bruna Cristina Silva, Carolina Custodio Oliveira, Luciana Ferreira e Willian Rafael de Oliveira Melo
Introdução
Atualmente, a qualidade dos produtos de software está cada vez mais sendo exigida no mercado, por essa razão a área de teste de software tem evoluído nos últimos tempos. E, parte da importância deste avanço ocorre devido a contribuição da literatura para que as iniciativas nesta área sejam mais valorizadas. Neste texto, iremos dar destaque ao autor James Bach. O autor é conhecido na comunidade científica por ser o defensor dos testes exploratórios, no entanto outras abordagens são propostas no sentido de desenvolver e criar grandes inputs para a área de teste de software. A seguir, serão apresentados os pontos principais de três artigos do autor. No primeiro artigo, o autor partilha os seus 34 anos de experiência na área de teste de software e nos traz uma breve reflexão inspiradora sobre as transformações nesta área. Bach (2021) afirma que “quase todos no mundo do software pensam que entendem de teste, mas quase ninguém se esforça para estudá-lo”. Apesar do reconhecimento das mudanças que área tem passado, o autor revela que ainda predomina uma mentalidade herdada dos anos 80 de que os testes não são ainda levados a sério pelas organizações e gestores que acreditam que todos os testes devem ser formalizados e automatizados.
Atualmente, o autor defende que os testadores não devem se limitar a trabalhar de forma automática, eles necessitam de pensamento criativo e crítico, por isso não se pode banalizar a ideia de que todo mundo em uma organização pode testar, é uma tarefa que exige foco e dedicação por parte dos testadores para encontrar e solucionar os problemas. No entanto, o autor também propõe que o desenvolvimento da investigação e os recursos disponíveis online podem contribuir para o aprofundamento do tema e possibilitar a construção e novas bases de conhecimento em benefício da comunidade dos profissionais na área de teste de software.
No segundo artigo, o autor discute o quanto as pessoas costumam relacionar a qualidade diretamente com a medição. Utilizando uma abordagem professoral, na qual distingue as principais diferenças entre medir e avaliar e o quanto esta distinção é importante para os clientes. E destaca que a qualidade vai muito mais além do que medir, é saber utilizar os dados com métricas realistas considerando também a avaliação e discussão como parte do processo da qualidade.
Já no último artigo, o autor traz uma perspectiva de que um bom teste é feito quando o testador encontra bugs que realmente importam, ou melhor, trazem algum tipo de impacto no produto e usuário. Todavia, um bug é uma relação entre pessoas, produto e contexto, onde cada um pode representar uma peneira de filtros diferentes que impedem que os bons bugs sejam relatados. Para isso, o autor detalhou o que deveria conter um pipeline de relatório de bugs
James Bach, 34 anos de Experiência em Testes.
James Bach completou em Maio de 2021, 34 anos como Testador. Devido a sua vasta experiência como Testador, descreve a evolução na área de Testes e Qualidade em seu ponto de vista. Menciona que quando entrou para o ofício, a ideia dominante era formalizar os testes escrevendo procedimentos e automatizar os mesmos, se possível.
Nos anos 80, quando iniciou os testes não eram levados a sério, embora houvesse muitas pessoas chamadas testadores e dinheiro fosse gasto com isso. Segundo ele, gerentes acreditavam que todos os testes deviam ser formalizados e automatizados e acreditavam nisso, porque não sabiam e nunca entenderam o que os bons testadores realmente fazem e como o fazem, e na maioria dos casos sequer queriam aprender, um problema que acredita se repetir na atualidade.
Havia equipes de teste e gerentes de teste, os testadores estavam sempre sob pressão porque o time, exceto os testadores, queria enviar o produto o mais rápido possível. James e alguns colegas, se posicionaram contra a ideia de que formalizar testes é sempre bom, e que testes informais não são bons. Eles afirmavam que o teste é sobre pessoas que aprendem, pensam e questionam e não sobre procedimentos e linhas de montagem de fábrica.
De acordo com a observação de Bach, a indústria passou por mudanças ao longo dos últimos anos, porém, houve uma constante ao longo de sua experiência nesse campo: quase todos no mundo do software pensam que entendem de teste, mas quase ninguém se esforça para estudá-lo. Atualmente, existem recursos fantásticos para aprender testes online, no entanto, ele descreve que “os bons recursos estão nadando em um mar de ruins.”
Hoje, há muito menos gerentes de teste e equipes de teste menores, enquanto a pressão para enviar é muito maior (por causa da entrega instantânea). Todos podem ajudar a testar, entretanto, é preciso dedicação e foco para analisar a necessidade de testes e se preparar para fazer o que deve ser feito — encontrar todos os problemas que importam.
Avaliando a qualidade, não medindo.
Com a crescente preocupação do mercado em melhorar a qualidade dos produtos e sendo essencial na área de testes de software, James Bach nos faz refletir sobre: A qualidade pode ser medida? Como definir se um produto tem ou não qualidade?
É comum que haja uma distorção em que medição e qualidade sejam a mesma coisa, no entanto, James nos leva a refletir sobre a utilização da medição (ação ou efeito de medir, determinar o valor) no contexto de desenvolvimento de software, como por exemplo o ato de medir/contar os casos de testes, nos condiciona a julgar os inúmeros artefatos produzidos como se isso bastasse para garantir a qualidade.
O que nos leva a questionar se o desejo por medir a qualidade de um produto se dá diante da falsa sensação de que os números fazem com que os argumentos sejam mais objetivos, de forma que minimize a possibilidade de questionamentos ou julgamentos.
Apenas medir nos possibilita transformar “número ruim” em “números melhorados”, um exemplo é a contagem de bugs, pode-se dificultar o acesso aos usuários em relatar bugs refletindo em relatórios satisfatórios. Diante desse exemplo , fica nítido que somente a medição, é insuficiente para garantir a qualidade.
James Bach nos convida para uma mudança de mindset em vez de dizermos que medimos a qualidade, precisamos ter um olhar crítico, sendo assim, ele nos convida a avaliar a qualidade que engloba a discussão de evidências sendo elas: como testamos; o que encontramos; o que isso nos diz sobre o risco do negócio. Nessa perspectiva a medição é apenas um meio para avaliar, por isso, avalie a qualidade e não meça.
Desobstruindo o Bug na Pipeline
Para chegarmos a conclusão da qualidade de um produto, na fase de testes são encontrados muitos bugs que são relatados para posterior correção. Por isso, o testador deve identificar os bugs que realmente importam e impactam a performance de um produto. Segundo James Bach, o produto, o testador e o próprio processo de teste, podem ser considerados uma peneira com filtros diferentes que podem impedir que os bons bugs sejam relatados. Um bug é sempre uma relação entre um produto, pessoas e contexto.
A existência do bug não depende do seu conhecimento ou do que você vê — depende do produto em si, das pessoas que importam e do contexto em que operam.O trabalho do teste é explorar o status dessas coisas. A única maneira de encontrar bugs em código inacessível é por meio de análise estática (ou seja, métodos que não envolvem a execução de código).
Um bom teste é um processo de cobrir sistematicamente as várias superfícies do produto (funções, dados, configurações de plataforma, interfaces etc.) para maximizar a chance de identificar todos os bugs que importam.
James Bach, ao comparar automatização com exploração diz que “você literalmente não pode codificar todos os aspectos de uma automatização em que um produto pode ser comportar mal, e vai enlouquecer tentando, já que os humanos são menos confiáveis em fazer qualquer observação explícita, mas muito mais capazes de perceber coisas inesperadas” .
O valor que a autenticação humana traz — quando feita corretamente — é que você acredita que um relatório que não escreveu definitivamente vale a pena ler. Em seguida ele cita sobre o fenômeno conhecido como cegueira por desatenção, que acontece quando você está tentando prestar atenção a um fator em particular e então ignora outros fatores, por isso, seguir um procedimento de teste detalhado pode fazer com que você perca bugs importantes. Outro ponto que Bach menciona é que muitos testadores, com frequência, têm apenas uma compreensão superficial de como seus produtos funcionam.
Bach comenta sobre a síndrome da “caixa de dinheiro” que acontece quando o testador se sente intimidado por uma equipe de desenvolvimento ou gerentes irritados e não quer deixá-los chateados ou também pode acontecer quando os bugs são encontrados tão rapidamente que haverá perda do controle de alguns deles. Então ele menciona que queremos encontrar bugs que importam. E quando falhamos, o que costumamos fazer, aprendemos com isso e nos aprimoramos.
O presente resumo propôs realizar uma análise à literatura acerca dos três artigos publicados pelo autor James Bach, apresentando uma abordagem crítica nos seus estudos relacionados à área de teste de software. Neste texto foram apresentados sob a perspectiva do autor como decorreu o processo evolutivo da área nos seus últimos 34 anos de carreira, evidenciando de um lado tanto as atitudes dos testadores como também dos gerentes no mercado de teste de software.
Analisando os fatores condicionantes do desenvolvimento deste mercado, denotou-se que os gerentes pensam que os testes devem ser formalizados e automatizados, assim como não sabem e entendem o que os bons testadores fazem e sua importância no projeto.
Por outro lado, os testadores não fazem um esforço para aprender mais sobre a área e acabam por abandona-la. O lado positivo é que atualmente há muitos recursos disponíveis online para aqueles que querem aprender mais sobre testes.A qualidade tão esperada no mercado foi também apontada como uma temática que vai além do que usualmente as empresas praticam a avaliação dos seus produtos baseando-se em medições.
Numa tomada de decisões, nem todo o dado útil obtido tem que obrigatoriamente ser medido para chegar a conclusão de que um produto de software é bom ou não. Portanto, a qualidade do software deve incorporar também alternativamente a avaliação e discussão.
Finalmente e no que concerne aos relatórios de report de bugs, podemos concluir que os testes corretos são aqueles em que são encontrados bugs que realmente importam. Paralelamente, a este processo verificou-se que parte do teste é bem feita quando consideramos que o produto, o testador e o próprio processo de teste são filtros distintos que podem ser apontados como uma barreira para bons reports de bugs.
REFERÊNCIAS:
Artigo 1
BACH, James. 34 Years in Testing. Disponível em: https://www.satisfice.com/BLOG/ARCHIVES/487354. Acesso em: 29 de outubro de 2022.
Artigo 2
BACH, James. Assess Quality, Don’t Measure It. Software Testing Serious People. Disponível em: https://www-satisfice-com.translate.goog/blog/archives/487091?_x_tr_sl=en&_x_tr_tl=pt&_x_tr_hl=pt-BR&_x_tr_pto=wapp . Acesso em: 29 de outubro de 2022.
Artigo 3
BACH, James. Unclogging the Bug Pipeline. Disponível em: https://www.satisfice.com/blog/archives/487131. Acesso em: 29 de outubro de 2022.
