Mas como podemos medir a qualidade do produto? Pela sua estabilidade? Escalabilidade? De fácil manutenção? Código livre de bugs?
Provavelmente existem muitas definições para o que é um bom produto, mas, na minha opinião, as duas bases são o comportamento e a funcionalidade do produto, conforme definido (esteja alinhado com os requisitos do desenvolvimento do produto) e zero bugs críticos. O produto pode atender a muitos objetivos, mas se não atingir o principal, pode não ter um motivo para existir. Naturalmente, nossa comunidade sempre esperam alta qualidade de nossos produtos; portanto, antes de liberá-lo para o controle de qualidade da produção, verificamos se não existem erros críticos.
Para respeitar essas duas etapas, tanto a pesquisa quanto o desenvolvimento e o controle de qualidade devem ser totalmente comprometidos aqui. Da perspectiva do controle de qualidade, as coisas podem se complicar durante a execução de testes de extremo a extremo que envolvem a interface do usuário / UX. Por que é que?
Teste entre navegadores - 9 ambientes diferentes
Todos os envolvidos com o produto devem se perguntar qual é o público-alvo do produto. Em outras palavras, diferentes localizações geográficas determinam o uso diferente do navegador. Por exemplo, se eu gostaria de abordar uma audiência de desktop nos EUA, provavelmente começaria minha cobertura de teste com o Chrome, opera, Firefox e Internet Explorer. Abaixo está um vislumbre dos dados extraídos do Statcounter:
Mas é claro que o produto deve ser executado em navegadores adicionais, que também devem ser suportados. a menos que o produto seja executado apenas em um navegador. Nesse caso, no ambiente de área de trabalho, o controle de qualidade deve abranger Chrome (PC e Mac), opera, Internet Explorer, Safari e Firefox. Quanto aos dispositivos móveis, devemos cobrir o Chrome no Android e Safari e Chrome no iOS.
Configure seus testes
Todo novo produto, ou mesmo um recurso, possui configurações diferentes. Portanto, além de uma verificação de sanidade, também devemos fazer testes de regressão que devem ser focados em novas funcionalidades nas diferentes configurações.
Um recurso simples pode ser composto de muitos parâmetros que podem obter valores diferentes, representando estados diferentes do produto.
Ao examinar a cobertura do teste, encontramos uma matriz tridimensional que consiste em casos de teste do Navegador X Configurações X. Abaixo está um exemplo dessa matriz.
Olhando para a matriz por um recurso que testamos há algum tempo, podemos encontrar, por exemplo, 9 casos de teste de Navegadores X 3 Configurações X 53, que somam ~ 1500 testes.
Além de executar a matriz, há muitos itens de ação que devem ser tomados pelo lado do controle de qualidade antes de começar a executar os testes. Aprendendo com falhas e sucessos do passado durante nossos ciclos de controle de qualidade, começamos a adaptar uma nova abordagem para gerenciar nossos testes.
Em um mundo perfeito, o controle de qualidade deve executar todos os cenários em todas as configurações e ambientes para fornecer uma luz verde para a produção. Obviamente, este não é o caso. Sendo a última roda antes da produção, o controle de qualidade deve encontrar a seção ideal entre qualidade e consumo de tempo, o que envolve correr riscos.
QA Kickoff
Para economizar tempo e estar o mais pronto possível, antes que o recurso esteja pronto para teste, o controle de qualidade pode começar a criar a matriz de teste de acordo com as especificações que contêm os casos de teste relevantes.
Uma boa dica aqui será fazer uma análise de teste com outro engenheiro de controle de qualidade para obter feedback e ter uma discussão aberta sobre a matriz - alterar, adicionar ou remover casos de teste. Na verdade, é muito semelhante à revisão de código feita pelo dev. Depois disso, é recomendável fazê-lo também com o PM dev relevante, a fim de definir expectativas - o que é testado e onde, enquanto gerencia o risco e fornece estimativas de tempo.
Naturalmente, quando o dev terminar sua parte, o próximo passo é começar a executar a matriz de teste. Pela minha experiência, existem algumas etapas necessárias que devem ser feitas com antecedência. É recomendável que o controle de qualidade faça uma transferência com o desenvolvedor para entender o que foi desenvolvido, quais configurações / parâmetros devem ser usados, como deve ser e, o mais importante - faça perguntas sobre o comportamento, os ambientes, a lista de problemas conhecidos etc. …
Antes de mover o recurso para o controle de qualidade, os desenvolvedores geralmente estão executando alguns testes, para garantir que o recurso não esteja quebrado. Muitas vezes, o desenvolvedor cria seu próprio ambiente (maquetes, ferramentas, configuração, páginas de teste) para teste e, posteriormente, o controle de qualidade também o usa. Isso pode ser prejudicial de duas maneiras: o controle de qualidade não entende o processo de criação dessa configuração e, portanto, você fica na sua zona de conforto, sem pensar em outras configurações. Fazendo isso, você está perdendo possíveis erros. É sempre preferível que o controle de qualidade crie seu próprio ambiente e o use independentemente do ambiente do desenvolvedor. Por último, mas não menos importante, é sempre útil revisar documentos de teste antigos e bugs antigos relacionados à mesma área que você está testando, a fim de verificar diferentes problemas que não estavam no escopo.
Mãos em
Já estamos prontos para começar com a matriz? Depende.
Você pode se apressar em cobrir a matriz, mas o risco aqui é detectar bugs em um estágio posterior, o que pode atrasar a implantação na produção.
Algumas coisas que podem ajudar aqui: Crie um "fluxo feliz" básico que teste o recurso diretamente (sem casos especiais) e execute-o em todos os ambientes (SOs). Essa é a sanidade muito básica para verificar se o recurso está funcionando e não está quebrando mais nada. Além disso, eu rodava com o recurso apenas no Chrome (o navegador mais usado hoje em dia) e fazia alguns testes de estilo livre, alterando alguns sinalizadores e verificando se o comportamento é esperado.
Em algumas horas, a execução dessas duas etapas fornece ao controle de qualidade uma aparência básica do recurso, um pouco de confiança sobre sua estabilidade e também pode trazer novas idéias para casos de teste adicionais.
Se nenhum bug do bloqueador foi encontrado durante a última sessão, o controle de qualidade pode prosseguir com a matriz. De acordo com os prazos, é uma decisão comum verificar a matriz inteira ou cobri-la parcialmente. Em projetos muito importantes, tendemos a cobrir tudo, sem exceder os prazos razoáveis. Embora a maioria dos projetos não seja considerada super importante, nosso plano é verificar todos os casos de teste no Chrome. Quanto aos outros navegadores, é sua decisão quais caixas devem ser cobertas na matriz de teste e quais testes você fará - resultando em uma combinação de aleatoriedade com alguma decisão intencional.
Aprender com os erros do passado, nos incentivou a criar novos procedimentos em nosso processo de controle de qualidade e nos deu mais confiança na liberação de produtos estáveis e de trabalho.
