Garantia de qualidade

A garantia da qualidade é o conjunto de práticas destinadas a assegurar que um produto atenda aos seus requisitos e funcione corretamente, abrangendo os processos, padrões e atividades que produzem qualidade, e não apenas as atividades que verificam a sua ausência. A distinção em relação ao controle de qualidade, que é a inspeção do produto final, é mais do que terminológica: a garantia preocupa-se com a prevenção de defeitos, enquanto o controle preocupa-se com a sua detecção.

O modelo tradicional, no qual uma equipe separada testa o trabalho concluído em uma fase distinta antes do lançamento, apresenta fragilidades bem documentadas. Os defeitos são encontrados muito tempo depois de terem sido introduzidos, quando o contexto já foi esquecido e o custo da correção é mais alto. O atraso entre a escrita e o teste significa que os desenvolvedores não recebem feedback oportuno sobre seus próprios padrões de erro. E a responsabilidade pela qualidade é transferida para um grupo sem controle sobre como o trabalho foi produzido.

A prática moderna distribui a responsabilidade em vez de concentrá-la. Os desenvolvedores escrevem testes automatizados como parte do processo de desenvolvimento, a revisão de código detecta problemas antes que cheguem a qualquer ambiente, a integração contínua executa verificações a cada alteração e os especialistas em qualidade se concentram na estratégia de testes, nos testes exploratórios e nas áreas que a automação não alcança. O papel do especialista passa a ser o de viabilizar e projetar a verificação, em vez de executá-la integralmente.

A pirâmide de testes descreve a distribuição sensata da verificação automatizada. Uma base ampla de testes unitários é executada rapidamente e identifica falhas com precisão. Uma camada menor de testes de integração verifica se os componentes funcionam em conjunto. Uma camada superior restrita de testes de ponta a ponta executa jornadas completas pelo sistema real. Inverter essa estrutura, com forte dependência de testes de ponta a ponta lentos e frágeis, produz conjuntos de testes que levam horas para serem executados, falham de forma imprevisível e acabam sendo ignorados.

Os testes exploratórios continuam sendo essenciais e frequentemente subestimados em organizações focadas em automação. Os testes automatizados verificam se o comportamento especificado ainda funciona; eles não conseguem perceber que um fluxo é confuso, que uma mensagem de erro é inútil, que uma combinação não considerada produz resultados sem sentido ou que uma mudança piorou algo de uma forma que nenhuma asserção cobre. A investigação manual especializada encontra categorias de problemas que nenhuma suíte de testes consegue identificar.

As obrigações de qualidade vão muito além da correção funcional. Acessibilidade, desempenho em condições realistas, segurança, comportamento nos dispositivos e conexões que o público realmente usa e correção no tratamento de dados são todos atributos de qualidade, e organizações que verificam apenas o comportamento funcional lançam produtos que funcionam corretamente, mas que falham com uma parte substancial de seu público.

A gestão de dados de teste é uma restrição pouco glamorosa que determina o quanto disso é viável na prática. Dados realistas são necessários para encontrar defeitos realistas, enquanto dados de produção frequentemente não podem ser usados ​​diretamente devido a obrigações de privacidade, e dados sintéticos excessivamente limpos ocultam justamente os problemas que valem a pena encontrar. Estabelecer um fornecimento de dados de teste representativos e em conformidade com as normas geralmente é um pré-requisito para uma verificação significativa, e não um mero detalhe.

O argumento econômico a favor da prevenção está bem estabelecido. O custo de correção de um defeito aumenta drasticamente quanto mais tarde ele for descoberto, desde insignificante quando detectado durante o desenvolvimento até substancial quando encontrado na produção, onde também acarreta custos operacionais e de reputação. O investimento na detecção precoce, portanto, se justifica apenas por razões de custo, independentemente do argumento da experiência do cliente.

Como a qualidade é determinada pela forma como o trabalho é produzido e não pelo que acontece no final, as práticas devem ser definidas durante a entrega, e não depois dela. Na prática, isso é estabelecido dentro da desenvolvimento de produtos como parte da definição de concluído, com os critérios de acessibilidade e experiência extraídos de Auditoria de experiência do usuário padrões e os limites de desempenho de desempenho na web orçamentos, para que o que for verificado corresponda ao que o produto realmente precisa entregar.