O que é testar

Testar é avaliar um sistema, ou parte dele, para descobrir se ele atende aos requisitos especificados. Em outras palavras, é executar o software para encontrar lacunas, erros ou requisitos que faltam em relação ao que foi pedido. ^{[1] [2]}

A norma ANSI/IEEE 1059 define teste como o processo de analisar um item de software para detectar as diferenças entre as condições existentes e as exigidas, ou seja, os defeitos, e para avaliar as características desse item. ^[2] Glenford Myers resume a atitude certa numa frase: testar é executar um programa com a intenção de encontrar erros, e não para provar que ele funciona. ^[7]

Três palavras aparecem o tempo todo e vale separá-las desde já, como faz o glossário do ISTQB: ^[3]

• Erro (engano): a ação humana que produz um resultado incorreto, como interpretar mal um requisito.
• Defeito (bug): a imperfeição que esse erro deixa no código ou em um documento.
• Falha: o comportamento errado que aparece quando o código com defeito é executado.

Quem testa

Depende do processo e das pessoas envolvidas no projeto. Empresas maiores costumam ter uma equipe dedicada a avaliar o software diante dos requisitos, mas os desenvolvedores também testam: o teste que fazem no próprio código é o teste unitário. Em geral participam:

• testadores e analistas de qualidade (QA);
• desenvolvedores;
• líderes e gerentes de projeto;
• usuários finais.

Os cargos variam de empresa para empresa: testador, engenheiro de qualidade de software, analista de QA e outros.

Quando começar e quando parar

Comece o mais cedo possível

Começar cedo reduz o custo e o tempo de retrabalho. No ciclo de vida de desenvolvimento (SDLC), o teste pode começar já no levantamento de requisitos e seguir até a implantação. Barry Boehm mostrou que um defeito fica muito mais caro de corrigir quanto mais tarde é descoberto: o que se resolve com uma conversa na fase de requisitos pode exigir retrabalho em várias camadas quando aparece em produção. ^[5]

O momento também depende do modelo de desenvolvimento. No modelo cascata, o teste formal acontece na fase de testes; no modelo incremental, ao fim de cada iteração, e a aplicação inteira é testada no final. Em qualquer modelo, o teste aparece em formas diferentes ao longo do ciclo:

• na fase de requisitos, analisar e verificar os requisitos já é testar;
• na fase de projeto, revisar o desenho para melhorá-lo também é testar;
• ao terminar o código, o teste do desenvolvedor faz parte do processo.

Saiba quando parar

Nenhum software pode ser dado como 100% testado, por isso o teste nunca “acaba” de verdade. Como escreveu Edsger Dijkstra:

O teste de programas pode ser usado para mostrar a presença de bugs, mas nunca para mostrar a sua ausência.

Edsger W. Dijkstra, 1970 ^[6]

Na prática, decide-se parar com base em critérios combinados antes, os chamados critérios de saída:

• prazo de testes atingido;
• execução completa dos casos de teste planejados;
• cobertura funcional e de código acima de um patamar definido;
• taxa de defeitos abaixo de um limite e nenhum defeito de alta prioridade em aberto;
• decisão da gestão, com os riscos conhecidos.

Verificação e validação

Os dois termos costumam ser usados como sinônimos, mas respondem a perguntas diferentes. ^[8]

O modelo em V junta as duas ideias: cada etapa de especificação, no lado esquerdo, tem um nível de teste correspondente, no lado direito, planejado desde cedo. ^[9]

Mitos sobre testes

Algumas crenças sobre testes são tão repetidas que parecem verdade. Estas são as mais comuns, e o que acontece na realidade. ^[2]

• “Testar é caro demais”

  Realidade: ou se paga pouco para testar durante o desenvolvimento, ou se paga muito para corrigir depois. Cortar testes para economizar costuma sair mais caro.

• “Testar toma tempo demais”

  Realidade: o que consome tempo é diagnosticar e corrigir os defeitos encontrados, e esse tempo é produtivo.

• “Só se testa o produto pronto”

  Realidade: revisar requisitos e escrever casos de teste não depende do código. Modelos iterativos reduzem ainda mais essa dependência.

• “É possível testar tudo”

  Realidade: o número de combinações de entradas e caminhos é grande demais. Sempre haverá cenários que só aparecem em produção. ^[6]

• “Software testado não tem bugs”

  Realidade: ninguém pode garantir que um software está 100% livre de defeitos, por melhor que seja o testador.

• “Defeito que escapou é culpa do testador”

  Realidade: prazos, custos e requisitos que mudam pesam tanto quanto a estratégia de teste escolhida.

• “Qualidade é problema do testador”

  Realidade: o testador informa os defeitos; a decisão de corrigir ou lançar é dos responsáveis pelo produto. Qualidade é do time todo.

• “Automatize tudo o que der”

  Realidade: a automação economiza tempo, mas só compensa quando o software já está estável. Com requisitos mudando toda hora, o custo de manter os scripts dispara.

• “Qualquer um pode testar”

  Realidade: pensar em cenários alternativos e tentar quebrar o software exige técnica e criatividade. E quem escreveu o código é quem tem mais dificuldade de enxergar os próprios erros. ^[7]

• “Testador só acha bugs”

  Realidade: o testador conhece o sistema de ponta a ponta, as dependências e o impacto de um módulo sobre o outro, e isso o torna um especialista no domínio.

QA, QC e testes

Garantia da qualidade (QA), controle da qualidade (QC) e testes estão ligados, mas não são a mesma coisa. Uma forma simples de lembrar é pensar em círculos, um dentro do outro. ^[3]

Auditoria e inspeção

Auditoria é um exame sistemático e, em geral, independente de como o processo de teste é conduzido numa organização. Pelo IEEE, é a revisão dos processos documentados que a organização diz seguir. Pode ser de conformidade legal, interna ou de sistema.

Inspeção é uma técnica formal em que requisitos, projeto ou código são examinados em detalhe por pessoas que não são o autor, para encontrar defeitos e desvios de padrão. Uma inspeção formal tem planejamento, apresentação, preparação, reunião de inspeção, retrabalho e acompanhamento.

Teste e depuração

Teste identifica o defeito sem corrigi-lo. Depuração (debugging) é o trabalho do desenvolvedor de localizar a causa, isolá-la e corrigi-la. A depuração acontece durante o teste unitário ou quando se corrigem os defeitos relatados.

Normas ISO e IEEE

Várias normas ajudam a definir e medir a qualidade do software. Algumas das citadas com frequência já foram substituídas; as notas abaixo indicam a referência atual quando é o caso.

Modelos de qualidade

• ISO/IEC 9126 definia um modelo de qualidade com seis características: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. Foi substituída pela ISO/IEC 25010, que amplia o modelo e inclui, por exemplo, segurança e compatibilidade. ^[10]
• ISO/IEC 25000 (SQuaRE) organiza os requisitos e a avaliação da qualidade de software em divisões: gestão (2500n), modelo (2501n), medição (2502n), requisitos (2503n) e avaliação (2504n). Ela substituiu a ISO/IEC 9126 e a ISO/IEC 14598. ^[10]
• ISO 9241-11 define usabilidade como a medida em que um produto pode ser usado por certos usuários para atingir certos objetivos com eficácia, eficiência e satisfação, num contexto de uso específico. ^[11]
• ISO/IEC 12119 tratava de requisitos e de testes para pacotes de software entregues ao cliente. Hoje o tema está na ISO/IEC 25051.

Normas de processo e documentação

