Um modelo prático para a qualidade das aplicações móveis

Uma aplicação móvel pode permanecer aberta e, ainda assim, falhar na tarefa em curso. Um rascunho pode perder-se, um controlo pode parecer funcionar sem alterar nada ou um processo interrompido pode ser retomado no local errado. Nenhum destes exemplos exige um encerramento inesperado, mas cada um representa um problema de qualidade que importa detetar antes do lançamento.

Os relatórios de encerramentos inesperados continuam a ser úteis, mas abrangem apenas uma categoria de falha. Uma prática de qualidade mais ampla procura saber se a aplicação preserva a intenção, comunica o seu estado, lida com a alteração das condições e permite a recuperação. O objetivo não é eliminar todos os defeitos possíveis. É identificar as falhas que mais afetam o trabalho útil e tomar decisões deliberadas sobre essas falhas.

Começar por percursos completos do produto

Uma análise ecrã a ecrã pode não detetar problemas entre ecrãs. É preferível analisar a qualidade móvel como um percurso: uma sequência que começa com uma intenção, passa por decisões e limites do sistema e termina com um resultado que a pessoa consegue reconhecer. Por exemplo, criar um documento inclui a introdução de conteúdo, a edição, a gravação, a saída, o regresso e a confirmação de que o conteúdo continua disponível.

1. Dar à tarefa um nome que descreva o resultado pretendido.
2. Registar cada estado visível e a transição que o liga ao seguinte.
3. Adicionar interrupções prováveis, incluindo cancelamento, atraso e perda de conectividade.
4. Definir como a interface mostra que a tarefa foi concluída com êxito.
5. Identificar um percurso de recuperação seguro para resultados incompletos ou incertos.

Os mapas de percursos devem incluir ramificações, e não apenas o trajeto preferencial. Uma permissão pode não estar disponível, os dados enviados podem ser rejeitados ou a aplicação pode voltar a abrir após uma interrupção. Estas são condições de implementação que devem ser verificadas, não pressupostos sobre qualquer sistema operativo. O seu mapeamento facilita a decisão sobre quais resultados exigem prevenção, explicação ou recuperação.

Avaliar a qualidade em várias camadas

Uma análise prática separa a qualidade em camadas, para que uma interface estável não oculte um comportamento incorreto. Cada camada coloca uma pergunta diferente e as respostas podem ser combinadas numa avaliação de lançamento. As categorias não têm de se transformar em departamentos ou painéis separados. São orientações para analisar o mesmo percurso sob vários ângulos.

• A correção funcional pergunta se uma ação produz o resultado pretendido.
• A continuidade pergunta se o progresso resiste à navegação, à interrupção e ao regresso.
• A clareza pergunta se o estado atual e a ação seguinte são compreensíveis.
• A recuperação pergunta se uma falha deixa um percurso seguro e útil para continuar.
• A eficiência pergunta se o percurso utiliza quantidades razoáveis de tempo, atenção e recursos do dispositivo.

A telemetria, ou seja, os dados registados sobre eventos e condições da aplicação, pode apoiar esta análise quando a recolha é adequada e permitida. A telemetria deve estar associada a perguntas específicas. Um evento de conclusão pode ajudar a revelar onde termina um percurso, enquanto um evento de nova tentativa pode ajudar a localizar pontos de atrito. A instrumentação, ou seja, o código que regista esses eventos, também precisa de ser testada para que registos em falta ou duplicados não distorçam as decisões de lançamento.

Tornar explícitos o estado e a recuperação

O estado é a informação de que uma aplicação necessita para representar o que é verdadeiro naquele momento, como um valor editado, um item selecionado ou uma operação pendente. Surgem problemas de qualidade quando o estado visível e o estado armazenado não coincidem. Uma especificação útil identifica o responsável por cada valor importante, quando esse valor muda, onde é armazenado e o que acontece se não for possível confirmar uma atualização.

