Os Squads e o redesenho das áreas de testes:

Observo com frequência no desenho das TIs das grandes empresas a existência de áreas de testes que operam com as seguintes premissas:

Operação como uma área física separada e apartada do projeto de desenvolvimento;
Acionamento baseado em ordens de serviço para a execução de testes;
Predominância de testes funcionais feito de forma manual;
Participação tardia em um projeto – o envolvimento dos analistas de testes começa do meio do projeto para a frente;
Pouco contato físico com os desenvolvedores;
E o mais interessante é que vários gestores se orgulham dessas áreas funcionais de testes e acreditam que esse modelo é completamente natural. Só que não!

A Origem do Mal — Áreas Funcionais

Quando temos longos tempos de implantação de software normalmente observamos milhares de operações necessárias para mover nosso código do controle de versão para o ambiente de produção. Para transmitir código através do fluxo de valor de TI, vários departamentos precisam trabalhar em uma variedade de tarefas, incluindo testes funcionais, testes de integração, criação de ambientes, administração de servidores, administração de armazenamento, rede, balanceamento de carga e segurança de informações.

Cada vez que o trabalho passa de equipe para equipe, exigimos todos os tipos de comunicação: solicitando, especificando, sinalizando, coordenando e muitas vezes priorizando, agendando, desconstruindo, testando e verificando. Isso pode exigir o uso de diferentes sistemas de tíquetes ou gerenciamento de projetos; escrever documentos de especificação técnica; comunicação via reuniões, e-mails ou telefonemas; e usando compartilhamentos de sistema de arquivos, servidores FTP e páginas Wiki.

Cada uma dessas etapas é uma fila em potencial onde o trabalho aguardará quando dependermos de recursos que são compartilhados entre diferentes fluxos de valor (por exemplo, operações centralizadas de áreas de testes). Os tempos de espera para essas solicitações costumam ser tão longos que há uma escalada constante para que o trabalho seja executado dentro dos cronogramas necessários.

Mesmo nas melhores circunstâncias, algum conhecimento é inevitavelmente perdido a cada entrega. Com transferências em excesso (handoffs), o trabalho pode perder completamente o contexto do problema que está sendo resolvido ou a meta organizacional sendo suportada. Por exemplo, um analista de testes pode ver um ticket recém-criado solicitando que um teste funcional seja realizado em uma tela sem saber o contexto, impacto e sem ter contato com o time que implementou o código.

O Crescimento do Mal e os Desperdícios na TI

Shigeo Shingo, um dos pioneiros do Sistema Toyota de Produção, acreditava que os “resíduos” constituíam a maior ameaça à viabilidade dos negócios — a definição comumente usada no Lean é “o uso de qualquer material ou recurso além do que o cliente requer e está disposto a pagar”. Ele definiu sete tipos principais de resíduos de fabricação: estoque, superprodução, processamento extra, transporte, espera, movimento e defeitos.

Interpretações mais modernas de Lean observaram que “eliminar o desperdício” pode ter um contexto depreciativo na TI. Ao invés, a meta é reformulada para reduzir as dificuldades e o trabalho penoso em nosso trabalho diário por meio do aprendizado contínuo, a fim de atingir as metas da organização. No livro Implementando o Desenvolvimento de Software Lean: Do Conceito ao Dinheiro, Mary e Tom Poppendieck descrevem o desperdício e as dificuldades na execução do fluxo de desenvolvimento de software como algo que causa atraso para o cliente, como atividades que podem ser contornadas sem afetar o resultado.

Quando apartamos o time de testes do trabalho diário do desenvolvimento incorremos em desperdícios diversos, abaixo apontados.

1. Trabalho parcialmente concluído: inclui trabalhos no fluxo de valor que não foram concluídos e trabalhos em fila (por exemplo, aguardando revisão de controle de qualidade ou a execução de teste funcional). O trabalho parcialmente feito torna-se obsoleto e perde valor à medida que o tempo avança. Em algumas empresas, passam-se semanas para que um um código subido para o repositório de código seja efetivamente testado.