Para quem está começando, a série ISO/IEC/IEEE 29119 é o melhor ponto de partida: reúne conceitos, processos, documentação e técnicas de teste num só lugar. ^[4]

Teste manual e automatizado

Teste manual

No teste manual, o testador faz o papel do usuário final e usa o software sem scripts nem ferramentas de automação, procurando comportamentos inesperados. Ele segue planos, casos e cenários de teste para garantir a cobertura, e também pratica o teste exploratório: aprende sobre o sistema enquanto testa e decide o próximo passo com base no que acabou de ver.

Teste automatizado

Na automação, o testador escreve scripts e usa outro software para testar o produto. O ganho maior é repetir rápido e muitas vezes os mesmos cenários, como na regressão, e simular carga com muitos usuários. A automação aumenta a cobertura e a precisão e economiza tempo em relação ao teste manual repetitivo.

O que automatizar: fluxos críticos e muito usados, como login e cadastro; áreas acessadas por muitos usuários ao mesmo tempo; validações de campos; e integrações com banco de dados. Martin Fowler sugere a pirâmide de testes: muitos testes unitários, rápidos e baratos, na base; menos testes de serviço no meio; e poucos testes pela interface gráfica no topo, que são lentos e frágeis. ^[12]

Quando automatizar:

• projetos grandes e críticos;
• áreas que precisam ser testadas com frequência;
• requisitos que não mudam o tempo todo;
• testes de carga e desempenho com muitos usuários virtuais;
• software já estável no teste manual;
• tempo disponível para criar e manter os scripts.

Como automatizar, passo a passo:

1. identificar as áreas do software a automatizar;
2. escolher a ferramenta adequada;
3. escrever os scripts de teste;
4. montar as suítes de teste;
5. executar os scripts;
6. gerar os relatórios de resultado;
7. analisar os defeitos e problemas de desempenho encontrados.

Ferramentas

O texto original cita ferramentas clássicas como HP QuickTest Professional (hoje OpenText UFT), IBM Rational Functional Tester, SilkTest, TestComplete, WinRunner, LoadRunner, Visual Studio Test Professional e Watir. Hoje são muito usadas ferramentas abertas como Selenium e Playwright, para interface web, e Apache JMeter, para carga. ^[15]

Métodos: caixa preta, cinza e branca

Os métodos se diferenciam pelo quanto o testador conhece do funcionamento interno da aplicação. ^[7]

Caixa preta

O testador não conhece a arquitetura nem tem acesso ao código. Ele interage pela interface, fornece entradas e examina as saídas, sem saber como elas são processadas.

• Vantagens: serve bem para grandes volumes de código; não exige acesso ao código; separa a visão do usuário da visão do desenvolvedor; permite que muitos testadores, sem conhecer a linguagem ou a plataforma, testem a aplicação.
• Desvantagens: cobertura limitada aos cenários escolhidos; cobertura “às cegas”, sem mirar trechos de código mais sujeitos a erro; casos de teste difíceis de projetar sem uma boa especificação.

Caixa branca

Também chamada de caixa de vidro ou caixa aberta, é a investigação detalhada da lógica e da estrutura do código. O testador precisa olhar o código para descobrir qual trecho se comporta mal.

• Vantagens: facilita escolher os dados de teste mais eficazes; ajuda a otimizar o código e a remover linhas que escondem defeitos; permite cobertura máxima dos caminhos.
• Desvantagens: exige testadores com conhecimento técnico, o que aumenta o custo; é impossível percorrer todos os caminhos; depende de ferramentas especializadas, como analisadores de código e depuradores.

Caixa cinza

O testador tem conhecimento parcial do interior: acesso a documentos de projeto e ao banco de dados, mas não ao código. Com isso prepara dados e cenários melhores, principalmente em integrações, protocolos de comunicação e tipos de dados.

Comparação

Níveis e tipos funcionais

Os testes se dividem em dois grandes grupos: os funcionais, que verificam o que o sistema faz, e os não funcionais, que verificam como ele faz, como desempenho e segurança.

Teste funcional em cinco passos

O teste funcional é um teste de caixa preta baseado na especificação. Fornecem-se entradas e comparam-se as saídas com o que a funcionalidade deveria fazer:

1. definir a funcionalidade que a aplicação deve executar;
2. criar os dados de teste a partir da especificação;
3. definir a saída esperada para esses dados;
4. escrever os cenários e executar os casos de teste;
5. comparar os resultados obtidos com os esperados.

Teste unitário

Feito pelo desenvolvedor sobre cada unidade de código, antes de entregar a versão para a equipe de teste. O objetivo é isolar cada parte do programa e mostrar que ela está correta. Tem limites: não é possível avaliar todos os caminhos de execução, e em algum momento a unidade precisa ser integrada às demais.

Teste de integração

Testa partes combinadas da aplicação para ver se funcionam juntas. Há duas estratégias clássicas:

• De baixo para cima (bottom-up): começa pelas unidades e sobe para combinações cada vez maiores. Usa drivers, programas que chamam os módulos ainda sem “chefe”.
• De cima para baixo (top-down): começa pelos módulos de mais alto nível e desce. Usa stubs, versões simplificadas dos módulos inferiores que ainda não existem.

Teste de sistema

Testa o sistema inteiro, já integrado, num ambiente o mais parecido possível com o de produção. É o primeiro momento em que a aplicação é testada como um todo, tanto nos requisitos de negócio quanto na arquitetura. Costuma ser feito por uma equipe especializada.

Teste de regressão

Toda mudança pode afetar outras partes do sistema. O teste de regressão verifica se uma correção ou melhoria não quebrou algo que já funcionava. Ele reduz o risco das mudanças, aumenta a cobertura sem estourar o prazo e é o primeiro candidato à automação.

Teste de aceitação

Avalia se a aplicação atende à especificação e às necessidades do cliente, com cenários preparados antes. É feito pelo cliente ou pelos usuários, muitas vezes com apoio da equipe de QA, e pode ter efeito contratual ou legal. Não procura só erros de digitação ou de aparência, mas qualquer problema que impeça o uso real.

Alfa e beta

• Teste alfa: feito no ambiente de quem desenvolve, por usuários em potencial ou por uma equipe independente, antes de o produto sair de casa. Busca erros de texto, links quebrados, instruções confusas e desempenho em máquinas modestas.
• Teste beta: também chamado de pré-lançamento, é feito por uma amostra do público real, no ambiente dele. Os usuários instalam, usam e enviam feedback, e o time corrige antes do lançamento geral.

Testes não funcionais

Verificam atributos que não são funções do sistema, mas são igualmente importantes: desempenho, usabilidade, segurança e portabilidade, entre outros.

Desempenho

Procura gargalos, mais do que defeitos. As causas mais comuns de lentidão são atraso de rede, processamento no cliente, transações de banco de dados, balanceamento de carga entre servidores e renderização de dados. Os aspectos medidos são velocidade (tempo de resposta), capacidade, estabilidade e escalabilidade. Os dois subtipos mais conhecidos são carga e estresse.

• Teste de carga: aplica o volume de acessos e de dados esperado, em condições normais e de pico, para descobrir a capacidade máxima e o comportamento no horário de maior uso. Usa ferramentas que simulam usuários virtuais, como JMeter ou LoadRunner, com a quantidade aumentada aos poucos ou de uma vez. ^[15]
• Teste de estresse: leva o software a condições anormais, acima do limite ou tirando recursos, para achar o ponto de ruptura. Exemplos: derrubar e religar portas de rede, desligar e ligar o banco de dados, rodar processos que consomem CPU e memória.

