Então Em 2018, na Heisenbug (Moscow Testing Conference), Baruch Sadogursky (Advogado de Desenvolvedor da JFrog) apresentou uma palestra interessante, na qual falou sobre suas idéias básicas sobre para onde ir. Em 2019, no mesmo Heisenbug, uma sequência de seu relatório foi realizada sobre COMO alcançar esse objetivo. Por um lado, gostaria de apoiar a versão do movimento de B. Sadogursky, que ele transmitiu, mas primeiro ainda não o conheço e, em segundo lugar, arriscarei formular minha visão e descrever meu caminho pessoal com base em minha própria experiência.
Dado
Para o contexto (é fictício e qualquer coincidência com casos reais é pura coincidência), apresentaremos a uma empresa regional de fornecedores de TI uma unidade de desenvolvimento bastante grande. Dentro desta unidade existe uma função de teste, que consiste em condicionalmente 30 pessoas de vários níveis de conhecimento e habilidades.
Companhia
A empresa apresentada possui vários produtos que estão na versão há muito tempo e o estágio inicial de seu desenvolvimento foi concluído há mais de 7-8 anos atrás. Dado que a empresa é um fornecedor, monitora seus produtos e os desenvolve regularmente, mas não os refaz do zero. Isso significa que os produtos contêm uma grande quantidade de código legado, soluções tecnológicas e arquitetônicas "antigas". O teste desses produtos nos estágios iniciais não foi considerado, antes que seu desenvolvimento fosse realizado com o princípio de "mais rápido, mais rápido e em produção", mas hoje há uma grande quantidade de testes manuais - tanto na regressão quanto no teste de novas funções. Ideologicamente, o desenvolvimento de produtos é realizado sob a pressão das necessidades dos negócios, para que não haja tempo para repensar as ideologias e refatorar os próprios produtos. Isso é feito apenas no momento em que todos entendem que isso não funcionará mais da palavra "completamente".
Além dos produtos antigos, a empresa está desenvolvendo soluções completamente novas, usando as mais recentes tecnologias e abordagens arquitetônicas. Mas aqui nem tudo é tranquilo, pois a pressão geral das necessidades dos negócios não diminui. Os testes nesses projetos já estão presentes nos estágios iniciais do desenvolvimento, no entanto, ainda prevalecem as "soluções manuais", que fornecem os resultados mais rápidos e permitem que os desenvolvedores escrevam exclusivamente o código do produto sem pensar em como será testado.
Função de teste
Agora, algumas palavras sobre a estrutura: como eu disse, cerca de 30 pessoas fazem parte da função de teste. Destes, 17-19 é o elo júnior com experiência nesta área de não mais de 1 ano. Freqüentemente, são pessoas sem formação técnica, mas com “olhos ardentes” e um grande desejo de trabalhar na área de TI (por que eles têm esse desejo é um tópico separado para discussão). As 11-13 pessoas restantes são os gerentes seniores e médios: 3-4 pessoas representam os seniores e 7-10 pessoas - a média. Toda a função de teste é distribuída por 13 a 15 produtos / projetos diferentes, com diferentes graus de participação, complexidade e envolvimento.
Cultura
Esta é a última introdução.
Infelizmente, ainda há algum mal-entendido sobre o valor que a função de teste pode trazer. Isso ocorre porque o resultado do trabalho na forma (por exemplo) de um novo recurso é visível para todos, compreensível e praticamente "tangível" - quando implementado, a qualidade geral do produto aumenta e torna-se pelo menos embaraçoso para os produtos da empresa. Ao mesmo tempo, existe um culto aos desenvolvedores, onde as seguintes afirmações são verdadeiras: “O desenvolvedor é o ator principal e, se ele não estiver lá, o resto pode ser demitido”, bem como “Os desenvolvedores são um recurso caro e devem escrever apenas o código do produto e não devem se distrair com atividades sem importância. " Com base nessas declarações, uma certa "cultura" se formou nesta empresa.
Declaração do problema
E como eles dizem, qual é o problema? Por que mudar alguma coisa se tudo funciona assim? Por que mudar para algum lugar, se houver um modelo funcional, e que traga seus dividendos?
Essas perguntas podem surgir logicamente em uma pessoa que paga por todo o desenvolvimento. Mas existem 3-4 pessoas na função de teste que se consideram subestimadas, que viram o primeiro relatório de B. Sadogursky e não apenas que veem o lado oposto da situação e gostariam de mudar o que está acontecendo para melhor e, assim, resolver alguns problemas doentios.
Em seguida - pura fantasia e sugestões baseadas em materiais de vários autores e especialistas na área de TI.
Solução (possível)
Vamos começar definindo metas e objetivos dentro da estrutura da mudança. Omitiremos conscientemente o lado mercantil e não o levantaremos; esse é um tópico separado para o holivar, especialmente porque ele desempenhou um papel significativo na situação atual da empresa.
Nós desenhamos uma imagem do futuro. Para que estamos nos esforçando?
Antes de mais, queremos em pouco tempo obter um conjunto de produtos de alta qualidade (!) Que trarão um lucro bastante alto. Você precisa entender que "rentável" não significa "qualidade".
O que precisamos fazer para alcançar a meta? Antes de tudo, proponho considerar o caminho do ponto de vista da tecnologia, e não do comércio. Para atingir a meta, é necessário focar no fato de que os produtos devem atender às necessidades dos usuários finais, ao mesmo tempo em que apresentam baixos custos, tanto para o desenvolvimento de novas funções quanto para a manutenção das que já estão em produção. Ou seja, durante o desenvolvimento, devemos: a) entender claramente o vetor de movimento, b) tornar os produtos confiáveis o suficiente para que não haja problemas com sua operação, em termos simples, verifique se não há erros ao trabalhar com o produto. Com base nisso, devemos ter a chamada Política de Zero Bug para todos os produtos, ou seja, nossos testes, como um processo, devem nos dar uma garantia da ausência de erros de produção.
O segundo aspecto é o foco no resultado final de todo o processo de desenvolvimento, o que nos permitirá não desenvolver o que o usuário não pode usar ou não pode entender COMO usá-lo. Mencionamos apenas a segunda parte, porque o tópico é muito extenso, mas não funcionará sem tocá-lo.
Portanto, nosso objetivo é:
"De maneira rápida, eficiente e com um preço razoável " (mais barato, provavelmente, você não pode fazê-lo imediatamente).
Agora vamos tentar correlacionar o que foi dado com o objetivo pretendido.
Rápido . Sim, é possível, mas comprometemos a qualidade: os processos manuais existentes de garantia de qualidade poderão fornecer velocidade de execução suficiente apenas em pequenos produtos com histórias simples de usuários. Além disso, o perfil da empresa é o desenvolvimento de soluções bastante complexas para automatizar processos de negócios. Conclusão - “rápido” não funciona, pois o trabalho manual a priori em grandes volumes perderá para qualquer solução automatizada.
Concentre-se no resultado . É possível, mas requer que os participantes gerem o valor de uma imersão suficientemente profunda na área de assunto e um grande tempo gasto em transmitir esse valor ao executor final. Ao mesmo tempo, artistas são desenvolvedores que, como parte de uma das instruções, devem passar o tempo máximo escrevendo código sem se distrair com o ambiente.
De tudo isso, segue-se que, para resolver o problema principal, é necessário envolver não apenas especialistas em controle de qualidade, mas também desenvolvedores no processo de teste. Ao mesmo tempo, para aumentar a velocidade de entrega de valor, é necessário considerar com mais cuidado os processos de automação de entrega e automação de verificação do que é entregue.
O que precisa ser feito para resolver o problema principal?
Na minha opinião, com base na experiência, requer:
- Mergulhe os desenvolvedores mais nos objetivos do produto;
- Convencer as empresas de que os custos de automação são importantes e fornecem mais benefícios econômicos para todos os custos econômicos.
- É aconselhável automatizar tudo o que pode ser automatizado, excluir o trabalho manual do processo de entrega de valor ao máximo.
- Implemente a Política de Zero Bug, sem a qual os usuários enfrentarão problemas que repelem nossos produtos. A propósito, um exemplo bem-sucedido de "DoDo" sugere que isso é bastante viável.
O que precisamos fazer para convencer os participantes da necessidade de mudar atitudes e visões de mundo?
Desenvolvedores
Como argumentar - por que eles precisam fazer outra coisa além de sua programação de código funcional favorita? Proponho que me concentre diretamente nos problemas que surgem com essa organização. Existem vários deles:
- Desenvolvendo o que ninguém precisará. IMHO, este é um dos primeiros problemas. Os desenvolvedores estão fazendo algo, mantendo a confiança de que estão fazendo certo, mas no final eles obtêm o resultado errado que o usuário final queria. Porque Porque tarefas e problemas não são transmitidos a eles por quem usa o produto, mas por gerentes ou clientes que posteriormente não usam esses produtos. Por que isso está acontecendo? Todas as pessoas têm opiniões diferentes. Se o desenvolvedor fosse colocado não como uma tarefa puramente técnica, mas funcional com uma descrição do resultado na saída (e ainda melhor - com uma descrição do problema que essa tarefa deveria resolver), haveria mais compreensão do resultado e, como resultado, o número de casos de desenvolvimento de algo desnecessário seria reduzido. Sim, essa é uma verdade bem conhecida, mas o problema ainda não desaparece, ele precisa ser resolvido com os negócios, justificando de uma maneira um pouco diferente a formulação de tarefas para o desenvolvimento. Sobre como transmitir isso aos negócios - além disso.
- A necessidade de alternar entre contextos. Freqüentemente, no processo de desenvolvimento com a presença de testes manuais, os resultados estão atrasados; como resultado, o desenvolvedor precisa se distrair resolvendo os problemas que aparecem como resultado dos testes. O que impede que os desenvolvedores verifiquem após a implementação seu próprio resultado? Existem dois pontos. O primeiro é a falta de conhecimentos e habilidades no campo da garantia da qualidade. O segundo - os desenvolvedores costumam pensar que esse não é o trabalho deles e, como resultado, não querem fazê-lo. Em um dos primeiros podcasts do RadioQA, há toda uma questão sobre desenvolvimento sem testadores, que descreve com detalhes suficientes esse efeito e as razões dessa "relutância".
Como o teste ajudará os desenvolvedores ou como ajudá-los a resolver os problemas indicados?
- Obtenha mais informações sobre a área de assunto ou o objetivo das tarefas a serem resolvidas. Quais são as perguntas típicas que um desenvolvedor faz ao apresentar uma tarefa? “Como fazer isso?” “E o que precisa ser feito aqui?” “E como fazer isso, apesar de apenas isso ser conhecido?” “E como isso afetará essa função?” Todas essas perguntas visam esclarecer a implementação da tarefa e não entender a variabilidade dessa tarefa. O que um testador faz quando se familiariza com uma nova descrição de uma nova função? Ele também faz perguntas, mas de uma maneira um pouco diferente: “O que acontecerá se?” “Por que deveria ser assim?” “O que devo obter no final?” “O que eu tenho no começo?” “Como isso deve ser relacionado com isso? " Ou seja, quase todas as perguntas têm como objetivo identificar exatamente o cenário do usuário e entender o resultado dessa função.
O que é importante? Ao fazer não apenas perguntas esclarecedoras (como implementar), mas também perguntas destinadas a entender o resultado final, você pode obter mais informações sobre a tarefa, tornar os esperados não apenas métodos familiares, mas também mais simples e mais eficazes. Em um cenário positivo, isso ajudará a não escrever código extra ou a criar exatamente o que o usuário final exige, e é disso que precisamos.
Alguém perguntará: "Por que eu, como desenvolvedor, deveria estar interessado ou devo pensar sobre isso?" Nós responderemos - para não evoluirmos "para a mesa". Os resultados de uma pesquisa de desenvolvedores em meu ambiente mostram como é desmotivador quando você faz algo, mas não o libera (coloque-o na prateleira).
- Outra pergunta: “Por que eu, como desenvolvedor, preciso fazer testes se tivermos testadores?” Ou “Por que preciso desenvolver algum código adicional que não atenda às tarefas definidas do produto?” . Aqui você pode oferecer outra coisa. Os testes automatizados são essencialmente o mesmo código que obedece às mesmas leis de programação com uma leve nuance. Quando um desenvolvedor trabalha na estrutura de um produto grande, ele é forçado a obedecer às regras e tecnologias de desenvolvimento selecionadas no produto e escreve no idioma em que este produto foi criado para usar as estruturas usadas neste produto. Não é necessário fazer isso ao escrever um teste: ninguém o obriga a usar a mesma linguagem ou as mesmas abordagens: ao implementar testes automatizados, você pode facilmente experimentar um idioma completamente novo e obter experiência com ele.
Há uma regra simples que os desenvolvedores seguem ao escrever o código do produto - a otimização máxima do que você está fazendo, o consumo ideal de recursos, o desempenho ideal, (preferencialmente) a reutilização máxima e assim por diante. Ao desenvolver testes automatizados, também existem regras, existem modelos, existem estruturas, mas são diferentes. A tarefa deles é capacitá-los a criar o código de teste o mais rápido possível, o que funcionará ... Simplesmente funcionará.
Otimização e velocidade de execução em autotestes são pontos secundários e não são lembrados imediatamente. Portanto, se você quiser tentar repentinamente com o Kotlin, Java ou qualquer outra linguagem, mas o projeto estiver escrito em uma linguagem completamente diferente da desejada (por exemplo, em C #), você poderá alterá-la para a desejada desenvolvendo autotestes.
- Como faço para testar? Eu não entendo nada sobre isso. Eu sou apenas um desenvolvedor. Aqui, os testadores vêm em socorro, ou melhor, engenheiros de controle de qualidade que estão bem cientes de todas as tecnologias nas quais o produto principal está escrito. Graças ao seu conhecimento, eles podem ajudar a educar os desenvolvedores sobre como e o que testar, como escolher os dados corretos, o que o gerador de dados deve fazer para minimizar os riscos por tipo e o que você não deve prestar atenção. Nesse conjunto, os testadores tiram o máximo proveito de seus conhecimentos e os desenvolvedores não realizam trabalhos desnecessários.
- “Mas e a velocidade? Ela está sofrendo! Sim, ela sofrerá nos estágios iniciais do desenvolvimento do projeto e, claro, desde o início, mergulhar na automação total é cara. O que fazer para que os custos sejam ótimos? No mínimo, devemos entender claramente como e o que automatizar. E também faz sentido não fechar tudo sem pensar com testes e se esforçar para obter 100% de cobertura do código, mas fazê-lo com base no modelo de risco. Os engenheiros de controle de qualidade farão o mesmo.
- “Velocidade! Queremos receber entregas com rapidez suficiente. Também queremos ser confiáveis e nossos produtos não apresentam erros! ” Aqui proponho mudar a abordagem do desenvolvimento. Se costumava estar na moda executar tudo no modo de depuração localmente, agora para aplicativos sérios, é necessária alguma infraestrutura para funcionar. É aqui que todas as novas tendências sobre dockereization e a implementação de vários estandes são adequadas. Outra coisa é importante: mesmo no primeiro estágio de desenvolvimento, você precisa pensar em como ele será entregue nos estandes de trabalho, ou seja, não apenas implantar tudo manualmente, mas também configurar um processo automatizado de implantação. O que isso nos dará? Quando chegar a hora da entrega à produção, será suficiente alterar apenas o ponto de cálculo e não configurar todo o processo do zero. O que isso dará ao desenvolvedor? Mais confiança de que ele está fazendo tudo certo, porque os scripts de entrega foram verificados por mais de uma rodada e não deve haver problemas com o lançamento.
Negócios
Mas e os negócios? Por que ele deveria estar interessado nessa transformação? Por que faz sentido para ele investir nessa abordagem? Construindo a explicação, irei da mesma maneira. Que problemas essa empresa tem agora, que problemas você precisa resolver ao trabalhar no campo de TI e ao desenvolver produtos de alta tecnologia? Novamente, vou confiar aqui precisamente na minha opinião:
- "O que pode não ser mais adequado para os negócios?" Freqüentemente, o desenvolvimento esquece que o produto deve não apenas ser desenvolvido, mas também vendido, para o qual é necessário um conjunto de medidas suficientemente grande, incluindo a preparação para a entrada no mercado. Fazer isso após o desenvolvimento do produto é uma falha garantida, razão pela qual a maior parte do trabalho na preparação dos canais de vendas e na promoção de um novo produto começa quase no exato momento em que o desenvolvimento começa.
“O que acontece se o desenvolvimento estiver atrasado para a data de lançamento? Ou o desenvolvimento trará ao mercado um produto insuficientemente de alta qualidade? ” Haverá perdas. E não apenas material, mas também de reputação. É importante que as empresas tenham certeza de que, no momento em que as vendas começarem, o produto não estará apenas pronto, mas também terá a qualidade adequada. Se houver etapas manuais de teste no processo de desenvolvimento, será inevitavelmente necessário reagendar ou levar em consideração os riscos de interrupções nessas etapas. É possível prever o fator humano, mas é difícil e (na minha opinião) não é menos caro.
- “Com o que mais a empresa se importa?” É claro que ele está preocupado com investimentos de capital em desenvolvimento. Mas os investimentos de capital, em sua maioria, embora volumosos, são feitos no estágio inicial, ou seja, Antes da liberação, ou pelo menos antes da liberação, os custos não são compensados pelas vendas. Juntamente com os investimentos de capital, também existem despesas operacionais que começam a contribuir no estágio operacional e é importante tentar minimizá-las o máximo possível.
“Por que a automação é muito cara (em termos de dispêndios de capital), neste caso, vence em relação à abordagem manual?” Minha opinião é um fator óbvio. Automação é o mesmo desenvolvimento. , . , , , , . , . Por que isso é importante? . , , « , , , » , , .
- — . , . , , . , .
? , - . . , , , . , , , , , . , .
Suponha que uma empresa concorde com a necessidade de mudanças no processo e esteja pronta para "comprar tudo de uma vez". Quanto vai custar e quais despesas devem ser incluídas?- , , , , . : X Y , , , X Z , Z < Y. : , , ( ) .
- — QA-. , «» . , QA- , , , . : , , , , , .
— , . . , , , , , , , , , . .
- — . , , . , , , , . , QA-. , . , , «» — , , , . , , .
- , , — (, , - ). . , . , , , , , (), .
É impossível dizer que esse caminho é definitivamente mais lucrativo em relação a uma solução manual, mas toda a sua vantagem é revelada nos deltas de despesas operacionais e satisfação do usuário final. Podemos comparar isso com a compra de um carro caro, mas confiável, que não requer despesas, exceto gasolina e manutenção regular, e a compra de um carro usado antigo. Sim, o preço de um novo é mais alto no início, mas os custos operacionais são mais baixos e o conforto e a "sensação de calma" são mais altos. Com um usado no início, os custos são baixos, mas durante a operação, os custos aumentam e após um curto período de tempo podem ser comparados com o custo da compra inicial.Vá em frente. Não esqueça o nosso contexto e lembre-se da composição da função de teste.Testadores
O que acontecerá com o recurso de teste existente? Se olharmos novamente para a composição dessa função, com 90% de certeza, podemos dizer que 60% dos funcionários de toda a estrutura não serão úteis na nova forma da função, mas existem vários MAS.Se você se lembra que mencionamos produtos novos e antigos de nossa empresa. A transição de novos produtos para o modelo de entrega descrito por mim será relativamente indolor, pois eles ainda não estão no lançamento ou acabaram de sair. Ao mesmo tempo, os produtos que estão em operação há muito tempo não permitem aplicar imediatamente esses conceitos. Isso não significa que você precise colocar um fim nelas, há algo para mudar, mas não será rápido - mover o processo do zero, obter processos de entrega mais confiáveis e mais rápidos.É por isso que a camada da função de teste “manual” não deixará de existir da noite para o dia, pois você precisará fazer muito esforço. Uma parte dos testadores “manuais” terá tempo para se transformar em engenheiros de automação ou de controle de qualidade. É bastante óbvio que durante esse processo de transição, o vínculo médio e sênior assumirá a função de suporte - eles são os candidatos mais prováveis a incorporar novos conceitos em diferentes níveis amanhã. Uma equipe sênior com experiência e conhecimento, também familiarizada com os conceitos de automação e testes ShiftLeft, está pronta para desempenhar o papel de engenheiros de controle de qualidade amanhã, o link do meio levará algum tempo, mas também poderá integrar-se rapidamente às funções de engenheiro de controle de qualidade ou engenheiro de automação.Definitivamente, ainda não respondi a nenhuma pergunta neste amplo tópico. Estes são os que eu ainda não entendo. Aguardando seus comentários.