A conceção da recuperação deve distinguir entre falha, atraso e incerteza. Se uma operação falhar, a interface pode disponibilizar uma correção ou uma nova tentativa. Se a operação estiver atrasada, a aplicação pode preservar o progresso enquanto comunica que a conclusão está pendente. Se o resultado for incerto, repetir a ação pode criar outro problema, pelo que a equipa deve verificar o resultado antes de disponibilizar uma nova tentativa. O comportamento adequado depende da operação e dos sistemas envolvidos.

Testar os limites, não apenas os ecrãs

Muitos riscos de qualidade encontram-se nos limites: entre a interface e o armazenamento, entre dados locais e remotos, entre os diferentes estados em que uma conta pode estar, ou entre a aplicação e uma capacidade do sistema. Um teste de limites altera uma condição enquanto preserva a tarefa pretendida. Desta forma, torna-se mais fácil definir a resposta esperada e interpretar o resultado observado.

• Colocar em pausa ou cancelar durante uma transição significativa e, em seguida, verificar o progresso preservado.
• Alterar a conectividade durante o pedido ou o envio de dados.
• Remover uma permissão opcional e verificar um percurso alternativo.
• Voltar a abrir a aplicação enquanto o trabalho incompleto ainda está presente.
• Apresentar dados desatualizados ou contraditórios e verificar o percurso de resolução.

Estes testes devem utilizar condições que a equipa de produto consiga reproduzir e observar. As provas relevantes podem incluir a interface visível, os valores armazenados e os registos de diagnóstico permitidos. A equipa deve verificar quais as condições de ciclo de vida, execução em segundo plano e permissões que se aplicam a cada plataforma suportada, em vez de transferir expectativas de um ambiente para outro. As definições de acessibilidade e os recursos limitados do dispositivo podem ser tratados como limites adicionais com expectativas definidas.

Converter as conclusões em decisões de lançamento

Uma lista de defeitos torna-se mais útil quando cada item inclui contexto e consequência. A gravidade, por si só, pode ser vaga. Uma decisão de lançamento deve considerar o percurso afetado, se os dados ou a intenção estão em risco, a disponibilidade de recuperação, a clareza da interface e a capacidade da equipa para detetar a repetição do problema após o lançamento.

1. Reproduzir a condição e registar a sequência fiável mais curta.
2. Identificar o percurso, o limite e a camada de qualidade envolvidos.
3. Descrever a consequência sem presumir a reação de uma pessoa.
4. Decidir se o problema deve ser corrigido, contido, monitorizado ou adiado.
5. Adicionar uma verificação direcionada que consiga voltar a detetar a mesma falha.

Um orçamento de qualidade pode ajudar a organizar os compromissos. Neste contexto, um orçamento de qualidade significa um limite explícito para o risco aceite, e não um montante financeiro. Uma equipa pode decidir que um envio de dados incerto impede o lançamento, enquanto uma inconsistência visual recuperável pode ser adiada. O valor resulta de redigir a regra antes de a pressão do lançamento influenciar a sua interpretação e de voltar a analisá-la quando o produto ou a implementação mudam.

Construir a qualidade em torno do trabalho importante

O funcionamento sem encerramentos inesperados continua a ser um indicador útil, mas deve integrar um modelo mais amplo. O processo começa com percursos completos, examina a correção, a continuidade, a clareza, a recuperação e a eficiência e, em seguida, testa os limites nos quais os estados podem divergir. A telemetria só deve ser utilizada quando responde a uma pergunta definida, e as verificações automatizadas devem ser combinadas com a inspeção direta de estados significativos.

O passo prático seguinte consiste em escolher um percurso importante e mapeá-lo desde a intenção até ao resultado confirmado. Devem adicionar-se percursos de interrupção e recuperação, atribuir-se a responsabilidade pelos estados importantes e definir-se as provas necessárias para uma decisão de lançamento. A repetição deste processo em toda a aplicação cria uma prática de qualidade baseada no trabalho útil, e não numa única medida técnica.