2. Processos extras: qualquer trabalho adicional que esteja sendo executado em um processo que não agregue valor ao cliente. Processos extras adicionam esforço e aumentam o lead time. Quando colocamos pessoas de testes em áreas apartadas operando em seu próprio ciclo estamos criando handoffs artificiais e aumentando o lead time.

3. Alternância de tarefas: quando as pessoas são atribuídas a vários projetos e fluxos de valor, exigindo que elas alternem o contexto e gerenciem dependências entre o trabalho, estamos adicionando esforço e tempo adicionais ao fluxo de valor da TI. Por exemplo, fazer que analistas de testes trabalhem em múltiplos projetos e realizem testes de projetos diferentes em um único dia irá inevitalmente gerar prejuízo para todos os projetos.

4. Espera: Qualquer atraso entre o trabalho que requer recursos para esperar até que eles possam concluir o trabalho atual. Atrasos aumentam o tempo de ciclo e impedem que o cliente obtenha valor. Quando criamos filas entre desenvolvedores e testadores estamos introduzindo esperas desnecessárias.

5. Movimento: A quantidade de esforço para mover informações ou materiais de uma função para outra. O desperdício de movimento pode ser criado quando as pessoas que precisam se comunicar com frequência estão distantes fisicamente ou não tem equipamentos virtuais adequados em times geograficamente distribuídos. As transferências também criam desperdício de movimento e geralmente requerem comunicação adicional para resolver ambiguidades. Quando analistas de testes e desenvolvedores estão longe e se comunicam apenas por ferramentas e emails estamos criando movimento desnecessário.

6. Defeitos: informações, materiais ou materiais incorretos, ausentes ou pouco claros geram desperdício, pois é necessário esforço para resolver esses problemas. Quanto maior o tempo entre a criação de defeitos e a detecção de defeitos, mais difícil é resolver o defeito.

7. Trabalho manual: dependência de trabalho não padronizado ou manual de outras pessoas, como a configuração manual de servidores, ambientes de teste e configurações. Idealmente, quaisquer dependências devem ser automatizadas, realizada em modo self-service disponíveis sob demanda.

Reorganizado o trabalho da qualidade — O princípio do Feedback

Analistas de testes e desenvolvedores devem desenvolver um sistema de feedback diário, preferencialmente através de contato físico direto. Photo by rawpixel on Unsplash.

Iremos tornar o nosso sistema de trabalho mais seguro através da criação de fluxo de informações rápido, frequente e de alta qualidade em todo o fluxo de valor e em nossa organização, o que inclui feedback frequente entre todas as pessoas e funções. Isso permite detectar e corrigir problemas enquanto eles são menores, mais baratos e mais fáceis de consertar; evitar problemas antes que causem catástrofe; e criar aprendizado organizacional que integramos no trabalho futuro. Quando fracassos e acidentes ocorrem, devemos trata-los como oportunidades de aprendizado, em oposição a uma causa de punição e culpa.

Uma das características que define um sistema complexo é que ele desafia a capacidade de qualquer pessoa de ver o sistema como um todo e entender como todas as partes se encaixam. Os sistemas complexos normalmente possuem um alto grau de interconectividade de componentes fortemente acoplados, e o comportamento no nível do sistema não pode ser explicado meramente em termos do comportamento de cada componente individual do sistema.

Falhas são inerentes e inevitáveis em sistemas complexos. E então devemos projetar um sistema de trabalho seguro onde possamos executar o trabalho sem medo, confiantes de que quaisquer erros serão detectados rapidamente, muito antes de causarem resultados catastróficos como danos aos trabalhadores, defeitos no produto ou impacto negativo no cliente.

