Assista ao vídeo, leia a transcrição e escreva sua opinião sobre as questões expressas nos comentários. Vamos descobrir juntos: ser ou não ser?
Discussão número um
Timecodes
0:56 - O teste é sempre necessário?
2:00 - Por que testar quando você precisa lançar recursos para o mercado o mais rápido possível?
3:24 - É possível testar apenas a funcionalidade básica ou uma parte do aplicativo?
5:29 - Critérios para testar a funcionalidade
7:28 - Em que ponto uma startup ou empresa de terceirização deve parar de lançar recursos e começar a perder tempo em testes
O encontro começou imediatamente com um quente - com discussões. Portanto, apresentaremos os participantes em nossa discussão online:
- Dmitry Voronin, engenheiro chefe da equipe Speed (Avito).
- Yuri Chechetkin, desenvolvedor móvel (Revolut)
- Dmitry Manko, desenvolvedor Android (Citymobil)
- Nina Semkina, programadora sênior (Yandex.Money)
- Vladimir Genovich, programador líder (Yandex.Money)
- Dmitry Zhakov, testador (Yandex.Money)
Nina Semkina: Muitas pessoas dizem que os testes devem ser introduzidos nos projetos ... Mas todos entendem que é muito caro. É muito caro gastar tempo e muitos recursos dos desenvolvedores para cobrir todo o código com testes. O teste sempre deve ser feito?
Dmitry Manko: O que você vai testar?
Nina Semkina: aplicativo Android. Quando preciso entender que 100% disso precisa ser testado?
Dmitry Manko:Se o mercado não espera pelo surgimento de nenhuma funcionalidade, então, do ponto de vista do desenvolvimento ou do ponto de vista da cobertura, os testes podem ser simplificados ou completamente negligenciados. Tudo depende do produto. Se estivermos fazendo uma calculadora com 2 funções, provavelmente passamos por uma série de casos de teste mais de uma vez. Assim, os testes podem ser omitidos, o aplicativo pode ser colocado no mercado mais rapidamente e o tempo de colocação no mercado pode ser reduzido.
Nina Semkina:Sempre temos uma corrida de time-to-market, o mercado sempre exige um monte de recursos e não podemos atrasá-los. Principalmente quando se trata de um projeto que está começando e que precisa ser lançado no mercado agora, não temos nome, competimos com outras empresas. O que nos preocupa em testar neste momento? Precisamos fornecer recursos ao nosso aplicativo e eliminá-los mais rápido, caso contrário, eles se tornarão obsoletos em 3 semanas. Por que testá-los?
Dmitry Voronin:Na verdade, a velocidade de desenvolvimento em algum ponto começa a depender da cobertura do teste. Se, por exemplo, uma empresa está arquitetonicamente ligada a uma tela principal, onde estão todos os recursos principais, e as mudanças são feitas muitas e muitas vezes, então, sem testes, você pode começar a se mover para lá mais lentamente, mesmo com um grande "pipeline de recursos". Parece que logo há sinais de que você costuma voltar na regressão, ou seja, um motivo para pensar no fato de que algo está errado com o revestimento e você não está realizando ações reativas. Por exemplo, algo sempre quebra, o que significa que este lugar não está sendo testado como deveria.
Nina Semkina:Posso chegar a uma conclusão de que apenas a funcionalidade básica precisa ser testada constantemente, e os recursos devem ser conectados “em um ponto”. Deixe que esses recursos individuais sejam bugs, mas talvez eles existam hoje e não existirão amanhã. Posso testar apenas uma parte do aplicativo?
Dmitry Manko: Eu prefiro dizer que vale a pena testar as partes principais. O que é importante do ponto de vista comercial para este produto. E se houver recursos com bugs, eles estão localizados em algum lugar separadamente e não afetam algo em comum, então, o ideal é fechá-los com um botão remoto. E se, de acordo com a análise, você vir que realmente existem bugs e os usuários estão reclamando, desative esse recurso.
Dmitry Voronin:Dima tocou em um bom tópico, que os testes não são a única ferramenta de controle de qualidade que um desenvolvedor possui. Você deve sempre lembrar que além dos testes de unidade e integração, testes manuais, existe e deve haver monitoramento. E há maneiras de implementar e reverter suas alterações. Se você tem todas essas práticas de engenharia, então, em princípio, você pode negligenciar algumas ferramentas em favor de outras, se a velocidade se beneficiar disso. Mas, em geral, é sempre considerado bom se o desenvolvedor tem uma cultura de teste - que é mais confortável e mais confiável para ele entregar mudanças para que ele teste a funcionalidade que deve executar. Em nossa empresa, é comum deixar esse código, no qual você pode facilmente fazer alterações e executar testes rapidamente para entender que você não estragou o que já aconteceu.
Nina Semkina: No chat escrevem que é preciso testar o que traz renda. E quando os custos de teste são menores do que as possíveis perdas de funcionalidade não operacional. Em princípio, esse é um bom critério para entender o que exatamente precisa ser testado. Você poderia citar algum outro critério para testar uma funcionalidade específica?
Dmitry Manko: Os critérios podem ser identificados usando análises. Por exemplo, se você corrigir as funções usadas com mais frequência, também é aconselhável testá-las para que os usuários encontrem bugs o menos possível. Se os insetos estiverem em lugares raros, esse é um pequeno problema. E se o banimento estiver na tela de autorização, pode não ser crítico, mas ainda assim um bug que todos verão. E isso já é um risco para a reputação.
Dmitry Zhakov:O teste em geral é geralmente necessário. Não devemos esquecer que o teste é um teste dos requisitos que colocamos em um produto. Se algo não atender aos requisitos, isso é um problema, bug, problema. Todos os casos de teste e testes podem ser automatizados e, se não houver tempo suficiente, primeiro vale a pena verificar os momentos críticos e depois todo o resto. Por exemplo, se você tem um lançamento amanhã e sua empresa deseja um recurso amanhã, você verifica a funcionalidade mais crítica. E se você tiver tempo suficiente, poderá verificar as caixas médias e baixas. É mais uma questão de saber se o teste será manual ou automatizado. Seja métricas ou testes de IU, totalmente verificáveis por um robô.
Nina Semkina:Estamos todos falando em nome de grandes empresas com muitos recursos e oportunidades. E se considerarmos o ponto de vista das pequenas empresas, startups, que têm tempo e recursos limitados. Acho que no início todos vão sacrificar os testes lá. Em que ponto podemos entender que este é o marco crítico quando devemos parar e parar de lançar recursos e gastar recursos em testes?
Dmitry Manko:Posso partilhar a minha opinião, pois venho de uma empresa de outsourcing. A terceirização é principalmente sobre onde as horas de trabalho são vendidas, e os testes são muito caros lá. Às vezes, custa mais do que desenvolver a própria funcionalidade. Essas empresas de terceirização, quando o cliente está esperando pela aplicação e "dá um pontapé de lado", não são famosas pelos testes. Em nossa equipe, enfrentamos a seguinte situação. O produto é um cardápio de bares, onde as promoções foram utilizadas para um grande número de casos (aniversário, 2 em 1, aluno, etc.). E notamos que essa funcionalidade de estoque estava quebrando a cada mês durante um ano. E então o teste de unidade descreveu todos os casos de maneira ideal. Entendemos como tudo funciona (foram cerca de 70 casos de teste). Vencemos esse produto, mas, é claro, não seria possível fazer isso em todos os lugares.
Yuri Chechetkin:Minha experiência de trabalho em grandes empresas - Yandex, Alfa-Bank, Revolut - em fintech, onde a criticidade de qualquer bug simplesmente dispara. Dito isso, tenho experiência em startups e, mesmo lá, os testes foram absolutamente necessários. Acho que não importa se é uma startup ou não, porque o desenvolvedor deve ser o responsável por seu código, e os testes são uma garantia de que esse código funciona. Um desenvolvedor é basicamente um engenheiro responsável pelo produto que está sendo desenvolvido. Portanto, você precisa escrever testes não porque precisa, mas porque eles devem ajudá-lo. Se esses são testes escritos para exibição, isso pode retardar o desenvolvimento. E se você precisa de testes e entende por si mesmo, então eles devem ser escritos. Se um desenvolvedor escreve código e tem certeza de que ele funciona sem testes, então isso é um risco e é sua escolha. Mas eu ainda pensoque o desenvolvedor não deve correr esse risco e deve se cobrir e cobrir tudo com testes.
Nina Semkina: Então, decidimos que precisamos testar nosso código de alguma forma, vamos analisar esse tópico com mais detalhes. Passo agora a palavra a Vladimir Genovich com o seu relatório .
Discussão número dois
Timecodes
0:09 - Como remover a carga de regressão do controle de qualidade antes dos lançamentos? As empresas têm uma estratégia para melhorar a estabilidade do aplicativo?
4:25 - Faz sentido usar mocks ou objetos falsos em testes de IU
8:05 - Testando em usuários: é aceitável ou não?
Nina Semkina: Durante a reportagem, recebemos uma pergunta no chat, e é dele que gostaria de continuar nossa discussão. Como remover a carga de regressão do controle de qualidade antes dos lançamentos? Que práticas nossos palestrantes usam na escolha de locais para o teste? As empresas têm uma estratégia para melhorar a estabilidade do aplicativo e dispensar os especialistas em QA?
Dmitry Zhakov:Nossa estratégia é testar tudo. Porque somos a última fronteira, como funcionários antes dos usuários. Portanto, fornecemos apenas tal aplicativo ao cliente, que funciona de forma estável sempre e em qualquer lugar. A única questão é a velocidade. Inicialmente, a execução manual levou muito tempo - até uma semana. Mas graças à automação, conseguimos que o lançamento dure em média um dia. Portanto, se você estiver desenvolvendo qualquer funcionalidade, será necessário concordar que você ou os testadores escreverão os autotestes imediatamente. E alguns casos específicos de dispositivos móveis que você não pode automatizar terão apenas que ser verificados na regressão, e o robô verificará o resto. Assim, você descarregará testadores, eles se envolverão em um trabalho de pesquisa mais interessante e você dará ao robô toda a rotina - scripts de cliques.
Yuri Chechetkin: A maioria das grandes empresas se recusa a fazer testes manuais de controle de qualidade. Este não é exatamente um caminho revolucionário, mas uma espécie de relíquia do passado. E, por exemplo, na minha empresa, onde trabalho agora, nem se pronuncia uma palavra como regressão. Não temos nenhum departamento de controle de qualidade.
Vladimir Genovich: Você provavelmente automatizou isso?
Yuri Chechetkin: Na verdade não, ele estava apenas nos estágios iniciais do projeto, e então ele simplesmente se foi.
Vladimir Genovich: Você executa testes de IU, certo?
Yuri Chechetkin: Existem testes de IU, é claro.
Vladimir Genovich: E os testes de unidade? Então, executar esses testes no lançamento não é uma regressão?
Yuri Chechetkin:Sim, isso é uma regressão, mas não há nenhum teste manual de que estamos acostumados. E essa é uma abordagem muito interessante. Isso torna sóbrio e transforma o desenvolvedor de uma "criança" que escreve código e o entrega aos testadores, em um engenheiro mais maduro e independente que é responsável por seu próprio código. Quanto às coisas visuais, a revisão pode ser feita por um designer ou PO. E há coisas como testes de captura de tela - como o Facebook. Portanto, parece que agora as empresas de alimentos podem passar sem o controle de qualidade. E os próprios testadores podem fazer um trabalho mais interessante. Claro, há uma história ligeiramente diferente na terceirização - eles vendem horas-homem e o controle de qualidade pode ser vendido como um serviço adicional.
Dmitry Zhakov:Acontece que você tem regressão, ela é simplesmente entregue à automação, e você tem pessoas que estão engajadas no trabalho de pesquisa de sua aplicação. O teste pode ser não apenas UI, mas também diferente.
Yuri Chechetkin: Sim, por exemplo, teste em usuários.
Nina Semkina: Antes de tocarmos neste tópico muito perigoso, gostaria de ler a próxima pergunta de nossos ouvintes. Faz sentido usar mocks ou objetos falsos em testes de IU?
Dmitry Voronin:Faz sentido, e sem eles em lugar nenhum. Porque os testes de IU com integração total não são confiáveis. E você nunca pode confiar em um teste que tem 30 sistemas, cada um com um monte de pontos de falha executando uma solicitação de pull. Esses testes não são viáveis. E ninguém em nenhuma empresa poderia fazer essas coisas funcionarem. Portanto, os testes de IU são a ruína do desenvolvimento móvel. Se possível, é melhor testar sem IU. Mas devido ao fato de que somos forçados a conviver com um framework, e a única alternativa é algum tipo de robótica, e no iOS, nem isso é. E para verificar a interação com pelo menos um dos sistemas importantes para nós, rodamos tudo no dispositivo. A IU está aqui na medida em que, devido à nossa imaturidade de desenvolvimento, queremos capturar o máximo possível para verificar como o usuário clica - somos tão mais calmos. Parece para mim,que depois de algum tempo isso vai virar coisa do passado e vamos deixar de ter medo de zombarias, cliques e não vamos brigar com o sistema para verificar tudo como deveria, porque não vamos verificar tudo mesmo. Pode haver bugs visuais que não serão verificados por nenhum teste de IU. Portanto, acredito que a simulação em testes de IU pode e deve ser feita, e o principal objetivo disso é aumentar a estabilidade dessa ferramenta, para trazê-la a um estado que seja útil. E o benefício real neste caso é garantir que não haja regressões. E qualquer instrumento que descarrega se transforma no segundo "D" do relatório anterior de Vladimir Genovich, quando deixamos de confiar. Isso acontece quando um grande número de valores aleatórios começa a chegar em nosso teste. E esse teste não dá nenhuma confiança em si mesmo, mas apenas dá uma falsa esperança de que algo foi testado.
Dmitry Zhakov: Cerca de 70% dos nossos casos são automatizados e não usam uma única simulação no aplicativo. Pode ser mais fácil migrá-los para o back-end. Por exemplo, se se refere a um número de cartão, então você esperaria que o 3DS não fosse solicitado de você. Ou seja, o aplicativo não sabe que está bloqueado. Acho que é um problema de infraestrutura.
Nina Semkina: Antes de passar para o próximo relatório, gostaria que mencionássemos um tópico escorregadio - testes com usuários. Muitos pecam assim: sempre querem e injetam ... O que você acha disso? É possível distribuir aos usuários às escondidas, coletar travamentos deles e consertar você mesmo. E depois de testá-los, implemente boas versões completas. Ou é geralmente inadmissível? Ou existem limites razoáveis?
Yuri Chechetkin:Nós da Revolut praticamos isso um pouco no sentido de que não vai diretamente para a batalha, mas para usuários reais. A demonstração também é um teste com usuários, e durante a demonstração surgem perguntas sobre o fluxo e assim por diante. Nesta fase, podem surgir questões sobre design e mecânica geral. Entre outras coisas, existe a rolagem interna - a empresa é grande, mais de 1000 pessoas, e podemos implantar entre os colegas. Este é um teste do usuário, mas não externamente e parece ser seguro. E então ele pode ser implementado para uma pequena porcentagem de usuários reais externos, mas com a capacidade de fechar esse recurso com uma alternância. O que você acha que pode dar errado durante esses estágios?
Dmitry Manko:Em nossa realidade, as coisas podem dar errado. Não importa o quanto tentemos realizar bem essas etapas, em qualquer caso, os casos saltam quando precisamos monitorar a análise de falhas. O lançamento não acaba com o fato de termos enviado para a loja, todas as etapas já passaram, está tudo bem conosco. Você precisa continuar observando como o aplicativo se comporta.
Yuri Chechetkin: Definitivamente, sim. Em nosso caso, temos uma demonstração, implementação interna e teste para 5% dos usuários, em vez de teste manual. Claro, após o lançamento do recurso, você precisa olhar. O rolamento não deve ser 100% imediato - este é o principal mecanismo de defesa.
Dmitry Voronin:A questão ética dos testes de usuários é tratada pelo Google para nós. A Apple não parece ter isso. Existem canais de distribuição especiais, como você sabe (alfa, beta ... produção). Qualquer um pode entrar no teste beta e concorda com um formulário compreensível, que diz que eles estão concordando sensatamente que podem receber uma versão instável do produto. E então ele quer ser voluntário e ajudar a empresa a tornar o produto melhor. Assim que contarmos abertamente a uma pessoa sobre isso, acho que esse problema deve ser removido e não devemos ter medo de lançar uma versão da qual não tenhamos 100% de certeza. E é ainda melhor quando temos feedback de lá, e com cada versão instável, melhoramos esse processo. Se uma empresa tem processos que rastreiam tendências de qualidade em beta, então as coisas só devem melhorar.E isso também é uma vantagem para os usuários - eles serão os primeiros a receber os recursos. Esses são, em sua maioria, usuários motivados e leais ao seu produto, e eles próprios desejam testar coisas novas que aparecem no aplicativo. E eles estarão até prontos para sacrificar algo por isso.
Nina Semkina: Entendemos que quando falamos sobre um público leal, ele é leal, desde que não afete seus interesses pessoais. É assim que podemos lançar recursos com pequenos pãezinhos adicionais, que mesmo se caírem, esses usuários não ficarão muito chateados. Porém, mesmo que essa pessoa confirme que está pronta para fazer a versão de teste, mas algo sério aconteça com ela (por exemplo, dinheiro extra será cancelado), ela não será mais leal. E quanto maior a empresa, mais duramente o usuário responderá sobre o produto.
Vladimir Genovich:Mas e quanto ao pioneiro, que ama você, não importa o quanto a empresa bagunce? E, muito provavelmente, essa empresa será capaz de recuperar as perdas. Combine, se lançarmos algo, dizemos ao usuário: “Olha, estamos com muito medo. E você pode perder 1000 rublos. Mas vamos reembolsar você. " Muito provavelmente, esse usuário fará isso por sua própria conta e risco e, se o dinheiro for perdido, não diremos a ele mais tarde: "Bem, você é o culpado." Portanto, acho que, mesmo no caso de um aplicativo bancário, podemos ajudar os usuários.
Dmitry Zhakov:E se você tiver poucos testadores beta, então você pode usar o teste A / B com a ajuda de configs para habilitar / desabilitar algum recurso, de forma que em caso de travamento, você pode desabilitar imediatamente algo e testá-lo conforme necessário. Como lembramos, é muito difícil fazer rollback no mobile, por isso é melhor verificar tudo ao máximo antes do lançamento.
Vladimir Genovich: Ou escreva em React Native))
Nina Semkina: Vou interromper nossa conversa, pois chegou a hora do próximo relatório. Dima, eu passo a palavra para você.
Discussão número três
Timecodes
0:05 - Como melhorar o teste de regressão? Como e quando os testes são introduzidos no desenvolvimento de recursos (experiência de Avito)
10:43 - Onde os testes de unidade estão perseguindo: no CI ou localmente antes de implementar?
Nina Semkina: Eu gostaria de entrar em contato com Dima Voronin para ouvir sua opinião e sobre sua experiência sobre como eles aprimoraram os testes de regressão na empresa e quando eles introduziram os testes ao desenvolver recursos.
Dmitry Voronin:Eu realmente tenho algo para compartilhar. Esta é uma história de cinco anos lidando com regressão manual. E isso é em parte uma continuação da resposta à pergunta que tivemos entre os 2 primeiros relatórios. Esta questão é sobre o que fazer se você tiver regressão manual. Porque nem todos serão capazes de repetir a experiência do Revolut. Os caras são bons camaradas que cortaram no ombro e conseguiram fazer isso de forma confiável. É preciso muita coragem, uma boa cultura de desenvolvimento e, o mais importante, compreender os líderes de desenvolvimento que não se sentem entusiasmados com essa abordagem. Isso acontece porque existe uma inércia no nosso trabalho e pode ser difícil mudar os alicerces, principalmente nas grandes empresas. O exemplo do Revolut prova que, se funcionar, é pelo menos mais rápido do que a regressão manual, e cada desenvolvedor começa a se fazer as perguntas certas.Ou seja, ele passa a ser o responsável por grande parte do ciclo de lançamento, ou seja, não até o momento em que efetua as alterações, mas como todo engenheiro adulto, também lidera o produto na fase de lançamento.
O que aconteceu com a gente? Estávamos no ponto em que tínhamos uma regressão manual que era feita por 5 pessoas durante 12 dias úteis, e sem ela o aplicativo móvel não rodaria. Era 2015. E naquele momento não tínhamos um único teste de IU automatizado. Escrevemos testes de unidade quase desde o início e de forma bastante ativa. Vladimir em seu relatório falou sobre 10 segundos e 1000 testes - é assustador para mim imaginar quando passamos por tal momento em 2014. Agora temos 12.000 testes de unidade, e eles não levam 10 segundos, esta também não é uma peça gratuita. Embora todos os engenheiros entendam e escrevam testes, houve um momento complicado. Todos esses testes de unidade não provam um único grama sobre bugs na produção e como o aplicativo se comporta. Ou seja, o teste captura o comportamento, torna mais fácil fazer alterações e fornece feedback,você está fazendo certo. O problema é que existe um departamento de controle de qualidade. Claro, esse não é o problema. O problema é que eles têm a tarefa de fornecer um certo nível de qualidade. E eles estão acostumados a chegar nesse nível, eles assumem essa responsabilidade. E é difícil virar esse momento se não vier desde o início do seu produto. Que receitas existem? O mais correto é não ligar o modo difícil quando despedimos todos e tudo é assumido pela automação. Esta é provavelmente a abordagem mais assustadora e imatura que já vi. O que há de errado nisso? Primeiro, a qualidade dos testes será perdida por algum tempo. Em segundo lugar, todos os processos são destruídos e novos não são construídos rapidamente.E eles estão acostumados a chegar nesse nível, eles assumem essa responsabilidade. E é difícil virar esse momento se não vier desde o início do seu produto. Que receitas existem? O mais correto é não ligar o modo difícil quando despedimos todos e tudo é assumido pela automação. Esta é provavelmente a abordagem mais assustadora e imatura que já vi. O que há de errado nisso? Primeiro, a qualidade dos testes será perdida por algum tempo. Em segundo lugar, todos os processos são destruídos e novos não são construídos rapidamente.E eles estão acostumados a chegar nesse nível, eles assumem essa responsabilidade. E é difícil virar esse momento se não vier desde o início do seu produto. Que receitas existem? O mais correto é não ligar o modo difícil quando despedimos todos e tudo é assumido pela automação. Esta é provavelmente a abordagem mais assustadora e imatura que já vi. O que há de errado nisso? Primeiro, a qualidade dos testes será perdida por algum tempo. Em segundo lugar, todos os processos são destruídos e novos não são construídos rapidamente.a qualidade do teste será perdida por algum tempo. Em segundo lugar, todos os processos são destruídos e novos não são construídos rapidamente.a qualidade do teste será perdida por algum tempo. Em segundo lugar, todos os processos são destruídos e novos não são construídos rapidamente.
O que nos fizemos? Começamos nossa otimização escrevendo testes de IU que substituem a regressão. Ou seja, são testes de infraestrutura completos que tocam o back-end com os usuários de teste. E, de fato, o resultado desse trabalho foi, como você sabe, todos os tipos de frameworks populares - por exemplo, Kaspresso. Isso é exatamente o que colocamos quando começamos. Deixamos para trás vários artefatos que podem ajudar os desenvolvedores. E é mais fácil começar a testar agora. Também colocamos vários corredores no código aberto, e todos podem ver como trabalhamos com eles. Mas não esquecemos os testes manuais, sua otimização e como esses dois departamentos começam a se fundir em um processo eficaz. Provavelmente o ponto B é o estado Revolut. Mas nosso caminho do ponto A ao ponto B, como muitas outras empresas,leva muito tempo. Agora estamos no estágio em que o controle de qualidade desempenha o papel de pesquisadores, eles se envolvem mais no produto, trabalham nos requisitos funcionais, escrevem autotestes.
A coisa mais interessante sobre a prática de melhorar a regressão manual é a análise de impacto. Ou seja, uma tentativa de responder à pergunta: "O que mudou neste lançamento?" E o que podemos testar e o que podemos implementar com tranquilidade para os próximos estágios. A análise de impacto é uma pergunta difícil, porque quando você tem um grande ciclo de lançamento, ou seja, você fica liberado por 2 a 3 meses, a análise de impacto sempre responderá da mesma forma, pois durante esse tempo quase nenhuma parte do aplicativo foi tocada. Mas se você encurtar esse ciclo de lançamento para uma semana, ou melhor ainda, para um dia, a análise de impacto mostra coisas bastante adequadas, deixa marcas que ajudarão a otimizar a regressão manual. Aplicamos essa prática com bastante sucesso. No início, houve erros, mas reduzimos a quantidade de testes manuais únicos.
A próxima prática é otimizar o modelo de teste. Curiosamente, mas em testes também há legado: os testes são escritos, mas podem não ser muito ideais, então algo mais foi adicionado lá, e os casos de teste não foram processados para isso ... Com uma análise detalhada, descobriu-se que pode ser encurtado várias vezes número de cenários de teste.
Essas três direções nos permitiram chegar ao ponto de lançá-lo em beta uma vez por dia, uma vez por semana ele atinge 100% dos usuários, não há regressão manual. Espero que essa história motive as empresas, que estão insatisfeitas com seu estado de lançamento, a agirem - para pressionar apenas o botão de liberação no futuro, tudo vai para os usuários e todos olham apenas para os gráficos.
Yuri Chechetkin:Essas são, é claro, não apenas práticas Revolut, mas também em todo o mundo, são usadas pelo Google, Facebook e assim por diante. Eu concordo que esta deve ser uma transição suave. E quando muitos se tornam POs ou entram em QA automatizado, tudo fica um pouco embaçado, evolui e se transforma em algo dito. E na Rússia essa tendência, entretanto, está apenas começando. E como você disse com razão, ele deve ser o mais saudável possível.
Nina Semkina: Houve essa pergunta. Quem executa os testes de unidade onde? No CI ou localmente antes de enviar?
Yuri Chechetkin: Parece que dirigir localmente é tarefa do desenvolvedor, ou seja, você não deve fazer isso à força. É óbvio para mim que deveria haver 100% de CI.
Nina Semkina: Obrigado a todos os participantes pela discussão! Dou a palavra ao nosso palestranteDima Manko com seu relatório.