É possível automatizar alguma coisa? Então, dispararemos todos os testadores, é claro. Por que eles são necessários agora, não resta teste "manual". Afinal, afinal?
Esta é uma história sobre o futuro dos testes em termos de DevOps. Haverá números concretos e conclusões puramente práticas, como acontece que bons especialistas sempre têm trabalho. (Ou nenhum trabalho! Olhe para a fotografia de Shakespeare e tenha medo, seu destino será decidido agora).
O material é baseado em uma transcrição do relatório de Baruch
jbaruch Sadogursky, Advogado Desenvolvedor do JFrog. A versão em texto e o vídeo do relatório estão sob o corte.
Olá pessoal! Veja uma citação de Shakespeare na foto acima? Este é Henrique VI, a proposta de matar todos os advogados. Você entende, desde então, temos mais maneiras vegetarianas de se livrar das profissões erradas. Não vamos matar ninguém, basta pegar e despedir todos.
Mais precisamente, existe essa oportunidade. Vamos demitir alguém?
Vamos conversar.
Este é Vasya. Uma manhã, ele vem para o trabalho e passa pela sala principal de reuniões. E aí seu chefe recebe um novo consultor.
Um consultor de eficiência chega à empresa e diz: “Faremos DevOps como no netflix *. Nós voamos especificamente para o Vale do Silício para uma conferência, e lá fomos informados de como eles estão indo na netflix. ”
* isenção de responsabilidade: o Netflix é frequentemente usado neste artigo como o ideal inatingível do DevOps. Este uso é uma palavra familiar.
Uma discussão sobre se a Netflix realmente tem o DevOps perfeito está além do escopo deste artigo (provavelmente, a propósito, não).
Eles instalam o Spinnaker, iniciam o Chaos Monkey e tudo é automatizado. E faremos isso e seremos muito eficazes.
O chefe pergunta, e os testadores. “E aqui, como na netflix -
liberdade e responsabilidade . Os desenvolvedores escreverão os testes eles mesmos. ”
E então Vasya fica doente, porque ele olha para o seu cartão de visita, e lá ...
Vasya começa a se preocupar: na última vez em que um consultor de eficiência veio, seu amigo Natasha, que trabalhava como administrador de sistemas, foi demitido. Porque em todos os lugares DevOps. E então ele percebe que em breve tudo ficará muito ruim.
Mas, é claro, Vasya acorda.
Meu nome é Baruch Sadogursky, sou advogado do desenvolvedor no JFrog. O editor deste artigo pediu especificamente para escrever alguns parágrafos para que ninguém duvidasse da minha autoridade para nos dizer como acionaremos testadores.
JFrog é uma startup do Vale do Silício, nossa última avaliação foi superior a um bilhão de dólares. Somos oficialmente
unicórnios e fazemos a automação do DevOps. Nossos produtos -
Artefatos ,
Raios X ,
Controle de Missões etc. - são ferramentas para a própria automação que transforma a fábrica de processamento de carne de Omsk em netflix.
Eu mesmo não sou testador, então, talvez, eu conte algumas bobagens. No programa da conferência, no qual este relatório foi lido originalmente, há uma designação especial - uma foto com um coquetel Molotov. Então, o orador vai levar algum tipo de heresia, e o público vai queimar. Isso é sobre mim. No Twitter, eu sou
@jbaruch . Como você já entendeu, sou um cara muito alegre, preciso seguir com urgência.
Tenho novidades para você: 80% dos desenvolvedores escrevem testes. Os desenvolvedores estão satisfeitos com todos os tipos de pesquisas. Bem, o JetBrains está satisfeito com o muito bom
Relatório do Ecossistema do Desenvolvedor . Eles perguntam quem escreve testes de unidade.
- 59% escrevem por conta própria
- 11% veem testes de unidade em seu código e não sabem de onde vêm.
No total, 70% dos desenvolvedores usam testes de unidade. Isso é demais.
Há um
estudo mais aprofundado
de Hubstaff sobre testes com a ajuda de desenvolvedores, é um pouco mais antigo - 2014. Segundo ele:
- 85% dos desenvolvedores escrevem testes de unidade,
- 15% não;
- 40% trabalham de acordo com a metodologia de desenvolvimento orientada a testes;
- boa cobertura - entre 34 e 66 entre 31% dos desenvolvedores.
A grande maioria dos desenvolvedores afirma que eles também testam algo com canetas. Eles mentem, é claro, mas as estatísticas são as seguintes.
Desde 2011, nossa cotação favorita é:
“Toda empresa é uma empresa de software” . Incluindo, é claro, a fábrica de carne de Omsk, na qual Vasya trabalha. Em todo lugar existe software e todos os que estão tentando ganhar dinheiro. O que as empresas querem? Remar o saque com uma pá. De onde vem o dinheiro? De clientes satisfeitos. O que os clientes querem? Novos recursos. E quando eles querem novos recursos? Agora!
O diretor de quadrinhos Dilbert é o chefe de Vasya. Ele também ouviu todos os tipos de relatórios interessantes. Ele acredita que, se os clientes desejam novos recursos, precisam liberar novos recursos com mais frequência. É lógico. Para fazer isso, reduza o atrito nas equipes.
Devo liberar com mais frequência? Por exemplo, em 2017, o Java mudou para lançamentos mais frequentes, porque todo mundo quer recursos e, ao que parece, eles precisam ser lançados mais rapidamente. A cada seis meses, um novo Java é lançado. Mas ninguém usa.
Recentemente tivemos o Joker, hospedamos o
Java Puzzlers nele. No começo, sempre perguntamos quem está em qual Java, para entender quais peças do quebra-cabeça perguntar.
A imagem não mudou: 80%, ou mais, ainda estão no Java 8, lançado há cem anos. Ninguém leva a nona, nem a décima, nem a décima primeira.
Para entender por que eles não o estão usando, é necessário entender como tomamos uma decisão sobre fazer ou não atualizações. Vamos imaginar como colocamos as atualizações - sistema operacional, aplicativos, navegador - o que você quiser.
Como colocamos atualizações
Chega uma notificação de que temos uma atualização, vamos instalar um novo sistema operacional. Queremos isso? Existe algo útil lá ou temos uma caixa registradora que roda no Windows 98 Embedded e não precisamos de mais nada?
Se queremos essa atualização, a próxima pergunta é quão perigosa é. Uma coisa é quando o Facebook é atualizado, e temos rolagem e não poderemos gostar. Outra coisa é quando o sistema de suporte à vida é desligado no hospital. Se não dermos a mínima para os riscos, vamos atualizar. Se houver riscos, a questão é confiar em quem está lançando a atualização.
Não havia problemas com a Apple antes: existe um novo sistema operacional - vamos levá-lo. Foi antes, e agora temos medo de ser atualizados, não há confiança anterior. Se confiarmos - não há problema, estamos atualizando. Se não confiarmos, você precisa testar.
Fazemos o que chamamos de testes de aceitação. Aqui eles nos dizem: um novo Java foi lançado e, por exemplo, somos o Baidu. Highload, 100.500 servidores, nuvem, JVM em todos os lugares. Pegamos parte dos servidores, começamos a mudar o Java. Muitos engenheiros precisam fazer alguma coisa e verificar tudo. Uma vez a cada três anos é normal, mas uma vez a cada seis meses ... Você está ferrado? Só o verificaremos por seis meses. Obviamente, não levaremos este seu novo Java.
Portanto, se pudermos verificar rapidamente, vale a pena atualizar. Mas se você tiver que verificar por um longo tempo, poderá pular algumas versões. Nada acontecerá se passarmos da oitava versão imediatamente para a décima segunda.
O problema está na confiança. Se não confiarmos, a atualização será difícil. Se o problema de confiança for resolvido, não haverá problemas com as atualizações. Ou temos um recurso ou não damos a mínima.
Tome o Chrome. Ele, começando com alguma versão, atualiza sem perguntar a ninguém. Os riscos são pequenos, mas ainda existem. Por outro lado, confiamos em quem escreve o Chrome. Frequentemente, quando um novo lançamento do Chrome é lançado, nada acontece lá. De fato, não temos problemas com confiança e estamos nesse caminho.
Temos uma atualização, os riscos não são importantes, confiamos - nós atualizamos. E eles não nos perguntam se queremos ou não, portanto, sempre atualizaremos. Isto é exatamente o que está sendo feito.
Imagine que a netflix está lançando uma nova atualização e agora podemos pular não apenas legendas e protetores de tela, mas também todos os lugares chatos. Atualização legal? Legal. Nós o queremos? Nós queremos. Será que vai funcionar? Provavelmente sim. Em um caso extremo, iremos ao YouTube, veremos os desenhos animados se o Netflix estiver quebrado.
A questão da confiança é crítica. Como resolvemos isso? A palavra "nós" refere-se aos dois co-fundadores da JFrog, Fred Simon (Fred Simon), Yoav Landman (Yoav Landman) e seu humilde servo.
Escrevemos um livro que aconselha como resolver esse problema.
Digamos que convencemos nosso CEO, ele leu a Liquid Software e agora entende por que precisa de uma atualização. Ele pergunta ao consultor como atualizaremos com mais frequência. Ágil! DevOps! O que é o DevOps?
Devops
Deixe-me contar uma pequena teoria sobre o que é DevOps, já que ganhamos dinheiro com isso. Dê uma olhada na foto, tivemos esses grupos, equipes, departamentos:
Existem desenvolvedores, existem Ops - administradores de sistemas que pegam o que os desenvolvedores escreveram e os lançam no produto. E no meio entre os desenvolvedores de Ops, há QAs que estão sendo testados. Ou seja, os desenvolvedores sentaram-se, escreveram, depois os levaram aos testadores, testaram, atribuíram aos administradores do sistema e fizeram o upload para o prod. Para isso, tínhamos departamentos separados.
A língua russa é linda: o departamento está sempre
separado , essa é a raiz da palavra. Em inglês, esse encanto não é, portanto, esses diferentes departamentos são chamados
silos . A melhor tradução dessa palavra para o russo foi dada por Anton Weiss, que foi o melhor
orador da DevOops . Ele chama os silos de "poços". Departamentos diferentes - poços profundos. Para carregar algum trabalho lá, você precisa descer e depois retirar o trabalho de lá - levante-se. É mais conveniente fazer isso em grupos. Como agrupamos as coisas que saímos do poço?
Naturalmente, em baldes. Ou seja, temos esses "baldes de trabalho". Os desenvolvedores escreveram algo no poço, nós o carregamos em baldes, tiramos do poço, carregamos os baldes para os testadores e abaixamos para eles no poço.
Muitas ações são realizadas para transferir o trabalho entre diferentes poços. Quando agrupamos tarefas para economizar nesse trabalho, começamos a carregar esses buckets. Obviamente, quanto maior o balde, mais economizaremos nesse processo de transferência. Portanto, os baldes são grandes.
Qual é o problema com baldes grandes? O fato de que eles preenchem por um longo tempo. Portanto, quando temos recursos importantes que precisam ser liberados com urgência para produção, porque há uma linha de clientes com dinheiro, não podemos fazer isso. Temos poços, melhor coletarmos mais em um balde. Portanto, recursos importantes aguardam toda a bobagem, desde que tenhamos o suficiente para preencher isso bem. Isso é ruim, como você entende. Isso é resolvido pelo fato de obtermos e misturarmos todos esses poços.
Não é minha culpa! Eu apenas peguei as três cores originais, coloquei-as umas sobre as outras e essa cor acabou. Agora todos fazemos tudo. Temos engenheiros como Shvets, Reapers e Dyuras. Estes são Dev, QA e Ops. Ele escreveu e testou o código e, em seguida, colocou tudo em produção - como um unicórnio.
Qual é o problema dos unicórnios? Que eles não existem. E aqueles que existem, eles são contratados pela netflix há muito tempo. Portanto, resta fazer a mistura.
A mistura
Temos uma cultura comum, objetivos comuns. Saímos dos poços, estamos todos juntos agora, mas ainda temos profunda especialização. Um desenvolvedor ainda é mais desenvolvedor do que Ops, e um testador é mais testador que desenvolvedor. No entanto, eles entendem tudo. Eles entendem o que estão fazendo, por que estão fazendo e como funciona.
Ou seja, temos pessoas em forma de T, "pessoas na forma da letra T".
Eles têm uma profunda especialização, sabem muito bem o que estão fazendo. Eles sabem muito bem e tudo o mais também. Por exemplo, os desenvolvedores entendem um pouco como testar corretamente, como o layout é processado no prod e assim por diante.
O DevOps é:
- A cultura do que agora temos objetivos comuns, entendemos o que fazemos juntos.
- Automação para liberar com mais frequência.
Velocidade e qualidade
Vamos falar sobre a suposição de que existe uma relação inversa entre velocidade e qualidade. Grosso modo, quanto mais rápido lançarmos, pior será a qualidade. E vice-versa: se não tivermos pressa, teremos tempo para testar tudo minuciosamente. Temos uma troca!
Para entender se essa dependência realmente existe, vamos aos artigos científicos e falamos sobre o
relatório State of DevOps da organização DORA. Eu recomendo que você dê uma boa olhada neste relatório.
Quanto você pode confiar nele? O relatório diz que mais de cinco mil pessoas foram entrevistadas em cinco anos e, em 2018, quase 2000 pessoas. Essa é uma amostra muito grande e, com base nessa quantidade, por exemplo, são feitas previsões nas eleições nos EUA. Portanto, a pesquisa pode ser confiável.
Além disso, Nicole Forsgren, que chefia a DORA, ao contrário de nós, é uma cientista, então tudo é sério lá. Vamos ver o que o DORA nos diz sobre essa correlação inversa.
Em primeiro lugar, eles dividiram todos os entrevistados em três grupos: de baixo desempenho, médio e alto desempenho.
Além disso, há Elite. Esta é a Netflix (na verdade não, veja o
aviso acima).
Como você pode ver, as proporções estão mudando. Naturalmente, cinco anos atrás, havia muito mais baixo desempenho, agora há muito mais alto desempenho, porque já estamos começando a entender um pouco o que estamos fazendo.
Isso é de alguma forma estranho. Acontece que o Medium está sendo testado com alças acima de Low. Porque Sim, porque Low não testa nada.
Eles têm uma tendência, um gráfico chamado curva J, que mostra a própria correlação ou correlação inversa entre velocidade e qualidade. E aqui tudo é muito estranho. Em algum momento, vemos a confirmação dessa correlação inversa. Ou seja, quanto mais rápido lançarmos, menor será a qualidade.
Mas a correlação não é apenas não inversa, é direta. Quanto mais rápido lançarmos, melhor será a nossa qualidade. Digamos que somos Médios e testamos com canetas. Tudo não é ruim, mas lentamente, porque acreditamos que, se não tivermos pressa, testaremos tudo melhor. Então, um consultor da DevOps chega e diz: “É isso, agora estamos automatizando. E não precisamos de testadores. Está tudo bem.
Mas sem testes, é meio absurdo. Depois que percebemos que, afinal, algo precisa ser testado e é necessário automatizar corretamente, começamos a automatizar corretamente e continuamos a lutar pelas alturas altíssimas.
Esta falha, onde há muitos erros, deve ser corretamente superada. Como entrar, acho que não há perguntas. A questão é como sair disso.
Precisamos responder à questão de como viver sem teste manual. A resposta é a mesma da questão de como viver sem configurar servidores. Obviamente possível. O que está mudando?
Anteriormente, tínhamos um administrador de sistema que lançava um produto para prod. Ele sentou e esperou que os desenvolvedores terminassem de escrever. Depois disso, ele pegou este produto e foi inserir o CD-ROM e colar os fios. O que acontece com todos os outros neste momento? Todo mundo está esperando. Este é um gargalo, plug.
Resolvemos isso com a automação correta. Automatizamos o processo, temos um pipeline preparado com antecedência e agora o produto é lançado automaticamente assim que termina de escrever. Isso significa que agora essas pessoas não são necessárias? Não. Isso significa que eles são necessários, mas estão fazendo outra coisa.
A mesma coisa com o teste. Temos testadores que testam o produto. Eles esperam até escrever um produto. Escreveu - é hora de testar. O que todos os outros fazem enquanto testam? Eles não fazem nada, eles estão esperando. Como resolvemos isso?
Mais uma vez, a automação correta. Estamos construindo um processo. Ele garantirá a qualidade do produto. Podemos preparar esse processo com antecedência e, em seguida, o produto é testado automaticamente.
- Isso requer, por exemplo, equipes multifuncionais . Aqui nos levantamos dos poços e sentamos juntos. Agora temos um leão deitado com uma ovelha, e o testador trabalha junto com o programador.
- Fazemos testes contínuos . É como um teste automatizado, mas mais inteligente.
- No processo de desenvolvimento, é realizado o "teste do cérebro" . Este é um termo mais correto do que "teste manual", porque o teste manual é sobre o cérebro, não sobre as mãos. Obrigado por este termo para o meu irmão gêmeo no Facebook Alexey Vinogradov. Os testes cerebrais ocorrem durante o processo de desenvolvimento. Assim que algo aparece, você já pode verificar seu fluxo, já pode entender como funciona, já pode começar a descrever alguns casos de canto, que serão automatizados.
- Agora estamos seguindo o desenvolvedor. Se ele não escreveu o teste a princípio, podemos dar um tapa na cara dele. Este é o desenvolvimento orientado a testes .
- O feedback instantâneo é importante. Deveríamos ter um pipeline que nos informa imediatamente assim que algo quebra. Porque temos que ir imediatamente e consertá-lo instantaneamente.
- Participação no design . Acontece que você olha para alguma coisa e pensa em como agora vamos testar essa merda. Mas com licença, onde você estava quando todo mundo decidiu que haveria merda? Você chega à reunião e diz que não concorda, deve fazê-lo inconscientemente. Você precisa estar envolvido no design para garantir que possa testá-lo mais tarde.
- Ferramentas, arreios, suportes - o que muitos de vocês fazem hoje não vai a lugar nenhum. Pelo contrário, isso será mais. Por conseguinte, alguém deve escrever isso.
- Engenharia do caos . Você sempre sonhou em lançar o Chaos Monkey em produção, especialmente se você tiver uma rede de caixas eletrônicos no Windows 95. Aqui está sua chance.
- E, finalmente, você precisa ensinar o ignorante a projetar testes . Decidimos que os desenvolvedores pelo menos afirmam que escrevem testes. Agora deixe-os escrever testes, apenas precisamos ensiná-los a fazê-lo. Quem os ensinará, como eles sabem escrever testes? Só você Ninguém mais.
Resta automatizar tudo. De fato, podemos automatizar os testes. O problema é que você pode automatizar uma determinada parte.
Vocês todos conhecem essa piada sobre como um testador entra em um bar, pede cerveja, pede 0 cerveja, pede 99999999999, pede um lagarto, pede -1 cerveja e pede ... Isso é um bug, porque deve ser asdfgh, e não este besteira.
É facilmente automatizado. É claro que não há problemas nos números. Colocamos um randomizador, ele faz isso conosco. Até um lagarto hoje já pode ser gerado lá. Isso é confuso - espero que você tenha ouvido falar, porque li ontem.
Mas então o cliente chega, pergunta onde fica o banheiro e tudo, o bar queima, todo mundo morre e tudo mais. Isso não pode ser automatizado. Bem, como você pode, mas primeiro você precisa entender com a cabeça que o bar não é apenas onde estão as bebidas, é também onde está o banheiro. Além disso, as chances de o cliente querer ir ao banheiro são um pouco maiores do que ele pedir um lagarto. Portanto, é mais importante verificá-lo, mas para isso você precisa entender o negócio, o produto e apenas pessoas com a cabeça podem fazer isso.
, , , . DevOps. , . T- — , .
, - . « », , . , , , . , Selenium . , .
, .
— . , , . . , , Ops- , , , , , , , .
Developers in test — , , . , . , ; — , ; TDD , , , , . , , .
« ». , , , , , — . , , , , , , , , , , Continuous Testing .
end-to-end , . , , DevOps, .
, - , . , 70- : « DevOps, ». , , .
. -, , , , , . : ( EVP Engineering, SignalFx) , , .
70- . . , , . , . , , , , . , , , , — , netflix .
, , , , , , , , , . . , .
, . . « , », — , , .
«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».
, — , . , . ? !
DORA: , , , .
New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .
.
Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).