Usabilidade

Técnica de caixa preta que observa usuários reais usando o software para encontrar erros e melhorias. Jakob Nielsen define usabilidade por cinco componentes: facilidade de aprendizado, eficiência de uso, facilidade de memorização, poucos erros e satisfação. ^[13] A ISO 9241-11 a mede por eficácia, eficiência e satisfação num contexto de uso. ^[11]

Interface × usabilidade: o teste de interface (UI) verifica se a tela está conforme o requisito, em cores, alinhamento e tamanhos. O de usabilidade verifica se ela é fácil de usar. O primeiro é uma parte do segundo.

Segurança

Procura falhas e brechas do ponto de vista de vulnerabilidades. Deve garantir confidencialidade, integridade, disponibilidade, autenticação, autorização e não repúdio, e verificar ataques conhecidos como injeção de SQL e outras injeções, falhas no gerenciamento de sessão, cross-site scripting (XSS), estouro de buffer e travessia de diretórios. O OWASP Top 10 é a referência mais usada para os riscos mais críticos de aplicações web. ^[14]

Portabilidade

Verifica se o software pode ser levado para outros ambientes: outro computador, outro sistema operacional, outro navegador. Pré-condições: o software foi projetado pensando em portabilidade, os testes unitário e de integração já foram feitos e o ambiente de teste está pronto.

Documentação de testes

Documentar ajuda a estimar o esforço, medir a cobertura e rastrear os requisitos. Os quatro artefatos mais usados se encaixam como na figura. ^[4]

Plano de teste

Descreve a estratégia, os recursos, o ambiente, as limitações e o cronograma dos testes. Em geral é escrito pelo líder de QA e inclui: introdução, premissas, casos de teste previstos, funcionalidades a testar, abordagem, entregáveis, recursos, riscos, e tarefas e marcos.

Cenário de teste

Uma frase que diz qual área da aplicação será testada, por exemplo “login do usuário”. Os cenários garantem que os fluxos sejam testados de ponta a ponta. Uma área pode ter de um a centenas de cenários. Um cenário reúne vários casos de teste e a ordem em que devem ser executados.

Caso de teste

Um conjunto de passos, condições e entradas para verificar se uma funcionalidade passa ou falha. Não há modelo oficial, mas estes campos quase sempre aparecem:

Vários casos de teste saem de um mesmo cenário, e um conjunto de casos forma uma suíte de testes.

Matriz de rastreabilidade

A matriz de rastreabilidade de requisitos (RTM) é uma tabela que liga cada requisito aos seus casos de teste e aos defeitos encontrados. Pode ser lida para a frente, do requisito ao teste, para saber se tudo foi testado, ou para trás, do defeito ao requisito, para achar a origem do problema. Serve para:

• garantir que o software foi feito conforme os requisitos;
• ajudar a encontrar a causa raiz de um defeito;
• rastrear os documentos ao longo das fases do ciclo de vida.

Estimativa do esforço

Estimar bem o esforço de teste é o que permite testar com a maior cobertura possível dentro do prazo. As técnicas mais conhecidas:

• Análise de pontos de função (APF): mede o tamanho funcional do software a partir de cinco elementos: saídas, consultas, entradas, arquivos internos e arquivos externos. É mantida pelo IFPUG. ^[16]
• Análise de pontos de teste (TPA): parte dos pontos de função para estimar testes de caixa preta e de aceitação, considerando tamanho, produtividade, estratégia, interfaces, complexidade e uniformidade. ^[18]
• Método Mark II: mede o tamanho do ponto de vista funcional do usuário final, contando transações lógicas. Os passos são: definir o ponto de vista, o propósito e o tipo de contagem; delimitar a fronteira; identificar as transações lógicas; classificar as entidades de dados; contar os elementos de entrada; e calcular o tamanho funcional. ^[17]
• Outras: técnica Delphi (consenso entre especialistas), estimativa por analogia com projetos anteriores, estimativa pela contagem de casos de teste e estimativa por tarefas.

Revisão rápida

Tente responder antes de abrir cada pergunta.

Referências

1. Giovani Perotto Mesquita, “Software Testing”, GitHub Gist, texto original deste tutorial, gist.github.com/GiovaniPM/65ee981f26194197f25e6cfa3b6ee859.
2. Tutorialspoint, “Software Testing Tutorial”, acesso em 25/09/2026, tutorialspoint.com/software_testing.
3. ISTQB, “Glossário de testes”, acesso em 25/09/2026, glossary.istqb.org.
4. Wikipedia (em inglês), “ISO/IEC 29119”, acesso em 25/09/2026, en.wikipedia.org/wiki/ISO/IEC_29119.
5. Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981.
6. Edsger W. Dijkstra, “Notes on Structured Programming” (EWD249), 1970, cs.utexas.edu/~EWD/ewd02xx/EWD249.PDF.
7. Glenford J. Myers, Corey Sandler e Tom Badgett, The Art of Software Testing, 3ª ed., Wiley, 2011.
8. Wikipedia (em inglês), “Verification and validation”, acesso em 25/09/2026, en.wikipedia.org/wiki/Verification_and_validation.
9. Wikipedia (em inglês), “V-model (software development)”, acesso em 25/09/2026, en.wikipedia.org/wiki/V-model_(software_development).
10. Wikipedia (em inglês), “ISO/IEC 25010”, acesso em 25/09/2026, en.wikipedia.org/wiki/ISO/IEC_25010.
11. Wikipedia (em inglês), “ISO 9241”, acesso em 25/09/2026, en.wikipedia.org/wiki/ISO_9241.
12. Martin Fowler, “Test Pyramid”, 2012, martinfowler.com/bliki/TestPyramid.html.
13. Jakob Nielsen, “Usability 101: Introduction to Usability”, Nielsen Norman Group, nngroup.com/articles/usability-101-introduction-to-usability.
14. OWASP, “OWASP Top Ten”, acesso em 25/09/2026, owasp.org/www-project-top-ten.
15. Ferramentas: Selenium, selenium.dev; Playwright, playwright.dev; Apache JMeter, jmeter.apache.org.
16. IFPUG, International Function Point Users Group, ifpug.org.
17. Charles R. Symons, “Function Point Analysis: Difficulties and Improvements”, IEEE Transactions on Software Engineering, v. 14, n. 1, 1988.
18. Martin Pol, Ruud Teunissen e Erik van Veenendaal, Software Testing: A Guide to the TMap Approach, Addison-Wesley, 2002.

What testing is

Testing is evaluating a system, or part of it, to find out whether it meets the specified requirements. In other words, it means running the software to find gaps, errors or missing requirements compared with what was asked for. ^{[1] [2]}

The ANSI/IEEE 1059 standard defines testing as the process of analyzing a software item to detect the differences between existing and required conditions, that is, defects, and to evaluate the features of that item. ^[2] Glenford Myers sums up the right attitude in one sentence: testing is running a program with the intent of finding errors, not to prove that it works. ^[7]

Three words come up all the time, and it helps to tell them apart from the start, as the ISTQB glossary does: ^[3]

• Error (mistake): the human action that produces an incorrect result, such as misreading a requirement.
• Defect (bug): the flaw that the error leaves in the code or in a document.
• Failure: the wrong behavior that shows up when the defective code runs.

Who tests

It depends on the process and on the people involved in the project. Larger companies usually have a team dedicated to evaluating the software against the requirements, but developers test too: the testing they do on their own code is unit testing. The usual participants are:

• testers and quality assurance (QA) analysts;
• developers;
• project leads and managers;
• end users.

