Testes em Sistemas Web
Objetivo desta página
Esta página descreve como o QA deve atuar na validação de sistemas web, aplicando na prática os conceitos de estratégia, tipos de teste, risco, critérios de aceite, regressão e comunicação já definidos nos capítulos anteriores.
O foco aqui é execução consciente, não checklist automático.
Contexto de sistemas web na DBSeller
Os sistemas web da DBSeller, como o E-Cidade e o Portal do Aluno, possuem características que aumentam significativamente a complexidade dos testes:
-
múltiplos módulos integrados
-
grande volume de dados
-
regras de negócio sensíveis
-
uso intensivo de formulários, filtros e relatórios
-
integrações entre telas e módulos
-
usuários com perfis e permissões diferentes
Isso exige que o QA pense o teste a partir do uso real, não apenas do requisito isolado.
Pontos críticos em sistemas web
Antes de executar qualquer teste, o QA deve identificar os pontos críticos típicos de aplicações web.
1. Navegação e fluxo entre telas
O QA deve validar:
-
acesso correto às telas
-
navegação entre menus
-
retorno de ações (voltar, avançar, cancelar)
-
persistência de filtros e estados
Exemplo prático:
Ao salvar um cadastro e retornar à listagem, o sistema deve manter filtros aplicados ou voltar ao estado esperado.
2. Formulários e entrada de dados
Formulários são um dos maiores geradores de bugs em sistemas web.
O QA deve validar:
-
campos obrigatórios
-
validações de formato
-
limites de tamanho
-
comportamento ao salvar, editar e cancelar
-
mensagens de erro e sucesso
Aplicação prática:
Aqui entram Testes de Aceitação, Testes de Integridade e Precisão e Testes Baseados em Risco, conforme definido anteriormente.
3. Estados da interface
Sistemas web possuem múltiplos estados que precisam ser validados:
-
carregando
-
sucesso
-
erro
-
vazio
-
parcialmente preenchido
Exemplo prático:
Uma listagem sem registros deve exibir mensagem adequada, e não erro ou tela em branco.
4. Responsividade
Mesmo sistemas web corporativos precisam lidar com diferentes resoluções.
O QA deve validar:
-
desktop padrão
-
resoluções menores
-
comportamento de tabelas
-
quebra de layout
-
botões acessíveis
Aqui entram Testes de Usabilidade e Testes de Compatibilidade.
5. Sessão e autenticação
Pontos críticos:
-
expiração de sessão
-
múltiplas abas abertas
-
logout automático
-
acesso por perfil
Exemplo prático:
Usuário perde sessão e o sistema deve redirecionar corretamente, sem perder dados sensíveis.
Tipos de teste mais comuns em sistemas web
A seguir estão os tipos de teste mais aplicáveis a sistemas web, conforme a prática da DBSeller.
Testes de Aceitação
Aplicados para validar se:
-
a funcionalidade atende ao que foi definido
-
os critérios de aceite foram cumpridos
Sempre aplicados, independentemente do tipo de demanda.
Testes Exploratórios
Aplicados para:
-
descobrir falhas não previstas
-
validar comportamento fora do fluxo principal
-
observar interação real do usuário
Muito usados após a execução do plano formal.
Smoke Test
Aplicados para:
-
validar se o sistema está minimamente utilizável
-
confirmar que funcionalidades principais não quebraram
Muito usados após deploy ou hotfix.
Testes de Integração
Aplicados quando:
-
dados trafegam entre módulos
-
uma ação em uma tela impacta outra
Exemplo prático:
Cadastro feito no módulo Educação impacta relatórios e consultas em outros menus.
Testes de Usabilidade
Aplicados para validar:
-
clareza de mensagens
-
facilidade de uso
-
fluxo intuitivo
Não avaliam regra, avaliam experiência.
Testes de Integridade e Precisão
Aplicados para validar:
-
dados exibidos
-
cálculos
-
consistência entre telas e relatórios
Extremamente críticos em sistemas administrativos.
Testes de Regressão
Aplicados sempre que:
-
algo existente é alterado
-
bug é corrigido
-
regra compartilhada é modificada
Devem ser definidos conforme impacto, nunca de forma aleatória.
Riscos frequentes em sistemas web
Aqui entra o olhar estratégico do QA.
1. Alteração em um ponto afeta múltiplos fluxos
Sistemas web integrados possuem alto risco de efeito colateral.
Exemplo prático:
Alterar regra de filtro em uma tela pode impactar relatórios, exportações e integrações.
2. Dependência excessiva de estado da UI
Bugs comuns:
-
dados desaparecem ao trocar aba
-
filtros resetam indevidamente
-
listas não recarregam
Aqui o QA deve forçar:
-
troca de abas
-
mudança de filtros
-
navegação repetida
3. Dados inconsistentes entre telas
Risco clássico:
-
tela mostra uma informação
-
relatório mostra outra
Sempre validar:
-
mesma base de dados
-
mesma regra aplicada
4. Problemas de performance mascarados
Em homologação, dados costumam ser menores.
O QA deve:
-
simular cenários com mais dados
-
observar tempo de resposta
-
validar comportamento sob carga razoável
5. Regressões silenciosas
Sistemas web permitem que:
Por isso, a regressão precisa ser pensada, não executada mecanicamente.
Aplicação prática do fluxo de QA em sistemas web
Ao receber uma task de sistema web, o QA deve:
-
Fazer o mapa mental de impacto
-
quais telas
-
quais dados
-
quais integrações
-
-
Definir estratégia de teste
-
tipos de teste aplicáveis
-
riscos principais
-
-
Elaborar plano ou abordagem
-
plano de teste ou checklist direcionado
-
-
Executar testes
-
aceitação
-
exploratórios
-
regressão
-
-
Comunicar resultados
-
bugs
-
riscos
-
recomendação de Go ou No-Go
-
Esse fluxo conecta todo o conteúdo da wiki até aqui.
Erros comuns ao testar sistemas web
-
testar apenas o caminho feliz
-
ignorar estados intermediários
-
não testar troca de filtros e abas
-
não pensar em impacto entre módulos
-
focar só na tela, ignorando dados
Resultado esperado desta abordagem
Seguindo este modelo, o QA garante:
-
testes mais inteligentes
-
menos bugs em produção
-
maior previsibilidade
-
melhor comunicação com dev e produto
Testar sistemas web não é clicar em telas.
É entender como o sistema é usado, conectado e mantido.