Projetar sistemas perfeitamente seguros está além da capacidade de qualquer time, mas podemos tornar mais seguro trabalhar em sistemas complexos quando as quatro condições a seguir são atendidas:

  • O trabalho complexo é gerenciado para que os problemas no design e nas operações sejam revelados;
  • Os problemas são tratados coletivamente e resolvidos, resultando na rápida construção de novos conhecimentos;
  • Novo conhecimento local é explorado globalmente em toda a organização;
  • Os líderes criam outros líderes que continuamente aumentam as capacidades da organização.

Em um sistema de trabalho seguro, devemos testar constantemente nossas premissas de projeto e operação. Nosso objetivo é aumentar o fluxo de informações em nosso sistema de tantas áreas quanto possível, mais cedo, mais rápido, mais barato e com tanta clareza entre causa e efeito quanto possível. Quanto mais suposições possamos invalidar, mais rápido podemos encontrar e corrigir problemas, aumentando nossa resiliência, agilidade e capacidade de aprender e inovar.

No fluxo de valor de TI, muitas vezes obtemos resultados ruins devido à ausência de feedback rápido. Por exemplo, em um projeto de software em cascata, podemos desenvolver código para meses e não obter feedback sobre qualidade até começarmos a fase de testes — ou, pior ainda, quando lançamos nosso software para os clientes. Quando o feedback é atrasado e pouco frequente, o sistema se torna muito lento para nos permitir evitar resultados indesejáveis.

Em times de TI de alta performance, o nosso objetivo é criar feedback rápido em todos os estágios do fluxo de valor de tecnologia, abrangendo Gerenciamento, Desenvolvimento, Controle de Qualidade, Segurança da Informação e Operações do Produto. Isso inclui a criação de processos automatizados de criação, integração e teste, para que possamos detectar imediatamente quando uma alteração foi introduzida que nos tire de um estado de funcionamento e implementação corretos.

Também devemos criar telemetria abrangente para que possamos ver como todos os nossos componentes de sistema estão operando no ambiente de produção, para que possamos detectar rapidamente quando eles não estão operando conforme o esperado. A telemetria também nos permite medir se estamos atingindo nossas metas pretendidas e, idealmente, é irradiada para todo o fluxo de valor, para que possamos ver como nossas ações afetam outras partes do sistema como um todo.

Os loops de feedback não apenas permitem a rápida detecção e recuperação de problemas, mas também nos informam sobre como evitar que esses problemas ocorram novamente no futuro. Isso aumenta a qualidade e a segurança de nosso sistema de trabalho e cria aprendizado organizacional.

Controles de Qualidade Devem Ficar Perto da Fonte

Podemos inadvertidamente perpetuar sistemas inseguros de trabalho devido à forma como reagimos aos erros e incidentes. Em sistemas complexos, adicionar mais etapas de inspeção e processos de aprovação somente aumenta a probabilidade de falhas futuras. A eficácia dos processos de aprovação diminui à medida que forçamos a tomada de decisão mais longe de onde o trabalho é realizado. Fazer isso não apenas diminui a qualidade das decisões, mas também aumenta nosso tempo de ciclo, diminuindo assim a força do feedback entre causa e efeito e reduzindo nossa capacidade de aprender com os sucessos e fracassos.
Isso pode ser visto até mesmo em sistemas menores e menos complexos. Quando os sistemas burocráticos de comando e controle hierárquicos se tornam ineficazes, geralmente é porque a variação entre “quem deveria fazer algo” e “quem está realmente fazendo alguma coisa” é muito grande, devido à falta de clareza e pontualidade.

Exemplos de controles de qualidade ineficazes incluem:

  • Exigir que outra equipe conclua tarefas tediosas, propensas a erros e manuais que possam ser facilmente automatizadas e executadas conforme a necessidade da equipe que precisa do trabalho executado.
  • Exigir aprovações de pessoas ocupadas que estão distantes do trabalho, forçando-as a tomar decisões sem um conhecimento adequado do trabalho ou das possíveis implicações, ou simplesmente carimbando suas aprovações.
  • Criar grandes volumes de documentação de detalhes questionáveis ​​que se tornam obsoletos logo após serem escritos.
  • Empurrar grandes lotes de trabalho para equipes e comitês especiais para aprovação e processamento e, em seguida, aguardando respostas