Job titles vary from company to company: tester, software quality engineer, QA analyst and others.

When to start and when to stop

Start as early as possible

Starting early reduces the cost and time of rework. In the software development life cycle (SDLC), testing can begin as early as requirements gathering and continue until deployment. Barry Boehm showed that a defect becomes much more expensive to fix the later it is found: something solved with a conversation during requirements may require rework across several layers when it shows up in production. ^[5]

Timing also depends on the development model. In the waterfall model, formal testing happens in the testing phase; in the incremental model, at the end of each iteration, with the whole application tested at the end. In any model, testing takes different forms throughout the cycle:

• in the requirements phase, analyzing and verifying the requirements is already testing;
• in the design phase, reviewing the design to improve it is also testing;
• when the code is finished, the developer’s testing is part of the process.

Know when to stop

No software can be called 100% tested, so testing never truly “ends”. As Edsger Dijkstra wrote:

Program testing can be used to show the presence of bugs, but never to show their absence!

Edsger W. Dijkstra, 1970 ^[6]

In practice, the decision to stop is based on criteria agreed beforehand, the exit criteria:

• the testing deadline is reached;
• all planned test cases have been executed;
• functional and code coverage are above an agreed threshold;
• the defect rate is below a limit and no high-priority defect is open;
• a management decision, with the known risks.

Verification and validation

The two terms are often used as synonyms, but they answer different questions. ^[8]

The V-model brings both ideas together: each specification step, on the left, has a matching test level, on the right, planned early on. ^[9]

Testing myths

Some beliefs about testing are repeated so often that they sound true. These are the most common ones, and what really happens. ^[2]

• “Testing is too expensive”

  Reality: either you pay a little to test during development, or you pay a lot to fix things later. Cutting tests to save money usually costs more.

• “Testing takes too long”

  Reality: what takes time is diagnosing and fixing the defects found, and that time is productive.

• “Only finished products are tested”

  Reality: reviewing requirements and writing test cases do not depend on the code. Iterative models reduce that dependency even further.

• “Complete testing is possible”

  Reality: the number of input and path combinations is far too large. There will always be scenarios that only appear in production. ^[6]

• “Tested software is bug-free”

  Reality: no one can guarantee that software is 100% defect-free, however good the tester is.

• “Missed defects are the tester’s fault”

  Reality: deadlines, costs and changing requirements weigh as much as the chosen test strategy.

• “Quality is the tester’s problem”

  Reality: testers report defects; the decision to fix or release belongs to those responsible for the product. Quality belongs to the whole team.

• “Automate everything you can”

  Reality: automation saves time, but it only pays off once the software is stable. With requirements changing all the time, the cost of maintaining scripts soars.

• “Anyone can test”

  Reality: thinking of alternative scenarios and trying to break the software takes technique and creativity. And whoever wrote the code has the hardest time seeing their own mistakes. ^[7]

• “Testers only find bugs”

  Reality: testers know the system end to end, the dependencies and the impact of one module on another, which makes them domain experts.

QA, QC and testing

Quality assurance (QA), quality control (QC) and testing are related, but they are not the same thing. A simple way to remember is to picture circles, one inside the other. ^[3]

Audit and inspection

An audit is a systematic and usually independent examination of how the testing process is carried out in an organization. According to the IEEE, it is a review of the documented processes the organization says it follows. It can be a legal compliance, internal or system audit.

An inspection is a formal technique in which requirements, design or code are examined in detail by people other than the author, to find defects and deviations from standards. A formal inspection has planning, overview, preparation, the inspection meeting, rework and follow-up.

Testing and debugging

Testing identifies the defect without fixing it. Debugging is the developer’s work of locating the cause, isolating it and fixing it. Debugging happens during unit testing or when reported defects are fixed.

ISO and IEEE standards

Several standards help define and measure software quality. Some of the frequently quoted ones have already been replaced; the notes below point to the current reference where that applies.

Quality models

• ISO/IEC 9126 defined a quality model with six characteristics: functionality, reliability, usability, efficiency, maintainability and portability. It was replaced by ISO/IEC 25010, which extends the model and adds, for example, security and compatibility. ^[10]
• ISO/IEC 25000 (SQuaRE) organizes software quality requirements and evaluation into divisions: management (2500n), model (2501n), measurement (2502n), requirements (2503n) and evaluation (2504n). It replaced ISO/IEC 9126 and ISO/IEC 14598. ^[10]
• ISO 9241-11 defines usability as the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. ^[11]
• ISO/IEC 12119 covered requirements and testing for software packages delivered to the client. The topic now lives in ISO/IEC 25051.

Process and documentation standards

For beginners, the ISO/IEC/IEEE 29119 series is the best starting point: it gathers testing concepts, processes, documentation and techniques in one place. ^[4]

Manual and automated testing

Manual testing

In manual testing, the tester plays the end user and uses the software without scripts or automation tools, looking for unexpected behavior. They follow test plans, cases and scenarios to ensure coverage, and also practice exploratory testing: learning about the system while testing it and choosing the next step based on what they have just seen.

Automated testing

In automation, the tester writes scripts and uses another piece of software to test the product. The main gain is repeating the same scenarios quickly and often, as in regression, and simulating load with many users. Automation increases coverage and accuracy and saves time compared with repetitive manual testing.

What to automate: critical, heavily used flows such as login and sign-up; areas accessed by many users at once; field validations; and database integrations. Martin Fowler suggests the test pyramid: many fast, cheap unit tests at the base; fewer service tests in the middle; and a few graphical interface tests at the top, which are slow and brittle. ^[12]

When to automate:

• large, critical projects;
• areas that need frequent testing;
• requirements that do not change all the time;
• load and performance tests with many virtual users;
• software that is already stable under manual testing;
• time available to create and maintain the scripts.

How to automate, step by step:

1. identify the areas of the software to automate;
2. choose the right tool;
3. write the test scripts;
4. build the test suites;
5. run the scripts;
6. produce the result reports;
7. analyze the defects and performance issues found.

Tools

The original text lists classic tools such as HP QuickTest Professional (now OpenText UFT), IBM Rational Functional Tester, SilkTest, TestComplete, WinRunner, LoadRunner, Visual Studio Test Professional and Watir. Today, open-source tools such as Selenium and Playwright are widely used for web interfaces, and Apache JMeter for load. ^[15]

Methods: black, grey and white box

The methods differ in how much the tester knows about the inner workings of the application. ^[7]

Black box

The tester does not know the architecture and has no access to the code. They interact through the interface, provide inputs and examine outputs without knowing how those are processed.

• Advantages: works well for large amounts of code; does not require code access; separates the user’s view from the developer’s view; lets many testers, without knowing the language or platform, test the application.
• Disadvantages: coverage limited to the chosen scenarios; “blind” coverage, unable to target error-prone code; test cases are hard to design without a good specification.

White box

Also called glass box or open box, it is the detailed investigation of the logic and structure of the code. The tester needs to look at the code to find out which part misbehaves.

• Advantages: makes it easier to choose the most effective test data; helps optimize the code and remove lines that hide defects; allows maximum path coverage.
• Disadvantages: requires technically skilled testers, which raises the cost; it is impossible to go through every path; depends on specialized tools such as code analyzers and debuggers.

Grey box

The tester has partial knowledge of the inside: access to design documents and to the database, but not to the code. This allows better data and scenarios, especially for integrations, communication protocols and data types.

Comparison

Levels and functional types

