Protótipo e validação
Integrar uma tarefa, verificar casos difíceis e medir se a solução ajuda os utilizadores.
O voluntário escolhe um berbequim, indica os dias e recebe uma confirmação. Depois recarrega a página e a reserva mantém-se. Este percurso verifica mais do que um ecrã desenhado: liga a interação à regra de disponibilidade e ao registo dos dados.
Protótipo e integração
Um protótipo permite investigar uma dúvida com uma solução limitada. Pode ser um desenho clicável para estudar a compreensão de uma tarefa ou uma implementação integrada para estudar a confirmação de reservas. Um desenho não demonstra persistência. Uma implementação que aceita todos os pedidos não demonstra que a regra de conflitos funciona.
Escolhe a forma pela pergunta. Para perceber se o voluntário distingue uma proposta de uma reserva confirmada, o protótipo deve mostrar ambos os estados. Para perceber se duas confirmações simultâneas podem duplicar o empréstimo, é preciso executar a regra que guarda os dados. A dúvida determina a experiência necessária.
A integração deve incluir os casos em que a operação falha. Se a confirmação falha por conflito, a interface mostra o motivo e permite rever o período. Se falha a comunicação, não anuncia sucesso antes de conhecer o resultado. Uma nova tentativa precisa de um contrato que evite criar a mesma reserva duas vezes.
Verificação e validação
As duas palavras confundem-se porque só trocam a ordem dos mesmos termos. A distinção que conta é outra: a verificação confere a solução face às regras especificadas e a validação pergunta se a solução serve a necessidade dos utilizadores no contexto observado. As duas podem revelar problemas diferentes.
Para verificar a regra de reservas, usa períodos livres, sobrepostos, adjacentes e inválidos. Inclui duas tentativas concorrentes para a mesma ferramenta: no máximo uma confirmação incompatível pode ficar guardada. Um caso com uma ferramenta diferente não deve criar um conflito indevido. Guarda os dados de entrada e o resultado esperado antes de executar o teste.
Para validar a tarefa, acompanha voluntários a confirmar empréstimos representativos. Observa dúvidas, erros e informação que falta. A pergunta “gostaste?” pode complementar o ensaio, mas não mostra se a pessoa distinguiu uma confirmação de uma proposta. Define uma tarefa, deixa a pessoa executá-la e regista o que aconteceu sem transformar a sessão numa demonstração guiada pela equipa.
A cadeia liga uma decisão a uma observação. Se o ensaio falhar, a equipa pode corrigir a implementação, descobrir um critério incompleto ou rever a hipótese inicial sobre a necessidade.
Métricas e conclusão
Define o sucesso antes de medir. A equipa define sucesso como “confirmar uma reserva válida, sem ajuda, em até dois minutos”. Num ensaio didático com dez pessoas, sete cumprem todos esses critérios:
Não conta como sucesso quem termina em menos de dois minutos mas guarda uma reserva inválida.
Para comparar com o processo manual, conserva tarefas, condições e critérios. Num ensaio anterior com o processo manual, seis de dez tinham conseguido a mesma tarefa. A diferença entre 70% e 60% é de 10 pontos percentuais. A melhoria relativa da taxa é , cerca de 16,7%. São grandezas diferentes: a primeira subtrai percentagens, a segunda divide essa diferença pela taxa inicial. Um ensaio pequeno, por si só, não demonstra melhoria na população nem prova que a mudança de ferramenta foi a causa.
Regista também como escolheste as pessoas. Se as mesmas pessoas fizerem primeiro o processo manual e depois o protótipo, podem melhorar por aprendizagem. Alternar a ordem ou usar outro desenho pode reduzir esse efeito; a escolha depende dos recursos e da pergunta. Não escondas uma comparação fraca atrás de uma percentagem.
Limites e iteração
Um erro observado num teste local deve levar a uma alteração e a uma nova verificação. Se o botão diz “Guardar” e a pessoa pensa que o empréstimo já está confirmado, revê o texto e o estado apresentado. Repete a tarefa relevante, conservando um registo que permita comparar o antes e o depois.
Usa dados fictícios para testes repetíveis e demonstrações públicas. Uma validação com utilizadores reais requer condições acordadas para participação e recolha. Não publiques os registos pessoais para tornar o ensaio reproduzível; documenta o protocolo e resultados agregados adequados.
O primeiro incremento pode provar a confirmação de uma reserva e continuar sem gerir ferramentas danificadas ou devoluções atrasadas. Regista esses limites. “Todos os testes passaram” só abrange os testes executados; “os utilizadores conseguiram” só abrange participantes, tarefas e condições observados.
Exercícios
Escolher evidência para duas perguntas
Um protótipo recusa um período sobreposto num teste sequencial. Numa apresentação guiada, um voluntário diz que o ecrã é bonito. A equipa anuncia que o sistema impede qualquer duplicação e que os utilizadores já conseguem confirmar empréstimos sozinhos.
Identifica uma evidência em falta para cada afirmação. Define um ensaio de verificação e outro de validação, com um resultado observável. O elogio substitui algum desses ensaios?
Solução
O teste sequencial não cobre duas confirmações simultâneas. Para verificar a regra, inicia duas tentativas incompatíveis para a mesma ferramenta e consulta o estado final: no máximo uma deve ficar confirmada. Regista as respostas e os dados guardados. Este ensaio também não prova todos os comportamentos possíveis do sistema.
A apresentação guiada não mostra autonomia. Para validar a tarefa, pede a voluntários que confirmem um empréstimo num cenário representativo, sem conduzir cada passo. Observa se distinguem a confirmação de uma proposta, se escolhem um período válido e onde precisam de ajuda. Define antecipadamente o que conta como conclusão.
O elogio informa uma opinião estética. Não prova o controlo de concorrência nem a conclusão autónoma da tarefa. Pode complementar a avaliação, sem substituir os resultados que cada afirmação exige.
Confere a tua resposta:
- Usei tentativas concorrentes para verificar a regra.
- Usei tarefas com voluntários para validar a compreensão.
- Expliquei que o elogio não prova a regra nem a tarefa concluída.
Interpretar uma melhoria observada
No processo manual, quatro de oito participantes confirmaram uma reserva válida, sem ajuda, em até dois minutos. Depois, os mesmos participantes experimentam o protótipo: seis cumprem todos os critérios; um termina depressa mas cria uma reserva inválida, e outro precisa de ajuda.
Calcula a taxa de sucesso no protótipo, a diferença em pontos percentuais e a melhoria relativa face à taxa manual. Justifica quais participantes contam. A comparação prova que o protótipo melhora a tarefa para todos os utilizadores?
Solução
Só os seis que cumprem todos os critérios contam. A taxa é 6/8=75%, face a 4/8=50% no processo manual. A diferença é 75−50=25 pontos percentuais; a melhoria relativa é (75−50)/50=50%. Não são a mesma grandeza.
Quem cria uma reserva inválida falha o critério de validade; quem precisa de ajuda falha o de autonomia. O tempo isolado não basta.
Os resultados descrevem oito participantes e as tarefas realizadas. A ordem fixa permite um efeito de aprendizagem no segundo ensaio. Também falta saber como foram escolhidos os participantes e se as tarefas foram comparáveis. A comparação não prova uma melhoria universal nem isola por si só a causa. Regista esses limites e escolhe um desenho de avaliação adequado para a próxima pergunta.
Confere a tua resposta:
- Contei 6 sucessos e obtive 75%.
- Calculei 25 pontos percentuais e 50% de melhoria relativa.
- Limitei a comparação às condições e identifiquei possível aprendizagem.