Quem é o responsável pela qualidade no desenvolvimento de software

O desenvolvimento ágil de software e o DevOps - e sua ênfase na experiência do usuário - nos fazem focar nas pessoas por trás dos produtos. Mas o processo importa ou os fins justificam os meios? O London's P3X or People, Product, and Process Exchange se concentraram muito na interseção de seus três Ps, sendo talvez o último o mais interessante, pois reuniu mais siglas - TDD (Test-Driven Development), desenvolvimento orientado a comportamento (Behavior-Driven Development - BDD), entrega contínua (Continuous Delivery - CD), desenvolvimento orientado por domínio (Domain-Driven Development - DDD) e muito mais - para ajudar as equipes a examinar como construir sistematicamente melhores sistemas.

Cofundadora da Agile Testing Fellowship Janet Gregory terminou sua palestra sobre o processo de busca por qualidade em software pedindo à plateia cheia que levantasse as mãos se sentissem a magia em sua equipe ágil e se sentissem que estavam se espalhando com qualidade. Apenas algumas pessoas em uma auditório supostamente cheio de praticantes ágeis levantaram as mãos.

Como estamos 17 anos desde a assinatura do Manifesto Ágil e ainda temos tão poucas pessoas saindo da caverna? Talvez não tivemos as conversas certas. Talvez não vemos essas pessoas com as pessoas certas. Ou talvez as conversas não façam parte de nossos processos.

Enquanto o manifesto coloca indivíduos e interações sobre processos e ferramentas, há algo inerentemente humano nos processos. Talvez, examinando os nossos, possamos responder melhor a mudanças, aumentar nossa colaboração e diminuir os erros, tudo para satisfazer o cliente com antecedência e com maior frequência. Gregory adotou uma abordagem antiga de qualidade e aplicou-a a equipes modernas de software ágil, na esperança de que todos se apropriassem do que é lançado.

Mas afinal, o que é "Qualidade"?

Gregory estava apontando que a definição frequentemente subjetiva de qualidade deve ser definida sempre pensando no futuro. A palestrante citou "Cinco Abordagens à Qualidade", de David A. Garvin, de 1984, como uma maneira de começar a definir a qualidade:

• Transcendente - atmosfera, excelência inata, universalmente reconhecível, conquistas
• Baseado em valor - preço e custo
• Baseado no usuário - valor para alguém, para uma pessoa - essa é o que a maioria das pessoas pensa quando fala em qualidade
• Baseado em produto - O que os usuários estão procurando? (quais sabores de sorvete estão sendo oferecidos)
• Fabricação - práticas, processos, padrões, requisitos, especificações - Construímos certo?

Gregory visualizou a essência de cada categoria da seguinte maneira, irradiando-se do centro mais necessário e aplicando-a a ambientes ágeis modernos.

Qualidade Baseada em Fabricação

Primeiro, as coisas precisam funcionar, então a qualidade de fabricação têm que estar lá.

Gregory diz que isso envolve design orientado a testes porque "ao criar código limpo, o retrabalho é significativamente reduzido. Vamos fazer certo da primeira vez para não tenhamos outros bugs. Podemos entregar com confiança.

Besides TDD, Gregory said manufacturing-based processes include:

O TDD, a prática de projetar testes automatizados antes do software que está testando, que por sua vez leva ao desacoplamento do referido software, é uma parte importante da qualidade de fabricação. Gregory citou uma pesquisa que diz que as equipes que fazem o TDD têm entre 60% e 90% menos defeitos do que aquelas que não o fazem, mas o TDD leva em média a um aumento de 15% a 30% do cronograma.

Muitas equipes estão enfrentando essa problemática de velocidade e qualidade.

"Talvez seja o PO [Product Owner] dizendo que prefiro que coloque-se o novo recurso ao invés de ter a qualidade. Quem está tomando essas decisões?

Além do TDD, Gregory disse que os processos de fabricação incluem:

• Codificação para manutenção
• Monitoramento de logs de erro
• Integração contínua
• Testes exploratórios em histórias
• Testando se o produto atende às especificações
• Criação automatizada de testes para feedback rápido
• Análise estática da plataforma
• Uma definição clara de conclusão

Finalmente, Gregory disse: "Práticas como DevOps estão tentando reduzir o risco para o cliente quando entregamos ao cliente".

Qualidade baseada em produto

Simplificando, se a qualidade baseada na manufatura garante que o produto funcione, a qualidade baseada no produto garante que funcione conforme o esperado. Por exemplo, esperamos pagar por uma qualidade mais alta, mas vista grossa se algo quebrar e custar um pouco ou nada. A exceção pode ser com aplicativos que normalmente esperamos que sejam gratuitos, mas que realmente funcionem bem.

Gregory aponta que o que é definido como qualidade baseada no produto varia de acordo com o público-alvo. Alguém na contabilidade iria querer que a bandeja do teclado fosse excluída da maioria dos laptops hoje em dia.

É tudo uma questão de perguntar:

• Estamos construindo a coisa certa?
• Estamos colocando os recursos que queremos?

Isso inclui:

• Desenvolvimento Orientado a Teste de Aceitação (Acceptance Test-Driven Development - ATDD) ou às vezes chamado de Desenvolvimento Orientado a Testes de História - trazendo clientes-chave para a fase de TDD
• Testes de segurança
• Bug bashes - como um hackathon de equipe para encontrar tantos bugs quanto possível
• Entrega contínua
• Testes exploratórios em recursos
• Versões Beta
• Teste de performance
• Teste de carga

Qualidade baseada no usuário

É aí que as perspectivas mais variam. Como Gregory disse: "Pessoas diferentes escolhem coisas diferentes. Eles têm desejos diferentes, necessidades diferentes. Se estamos tentando deixar o cliente escolher, faça os clientes felizes."

Mas não se esqueça de ter em mente, continuou: "Também estamos fazendo uma grande suposição de que os consumidores têm informações suficientes para tomar uma decisão qualificada".

Ela falou de um aplicativo que ela usou uma vez que achou totalmente não amigável. Os usuários adoraram porque seguiam exatamente como eles funcionavam. Gregory não trabalhava nesse campo. Trata-se de conhecer os casos de uso específicos dos usuários específicos.

Qualidade baseada em valor

Este é simplesmente o que as pessoas estão dispostas a pagar. Valor é difícil de julgar, basicamente impossível julgar sem falar com seus potenciais clientes.

A qualidade baseada em valor é avaliada com alguma combinação de:

• Eficácia
• Eficiência
• Conforto
• Confiança
• Complexidade
• Ajuste de contexto

Qualidade Transcendente

Finalmente a qualidade mais incomensurável - transcendência. Gregory disse que é difícil porque é complicado medir a emoção, tornando a qualidade transcendente uma mistura de arte, envolvimento e fidelidade do cliente.

Como medimos a qualidade do software?

No geral, se aceitar a escala de qualidade da Garvin, será difícil medir a maior parte da qualidade do software. Gregory citou Isabel Evans na medição de qualidade em software. Existem muitos exemplos de qualidade de fabricação:

• Número de bugs na produção
• Gravidade de bugs na produção
• Dias desde o último envio para produção
• Número de novos tickets de suporte em X dias desde o último envio de produção
• O monitor de bugs continua verde
• Nenhum teste automatizado em pedaços (Falhas aleatórias)
• A análise de código estático da base de código é saudável
• As taxas de retrabalho são baixas
• Bugs não são reabertos

Também pode haver uma medida de qualidade baseada no usuário na forma de pesquisas de satisfação do usuário.

No entanto, não se pode medir a qualidade baseada em produto, valor ou qualidade transcendente. Pode-se, no entanto, discutir e avaliar todas as cinco camadas de qualidade. O teste é uma medida importante de qualidade, mas Gregory lembrou que as equipes de produto não podem negar o valor de discutir a qualidade entre si, com os usuários e em relação aos concorrentes.

É claro que as equipes precisam descobrir um equilíbrio entre o desejo de evitar erros e aqueles que querem velocidade.

A equipe toda é responsável pela qualidade

O que está claro é que a garantia de qualidade - ou um esforço em direção a essa impossibilidade equivocada - não é apenas o trabalho de um departamento, testando, quando o código é jogado no colo de algumas pessoas.

Toda a equipe possui qualidade

Gregory comentou que, "se a sua organização, se a sua empresa começa com a qualidade em mente, sua equipe provavelmente terá sucesso, porque todo o resto se encaixa. Tudo apenas funciona. Mas se começar com a ideia de que a velocidade é a coisa mais importante, não prestar atenção à qualidade, as chances são de que, a longo prazo, haverá muito retrabalho, muito código insustentável e sua qualidade diminuirá. mais e mais,"

Mas ela não ofereceu uma receita secreta para a busca perfeita de qualidade.

"Se sua equipe usa análises quantitativas ou qualitativas, não me importo, precisamos nos perguntar o que estamos olhando - isso leva à capacidade de entregar com confiança?", Disse Gregory. "A medição da qualidade do processo mede a qualidade do produto?"

Ela citou o coautor do Livro 1 do BDD: Discovery Seb Rose: "Quando uma medida se torna um alvo, deixa de ser uma boa medida".

"Não importa como se mede, mas sim o fato disso levar a uma conversa, uma discussão sobre o que se precisa ser feito", disse Gregory.

Ela continuou: "A equipe possui qualidade, mas tem que se pensar em algo maior que isso. Qualidade nos processos e qualidade nas práticas. Competência em sua equipe, competência em como se entrega o software. "

Ela terminou dizendo que toda conversa nessa direção é melhor se começar com pessoas tentando resolver um problema.

"Vamos criar um gerenciamento de qualidade em nosso processo e aprender a falar sobre o que fazemos", disse Gregory.

Sobre os autores

Atualmente sediada em Londres, Jennifer Riggins é uma contadora de histórias e escritora de tecnologia, onde a transformação digital encontra a cultura, esperançosamente mudando o mundo para um lugar melhor. Siga-a no Twitter @jkriggins.

Fundadora da Agile Testing Fellowship, Janet Gregory passou mais de 14 anos ajudando as equipes a fazer a transição para um ambiente ágil de desenvolvimento de software, especializando-se em ajudar os testadores e as empresas a entenderem seu papel como parte da "abordagem de toda a equipe".