Tests fall into two broad groups: functional tests, which check what the system does, and non-functional tests, which check how it does it, such as performance and security.

Functional testing in five steps

Functional testing is black-box testing based on the specification. Inputs are provided and outputs are compared with what the feature should do:

1. define the functionality the application must perform;
2. create test data from the specification;
3. define the expected output for that data;
4. write the scenarios and run the test cases;
5. compare the actual results with the expected ones.

Unit testing

Done by the developer on each unit of code, before the build is handed over to the test team. The goal is to isolate each part of the program and show that it is correct. It has limits: not every execution path can be evaluated, and at some point the unit has to be integrated with the others.

Integration testing

Tests combined parts of the application to see whether they work together. There are two classic strategies:

• Bottom-up: starts with the units and moves up to ever larger combinations. It uses drivers, programs that call modules that do not yet have a “boss”.
• Top-down: starts with the highest-level modules and moves down. It uses stubs, simplified versions of lower modules that do not exist yet.

System testing

Tests the whole, integrated system in an environment as close as possible to production. It is the first time the application is tested as a whole, both for business requirements and for architecture. It is usually done by a specialized team.

Regression testing

Any change can affect other parts of the system. Regression testing checks that a fix or improvement did not break something that already worked. It reduces the risk of changes, increases coverage without blowing the schedule and is the first candidate for automation.

Acceptance testing

Evaluates whether the application meets the specification and the client’s needs, using scenarios prepared in advance. It is done by the client or the users, often with support from the QA team, and may have contractual or legal effect. It looks not only for typos or cosmetic errors, but for any problem that prevents real use.

Alpha and beta

• Alpha testing: done in the developer’s environment, by potential users or an independent team, before the product leaves the building. It looks for text errors, broken links, confusing instructions and performance on modest machines.
• Beta testing: also called pre-release testing, it is done by a sample of the real audience, in their own environment. Users install it, use it and send feedback, and the team fixes issues before the general release.

Non-functional testing

These tests check attributes that are not functions of the system but are just as important: performance, usability, security and portability, among others.

Performance

Looks for bottlenecks rather than bugs. The most common causes of slowness are network delay, client-side processing, database transactions, load balancing between servers and data rendering. The aspects measured are speed (response time), capacity, stability and scalability. The two best-known subtypes are load and stress.

• Load testing: applies the expected volume of access and data, under normal and peak conditions, to find the maximum capacity and the behavior at the busiest times. It uses tools that simulate virtual users, such as JMeter or LoadRunner, with the number increased gradually or all at once. ^[15]
• Stress testing: pushes the software into abnormal conditions, beyond the limit or by taking resources away, to find the breaking point. Examples: shutting down and restarting network ports, turning the database off and on, running processes that consume CPU and memory.

Usability

A black-box technique that watches real users working with the software to find errors and improvements. Jakob Nielsen defines usability by five components: learnability, efficiency, memorability, few errors and satisfaction. ^[13] ISO 9241-11 measures it by effectiveness, efficiency and satisfaction in a context of use. ^[11]

UI × usability: user interface (UI) testing checks that the screen matches the requirement in colors, alignment and sizes. Usability testing checks that it is easy to use. The first is part of the second.

Security

Looks for flaws and gaps from a vulnerability point of view. It must ensure confidentiality, integrity, availability, authentication, authorization and non-repudiation, and check known attacks such as SQL and other injections, session management flaws, cross-site scripting (XSS), buffer overflows and directory traversal. The OWASP Top 10 is the most widely used reference for the most critical web application risks. ^[14]

Portability

Checks whether the software can be moved to other environments: another computer, another operating system, another browser. Preconditions: the software was designed with portability in mind, unit and integration testing are done and the test environment is ready.

Test documentation

Documentation helps estimate effort, measure coverage and trace requirements. The four most used artifacts fit together as shown in the figure. ^[4]

Test plan

Describes the strategy, resources, environment, limitations and schedule of the tests. It is usually written by the QA lead and includes: introduction, assumptions, planned test cases, features to test, approach, deliverables, resources, risks, and tasks and milestones.

Test scenario

A one-line statement of which area of the application will be tested, for example “user login”. Scenarios ensure that flows are tested end to end. An area can have from one to hundreds of scenarios. A scenario groups several test cases and the order in which they must run.

Test case

A set of steps, conditions and inputs to check whether a feature passes or fails. There is no official template, but these fields almost always appear:

Several test cases come from the same scenario, and a set of cases forms a test suite.

Traceability matrix

The requirements traceability matrix (RTM) is a table that links each requirement to its test cases and to the defects found. It can be read forward, from requirement to test, to know whether everything was tested, or backward, from defect to requirement, to find the origin of the problem. It helps to:

• ensure the software was built according to the requirements;
• find the root cause of a defect;
• trace documents across the phases of the life cycle.

Effort estimation

Estimating test effort well is what makes it possible to test with the greatest coverage within the deadline. The best-known techniques:

• Function point analysis (FPA): measures the functional size of the software from five elements: outputs, inquiries, inputs, internal files and external files. It is maintained by IFPUG. ^[16]
• Test point analysis (TPA): builds on function points to estimate black-box and acceptance testing, considering size, productivity, strategy, interfacing, complexity and uniformity. ^[18]
• Mark II method: measures size from the end user’s functional view, counting logical transactions. The steps are: define the viewpoint, purpose and type of count; set the boundary; identify the logical transactions; classify the data entity types; count the input data element types; and calculate the functional size. ^[17]
• Others: the Delphi technique (consensus among experts), analogy-based estimation from past projects, estimation by test case enumeration and task-based estimation.

Quick review

Try to answer before opening each question.

References

1. Giovani Perotto Mesquita, “Software Testing”, GitHub Gist, original text of this tutorial, gist.github.com/GiovaniPM/65ee981f26194197f25e6cfa3b6ee859.
2. Tutorialspoint, “Software Testing Tutorial”, accessed 25 September 2026, tutorialspoint.com/software_testing.
3. ISTQB, “Glossary of testing terms”, accessed 25 September 2026, glossary.istqb.org.
4. Wikipedia, “ISO/IEC 29119”, accessed 25 September 2026, en.wikipedia.org/wiki/ISO/IEC_29119.
5. Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981.
6. Edsger W. Dijkstra, “Notes on Structured Programming” (EWD249), 1970, cs.utexas.edu/~EWD/ewd02xx/EWD249.PDF.
7. Glenford J. Myers, Corey Sandler and Tom Badgett, The Art of Software Testing, 3rd ed., Wiley, 2011.
8. Wikipedia, “Verification and validation”, accessed 25 September 2026, en.wikipedia.org/wiki/Verification_and_validation.
9. Wikipedia, “V-model (software development)”, accessed 25 September 2026, en.wikipedia.org/wiki/V-model_(software_development).
10. Wikipedia, “ISO/IEC 25010”, accessed 25 September 2026, en.wikipedia.org/wiki/ISO/IEC_25010.
11. Wikipedia, “ISO 9241”, accessed 25 September 2026, en.wikipedia.org/wiki/ISO_9241.
12. Martin Fowler, “Test Pyramid”, 2012, martinfowler.com/bliki/TestPyramid.html.
13. Jakob Nielsen, “Usability 101: Introduction to Usability”, Nielsen Norman Group, nngroup.com/articles/usability-101-introduction-to-usability.
14. OWASP, “OWASP Top Ten”, accessed 25 September 2026, owasp.org/www-project-top-ten.
15. Tools: Selenium, selenium.dev; Playwright, playwright.dev; Apache JMeter, jmeter.apache.org.
16. IFPUG, International Function Point Users Group, ifpug.org.
17. Charles R. Symons, “Function Point Analysis: Difficulties and Improvements”, IEEE Transactions on Software Engineering, vol. 14, no. 1, 1988.
18. Martin Pol, Ruud Teunissen and Erik van Veenendaal, Software Testing: A Guide to the TMap Approach, Addison-Wesley, 2002.