Em vez disso, precisamos que todo nosso fluxo de valor as pessoas encontrem e corrijam problemas em sua área de controle como parte de nosso trabalho diário. Ao fazer isso, impulsionamos as responsabilidades de qualidade e segurança e a tomada de decisões para onde o trabalho é realizado, em vez de depender de aprovações de executivos distantes.

Usamos revisões por pares nas alterações de código para obter qualquer garantia necessária para que nossas alterações funcionem conforme o projetado. Nós automatizamos o máximo possível da verificação de qualidade normalmente executada por um departamento de controle de qualidade ou de segurança da informação. Em vez de os desenvolvedores precisarem solicitar ou agendar um teste para ser executado, esses testes podem ser executados sob demanda, permitindo que os desenvolvedores testem rapidamente seu próprio código e até implementem essas alterações na produção.

Ao fazer isso, realmente tornamos a qualidade de responsabilidade de todos, em vez de ser responsabilidade exclusiva de um departamento separado. A segurança da informação não é apenas o trabalho da Segurança da Informação, assim como a disponibilidade não é apenas o trabalho do time de operações.

Ter os desenvolvedores compartilhando a responsabilidade pela qualidade dos sistemas que eles criam não apenas melhora os resultados, mas também acelera o aprendizado. Isso é especialmente importante para os desenvolvedores, já que eles geralmente são a equipe mais distante do cliente.

Para atenuar esses tipos de problemas, nos esforçamos para reduzir o número de transferências, seja automatizando partes significativas do trabalho ou reorganizando as equipes para que elas possam agregar valor ao próprio cliente, em vez de depender constantemente de outras pessoas. Como resultado, aumentamos o fluxo reduzindo a quantidade de tempo que o nosso trabalho gasta esperando em fila, bem como a quantidade de tempo gasto em atividades que não agregam valor de negócio.

E o que acontece com os analistas de testes?

A figura acima foi proposta por Neilf Pfleding em seu excelente livro Organizar para Complexidade. O desenho da esquerda representa as TIs com áreas funcionais. Ela modela uma estrutura da era industrial que consegue operar bem com trabalhos simples e complicados, mas fracassa miseravelmente para trabalhos complexos, que são a tônica da TI. Já o desenho da direita mostra estruturas orgânicas onde testadores e desenvolvedores trabalham junto e em permanente comunicação. A figura da direita é mais apropriado para o trabalho em ambientes complexos.
Analistas de testes devem ser envolvidos desde o início do projeto e gerar especificações de testes antes que cada história seja implementada, preferencialmente executáveis como abordagens BDD.

Analistas de testes devem trabalhar lado a lado com analistas de negócio e desenvolvedores, observando em tempo real o resultado dos builds, executando testes em base diária e gerando feedbacks no mesmo ritmo para os desenvolvedores (do lado deles, e não através de ferramentas de defeitos). Desenvolvedores recebem feedback pela manhã para endereçar novos casos de testes em seus códigos e tratar defeitos e a cada dia novos builds mais poderosos são gerados pelo time.

Analistas de testes devem privilegiar a criação de testes automatizados, com ênfase para testes de unidade sobre testes funcionais. A respeito, o modelo da pirâmide de testes representa essa mudança de paradigma.

Testes de unidade automatizados são mais baratos para construir e mais rápidos para executar. O conceito foi documentado por Martin Fowler em blog.

E, finalmente, não deve haver “times de testes”, assim como não devemos ter “times de desenvolvedores”. Da mesma forma, no futebol não existe o “time dos laterais” e o “time dos atacantes”. Existe o time de futebol. E no desenvolvimento de software, deve existir o “time de produto”, com o goleiro, centro-avante e outros papéis necessários para fazer gols, defender a sua meta e vencer a partida.

Categorias: Agilidade

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *