Nem todos os tipos de testes de software são iguais. Alguns cenários de testes requerem mesmo perspectivas diferentes para avaliar se o software atingiu a marca. É o caso dos testes de aceitação do utilizador, que diferem bastante de uma abordagem técnica, como os testes de integração de sistemas.
Não há normas da indústria para testes de aceitação do utilizador (UAT) ou testes de integração de sistemas (SIT). Com o UAT, as pessoas que utilizam o sistema ou estabelecem os requisitos do produto conduzem os testes. O UAT pode variar muito com base na experiência da pessoa com a aplicação e na experiência com os próprios testes.
Com o SIT, uma equipa de GQ avalia se as aplicações – e os seus muitos componentes – funcionam como pretendido antes de irem para o cliente. Testes isolados, tais como testes unitários, falham frequentemente em detectar bugs que o SIT descobre.
A principal diferença entre o SIT e o UAT resume-se aos seus objectivos de teste muito diferentes e à experiência dos testadores. O tempo é um factor tanto no cenário UAT como no SIT. Os testadores precisam de saber qual é a diferença entre o SIT e o UAT, o que cada avaliação traz à qualidade do software e quem verifica cada teste. Leia mais sobre estes processos de teste.
O que é o UAT?
Com os testes de aceitação do utilizador, a organização de desenvolvimento dá a construção ou lançamento ao consumidor alvo do sistema, numa fase tardia do ciclo de vida de desenvolvimento de software (SDLC). Os utilizadores finais ou a equipa de desenvolvimento do produto dessa organização executam as actividades esperadas para confirmar ou aceitar o sistema como viável. A fase UAT é tipicamente uma das etapas finais de um projecto global de desenvolvimento de software.
Alguns tipos de UAT incluem o seguinte:
- testes Alfa e beta. Com os testes alfa, os utilizadores ou grupos de utilizadores testam o software no início do SDLC para identificar bugs durante o desenvolvimento. As organizações libertam o produto para o ambiente do cliente em testes beta, o que obtém mais feedback e melhora a qualidade mas vem depois da equipa de software ter feito mais trabalho após os testes alfa.
- teste de caixa negra. O utilizador não vê o código interno ou os componentes da aplicação, que é de onde provém o termo “caixa negra”. Os utilizadores devem avaliar o quão bem o produto satisfaz os requisitos com base apenas na sua interacção. O teste da caixa negra é também um tipo de teste funcional.
- Teste de aceitação de contrato. Este tipo de UAT ocorre quando um contrato entre o fornecedor e o utilizador define critérios e especificações para um produto. Com testes de aceitação de contrato, o utilizador verifica que o software cumpre os critérios acordados.
- Teste de aceitação operacional. A organização cliente determina a sua disponibilidade para utilizar o software, aferindo critérios como formação de funcionários, manutenção do software e como irá lidar com falhas.
- Teste de aceitação do regulamento. Também chamado teste de aceitação de conformidade, este processo verifica que o software satisfaz as necessidades regulamentares ou de conformidade dos utilizadores.
Uma desvantagem do UAT é que deixa aos utilizadores pouco tempo para testar antes do lançamento do produto. Se os utilizadores encontrarem defeitos, poderão sentir pressão para aceitar o software como é, em vez de atrasar um projecto. Em alguns casos, os clientes esperam meses pelo software e estão ansiosos por o receber e começar a trabalhar no mesmo para satisfazer as necessidades do negócio. Estas dinâmicas pressionam os utilizadores a aceitar o software em teste, mesmo que os defeitos previnam ou inibam a funcionalidade.
Outra desvantagem do UAT é que os utilizadores muitas vezes não sabem como testar correctamente. Os engenheiros de GQ aprendem técnicas que os ajudam a vetar o software. Os utilizadores chegam muitas vezes ao teclado sem qualquer conhecimento de como testar o software — mesmo que existam requisitos em vigor. Esses utilizadores são propensos a executar testes de percurso felizes — não mais envolvidos em casos de teste ou condições de teste interessantes — quer devido à inexperiência ou à falta de tempo para realizar eficazmente diferentes cenários.
Os utilizadores devem tentar compreender a dinâmica específica do projecto e determinar o que é adaptável e lógico pedir aos programadores. Se não acredita que os utilizadores possam lidar eficazmente com o UAT, comissione ajuda externa com a tarefa.
O que é SIT?
Testes de integração de sistemas, também chamados testes de integração, avalia que todos os componentes de software — hardware e software — funcionam como esperado num sistema completo. Equipas de GQ de software conduzem SIT, não utilizadores.
Testes que avaliam a funcionalidade tal como é entregue estão normalmente preparados para também verificar a funcionalidade da aplicação como um todo, solução integrada. O SIT é muitas vezes um processo de teste mais técnico do que o UAT. Os testadores concebem e executam o SIT, uma vez que se familiarizaram com os tipos de defeitos comuns na aplicação através do SDLC.
A fase SIT precede o UAT. Uma vez que os conhecimentos técnicos entre utilizadores e testadores variam significativamente, é provável que os dois demográficos encontrem defeitos muito diferentes entre o UAT e o SIT. O SIT descobre frequentemente que os testes unitários de bugs não detectaram – defeitos que dependem de um fluxo de trabalho ou interacção entre dois componentes de aplicação, tais como uma ordem sequencial de operações.
Um pouco de sobreposição entre SIT e UAT pode ser desejável, como uma segunda verificação da funcionalidade da aplicação. No entanto, o facto de tanto o SIT como o UAT ocorrerem tardiamente no processo SDLC, próximo do lançamento, é muitas vezes o único elemento comum entre as duas formas de teste.