Cos’è testare

Testare significa valutare un sistema, o una sua parte, per scoprire se soddisfa i requisiti specificati. In altre parole, significa eseguire il software per trovare lacune, errori o requisiti mancanti rispetto a quanto richiesto. ^{[1] [2]}

La norma ANSI/IEEE 1059 definisce il test come il processo di analisi di un elemento software per rilevare le differenze tra le condizioni esistenti e quelle richieste, cioè i difetti, e per valutarne le caratteristiche. ^[2] Glenford Myers riassume l’atteggiamento giusto in una frase: testare è eseguire un programma con l’intenzione di trovare errori, non per dimostrare che funziona. ^[7]

Tre parole ricorrono di continuo, ed è utile distinguerle fin da subito, come fa il glossario ISTQB: ^[3]

• Errore (sbaglio): l’azione umana che produce un risultato scorretto, come interpretare male un requisito.
• Difetto (bug): l’imperfezione che quell’errore lascia nel codice o in un documento.
• Malfunzionamento: il comportamento sbagliato che appare quando il codice difettoso viene eseguito.

Chi testa

Dipende dal processo e dalle persone coinvolte nel progetto. Le aziende più grandi hanno di solito un team dedicato a valutare il software rispetto ai requisiti, ma anche gli sviluppatori testano: il test che fanno sul proprio codice è il test di unità. Di solito partecipano:

• tester e analisti di qualità (QA);
• sviluppatori;
• capi progetto e manager;
• utenti finali.

I ruoli cambiano da azienda ad azienda: tester, ingegnere della qualità del software, analista QA e altri.

Quando iniziare e quando fermarsi

Iniziare il prima possibile

Iniziare presto riduce il costo e il tempo delle rilavorazioni. Nel ciclo di vita dello sviluppo (SDLC), il test può cominciare già dalla raccolta dei requisiti e proseguire fino al rilascio. Barry Boehm ha mostrato che un difetto costa molto di più da correggere quanto più tardi viene scoperto: ciò che si risolve con una conversazione nella fase dei requisiti può richiedere rilavorazioni su più livelli quando emerge in produzione. ^[5]

Il momento dipende anche dal modello di sviluppo. Nel modello a cascata il test formale avviene nella fase di test; nel modello incrementale, alla fine di ogni iterazione, e l’intera applicazione viene testata alla fine. In qualsiasi modello, il test assume forme diverse lungo il ciclo:

• nella fase dei requisiti, analizzare e verificare i requisiti è già testare;
• nella fase di progettazione, rivedere il progetto per migliorarlo è anch’esso testare;
• a codice finito, il test dello sviluppatore fa parte del processo.

Sapere quando fermarsi

Nessun software può dirsi testato al 100%, quindi il test non “finisce” mai davvero. Come scrisse Edsger Dijkstra:

Il test dei programmi può servire a mostrare la presenza di bug, ma mai a mostrarne l’assenza.

Edsger W. Dijkstra, 1970 ^[6]

In pratica si decide di fermarsi in base a criteri concordati prima, i cosiddetti criteri di uscita:

• scadenza del test raggiunta;
• esecuzione completa dei casi di test pianificati;
• copertura funzionale e del codice sopra una soglia stabilita;
• tasso di difetti sotto un limite e nessun difetto ad alta priorità aperto;
• decisione della direzione, con i rischi noti.

Verifica e validazione

I due termini sono spesso usati come sinonimi, ma rispondono a domande diverse. ^[8]

Il modello a V unisce le due idee: ogni fase di specifica, sul lato sinistro, ha un livello di test corrispondente, sul lato destro, pianificato in anticipo. ^[9]

Miti sul test

Alcune convinzioni sul test sono ripetute così spesso da sembrare vere. Ecco le più comuni, e cosa succede nella realtà. ^[2]

• “Testare costa troppo”

  Realtà: o si paga poco per testare durante lo sviluppo, o si paga molto per correggere dopo. Tagliare i test per risparmiare di solito costa di più.

• “Testare richiede troppo tempo”

  Realtà: ciò che richiede tempo è diagnosticare e correggere i difetti trovati, ed è tempo produttivo.

• “Si testa solo il prodotto finito”

  Realtà: rivedere i requisiti e scrivere i casi di test non dipende dal codice. I modelli iterativi riducono ancora di più questa dipendenza.

• “Si può testare tutto”

  Realtà: il numero di combinazioni di input e percorsi è troppo grande. Ci saranno sempre scenari che emergono solo in produzione. ^[6]

• “Il software testato non ha bug”

  Realtà: nessuno può garantire che un software sia privo di difetti al 100%, per quanto bravo sia il tester.

• “Il difetto sfuggito è colpa del tester”

  Realtà: scadenze, costi e requisiti che cambiano pesano quanto la strategia di test scelta.

• “La qualità è un problema del tester”

  Realtà: il tester segnala i difetti; la decisione di correggere o rilasciare spetta ai responsabili del prodotto. La qualità è di tutto il team.

• “Automatizza tutto il possibile”

  Realtà: l’automazione fa risparmiare tempo, ma conviene solo quando il software è già stabile. Con requisiti che cambiano di continuo, il costo di manutenzione degli script esplode.

• “Chiunque può testare”

  Realtà: immaginare scenari alternativi e cercare di rompere il software richiede tecnica e creatività. E chi ha scritto il codice è quello che fa più fatica a vedere i propri errori. ^[7]

• “Il tester trova solo bug”

  Realtà: il tester conosce il sistema da cima a fondo, le dipendenze e l’impatto di un modulo sull’altro, e questo lo rende un esperto del dominio.

QA, QC e test

Assicurazione della qualità (QA), controllo della qualità (QC) e test sono collegati, ma non sono la stessa cosa. Un modo semplice per ricordarlo è pensare a cerchi, uno dentro l’altro. ^[3]

Audit e ispezione

L’audit è un esame sistematico e, di solito, indipendente di come si svolge il processo di test in un’organizzazione. Secondo l’IEEE, è la revisione dei processi documentati che l’organizzazione dichiara di seguire. Può essere di conformità legale, interno o di sistema.

L’ispezione è una tecnica formale in cui requisiti, progetto o codice vengono esaminati in dettaglio da persone diverse dall’autore, per trovare difetti e scostamenti dagli standard. Un’ispezione formale prevede pianificazione, presentazione, preparazione, riunione di ispezione, rilavorazione e verifica finale.

Test e debugging

Il test individua il difetto senza correggerlo. Il debugging è il lavoro dello sviluppatore per localizzare la causa, isolarla e correggerla. Il debugging avviene durante il test di unità o quando si correggono i difetti segnalati.

Norme ISO e IEEE

Diverse norme aiutano a definire e misurare la qualità del software. Alcune di quelle citate spesso sono già state sostituite; le note qui sotto indicano il riferimento attuale quando serve.

Modelli di qualità

