O teste de aceitação é um processo de garantia de qualidade (QA). Ele determina em que grau um aplicativo atende à aprovação dos usuários finais. No entanto, dependendo da organização, o teste de aceitação pode assumir a forma de teste beta, teste de aplicativo, teste de campo ou teste do usuário final.
Uma equipe de QA conduz o teste de aceitação para garantir que o software ou aplicativo atenda aos requisitos de negócios e às necessidades do usuário final. Portanto, um teste de aceitação pode retornar um resultado de aprovação ou reprovação. Dessa forma, se identificar uma falha, o teste sugere que o software não deve entrar em produção.
Em suma, o teste de aceitação permite que uma organização envolva os usuários finais no processo de teste e reúna seu feedback para transmitir aos desenvolvedores. Esse feedback ajuda o controle de qualidade a identificar falhas que podem ter sido perdidas durante os testes do estágio de desenvolvimento, como teste de unidade e funcional. Contudo, além disso, o teste de aceitação ajuda os desenvolvedores a entender as necessidades de negócios para cada função no software testado. Não obstante, o teste de aceitação também pode ajudar a garantir que o software ou aplicativo atenda às diretrizes de conformidade.
O processo do teste de aceitação
O teste de aceitação ocorre após os testes do sistema, mas antes da implantação. Ou seja, uma equipe de QA escreve testes de aceitação e os configura para examinar como o software atua em um ambiente de produção simulado. Então, o teste de aceitação confirma a estabilidade do software e verifica se há falhas.
O teste de aceitação inclui as seguintes fases:
- Planejar;
- Testar;
- Registrar;
- Comparar;
- Resultar.
Depois que o teste é escrito de acordo com o plano, os usuários finais interagem com o software para avaliar sua usabilidade. Portanto, o software deve atender às expectativas, conforme definido pelo negócio nos requisitos. Então, quando os testes retornam resultados, a TI deve relatar e corrigir quaisquer falhas que apareçam. Se os resultados corresponderem aos critérios de aceitação para cada caso de teste, o teste será aprovado. Mas, se os casos de teste excederem um limite inaceitável, eles falharão.
Tipos de teste de aceitação
O teste de aceitação abrange vários tipos, incluindo aceitação do usuário e aceitação operacional.
O teste de aceitação do usuário (UAT), também chamado de teste do usuário final, avalia se o software opera conforme o esperado pela base de usuários alvo. No entanto, usuários podem significar funcionários internos ou clientes de uma empresa ou outro grupo, dependendo do projeto.
Já o teste de aceitação operacional analisa como um produto de software funciona. Afinal, esse tipo de teste garante que os processos operem conforme o esperado e que a equipe possa usar e manter o sistema de maneira suficiente. Portanto, o teste de aceitação operacional examina backups e recuperação de desastres, bem como capacidade de manutenção, failover e segurança.
Qual é a diferença entre SIT e UAT?
O teste de aceitação do usuário e o teste de integração de sistema diferem em um aspecto fundamental: a pessoa que faz o teste. Então, aprenda quando aplicar UAT vs. SIT.
Nem todos os tipos de teste de software são iguais. Afinal, alguns cenários de teste até exigem perspectivas diferentes para avaliar se o software atingiu a marca. Esse é o caso do teste de aceitação do usuário, que difere um pouco de uma abordagem técnica, como o teste de integração de sistema.
Não há padrões de mercado para teste de aceitação do usuário (UAT) ou teste de integração de sistema (SIT). Afinal, com o UAT, as pessoas que usam o sistema ou estabelecem os requisitos do produto conduzem os testes.Então, o UAT pode variar muito com base na experiência da pessoa com o aplicativo e com o próprio teste.
Com o SIT, uma equipe de QA avalia se os aplicativos – e seus muitos componentes – funcionam como pretendido antes de ir para o cliente. Afinal, testes isolados, como testes de unidade, geralmente falham em detectar bugs que o SIT descobre.
Portanto, a principal diferença entre o SIT e o UAT se resume a seus objetivos de teste amplamente diferentes e à experiência dos testadores. Contudo, o tempo é um fator importante nos cenários UAT e SIT. Afinal, os testadores precisam saber qual é a diferença entre SIT e UAT, o que cada avaliação traz para a qualidade do software e quem verifica cada teste.
O que é UAT?
Com o teste de aceitação do usuário, a organização de desenvolvimento fornece a construção ou liberação para o consumidor-alvo do sistema, no final do ciclo de vida de desenvolvimento de software (SDLC). Então, os usuários finais ou a equipe de desenvolvimento de produto dessa organização executam as atividades esperadas para confirmar ou aceitar o sistema como viável. Dessa forma, a fase UAT é normalmente uma das etapas finais em um projeto geral de desenvolvimento de software.
Alguns tipos de UAT incluem o seguinte:
Testes alfa e beta
Com o teste alfa, os usuários ou grupos de usuários testam o software no início do SDLC para identificar bugs durante o desenvolvimento. Ou seja, as organizações lançam o produto para o ambiente do cliente em teste beta, que recebe mais feedback e melhora a qualidade, mas ocorre depois que a equipe de software realiza mais trabalho após os testes alfa.
Teste de caixa preta
O usuário não vê o código interno ou os componentes do aplicativo. É daí que vem o termo caixa preta. Ou seja, os usuários devem avaliar o quão bem o produto atende aos requisitos com base apenas em sua interação. O teste de caixa preta 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 usuário define critérios e especificações para um produto. Portanto, com o teste de aceitação do contrato, o usuário verifica se o software atende aos critérios acordados.
Teste de aceitação operacional
A organização do cliente determina sua prontidão para usar o software, avaliando critérios como treinamento de funcionários, manutenção de software e como lidará com falhas.
Teste de aceitação do regulamento
Também chamado de teste de aceitação de conformidade, esse processo verifica se o software atende às necessidades regulatórias ou de conformidade dos usuários.
Desvantagens do UAT
Uma desvantagem do UAT é que ele dá aos usuários pouco tempo para testar antes do lançamento do produto. Então, se os usuários encontrarem defeitos, eles podem se sentir pressionados a aceitar o software como está ao invés de atrasar um projeto. Em alguns casos, os clientes esperam meses pelo software e ficam ansiosos para recebê-lo e começar a trabalhar nele para atender às necessidades do negócio. Essa dinâmica pressiona os usuários a aceitar o software em teste, mesmo que os defeitos impeçam ou inibam a funcionalidade.
Outra desvantagem do UAT é que os usuários geralmente não sabem como testar corretamente. Afinal, os engenheiros de controle de qualidade aprendem técnicas que os ajudam a controlar o software. Contudo, os usuários geralmente chegam ao teclado sem nenhum conhecimento de como testar o software – mesmo se houver requisitos em vigor. Portanto, esses usuários estão propensos a executar testes de caminho feliz – não casos de teste mais complexos ou condições de teste interessantes – devido à inexperiência ou à falta de tempo para realizar diferentes cenários de maneira eficaz.
Ou seja, os usuários devem tentar entender a dinâmica específica do projeto e determinar o que é adaptável e lógico para solicitar dos desenvolvedores. Então, se você não acredita que os usuários possam lidar com o UAT de maneira eficaz, contrate ajuda externa para a tarefa.
O que é SIT?
O teste de integração de sistema, também chamado de teste de integração, avalia se todos os componentes de software – hardware e software – funcionam conforme o esperado em um sistema completo. No entanto, as equipes de QA de software conduzem o SIT, não os usuários.
Então, os testadores que avaliam a funcionalidade estão preparados para também verificar a funcionalidade do aplicativo como uma solução completa e integrada. Ou seja, o SIT costuma ser um processo de teste mais técnico do que o UAT. Afinal, os testadores projetam e executam o SIT à medida que se familiarizam com os tipos de defeitos comuns no aplicativo em todo o SDLC.
Vale frisar que a fase SIT precede o UAT. Como a experiência técnica entre usuários e testadores varia significativamente, os dois dados demográficos provavelmente encontrarão defeitos muito diferentes entre o UAT e o SIT. Afinal, o SIT frequentemente revela bugs que os testes de unidade não detectaram – defeitos que dependem de um fluxo de trabalho ou interação entre dois componentes do aplicativo, como uma ordem sequencial de operações.
Uma pequena sobreposição entre SIT e UAT pode ser desejável, como uma segunda verificação da funcionalidade do aplicativo. No entanto, o fato de que SIT e UAT ocorrem tarde no processo SDLC, perto do lançamento, é frequentemente o único elemento comum entre as duas formas de teste.
O que acontece quando os critérios de aceitação no teste de software estão faltando?
Você não pode testar algo se não souber o que deve fazer. Inclusive, frequentemente, os testadores têm uma compreensão muito incompleta do que estão testando. Veja como resolver esse problema.
Os critérios de aceitação em teste de software são muito importantes. Então, o que acontece quando não existe ou está incompleto?
Os testadores de controle de qualidade podem ter experimentado isso uma vez ou outra: uma história de usuário, recurso ou correção de bug com uma descrição de uma a cinco palavras e nenhum detalhe, resultados esperados, resultado antecipado, critérios de aceitação ou qualquer tipo de dados úteis para entender o corrigir, quanto mais criar um caso de teste válido para ele.
Então, se você está no controle de qualidade há tempo suficiente, já viveu isso. Os detalhes vazios ou insuficientes independem da metodologia. Portanto, podem ocorrer a qualquer momento em que tal lapso no protocolo for permitido. E isso ocorre basicamente quando não faz parte de uma mudança governamental ou regulamentar. Em outras palavras, esses problemas ocorrem quando não há uma multa comercial significativa caso a mudança falhe. Quantas centenas de defeitos foram eliminados devido à falta de critérios de aceitação no teste de software?
Pelo menos 50% dos defeitos entregues aos clientes são resultado direto de descrições e critérios de teste de aceitação inadequados ou totalmente ausentes. Muitos grupos usam o Agile como desculpa para uma documentação de mudança de software desleixada, dizendo que se destina a ser flexível. No entanto, a flexibilidade do Agile é a sua capacidade de alterar um design que não está funcionando em tempo real. Ou seja, ela precisa recriar completamente um novo recurso do zero porque a descrição e os critérios de aceitação no teste de software estavam ausentes ou eram inválidos?
Como lidar com as lacunas?
Então, como testador de controle de qualidade, como você preenche as lacunas? Você precisa de testes válidos. Ou seja, encontre o desenvolvedor designado para codificar a mudança. Descubra quais eles acham que são os requisitos, bem como o resultado desejado. Crie seus casos de teste básicos em torno do entendimento do desenvolvedor sobre a mudança, porque é assim que ela será codificada.
Em seguida, dê um passo para trás e imagine como a mudança se encaixará no software existente. Então, liste outras áreas em risco. Isso inclui falhas nas conexões de mensagens e salvamentos do banco de dados. Todos esses são pontos de falha em potencial. É fundamental para os clientes que o controle de qualidade descubra todos os pontos de falha possíveis na codificação do desenvolvedor.
Finalmente, reúna-se com o gerente de produto. Descubra a intenção do negócio e veja se há alguma desconexão. Para ser ainda mais eficaz, convide o desenvolvedor e mantenha-o falando. Se o desenvolvedor ou o QA puder demonstrar a mudança conforme ela foi codificada até agora, ou demonstrar um protótipo, então você provavelmente obterá requisitos novos ou anteriormente não documentados do gerente de produto.
Por quê? Essa é a natureza da comunicação humana. Afinal, todos nós interpretamos as coisas para atender às nossas necessidades, e essas necessidades criam entendimentos diferentes. O membro da equipe de QA precisa observar as discrepâncias e conduzir a conversa para garantir que o que está sendo codificado é o que o cliente espera.
Portanto, preencher a lacuna de compreensão e chegar aos critérios de aceitação em testes de software são objetivos essenciais para garantir o lançamento de software de qualidade com menos bugs. Não obstante, eles também deixam os clientes muito mais felizes.
Armadilhas de teste de aceitação automatizada para evitar
Como as organizações podem obter o máximo de seus testes de software com o mínimo de esforço? Aqui estão algumas práticas recomendadas sobre como contornar essas armadilhas comuns de teste de aceitação automatizado.
Existe uma frase comum em testes: se você fizer algo mais de uma vez, deverá automatizá-lo. Compreensivelmente, no reino dos testes de software, onde a execução de processos repetitivos é rotina, é a base de teste perfeita para testes de aceitação automatizados. Em ambientes modernos de desenvolvimento de software, com a proliferação de microsserviços, onipresença de implantação contínua e, muitas vezes, uma abordagem reativa para o desenvolvimento de sistemas, as equipes de software desejam entregar recursos com a maior velocidade possível. Contudo, se as organizações desejam fazer a automação de teste da maneira certa, elas precisam evitar esses cinco erros muito comuns que as equipes de desenvolvimento de software cometem.
Estabilidade
A estabilidade dos testes automatizados é um dos problemas mais óbvios, embora seja o mais difícil de obter. Mesmo grandes players como LinkedIn ou Spotify admitem ter lutado com isso. Ao projetar sua automação, você deve dar atenção extra à estabilidade, pois é a causa mais frequente de falha e ineficiência do teste. Escrever testes é apenas o começo, portanto, você deve sempre planejar algum tempo no sprint para manutenção e revisões.
Perspectiva da interface do usuário
A maioria dos aplicativos modernos é baseada na Web; portanto, a maneira mais preferível de iniciar o teste funcional é a partir da perspectiva da IU. Portanto, apesar de sua utilidade, os testes de navegador também apresentam alguns problemas substanciais, como tempo de execução lento ou aleatoriedade de estabilidade. Como estamos no mundo dos microsserviços, vale a pena considerar a divisão dos testes em camadas – testando os recursos do seu aplicativo diretamente por meio da integração de serviços da Web ou qualquer tipo de back end em geral e limitando os testes de IU a um conjunto mínimo de fumaça testes de eficiência.
Mocks demais
Por causa de muitas dependências sobre os sistemas, os serviços de simulação tornam-se um padrão popular. No entanto, as organizações devem prestar muita atenção ao volume das simulações. O problema com os mocks é que eles podem perder a verdade ou simplesmente estar desatualizados, então seu desenvolvimento estaria rodando em falsas suposições. Há um ditado: “Não faça mock do que você não possui”, que afirma que você só pode criar stub nas peças de arquitetura que está implementando. Esta é uma abordagem adequada ao testar a integração com o sistema externo, entretanto, e se você quiser assumir dependências estáveis e testar apenas sua implementação? Então, sim, você faz mock de tudo, exceto do que possui. Para resumir, a estratégia de simulação e stub pode diferir dependendo dos propósitos do teste.
Acoplamento estreito com estrutura
Essa é complicada. Afinal, os desenvolvedores geralmente tendem a escolher estruturas e ferramentas com base nas tendências atuais. O mesmo se aplica a frameworks de teste, onde temos pelo menos alguns ótimos frameworks para usar apenas para um executor de teste, sem mencionar o cliente REST, ferramenta de construção e assim por diante. Portanto, ao escolher uma pilha de tecnologia, devemos ter em mente a necessidade de permanecer o mais independente possível das ferramentas – é o cenário de automação de teste que é o mais importante, não as estruturas, portanto, o acoplamento estreito entre elas deve ser evitado.
Mantenha as coisas simples
Dependendo da estrutura de sua equipe, o teste de aceitação é implementado por desenvolvedores ou testadores. Normalmente, os desenvolvedores são melhores na escrita de código, enquanto os testadores têm uma abordagem mais funcional – embora isso não seja uma regra. O teste de aceitação automatizado não é um produto em si, mas sim uma ferramenta; portanto, a funcionalidade deve superar a complexidade.
Ou seja, sua base de código de teste é quase tão grande quanto o sistema testado? Então, tente categorizar os testes de acordo com seu domínio ou tipo. Adicionar novos testes requer uma análise da estrutura do código demorada? Às vezes, um código mais detalhado, mas mais legível, é melhor para seus testes do que estruturas complexas.
O pior cenário que pode acontecer com seu teste de aceitação automatizado é abandoná-lo devido a problemas relativamente simples, mas comuns. O tempo economizado com a automação de casos de teste simples pode ser usado para executar cenários mais complexos manualmente, o que leva a uma melhor qualidade de software e maior motivação dos funcionários em geral. Se você tiver outras experiências interessantes com automação de teste, diga-nos.
Podemos automatizar totalmente nossos testes de software?
Seu chefe entrou no movimento para automatizar os testes de software. Não se desespere. O especialista em teste de software Matt Heusser explica o que dizer – e fazer – para deixar todos felizes.
A maioria das pessoas está familiarizada com o termo teste automatizado de software. Parece ótimo, mas claramente, não é tão simples quanto apertar um botão.
Então, o que realmente significa adotar uma estratégia de teste de software automatizado? Se o teste manual de software for removido da equação, a equipe de QA enfrentará mudanças dramáticas – ou, talvez, a extinção. Mas o controle de qualidade totalmente automatizado não garante a qualidade; pode até servir como um prejuízo.
Então, é possível automatizar totalmente o teste de software? E, em caso afirmativo, é uma boa ideia? Vamos explorar essa questão com uma discussão sobre o valor da automação de teste.
Como o teste automatizado cria valor?
A maioria da automação de teste executa um aplicativo por meio de um algoritmo, com um local de início, uma mudança e um resultado esperado. Na primeira vez que esses testes são aprovados, a automação é concluída, no entanto, o recurso não é concluído até que as verificações sejam executadas. Portanto, os testes automatizados ainda não agregaram valor.
O loop teste-correção-reteste ajuda a concluir os testes com mais rapidez e fornece instruções claras para orientar o comportamento correto. No entanto, quando as verificações automatizadas são criadas, elas não encontram problemas. Depois que tudo passa nos testes iniciais, ocorrem mudanças para que o software possa detectar quebras quando o resultado esperado não for o correto.
Nesse ponto, chegamos a uma máxima de ferramentas de teste de aceitação: depois de uma única mudança no software, a automação de teste torna-se essencialmente a detecção de mudança.
Então, lembre-se: o trabalho do programador é criar mudanças e isso, por sua vez, cria uma carga de manutenção. Quando alguém precisar depurar um teste, confirme se o software realmente mudou e, em seguida, atualize o teste – digamos, para adicionar o campo de número de telefone agora obrigatório ao criar um usuário.
Com esse conhecimento básico, você vê como os testes automatizados podem beneficiar sua organização. Então, a pergunta é: quanto você deve tentar automatizar o teste de software?
Determine o quanto de automação é suficiente
Digamos que você esteja fazendo uma demonstração de software para um cliente ou executivo sênior. O produto ainda não está em produção; você está apenas mostrando o que fez para obter feedback para a próxima iteração. O vice-presidente de finanças pergunta o que acontece se você criar uma fatura que está vencida no dia em que foi criada. É uma boa pergunta e, essencialmente, uma ideia de teste. Ou seja, é o tipo de coisa em que ninguém pensou antes. Se o software funcionar de uma maneira, tudo bem; caso contrário, é uma solicitação de novo recurso, não é realmente um bug.
A pessoa no teclado tenta responder à pergunta. Você diz a ele para parar por que você precisa criar e executar um teste automatizado antes de responder a essa pergunta? Certamente esperamos que não.
Existem muitas ideias de teste como esta, coisas que você pensa no momento para explorar, especialmente ao testar um novo recurso que faz parte de um sistema existente. Afinal, a maioria das ideias você deseja experimentar apenas uma vez. Então, automatizar esses testes em código que é executado o tempo todo é um desperdício e caro. Seu chefe certamente não quer que todas as pequenas ideias sejam institucionalizadas. Além disso, seu chefe deseja automatizar o design de teste – o desenvolvimento de ideias de teste?
Expectativas
Não existe uma caixa mágica na qual você possa alimentar requisitos como documentos do Word e mostrar as condições de teste e os resultados esperados. Quando a maioria das pessoas diz automação de teste de aceitação, elas querem clicar em um botão, executar todas as verificações pré-existentes e obter resultados. Portanto, uma estratégia de teste de software totalmente automatizada implica que um polegar para cima é suficiente para passar para a produção sem mais pesquisas e análises.
Na realidade, isso é 100% de automação de teste de regressão. Afinal, você exclui desempenho, segurança e suporte a nova plataforma ou navegador e apenas diz: “Uma vez que qualquer mudança foi testada isoladamente, ela pode ir para a produção depois que o ferramental for aprovado”. No entanto, isso ainda nos deixa com o problema de manutenção do teste.
3 maneiras de realizar manutenção de teste de aceitação
Existem duas abordagens populares para tornar a manutenção de teste de aceitação mais eficiente. A primeira é escrever recursos em fatias finas. Então, executá-las rapidamente e de forma fácil de depurar, às vezes chamados de testes DOM para banco de dados. Outra abordagem é isolar o código em componentes que são implantados separadamente que simplesmente não têm verificações automatizadas de GUI, concentrando os esforços de automação “nos bastidores”.
Contudo, uma terceira e mais nova abordagem de manutenção é usar o aprendizado de máquina e a inteligência preditiva para descobrir se o software está realmente danificado e, em seguida, autocorrigir-se. Às vezes, uma mudança na IU não afeta os recursos de forma alguma – ela apenas altera a posição dos elementos na tela, fazendo com que os localizadores falhem. Nesse caso, o software pode usar um histórico de onde os elementos são armazenados para essencialmente adivinhar a localização do botão de envio e verificar novamente. Então, se o software for aprovado nessas condições, o AI pode ajustar a verificação para autocorreção. Algumas empresas tentaram essa abordagem com sucesso moderado, reduzindo a carga de manutenção do teste sem aumentar suas taxas de aprovação falsa.
No geral, o conselho para as organizações que questionam a viabilidade de uma política de automação 100% é simples: dê um passo para trás e respire. Faça perguntas razoáveis. Não seja um sabe-tudo, não seja um capacho, não habilite e não obstrua abertamente. Trabalhe com o chefe para definir os termos, focar nos resultados finais e encontrar os meios para atingir esses resultados – qualquer nível de teste automatizado ou manual que ele requeira.
