Um ano e meio atrás, destruímos a equipe de teste: desistimos da regressão, transferimos os autotestes E2E para o Selenium para dar suporte aos desenvolvedores e fomos para as equipes que viram recursos para evitar bugs à nascença. Em sonhos otimistas, parecia-nos que seria mais útil: o controle de qualidade funciona com a qualidade, os testes começam cedo e os desenvolvedores escrevem autotestes e ninguém os incomoda.
Mas
Quais são as consequências de primeira e segunda ordem
Ray Dalio em Principles tem o conceito de "consequências de segunda ordem". Essas são consequências não óbvias de nossas decisões que muitas vezes não podemos prever. Por exemplo, nos anos 60 do século 20, uma guerra com pardais foi lançada na China. Os pardais comiam grãos e, para que parassem de comê-los, a China começou a caçar pássaros. Durante a caça, os chineses mataram quase dois bilhões de pássaros em massa.
Como resultado do genocídio dos pardais, a colheita aumentou depois de um ano. Essas são consequências de primeira ordem. Mas não havia ninguém para comer insetos e gafanhotos e lagartas se multiplicaram, o que começou a destruir ainda mais safras, o que levou a uma fome massiva na China nos anos seguintes. Essas são consequências de segunda ordem.
As consequências de primeira ordem são consequências diretas de nossas decisões e estão sempre na superfície. As consequências de segunda ordem são sutis e frequentemente de longo prazo. Para entendê-los, você precisa pensar e simular a situação. Por exemplo:
- Se você pagar aos desenvolvedores pelo número de linhas de código, haverá mais código, mas a qualidade será pior. Com o tempo, as pessoas começarão a trapacear e produzir mais e mais códigos ruins para conseguir mais dinheiro. Essas são consequências de segunda ordem.
- Se você começar a se exercitar, vai doer no começo e demorará muito. Mas depois de um tempo (de uma semana a meses), um hábito surgirá e a saúde e a aparência irão melhorar. Essas são consequências de segunda ordem.
- Se você ficar bêbado como um porco toda sexta-feira, a noite de sexta será bom. Mas a manhã de sábado será ruim - essas são consequências de segunda ordem. E se você fizer isso regularmente, durante anos, talvez isso evolua para alcoolismo e cirrose hepática. Mas essas já são consequências de terceira ordem e "uma história completamente diferente".
Tínhamos uma equipe de QA e a "dispersamos"
Agora vou contar como sentimos as consequências da primeira e da segunda ordem. Tínhamos uma equipe dedicada e aconchegante de testadores de 7 pessoas: 4 deles escreveram autotestes e 3 os testaram manualmente. Em algum momento, decidimos nos separar e nos dispersar em equipes. Por quê?
Porque os desenvolvedores receberam feedback tarde demais.
Os bugs estavam na fase em que todo o desenvolvimento estava “finalizado”, tudo estava “integrado” e era necessário verificar se o produto estava pronto para o lançamento. Não houve teste de aceitação , ele foi realizado por analistas de produto que não tinham habilidades de teste. Além disso, os testadores e desenvolvedores estavam em mundos diferentes e tinham pouca interação.
A solução óbvia (então) é dividir as equipes que trabalham em certos recursos (partes) do sistema para evitar bugs pela raiz. Não queríamos desistir de nosso trabalho, então decidimos transferir nossas funções para os desenvolvedores. Pensamos em autotestes - vamos entregá-los aos desenvolvedores e eles vão se testar sem problemas.
No início, eles decidiram testar a hipótese em nós mesmos com um "experimento": cobriremos os cenários críticos de regressão com testes automáticos e recusaremos a regressão manual. Se, como resultado da experiência, o número de hotfixes e rollbacks de liberação não aumentar drasticamente, o experimento pode ser considerado bem-sucedido. E assim aconteceu - não havia mais hotfixes. Resolvido - discordo.
Nota . A empresa possui um produto denominado Restaurante. Inclui todos os serviços e nosso monólito. O objetivo do produto é automatizar e otimizar o trabalho de todos os funcionários do restaurante, tanto quanto possível. Nosso trabalho agora se concentra mais na prevenção de erros. Agora somos QA no produto "Restaurante": desenvolvemos as qualidades do produto, participamos de todas as etapas do desenvolvimento da tarefa.
Consequências de primeira e segunda ordem
Consequências diretas . Como esperado, começamos a nos envolver no desenvolvimento de tarefas desde o início, para participar da PBR, planejamento, workshops e levar a experiência de teste para eles. Ficamos mais próximos das equipes de desenvolvimento, ou melhor, parte delas, e nossos problemas também eram os problemas da equipe. Expertise em testes, garantia de qualidade e amplo conhecimento do sistema começaram a crescer nas equipes. Nós, por sua vez, começamos a mergulhar no trabalho dos desenvolvedores e entender suas dores.
Agora, o que não planejamos são consequências de segunda ordem .
Ninguém impulsiona a qualidade do produto . Existem 2 lados para este problema:
- qualidade em termos de processos;
- qualidade de autotestes e pipeline.
Em nossa equipe de controle de qualidade dedicada, impulsionamos a qualidade. Fomos os últimos a ver o produto na frente dos usuários e a entender como eles o veem. Discutimos mudanças e melhorias no time retro, viemos com propostas para as equipes de desenvolvimento para decidirem juntas se deveriam ou não ser introduzidas. Monitoramos os autotestes e trabalhamos em sua estabilidade.
Depois que nos dispersamos em equipes, tudo desapareceu em algum lugar. Na equipa de desenvolvimento, fazemos parte da equipa, fazemos parte do
Todas as ideias visavam apenas melhorar o estado da equipe - fizemos de tudo para lançar um recurso de qualidade, não um produto de qualidade. Como resultado, soluções fundamentalmente fortes que podem elevar a qualidade do produto a um novo nível deixaram de aparecer.
A competência de escrever autotestes desapareceu - os autotestes começaram a se dobrar e cair com mais frequência sem alterar o código. No momento em que a equipe foi dissolvida, os testadores manuais estavam apenas começando a entender os fundamentos da automação. Descobriu-se que nem os testadores nem os desenvolvedores tinham experiência. Além disso, os grãos de conhecimento ficaram confusos quando as pessoas que escreveram esses testes foram para o desenvolvimento, gerenciamento de produto e alguém saiu.
Não sabíamos de forma confiável quais autotestes temos, o que eles cobrem, não sabíamos como eles desenvolvem, evoluem, adicionam e removem - tudo foi deixado à mercê dos desenvolvedores. Como resultado, quando era necessário encontrar alguma informação em autotestes, era aquele tipo de busca que você não conseguiria descobrir sem um desenvolvedor.
Trabalho extra para desenvolvedores . É difícil ser um desenvolvedor. Se antes eles se acostumaram a escrever o código do produto, que é checado de uma forma "mágica" e vai para a produção, agora eles precisam escrever testes, editar e estabilizar. Na PBR, determinamos quais cenários devem ser cobertos pelos testes e os próprios desenvolvedores escolhem o nível dos autotestes.
Os desenvolvedores passaram por vários estágios de aceitação da
Negação... Todos os lançamentos do Dodo IS são implementados por desenvolvedores. Eles organizam o processo, se comunicam com a equipe de teste de carga, examinam os logs e monitoram durante o lançamento. Os desenvolvedores que lançaram o lançamento, confrontados com o teste vermelho, não tentaram descobrir o motivo, mas simplesmente reiniciaram o pipeline até que ele ficasse verde 5-7-10 vezes. Isso porque não havia confiança nos autotestes.
O número máximo de reinicializações que encontrei é 44 vezes !!! Parece-me que a regra que adotamos em um dos retro “Não lance com testes vermelhos. Se o teste estiver vermelho, descubra qual é o problema. Se o problema estiver nos testes, corrija ou assine e faça um cartão para desbloquear o teste e adicione à lista de pendências. "
Raiva : os desenvolvedores juraram em nossos testes, eles disseram que
Não houve barganha e depressão, a aceitação veio imediatamente : os desenvolvedores agora podem escrever testes E2E para UI e API eles próprios, estabilizá-los e melhorá-los.
O número de bugs à venda começou a aumentar . Bugs não críticos começaram a entrar em produção. Há várias razões para isso:
- Nossos autotestes não cobrem todas as funcionalidades, mas apenas as críticas. E não há mais teste de regressão manual.
- Não havia engenheiros de controle de qualidade suficientes para todas as equipes. As equipes não tinham competências de teste, então não prestaram a devida atenção aos testes
Como resultado, começamos a encontrar acidentalmente bugs na produção. Não são críticos, mas quantos deles em geral não foram imaginados.
Como resolvemos esses problemas
Talvez outra equipe pudesse ter previsto todas as consequências não óbvias, mas nós não. Tomamos uma decisão, depois de alguns meses vimos as consequências e começamos a eliminá-las.
Criou uma guilda de QA de restaurante ou comunidade de prática, que incluía todos os QAs de restaurante. O objetivo da comunidade é impulsionar a qualidade de todo o produto, para espalhar boas práticas de teste para todas as equipes de produto. Esta é uma formação que combina as vantagens de uma equipe de QA dedicada e também nos beneficiamos de ser QA na equipe de desenvolvimento.
Nos encontramos uma vez por semana: compartilhamos resultados, descobertas e planejamos trabalhar juntos na qualidade. Também alocamos vários slots por semana para trabalhar nas tarefas da guilda. Por exemplo, estamos terminando nosso robô assistente para liberadores.
Dever... A guilda cobre parcialmente o problema da falta de dono e autotestes de qualidade. Mas a guilda não tem grandes competências em desenvolvimento e automação, então nosso CTO tomou uma decisão obstinada e organizou uma tarefa no pipeline.
Agora, os desenvolvedores podem melhorar sistematicamente o processo de pipeline: estabilizar, encontrar problemas que atrasam os lançamentos e corrigi-los. Um desenvolvedor da equipe de desenvolvimento se torna o proprietário do pipeline por um mês e o aprimora sistematicamente. Não liberando, mas melhorando - torna o processo de lançamento e suporte de testes fácil e sem esforço. Agora que as métricas do produto melhoraram, nos livramos deste atendente, mas podemos devolvê-lo a qualquer momento. (Ao escrever um artigo, nós o devolvemos porque o aviso começa a degradar a estabilidade)
Cursos... Fechamos o problema de falta de competências com cursos para testadores manuais e trabalho pareado com desenvolvedores com experiência em automação.
Trabalho extra para desenvolvedores . Não há nada que você possa fazer sobre isso, os desenvolvedores acabaram de chegar ao estágio de aceitação de autotestes. Agora eles escrevem testes E2E, se os de nível inferior não podem cobrir um recurso, e eles estabilizam o pipeline. Como se costuma dizer em livros inteligentes, é uma boa prática quando toda a equipe e desenvolvedores e testadores podem escrever testes. Também afeta nossa viagem ao lado de microsserviços bebidos do monólito. Existem menos testes no monólito, e cada vez mais em repositórios separados, o pipeline se torna mais estável.
Nós investigamos o produto... Resolvemos problemas com bugs na produção, começando a investigar o produto em busca de inconsistências com o comportamento esperado. Agendamos sessões semanais de teste exploratório. E trazemos bugs para o backlog para o product owner.
O que faríamos agora?
Deixar de considerar as consequências de segunda e terceira ordem levou a decisões erradas. É especialmente perigoso quando a primeira e não a melhor opção reforça um preconceito já existente. Mas agora, com toda a experiência adquirida, teríamos agido de forma diferente.
Por exemplo, a perda de competências pode ser resolvida pelo fato de que alguns meses antes da transição das pessoas com competência em automação, peça-lhes que compartilhem a competência com todos os engenheiros de QA em um produto ou com desenvolvedores de equipes. E melhor para tudo de uma vez.
Não há como compensar o problema de trabalho extra para desenvolvedores , mas você pode reduzir a dor de escrever testes não colocando isso antes de um fato, mas:
- mostre o valor dos testes explicitamente;
- ensinar os desenvolvedores a escrever, melhorar e manter esses testes;
- ( ), .
Quando nos separamos, nem mesmo pensamos sobre esses problemas. “Olhando para trás”, parece, bem, como pode ser, pensar sobre isso é elementar. Mas, pensando bem, todos nós somos fortes - tente prever o futuro.
As consequências de segunda ou terceira ordem para mim podem ser as consequências de primeira ordem para pessoas mais experientes que tomaram tais decisões muitas vezes e viram os resultados de tais decisões.
Muitas incertezas e variáveis afetando os resultados.
É importante não prever as consequências, mas, pelo menos, saber quais podem ser. Antes de tomar qualquer decisão, é importante pensar sobre quais serão as prováveis consequências, ler informações sobre casos em outras empresas para ter pelo menos uma ideia da escala de possíveis consequências não óbvias.
Qualquer um que aprenda a prever as consequências da segunda (e até terceira) ordem de qualquer decisão será capaz de salvar ou destruir a humanidade. Ou ganhar mais dinheiro do que o Tio Patinhas - pelo menos com as flutuações do preço das ações.
Como vou tentar prever as consequências agora
Li artigos sobre o assunto e deduzi por mim mesmo várias regras que, segundo os autores, ajudarão a prever tais consequências. Vou tentar usá-los:
- Antes de tomar uma decisão - pergunte a si mesmo "O que acontecerá a seguir?" e adicionar intervalos de tempo à pergunta. O que acontecerá em 10 minutos, 10 meses ou 10 anos?
- Treine seu pensamento para essas consequências, refletindo sobre diferentes situações. Por exemplo, quais seriam as consequências da primeira segunda ou mesmo terceira ordem se o mundo todo mudasse para carros elétricos, ou, por exemplo, introduzisse uma renda básica incondicional. Não há respostas corretas neste exercício, mas permitirá que você pense mais amplo.
- Lembre-se de que o primeiro pensamento em sua cabeça é a primeira ordem. É sempre.
Se você encontrou outros problemas ao mudar a organização da equipe de teste ou de outras equipes, escreva nos comentários, será interessante saber quais problemas você enfrentou e como os resolveu.
P.S. 2 QA- « » . . : , , SRE- mobile SRE . . , : (@EvgenSkt) HR (@alexpanev).
, , , : « » « » ( «» — ). QA, « ? ».
-, .