• ISO/IEC 9126 definiva un modello di qualità con sei caratteristiche: funzionalità, affidabilità, usabilità, efficienza, manutenibilità e portabilità. È stata sostituita dalla ISO/IEC 25010, che amplia il modello e aggiunge, per esempio, sicurezza e compatibilità. ^[10]
• ISO/IEC 25000 (SQuaRE) organizza i requisiti e la valutazione della qualità del software in divisioni: gestione (2500n), modello (2501n), misurazione (2502n), requisiti (2503n) e valutazione (2504n). Ha sostituito la ISO/IEC 9126 e la ISO/IEC 14598. ^[10]
• ISO 9241-11 definisce l’usabilità come il grado in cui un prodotto può essere usato da utenti specifici per raggiungere obiettivi specifici con efficacia, efficienza e soddisfazione, in un determinato contesto d’uso. ^[11]
• ISO/IEC 12119 trattava requisiti e test dei pacchetti software consegnati al cliente. Oggi il tema è nella ISO/IEC 25051.

Norme di processo e documentazione

Per chi comincia, la serie ISO/IEC/IEEE 29119 è il punto di partenza migliore: riunisce concetti, processi, documentazione e tecniche di test in un unico posto. ^[4]

Test manuale e automatizzato

Test manuale

Nel test manuale il tester fa la parte dell’utente finale e usa il software senza script né strumenti di automazione, cercando comportamenti inattesi. Segue piani, casi e scenari di test per garantire la copertura, e pratica anche il test esplorativo: impara il sistema mentre lo testa e decide il passo successivo in base a ciò che ha appena visto.

Test automatizzato

Nell’automazione il tester scrive script e usa un altro software per testare il prodotto. Il guadagno principale è ripetere in fretta e spesso gli stessi scenari, come nella regressione, e simulare carico con molti utenti. L’automazione aumenta copertura e precisione e fa risparmiare tempo rispetto al test manuale ripetitivo.

Cosa automatizzare: flussi critici e molto usati, come login e registrazione; aree usate da molti utenti contemporaneamente; validazioni dei campi; e integrazioni con il database. Martin Fowler propone la piramide dei test: molti test di unità, veloci ed economici, alla base; meno test di servizio nel mezzo; e pochi test dall’interfaccia grafica in cima, che sono lenti e fragili. ^[12]

Quando automatizzare:

• progetti grandi e critici;
• aree da testare di frequente;
• requisiti che non cambiano di continuo;
• test di carico e prestazioni con molti utenti virtuali;
• software già stabile nel test manuale;
• tempo disponibile per creare e mantenere gli script.

Come automatizzare, passo per passo:

1. individuare le aree del software da automatizzare;
2. scegliere lo strumento adatto;
3. scrivere gli script di test;
4. costruire le suite di test;
5. eseguire gli script;
6. produrre i report dei risultati;
7. analizzare i difetti e i problemi di prestazioni trovati.

Strumenti

Il testo originale cita strumenti classici come HP QuickTest Professional (oggi OpenText UFT), IBM Rational Functional Tester, SilkTest, TestComplete, WinRunner, LoadRunner, Visual Studio Test Professional e Watir. Oggi sono molto usati strumenti open source come Selenium e Playwright, per le interfacce web, e Apache JMeter, per il carico. ^[15]

Metodi: scatola nera, grigia e bianca

I metodi si distinguono per quanto il tester conosce del funzionamento interno dell’applicazione. ^[7]

Scatola nera

Il tester non conosce l’architettura e non ha accesso al codice. Interagisce tramite l’interfaccia, fornisce input ed esamina gli output, senza sapere come vengono elaborati.

• Vantaggi: adatto a grandi quantità di codice; non richiede accesso al codice; separa la visione dell’utente da quella dello sviluppatore; permette a molti tester, senza conoscere linguaggio o piattaforma, di testare l’applicazione.
• Svantaggi: copertura limitata agli scenari scelti; copertura “alla cieca”, senza poter puntare alle parti di codice più soggette a errori; casi di test difficili da progettare senza una buona specifica.

Scatola bianca

Chiamato anche scatola di vetro o scatola aperta, è l’analisi dettagliata della logica e della struttura del codice. Il tester deve guardare il codice per scoprire quale parte si comporta male.

• Vantaggi: facilita la scelta dei dati di test più efficaci; aiuta a ottimizzare il codice e a togliere righe che nascondono difetti; permette la massima copertura dei percorsi.
• Svantaggi: richiede tester con competenze tecniche, il che aumenta il costo; è impossibile percorrere tutti i percorsi; dipende da strumenti specializzati, come analizzatori di codice e debugger.

Scatola grigia

Il tester ha una conoscenza parziale dell’interno: accesso ai documenti di progetto e al database, ma non al codice. Così prepara dati e scenari migliori, soprattutto per integrazioni, protocolli di comunicazione e tipi di dati.

Confronto

Livelli e tipi funzionali

I test si dividono in due grandi gruppi: quelli funzionali, che verificano cosa fa il sistema, e quelli non funzionali, che verificano come lo fa, come prestazioni e sicurezza.

Il test funzionale in cinque passi

Il test funzionale è un test a scatola nera basato sulla specifica. Si forniscono input e si confrontano gli output con ciò che la funzionalità dovrebbe fare:

1. definire la funzionalità che l’applicazione deve svolgere;
2. creare i dati di test a partire dalla specifica;
3. definire l’output atteso per quei dati;
4. scrivere gli scenari ed eseguire i casi di test;
5. confrontare i risultati ottenuti con quelli attesi.

Test di unità

Fatto dallo sviluppatore su ogni unità di codice, prima di consegnare la versione al team di test. L’obiettivo è isolare ogni parte del programma e mostrare che è corretta. Ha dei limiti: non si possono valutare tutti i percorsi di esecuzione, e prima o poi l’unità va integrata con le altre.

Test di integrazione

Testa parti combinate dell’applicazione per vedere se funzionano insieme. Esistono due strategie classiche:

• Dal basso verso l’alto (bottom-up): parte dalle unità e sale verso combinazioni sempre più grandi. Usa i driver, programmi che chiamano i moduli ancora senza “capo”.
• Dall’alto verso il basso (top-down): parte dai moduli di livello più alto e scende. Usa gli stub, versioni semplificate dei moduli inferiori che ancora non esistono.

Test di sistema

Testa l’intero sistema, già integrato, in un ambiente il più possibile simile alla produzione. È il primo momento in cui l’applicazione viene testata nel suo insieme, sia nei requisiti di business sia nell’architettura. Di solito lo fa un team specializzato.

Test di regressione

Ogni modifica può influire su altre parti del sistema. Il test di regressione verifica che una correzione o un miglioramento non abbia rotto qualcosa che già funzionava. Riduce il rischio delle modifiche, aumenta la copertura senza sforare i tempi ed è il primo candidato all’automazione.

Test di accettazione

Valuta se l’applicazione rispetta la specifica e i bisogni del cliente, con scenari preparati in anticipo. Lo fanno il cliente o gli utenti, spesso con il supporto del team QA, e può avere valore contrattuale o legale. Non cerca solo refusi o difetti estetici, ma qualsiasi problema che impedisca l’uso reale.

Alfa e beta

• Test alfa: fatto nell’ambiente di chi sviluppa, da potenziali utenti o da un team indipendente, prima che il prodotto esca. Cerca errori nei testi, link rotti, istruzioni confuse e prestazioni su macchine modeste.
• Test beta: detto anche pre-rilascio, è fatto da un campione del pubblico reale, nel proprio ambiente. Gli utenti installano, usano e inviano feedback, e il team corregge prima del rilascio generale.

Test non funzionali

Verificano attributi che non sono funzioni del sistema ma sono altrettanto importanti: prestazioni, usabilità, sicurezza e portabilità, tra gli altri.

