Oi Habr. No último BackendConf, Anton Olievsky, nosso chefe do departamento de teste de software e controle de qualidade, falou sobre o mais, talvez, o mais importante - uma atitude consciente em relação ao trabalho.
Aqui está a coisa. A velocidade de implementação das idéias de negócios se tornou um fator-chave. Essa velocidade no SJ é estimada pelo tempo médio necessário para concluir a tarefa. Na empresa, esse tempo foi igual a 65 dias. Sim, dois meses desde a criação de uma tarefa até o envio ao usuário.
Anton diz que eles foram capazes de acelerar os processos em três vezes, graças a testes conscientes. Agora vamos dizer o que é e como exatamente.
Como foi antes?
O processo foi assim:
- 5 testadores para 40 desenvolvedores;
- Cada tarefa é testada separadamente;
- As tarefas concluídas são mescladas no ramo de lançamento;
- Na liberação, é realizado o teste de aceitação;
Então integração.
Se o resultado foi bem-sucedido, a liberação foi enviada aos usuários, e 50 a 60 tarefas aguardando testes estavam constantemente penduradas no quadro.
Como você trabalhou com a tarefa:
- Desde o desenvolvimento, a tarefa foi testada e foi perdida na lista sem fundo de outras pessoas esperando;
- Na lista, ela podia ceder de alguns dias a um mês;
- Em seguida, a tarefa foi verificada pelo testador, foram feitos bugs e enviada de volta ao desenvolvimento;
- O programador corrigiu os erros e retornou a tarefa novamente para um teste.
O ciclo foi repetido e a tarefa pode congelar no estágio de teste por vários meses. Do ponto de vista técnico, tudo estava bem, apenas os recursos foram lançados lentamente e o negócio foi infeliz. Os testadores ouviram constantemente o fato de que o desenvolvimento está avançando muito lentamente, os prazos estão se esgotando e os negócios estão perdendo dinheiro.
Como qualquer testador normal, os caras leem livros inteligentes sobre testes e pensam que o principal é a qualidade do produto. Assim, você precisa encontrar o maior número possível de bugs e certamente consertar todos eles. Mas não.
Porque não
Como não precisamos corrigir bugs, mas ajudar os negócios, Anton foi até o produto Dima para lidar com a situação. Lá eles decidiram que o principal é a velocidade de lançamento dos recursos. O fato é que os negócios não gostam de perder dinheiro com o desenvolvimento e a correção de projetos, o que não está claro se trará benefícios. Portanto, é melhor lançar um projeto imperfeito e, com base nos resultados de seu sucesso, decidir se deve trazê-lo ao ideal ou minimizá-lo. Os testadores se reuniram e tentaram entender como aumentar a velocidade de liberação. Acabou que tudo é óbvio.
O SJ tem uma aceitação (um conjunto de casos nas principais áreas de funcionalidade para verificar o produto como um todo, por exemplo, autorização do usuário, colocação de trabalho etc.), que consiste em 150 casos e leva 1,5 dias do testador. É muito longo.
Sério, são cerca de 1,5 dias de verificações manuais 2 vezes por semana. O que deve ser feito com verificações manuais repetidas? Automatize.
Acabou automatizando 100 casos. Casos não lucrativos para compartilhar sobre automação, enviar cartas e receber SMS permaneceram não lucrativos. Os testadores ficaram encantados, pois havia menos custos regulares para liberar os testes - 3 horas, em vez de 1,5 dias. Em segundo lugar, os autotestes fornecem feedback rápido sobre a possibilidade de começar a assistir a uma versão e permitem detectar bugs mesmo antes de uma tarefa ser lançada.
Quase tudo foi decidido, mas o CTO chegou.
O que mais está errado?
Ele veio e disse que precisamos ver para onde vai a overdose de horas de trabalho. Os caras sentaram e perceberam que as ações repetitivas eram apenas em lançamentos - era aceitação e integração.
E a integração? Em suma, houve uma situação em que eles enviaram um release e o produto de Dim ficou ultrajado por a tarefa que prometeram não ter chegado à batalha. Eles começaram a descobrir para onde ela tinha ido. Aconteceu que, ao manter tarefas na ramificação de liberação, algumas confirmações foram perdidas e a tarefa foi visualmente perdida para os usuários.
Os desenvolvedores começaram a corrigir os scripts de construção e os testadores verificaram os casos de cada tarefa no release para garantir que tudo acontecesse juntos e que todas as tarefas estivessem no lugar. Parece ser tão difícil verificar as tarefas que já foram visualizadas. Mas aconteceu que havia cerca de 5 tarefas para cada testador na versão, e casos complexos surgiram, como alterar algo no banco de dados, executar um script, verificar a carta recebida. Todo esse estágio levou muito tempo: de 2 a 10 horas de trabalho para todos os testadores.
Os caras fizeram estatísticas por vários meses dessa prática e verificou-se que não havia mais casos com uma versão ruim do lançamento e, nesta fase, apenas algumas vezes havia bugs acríticos que eram perdidos ao testar as tarefas. Pesamos todos os prós e contras e decidimos abandonar esse estágio.
Agora ok
Não está bem No mundo da TI, você não pode obter sucesso por muito tempo, porque sempre há algo a melhorar. No nosso caso, estes eram lançamentos 2 vezes por semana. Por exemplo, os testadores verificaram a tarefa na manhã de quarta-feira e a enviaram para liberação, e ela chega ao usuário somente na terça-feira da próxima semana.
O que mais? Muitos hotfixes da empresa. A empresa planejava lançar um recurso para alguma data, anunciou e lançou um anúncio publicitário, e os testadores foram: "Ninhada, gay, planejamos lançamentos aqui e a tarefa será lançada apenas na próxima semana". Portanto, para cada uma dessas tarefas, o produto Dima recorreu a eles.
E todo mundo sabe que, se o Dima entrar em desenvolvimento, aguarde o urgente. Tais ataques estão cansados dos desenvolvedores e testadores. Não é este um motivo para voltar à sala de reuniões ?! Todos eles se trancaram e decidiram que o negócio precisa ser lançado com mais frequência; portanto, você precisa automatizar ainda mais, verificar o lançamento em três horas, automatizar a criação diária do lançamento e configurar o lançamento de autotestes no lançamento e realizar aceitação todos os dias.
Esta foi uma pequena vitória, porque os recursos se espalham após testar o máximo no dia seguinte. Houve menos problemas com hot fixes, alguns foram enviados para a versão atual e outros aguardavam a liberação de amanhã. Isso permitiu que os testadores não se distraíssem com essas verificações e liberassem tempo para testar novas tarefas. Estatísticas sobre erros perdidos permanecem inalteradas, a propósito.
Então a testadora Julia foi até Anton e disse que estava cansada disso. Como, faça o que você quiser, mas ela não poderá mais aceitar todos os dias, dado que, de acordo com a funcionalidade principal, raramente algo muda e ele não encontra bugs. Portanto, Julia se ofereceu para realizar uma aceitação uma vez por semana.
Bem, ok gays.
E como é isso?
Economize tempo - 12 horas por semana para testar novas tarefas, menos desmotivação em verificações monótonas. Dos pontos negativos - os bugs podem viver até 5 dias a partir da data de aparecimento. Muito foi feito com sucesso para acelerar, mas, ao mesmo tempo, os caras tiveram pouca influência sobre o mais importante - o tempo médio necessário para concluir uma tarefa na produção.
Eles avançaram em direção à meta, mas não a alcançaram. Sim, os testadores podiam dedicar seu tempo a novas tarefas, mas, pela velocidade da passagem, era uma gota no balde.
Anton saiu para pensar em quais tarefas passam por testes e percebeu isso quase tudo. E o fluxo é enorme, como a Fossa das Marianas, por isso é impossível processar tudo. Portanto, foi decidido priorizar. Nesta fase, o produto Dima ajudou, o qual, juntamente com Anton, verificou tudo o que não era importante para os negócios.
Apenas pontos diretamente relacionados ao dinheiro e coisas críticas para os usuários permaneceram.
Em resumo, apenas 50 são deixados em uma lista de 300 itens.
Você já pode trabalhar com isso. A propósito, que bônus o desenvolvimento web oferece?
- A capacidade de responder rapidamente aos bugs encontrados na batalha;
- Monitoramento online de problemas;
- Suporte técnico em contato com os usuários.
Agora a coisa mais importante. Sim, os livros de teste ensinam como testar tudo, mas todas as circunstâncias disseram a Anton que nem tudo precisa ser testado. Segundo Anton, nesses três dias de reflexão, ele se sentia como Hamlet com a pergunta "Ser ou não ser".
Reunindo toda a sua vontade em um punho, ele decidiu o que ser. E ele se recusou a testar funcionalidades sem importância. Os testadores começaram a aplicar tarefas nesses 250 pontos após o desenvolvimento imediatamente no lançamento. Sério.
Nem toda empresa concordaria com esse passo, e quase todos os testadores que se recusam a testar feriram o boato. Mas essa decisão tornou possível se concentrar no realmente importante.
A falha no teste é uma etapa responsável e perigosa.
Se você também quiser fazer isso:- A lista de funcionalidades críticas está disponível ao público para que os desenvolvedores possam acessá-las;
- Para avaliar a nova abordagem, adicione ao Jira o relacionamento "gerado em => gerado". Assim, você pode acompanhar quantos bugs passam em tarefas não testáveis;
- Como não é muito estúpido testar a maioria das tarefas, verifique alguns casos principais, mas na versão para não desacelerar o vazamento;
- Funcionalidade crítica para testar de acordo com o esquema antigo.
O que vai mudar?- A maioria das tarefas irá parar de derrapar durante a fase de teste;
- Os testadores lidam apenas com tarefas críticas aos negócios;
- O importante é levado a testes mais rapidamente, já que os sem importância agora não interferem no quadro.
O que é tão ruim- Usuários reais são mais propensos a encontrar erros menores;
- A carga no suporte técnico está aumentando, porque os erros perdidos começam a surgir dos usuários.
Foi machucado?
Os caras concluíram todas as etapas descritas em seis meses. Sim, doeu, mas a saída foi a seguinte:
O tempo médio necessário para concluir uma tarefa foi reduzido para 19 dias e está diminuindo constantemente;
O fluxo de tarefas de teste é reduzido. Os testadores começaram a se preparar para testar recursos importantes em paralelo com o desenvolvimento;
O produto Dima parou completamente de ir para Anton.
Em vez de conclusões
Não use nossa abordagem na medicina ou na construção de aeronaves. Em situações que não estão associadas a um risco à vida - teste suas decisões e abordagens.
Não acredite em livros e pare de testar apenas por estar escrito em algum lugar.
Pergunte a si mesmo se você atende às expectativas da empresa e se cada item da sua lista de tarefas é realmente útil.
SuperJob estava com você. Consciência a todos!