Um , complementado por
outro , meus artigos acabaram sendo um possível guia de ação para aqueles que ainda não encontraram "seu próprio estilo" e não sabem por onde começar.
Alguns responderam que eu estava escrevendo sobre “verdades comuns”, mas recebi uma boa resposta nos comentários e mensagens pessoais da categoria “foi útil”, “o que preciso agora” etc. Mas havia perguntas. As perguntas, na maioria das vezes, se resumiam à “dor” que não passou por um único controle de qualidade em sua carreira:
- Como interagir efetivamente com os desenvolvedores?
- como organizar o trabalho com eles para que aceitem: existe outra opinião sobre o projeto, a opinião do controle de qualidade, e também é importante?
- como incentivá-los a interagir, por exemplo, ao criar uma automação de teste conjunta quando eles não estão configurados para trabalhar juntos?
- como agir no caso em que suas habilidades técnicas na pilha de tecnologias usadas simplesmente não são suficientes?
Imediatamente, faça uma reserva de que o tópico é muito sensível. Ao falar sobre isso, você sempre deve equilibrar-se a ponto de não prejudicar o orgulho dos desenvolvedores e do próprio QA. Portanto, peço que você leia com o coração frio e tente destacar alguns pontos úteis e experimentá-los na prática.
1. Introdução
Em primeiro lugar, como mostra a prática, geralmente os QA que não conseguem entrar no desenvolvimento conforme exigido pela profissão
- simplesmente não é autoconfiante. Eles não podem conseguir que foram ouvidos, porque falam de maneira inaudível, não razoável, expressando constantes dúvidas;
- eles têm medo de cometer erros e incorrem em responsabilidade extra;
- complexo devido ao conhecimento técnico imperfeito.
Em segundo lugar, os desenvolvedores da equipe percebem o controle de qualidade como um apêndice que simplesmente pressiona os botões antes de entregar o produto ao cliente ou simplesmente não imagina como interagir com eles. Isso pode ser devido ao fato de que
- eles ainda pensam no controle de qualidade como testadores de 10 a 20 anos atrás, quando realmente eram;
- todos os QAs anteriores com os quais eles trabalharam exatamente da mesma maneira e se comportaram, e eles simplesmente não sabem o que acontece de outra forma;
- em princípio, eles não sabem qual é a essência do trabalho do engenheiro de controle de qualidade, porque eles simplesmente não precisam dele - eles desenvolvem suas habilidades;
- o desenvolvimento de código já está bem estabelecido e mudar algo é apenas preguiça.
Vamos começar com o primeiro problema.
Engenheiro de controle de qualidade! Faça uma limpeza de primavera em sua cabeça
Trabalhe para entender sua profissão
Se você quer mudar o mundo, comece por você mesmo. Verdade bem conhecida e muito relevante em nosso tópico.
Como engenheiro de controle de qualidade, realmente não faz mal a você descobrir em que posição você trabalha. Se o seu projeto ainda segue os princípios da arquitetura em cascata e você foi contratado simplesmente por um testador manual, que, como a OTK nas empresas, verifica a disponibilidade do produto final, isso é uma coisa, e aqui tudo é bastante transparente.
E se você estiver na posição de um engenheiro de controle de qualidade completo, que está em quase toda parte agora, significa que sua responsabilidade, estabelecida pelos cânones dessa profissão em [1], não está apenas testando o produto final, mas também participando diretamente na organização dos processos de criação e na interação dos participantes. todo o projeto. Lembre-se de que, sem processos e organização claros da equipe, é quase impossível obter um produto de qualidade; portanto, nesse campo, a voz do controle de qualidade deve parecer confiante e clara. Para evitar o aparecimento de bugs, e não corrigir após o fato - esse é o conjunto de equipes bem organizadas. E fazer esforços para minimizar o número de bugs é parte da equipe de controle de qualidade. (O círculo fecha.)
Portanto, desde o primeiro momento, lembre-se de todas as coisas fundamentais sobre os princípios, tipos, níveis de teste e a redação da definição da profissão de engenheiro de controle de qualidade. Entenda o notório "Quem sou eu?" e "Por que estou aqui?"
Encontre respostas para as perguntas
Quando a escavação profissional terminar, traçar um plano para você, o que você fará, poderá obter idéias dos meus artigos ou elaborar seu próprio plano adequado às suas circunstâncias. Cada ponto de sua atividade deve ser claro para você mesmo - por que é, como implementá-lo, qual é o lucro.
Somente nesse caso você poderá falar com confiança no projeto. Mesmo que você, até agora, saiba apenas as respostas para as perguntas "por que" e "qual é o benefício", mas não sabe "como". Já se sinta confiante pelo fato de ver a frente do trabalho, a formulação correta da tarefa é 80% de sucesso.
O próximo passo é anotar as perguntas que você precisa resolver para responder à pergunta "como". E vá para as pessoas com isso, ou seja, discuta com a equipe - em uma reunião especialmente organizada, conversando entre negócios ou informalmente na cozinha, tomando uma xícara de café, isso não importa. É importante que o seu projeto esteja cheio de pessoas que tenham experiência diferente, outros conhecimentos, usem esse depósito de informações úteis, se comuniquem, perguntem e tudo será esclarecido.
Abandone a experiência de que você não é perfeito
Se você é muito tímido ou na vida um maximalista que sempre se esforça para ser um líder, será difícil desempenhar o papel de controle de qualidade. Como o engenheiro de controle de qualidade é um engenheiro, ele é uma pessoa envolvida no desenvolvimento, mas ao mesmo tempo nos encontramos em projetos com uma pilha diferente de tecnologias e arquitetura, enquanto os desenvolvedores têm sua própria especialização. Reconhecer que você está “fora de tópico” para algumas pessoas significa escrever a si mesmo em um “elo fraco”. E esse era o meu problema, que lutei por muito, muito tempo. "É isso que eu preciso dizer que não sei, que não sei o que, não entendo?!" - Mais de uma vez caí em estupor nas discussões de todos os aspectos técnicos.
Mas apenas em algum momento eu finalmente percebi que não saber não é uma vergonha. Tenho vergonha de continuar a "esconder-me" e não tentar descobrir. E permanecer calado, parecer onisciente, é mais caro para si mesmo.
Você foi contratado, eles leram seu currículo (você terá certeza de suas habilidades;)), conversaram com você na entrevista e foram contratados. Portanto, sua pilha de habilidades técnicas é boa para todos e para quem contratou você adivinhou o que esperar. Portanto, saltar acima da cabeça agora não faz sentido.E quando você diz: "Eu nunca trabalhei com isso, mas quero descobrir, me ajude a entender isso e aquilo" - esta é uma situação absolutamente normal, saudável e correta (não leve apenas o mais importante ao ponto do absurdo). conhecimento - definições e formulações - aprenda na Internet). E quando você indica a outras pessoas que não entende essa base técnica, em primeiro lugar, elas já sentem que é necessário falar de maneira mais simples e, em segundo lugar, você pode fazer perguntas esclarecedoras com a consciência limpa. Se você escrevesse o código uma ou duas vezes e entendesse completamente a arquitetura interna do projeto, provavelmente estaria diretamente envolvido no desenvolvimento, certo?
E meu pequeno truque favorito é sempre ajudar os outros, quando eu sou capaz - através de ações, conselhos, palavras gentis, isso volta com o desejo mútuo de outros de me ajudar.
Não tenha medo de cometer erros
Tome como certo que os fluxos de trabalho envolvem uma discussão de todas as opções possíveis. A verdade nasce em uma disputa. Sua tarefa não é estar certa, mas encontrar as melhores soluções. E se você quiser oferecer algo, mas tem medo de que isso pareça bobo, acredite em quantas equipes eu vi, os colegas silenciosos mais indiferentes parecem perdedores. Reconhecer alguns de nossos erros, apoiar as melhores idéias e contribuir com entusiasmo para sua implementação é um fluxo de trabalho saudável.
Lembre-se, a heroína de Muravyeva no filme "Moscou não acredita em lágrimas" se instalou antes de ir para a biblioteca: "se você deixar escapar, deixe escapar com confiança - então isso é chamado de ponto de vista". Isso realmente funciona.
Não tenha medo de chamar a si mesmo tarefas que você não pode lidar. Lembre-se, você está trabalhando em equipe e dizendo que algo não está funcionando e pedir ajuda à equipe é normal.
E mesmo que, no decorrer do seu trabalho, você chegue à conclusão de que não precisa fazer isso, será um progresso, porque o próximo passo é encontrar a melhor solução.
Liberar padrões obsoletos, olhar para o futuro
Essas bases de que o controle de qualidade é uma posição baixa, não são tão importantes e nem tão significativas, de uma maneira ou de outra, encontradas nas equipes. E enquanto você pensa assim, está subestimando essa tendência, infelizmente, a alimentação.
Você trabalha todos os dias, faz esforços todos os dias, aprimora o produto e a equipe, gasta tempo e energia, sua posição é definida na estrutura dos projetos - isso significa que é importante e necessário. Só isso. Não deixe espaço para a auto-mutilação e não deixe espaço para sua "provocação" daqueles que consideram que você é um status inferior a ele. Hoje em dia, quando havia testadores simples de mão para macacos, no futuro, os engenheiros de controle de qualidade são “um destacamento de elite das forças especiais cujo sucesso depende de excelentes táticas e armas modernas” [2].
Lembre-se de que hoje em empresas líderes como, por exemplo, Microsoft e Google, “os desenvolvedores são responsáveis pela qualidade. Se o produto quebrar após o lançamento, os cones voarão para o desenvolvedor que criou o problema, e não para o testador que não o encontrou ”[2]. Portanto, nessas empresas, ter uma equipe de controle de qualidade que ajudará a criar um produto de qualidade é um privilégio para os desenvolvedores.
E está em suas mãos a introdução de princípios avançados em suas empresas, em vez de rever os estereótipos anteriores.
Mais uma vez, volto ao fato de que você precisa crescer constantemente em seu projeto. Se você veio ao projeto, seis meses se passaram e ainda não criou uma automação de teste eficaz, não tente descobrir o que a equipe está fazendo, não analise os autotestes existentes, então você não é a elite que os livros escrevem.
Existem equipes que vivem sem uma posição de engenheiro de controle de qualidade, eu as conheço. E se você já se esforça hoje para mergulhar no projeto e aprender a escrever autotestes com desenvolvedores, um dia poderá vender suas competências até lá e se tornar um engenheiro de software em teste lá.
Engenheiro de controle de qualidade! Ajustar o trabalho em equipe
Quando o trabalho em si mesmo terminar, é hora de estabelecer uma colaboração com os desenvolvedores.
A coisa mais importante
- Suas ações devem ser claras e transparentes para a equipe. O mais simples e mais eficaz é transmitir sua missão a eles. Se, por nenhuma razão, você começar a subir no pool deles com solicitações perguntando: "que tipo de testes você tem aqui?", "Mas você ainda precisa escrever esse teste", a primeira reação (protetora) será " onde você está indo?! ”,“ quem é você / tal para criticar o meu trabalho?! ”. Ele pode ter preparado esse brunch por uma semana, finalmente exalado e depois o controle de qualidade. Portanto, diga a eles com antecedência o que você fará, por que e quais os benefícios disso para o projeto e a equipe. Prepare o solo.
- Sua participação no desenvolvimento a priori deve ser percebida como uma bênção, como algo que melhora qualitativamente o trabalho do desenvolvedor. Torne-se seu parceiro. Por exemplo, instrua - informe como é provável que os clientes usem a funcionalidade, quais erros já ocorreram e quais devem ser evitados, o que significa juntos pensar em quais testes e por que são importantes. Não se comunique de modo imperativo. Você pode até recorrer a truques psicológicos - para observar aqueles que aumentaram a cobertura dos autotestes em alguns relatórios finais no formato “estamos todos bem!”. É sempre bom quando seu trabalho é apreciado. E as análises tradicionais de controle de qualidade com cobertura de autoteste também são uma motivação para trabalhar em conjunto.
Que as mudanças no projeto sejam suaves. Se você vier trabalhar uma manhã e disser: "Eu li um artigo sobre Habré, e você começará a espancar um sapato em uma plataforma condicional, sacudindo o ar, eles dizem, agora eu vou lhe mostrar a mãe de Kuzkin!", Eles parecerão estranhos para você, isso é um fato. Sim, e será difícil para você - diante de problemas em todas as frentes - haverá um desejo irresistível de desistir de toda a idéia de melhorar o trabalho de controle de qualidade.
Melhor definir pequenas tarefas compreensíveis para todos, realizá-las e assumir o seguinte. Cuidadosamente, o tempo voa rapidamente; um dia será bom voltar.
Respostas a perguntas específicas
Depois do
meu segundo artigo , que ofereceu um trabalho próximo de controle de qualidade e desenvolvimento, o público expirou na categoria "tentamos, mas o líder da equipe de desenvolvedores realmente não queria conhecer". Do meu nível atual de desenvolvimento profissional, só posso aconselhar o seguinte.
Seja amigável e trate com sabedoria acalme aqueles que não aceitam seu trabalho como você espera. Em minha prática, conheci muitos desenvolvedores diferentes e todos aqueles que eram verdadeiramente profissionais sempre vinham me conhecer, sempre ajudavam, e alcançávamos excelentes resultados conjuntos, todos satisfeitos. Aqueles que “bufam” e “acenam para longe de você”, infelizmente, são da categoria de “adolescentes profissionais”. Eles ainda não aprenderam a lidar com seus sentimentos, considerando-se os mais de direita (e a idade física não desempenha um papel aqui). Eles simplesmente não sabem trabalhar em equipe, e você é parte integrante. Você pode apenas ajudá-los a crescer, mas, infelizmente, alguns nunca crescem. E aqui você só pode influenciá-los através do apoio da liderança e da autoridade coletiva do restante da equipe que o apoiará. Se você conhece as melhores maneiras, compartilhe!
Havia também uma pergunta interessante sobre como ser, se você ainda não sabe ler o código do desenvolvedor, não consegue descobrir seus autotestes.
Deixarei minha resposta aqui, para que não se perca, talvez alguém venha a calhar. Se você não consegue lê-lo, insisto em incluir uma lista de autotestes desenvolvidos na descrição de RP e focar nele. Acredito que este é um direito e dever total da equipe de controle de qualidade estar o mais consciente possível sobre a cobertura do produto com autotestes; caso contrário, toda a idéia de garantia de qualidade será perdida ... Se considerarmos a situação de severas limitações de tempo de toda a equipe, incluindo o desenvolvedor, eu insistiria na revisão Cobertura de cenários críticos / estratégicos pelos autotestes de integração. E para todos os outros cenários, documentei tarefas separadas para fazê-las mais tarde. Em qualquer projeto, há períodos calmos em que não há prazos - vale a pena focar o gerente de produto / líder de equipe / Scrum Masters em como incluir essas tarefas: é mais complicado - deixe os desenvolvedores fazerem, aprendam você mesmo os mais simples.
Conclusão
Não posso dizer que tudo o que está escrito acima certamente o ajudará, afinal, tenho a sensação de que minha própria voz e estilo profissionais vêm com experiência e através de inchaços. É impossível usar e como aplicar o script de trabalho de outra pessoa ao seu projeto através de um estêncil. Mas se meu rabisco o levou a não aguentar momentos de que não gosta, e você tinha na cabeça idéias de que pode fazer o bem a si mesmo, à equipe e ao produto, então passei o tempo em vão. E sim, não pense que eu represento o QA Shark, que sabe tudo, sabe tudo. Eu estudo e mudo constantemente. Estou ciente de que em um ano meus princípios de trabalho poderão mudar. Sempre muito feliz com o feedback e terei prazer em aprender com sua experiência, escreva;)
E se você quiser ler algo para fortalecer sua própria motivação, comece com dois livros maravilhosos, uma referência a que eu dei no texto:
1. Fundamentos de teste de software: Certificação ISTQB
por Dorothy Graham, Rex Black, Erik van Veenendaal, Isabel Evans
2. Como testar no Google
James Whittaker, Jason Arbon, Jeff Carollo
Obrigado a todos pela atenção!