Prestazioni

Cerca colli di bottiglia più che difetti. Le cause più comuni di lentezza sono ritardi di rete, elaborazione lato client, transazioni sul database, bilanciamento del carico tra server e rendering dei dati. Gli aspetti misurati sono velocità (tempo di risposta), capacità, stabilità e scalabilità. I due sottotipi più noti sono carico e stress.

• Test di carico: applica il volume di accessi e di dati previsto, in condizioni normali e di picco, per scoprire la capacità massima e il comportamento nelle ore di maggiore uso. Usa strumenti che simulano utenti virtuali, come JMeter o LoadRunner, aumentandone il numero gradualmente o tutto insieme. ^[15]
• Test di stress: porta il software in condizioni anomale, oltre il limite o sottraendo risorse, per trovare il punto di rottura. Esempi: chiudere e riaprire porte di rete, spegnere e riaccendere il database, avviare processi che consumano CPU e memoria.

Usabilità

Tecnica a scatola nera che osserva utenti reali mentre usano il software per trovare errori e miglioramenti. Jakob Nielsen definisce l’usabilità con cinque componenti: facilità di apprendimento, efficienza d’uso, facilità di memorizzazione, pochi errori e soddisfazione. ^[13] La ISO 9241-11 la misura con efficacia, efficienza e soddisfazione in un contesto d’uso. ^[11]

Interfaccia × usabilità: il test dell’interfaccia (UI) verifica che la schermata rispetti il requisito in colori, allineamento e dimensioni. Quello di usabilità verifica che sia facile da usare. Il primo è una parte del secondo.

Sicurezza

Cerca falle e lacune dal punto di vista delle vulnerabilità. Deve garantire riservatezza, integrità, disponibilità, autenticazione, autorizzazione e non ripudio, e verificare attacchi noti come SQL injection e altre iniezioni, falle nella gestione della sessione, cross-site scripting (XSS), buffer overflow e directory traversal. L’OWASP Top 10 è il riferimento più usato per i rischi più critici delle applicazioni web. ^[14]

Portabilità

Verifica se il software può essere portato in altri ambienti: un altro computer, un altro sistema operativo, un altro browser. Precondizioni: il software è stato progettato pensando alla portabilità, i test di unità e di integrazione sono stati fatti e l’ambiente di test è pronto.

Documentazione dei test

Documentare aiuta a stimare l’impegno, misurare la copertura e tracciare i requisiti. I quattro artefatti più usati si incastrano come nella figura. ^[4]

Piano di test

Descrive strategia, risorse, ambiente, limiti e calendario dei test. Di solito lo scrive il responsabile QA e comprende: introduzione, ipotesi, casi di test previsti, funzionalità da testare, approccio, deliverable, risorse, rischi, e attività e traguardi.

Scenario di test

Una frase che indica quale area dell’applicazione verrà testata, per esempio “login dell’utente”. Gli scenari garantiscono che i flussi siano testati da capo a fondo. Un’area può avere da uno a centinaia di scenari. Uno scenario raggruppa più casi di test e l’ordine in cui vanno eseguiti.

Caso di test

Un insieme di passi, condizioni e input per verificare se una funzionalità passa o fallisce. Non esiste un modello ufficiale, ma questi campi compaiono quasi sempre:

Da uno stesso scenario nascono più casi di test, e un insieme di casi forma una suite di test.

Matrice di tracciabilità

La matrice di tracciabilità dei requisiti (RTM) è una tabella che collega ogni requisito ai suoi casi di test e ai difetti trovati. Si può leggere in avanti, dal requisito al test, per sapere se è stato testato tutto, o all’indietro, dal difetto al requisito, per trovare l’origine del problema. Serve a:

• garantire che il software sia stato fatto secondo i requisiti;
• trovare la causa radice di un difetto;
• tracciare i documenti nelle varie fasi del ciclo di vita.

Stima dell’impegno

Stimare bene l’impegno di test è ciò che permette di testare con la massima copertura entro la scadenza. Le tecniche più note:

• Analisi dei punti funzione (FPA): misura la dimensione funzionale del software a partire da cinque elementi: output, interrogazioni, input, file interni e file esterni. È curata dall’IFPUG. ^[16]
• Analisi dei punti di test (TPA): parte dai punti funzione per stimare i test a scatola nera e di accettazione, considerando dimensione, produttività, strategia, interfacce, complessità e uniformità. ^[18]
• Metodo Mark II: misura la dimensione dal punto di vista funzionale dell’utente finale, contando le transazioni logiche. I passi sono: definire il punto di vista, lo scopo e il tipo di conteggio; delimitare il confine; individuare le transazioni logiche; classificare le entità di dati; contare gli elementi di input; e calcolare la dimensione funzionale. ^[17]
• Altre: tecnica Delphi (consenso tra esperti), stima per analogia con progetti precedenti, stima per conteggio dei casi di test e stima per attività.

Ripasso veloce

Prova a rispondere prima di aprire ogni domanda.

Riferimenti

1. Giovani Perotto Mesquita, “Software Testing”, GitHub Gist, testo originale di questo tutorial, gist.github.com/GiovaniPM/65ee981f26194197f25e6cfa3b6ee859.
2. Tutorialspoint, “Software Testing Tutorial”, consultato il 25/09/2026, tutorialspoint.com/software_testing.
3. ISTQB, “Glossario dei termini di test”, consultato il 25/09/2026, glossary.istqb.org.
4. Wikipedia (in inglese), “ISO/IEC 29119”, consultato il 25/09/2026, en.wikipedia.org/wiki/ISO/IEC_29119.
5. Barry W. Boehm, Software Engineering Economics, Prentice Hall, 1981.
6. Edsger W. Dijkstra, “Notes on Structured Programming” (EWD249), 1970, cs.utexas.edu/~EWD/ewd02xx/EWD249.PDF.
7. Glenford J. Myers, Corey Sandler e Tom Badgett, The Art of Software Testing, 3ª ed., Wiley, 2011.
8. Wikipedia (in inglese), “Verification and validation”, consultato il 25/09/2026, en.wikipedia.org/wiki/Verification_and_validation.
9. Wikipedia (in inglese), “V-model (software development)”, consultato il 25/09/2026, en.wikipedia.org/wiki/V-model_(software_development).
10. Wikipedia (in inglese), “ISO/IEC 25010”, consultato il 25/09/2026, en.wikipedia.org/wiki/ISO/IEC_25010.
11. Wikipedia (in inglese), “ISO 9241”, consultato il 25/09/2026, en.wikipedia.org/wiki/ISO_9241.
12. Martin Fowler, “Test Pyramid”, 2012, martinfowler.com/bliki/TestPyramid.html.
13. Jakob Nielsen, “Usability 101: Introduction to Usability”, Nielsen Norman Group, nngroup.com/articles/usability-101-introduction-to-usability.
14. OWASP, “OWASP Top Ten”, consultato il 25/09/2026, owasp.org/www-project-top-ten.
15. Strumenti: Selenium, selenium.dev; Playwright, playwright.dev; Apache JMeter, jmeter.apache.org.
16. IFPUG, International Function Point Users Group, ifpug.org.
17. Charles R. Symons, “Function Point Analysis: Difficulties and Improvements”, IEEE Transactions on Software Engineering, vol. 14, n. 1, 1988.
18. Martin Pol, Ruud Teunissen ed Erik van Veenendaal, Software Testing: A Guide to the TMap Approach, Addison-Wesley, 2002.