Testar a conformidade — ou a qualidade?

Discover how to deliver better software and systems in rapidly scaling environments. Join our Community

O mundo está repleto de software que cumpre perfeitamente todos os requisitos documentados, mas que ainda assim não consegue criar valor para os seus utilizadores. Quando estudei engenharia de software — há muito tempo — qualidade significava conformidade, ou seja, conformidade com os requisitos. Aprendi também que garantia da qualidade significa todas as medidas tomadas […]

O mundo está repleto de software que cumpre perfeitamente todos os requisitos documentados, mas que ainda assim não consegue criar valor para os seus utilizadores.

Quando estudei engenharia de software — há muito tempo — qualidade significava conformidade, ou seja, conformidade com os requisitos. Aprendi também que garantia da qualidade significa todas as medidas tomadas para permitir, criar e verificar a qualidade, e que os testes são um método fundamental de garantia da qualidade. 

Atualmente, a Wikipédia define testes como o ato de examinar os artefactos e o comportamento do software sob teste através de validação e verificação. Os testes são definidos como uma atividade, deixando o seu objetivo em aberto. As definições que aprendi na faculdade de engenharia são muito compatíveis com a definição de testes de conformidade da Wikipédia: testes que determinam se um processo, produto ou serviço está em conformidade com os requisitos de uma especificação, norma técnica, contrato ou regulamento. Curiosamente, nenhuma destas definições utiliza sequer a palavra qualidade . 

O que é a qualidade?

Hoje em dia, evito a tentação de definir qualidade, exceto indiretamente através de quatro dimensões: benefícios, funções, processo e experiência. Pensemos em algo que toda a gente conhece, por exemplo, o PayPal. As pessoas utilizam-no para transferir dinheiro online; essa é a sua função. Os benefícios que procuram são a facilidade, a segurança e o baixo custo. A utilização do PayPal envolve vários processos do utilizador, e o software orienta o utilizador ao longo deles. Os sentimentos, como felicidade, frustração ou sensação de realização, que o utilizador sente enquanto utiliza o PayPal constituem a experiência. Seja o que for a qualidade, dificilmente poderá existir sem todas estas quatro dimensões.

Os testes concentram-se normalmente na conformidade funcional, ou seja, na verificação de que o software faz aquilo que os seus requisitos estabelecem e não faz mais nada. Também pode haver requisitos não funcionais, como os tempos de resposta, o número de transações paralelas suportadas e a segurança dos dados do utilizador. As normas e os regulamentos, como a SOC2 ou o GDPR, introduzem requisitos adicionais, tal como os acordos do PayPal com as empresas de cartões de crédito. Estes podem ter pouco que ver com as funções reais e o valor do software, mas o seu cumprimento é um pré-requisito para entrar no negócio. 

A qualidade vai além da mera conformidade. Para alcançar ambos, consulte a nossa lista selecionada das principais plataformas de testes de software

O mundo ideal

Os bons testadores aplicam tanto uma perspetiva baseada na conformidade, que se concentra no cumprimento dos requisitos, como uma perspetiva baseada nos resultados, que se concentra na concretização dos benefícios. Num mundo ideal, o cumprimento dos requisitos documentados implicaria a concretização dos benefícios para o utilizador, mas o mundo raramente é ideal. Mesmo que o software fosse perfeito, os utilizadores não o são. A concretização dos benefícios depende em grande medida das ações do utilizador, e as ações do utilizador dependem da forma como o software interage com o utilizador e o orienta. Estas, por sua vez, afetam a qualidade da experiência como um todo. Estas características do software dificilmente podem ser captadas em requisitos de conformidade ou casos de teste formais. Mais uma vez, num mundo ideal, todos estes desafios seriam resolvidos suficientemente cedo através de um design centrado no utilizador — mas o mundo está longe de ser ideal, e um testador precisa de desempenhar o papel de representante do utilizador real.

Testes de conformidade vs. testes de resultados

Os testes de conformidade e os testes de resultados exigem mentalidades diferentes. Os testes de conformidade são como preparar armadilhas: ler os requisitos, imaginar o que pode correr mal e conceber condições de teste nas quais seja provável que o software falhe. Os testes baseados nos resultados são mais semelhantes a um ato de curiosidade: compreender aquilo que o utilizador precisa de concretizar, imaginar todas as ações que poderá realizar, perceber como o software deverá reagir e, depois, experimentá-lo. 

A conformidade é um pré-requisito da qualidade. Em muitos setores, o cumprimento dos requisitos formais de conformidade é inclusivamente um pré-requisito para participar no negócio. Também é possível mitigar os riscos de responsabilidade através da produção de uma prova documentada de que a conformidade foi devidamente testada. Costumo pensar que os testes de conformidade ajudam a reduzir o risco de falha e que os testes baseados nos resultados ajudam a aumentar a probabilidade de sucesso.

Esko Hannula
Esko Hannula is VP Product Line Management at Copado, a DevOps and testing solution for low code SaaS platforms that run the world’s largest digital transformations. Backed by Insight Partners, Salesforce Ventures and SoftBank Vision Fund, Copado accelerates multi-cloud, enterprise deployments by automating the end-to-end software delivery process to maximize customers’ return on their cloud investment.
Follow the author:

You may also like