Antecedentes
Recentemente, um dos meus conhecidos engenheiro de controle de qualidade, que trabalhou por um longo período em um projeto lento, onde suas responsabilidades eram estritamente descritas, mudou de emprego e entrou em um projeto recém-lançado. Depois de passar alguns dias sem as tarefas indicadas acima, e francamente entediada, ela foi à gerência com a pergunta "O que devo fazer?" a que ela recebeu uma resposta significativa "Organize seu trabalho". E então ela caiu em um estupor "E como é isso?" E realmente, como?
Alguns meses atrás, mudei de emprego e entrei em um projeto em inglês que nunca tinha controle de qualidade antes. O projeto em si já existe há muito tempo. Como costuma acontecer, uma empresa em que há muito dinheiro comprou uma empresa em que há menos dinheiro, mas há clientes. Como resultado, uma grande empresa recebeu novos clientes e menos um concorrente no mercado. Meu projeto recebeu uma mudança de gestão e princípios de gestão.
Nos primeiros dias em que conheci uma nova equipe, ouvi uma pergunta confusa e honesta de um dos desenvolvedores do escritório de Londres: "O que você fará aqui?"
Na verdade, tendo chegado a esse projeto e olhando em volta por vários dias, eu, como meu colega, caí em um estupor. Não porque eu não sabia o que fazer. Antes, não sabia como me encaixar corretamente nas fundações que se desenvolveram aqui. A equipe de desenvolvimento teve uma existência maravilhosa sem testadores. Eles usaram o kanban, os princípios da entrega contínua, sem medo, calma e confiança, implantados na produção quase todos os dias, mesmo às sextas-feiras. E tudo porque eles tiveram excelente cobertura com autotestes. Talvez o melhor que eu já conheci. Ao revisar as solicitações de cada um, eles não hesitaram em dizer um ao outro que outros autotestes adicionar. O próprio autor da mudança atual implantou seu trabalho na produção, o que significa que ele era totalmente responsável por seu trabalho. E ele o carregou, apesar do fato de eu ter aparecido no projeto ... e antes da implantação, seria bom ouvir minha opinião.
Mas, no entanto, é claro, o processo não foi perfeito: aconteceu que os desenvolvedores não entenderam os requisitos, perderam os bugs e, muitas vezes, no lado do cliente, houve alguns problemas que exigiram ação.
Diante da necessidade de determinar minha posição na equipe, fui também à liderança. Apenas o nosso diálogo foi construído de maneira bastante diferente, não como a do meu amigo.
Organização do trabalho do engenheiro de controle de qualidade
Faça as perguntas certas.
Então Para um diálogo, convoquei a liderança e os principais desenvolvedores do projeto. Existe uma regra maravilhosa de gerenciamento, que eu obviamente não poderia esquecer: expressar o problema, expressar a opção de resolvê-lo, pelo menos uma.
No entanto, eu tinha duas perguntas, as respostas que eu não sabia. A maneira mais fácil de começar com eles.
Primeira pergunta. Qual é a estrutura da organização, a saber, quem está de pé sobre quem e quem é responsável por quê?Idealmente, as empresas devem ter um esquema apresentado hierarquicamente ilustrando a estrutura da empresa. Mas como eu não sou o ideal, era importante descobrir a quem, com quais perguntas e sugestões você pode ir.
A segunda pergunta. A empresa introduziu o engenheiro de controle de qualidade no projeto, quais são suas expectativas para mim e quais foram seus objetivos na abertura dessa posição?Quando a resposta é muito específica, determina em grande parte a frente do trabalho. No meu caso, a resposta continha muitas frases borradas gerais, que eu percebi como "faça o que você quer, mas para que tudo esteja bem conosco".
Sobre isso, a primeira parte da discussão terminou.
Discutimos o plano de ação
A segunda parte das discussões, e talvez a mais importante, foi a apresentação do meu plano de trabalho e sua lógica. Eu precisava receber a bênção de meus superiores pela introdução sem impedimentos de mim e de minhas atividades no projeto.
É agradavelmente óbvio que livros e teoria inteligentes não existem do zero, por isso me preparei com o conhecimento adquirido na preparação para a certificação ISTQB. Uma vez por curiosidade, li livros sobre teoria de testes e Scrum, passei por uma peneira de dez anos de experiência e compilei um piloto projeto para a estratégia de controle de qualidade.
Negociado com a administração e com o total apoio dele, mais tarde ele adquiriu o formato do documento oficial da empresa. Em seguida, quero compartilhar idéias sobre como elaborar esse documento. Eles formaram a quintessência da experiência anterior e o caminho percorrido no projeto atual.
E, talvez, na forma de citações, reimprima aqui alguns fragmentos em minha forma original: em inglês. Estou certo de que, para cada engenheiro de controle de qualidade, a preparação de um plano desse tipo será a resposta principal para a pergunta "Como organizar seu trabalho"
Formamos a estratégia de controle de qualidade
1. Introdução à Garantia da Qualidade
Lembre / introduza o termo Garantia de Qualidade pela primeira vez. Acredite, sua equipe está cheia de pessoas que imaginam vagamente o que é. Definições bastante gerais podem ser emprestadas
da Wikipedia . Indique taticamente que a presença da equipe de controle de qualidade no projeto não significa que toda a responsabilidade pela qualidade do trabalho agora seja transferida apenas para eles:
O teste faz parte do controle de qualidade. Isso nos permite determinar o nível de qualidade do (s) recurso (s) que estamos avaliando.
Não é de responsabilidade exclusiva dos testadores realizar o controle de qualidade. Toda a equipe pode e deve contribuir para garantir um alto nível de qualidade dos produtos e serviços entregues.
2. Introdução à estratégia de controle de qualidade
Prepare-se para o que mais as pessoas vão ler.
A estratégia de testes é um documento em evolução que detalha os processos e a maneira como garantiremos a qualidade do nosso produto no futuro.
Soe o conteúdo. Pode ser apenas um sumário ou mais frases abstratas. Aqui, mencione a existência de uma abordagem de teste, processo de teste, estratégia de automação de teste e a necessidade de um plano de teste.
É importante. Indique o intervalo de tempo para revisar este documento. E, como o projeto e os processos da empresa estão em desenvolvimento, este documento não deve se transformar em dinossauro. Portanto, planeje uma data em que sua estratégia será revisada e alterada. Na minha opinião, seis meses são suficientes para voltar com novos pensamentos.
3. Abordagem de Teste
O que é uma abordagem de teste? Afastando-me um pouco da volumosa redação oficial dessa definição, permito-me simplificá-la à tese de que esses são “pensamentos básicos com os quais começamos a trabalhar todos os dias”. Escreva aqui: qual é o motor do seu progresso?
Clássicos do gênero e abordagens que funcionam bem são "proativos" e "baseados em riscos".
Adotaremos uma abordagem de teste proativa e baseada em riscos.
Proativo - Isso significa que o processo de design do teste é iniciado o mais cedo possível, a fim de encontrar e corrigir os defeitos antes da criação da compilação.
Baseado em risco - Isso significa que organizaremos nossos esforços de teste de forma a reduzir o nível de risco do produto quando o sistema for enviado. De acordo com o programa do ISTQB, “Teste baseado em risco é a ideia de que podemos organizar nossos esforços de teste de maneira a reduzir o nível residual de risco do produto quando o sistema é enviado. O teste baseado em risco usa o risco para priorizar e enfatizar os testes apropriados durante a execução do teste, mas é mais do que isso. O teste baseado em risco começa no início do projeto, identificando riscos à qualidade do sistema e usando esse conhecimento de risco para orientar o planejamento, a especificação, a preparação e a execução do teste. O teste baseado em risco envolve ambas as atenuações - teste para fornecer oportunidades para reduzir a probabilidade de defeitos, especialmente defeitos de alto impacto - e teste de contingência - para identificar soluções alternativas para tornar os defeitos que passam por nós menos dolorosos. O teste baseado em risco também envolve medir o desempenho que temos em encontrar e remover defeitos em áreas críticas »
Quando falamos em ser pró-ativos, precisamos falar principalmente sobre a especificação de requisitos de controle de qualidade. Os gerentes que compilam as especificações dos elementos do próximo ciclo de desenvolvimento, na maioria das vezes, pensam como usuários comuns do sistema, enquanto a lógica dos pensamentos dos desenvolvedores existe em outra dimensão. Primeiro, mais de uma vez vi que um desenvolvedor, lendo uma especificação, não pode traduzi-la em uma linguagem de programação. Por exemplo, ele não pode corresponder o usuário mencionado na especificação com funções / direitos de acesso existentes no sistema. Como resultado, ele pode escolher a função mais adequada, na sua opinião pessoal, que se mostrará errada e precisará retornar a funcionalidade para trabalhar mais tarde e perder tempo; ou faça uma pergunta ao gerente, que talvez tenha saído de férias e perca novamente o tempo em antecipação. O engenheiro de controle de qualidade é essa maravilhosa camada entre o gerente focado no usuário e o desenvolvedor tecnicamente consciente, especialmente se o engenheiro de controle de qualidade não negligenciar os testes de caixa branca. Somos nós que somos capazes de entender os gerentes e traduzir seus pensamentos para os desenvolvedores. Na hora.
O teste baseado em risco possui métodos formais interessantes para avaliar os riscos do projeto e os produtos. É ótimo poder colocá-los em prática. Mas, pessoalmente, nunca tenho tempo suficiente para descrever as probabilidades de ocorrência, a gravidade de suas conseqüências etc. e calcule os riscos de acordo com todas as regras. Aqui confio totalmente em meus instintos e senso comum. Ao testar ou cobrir autotestes com uma zona de risco (o que deve ser dada a primeira e principal atenção) em sua maior parte:
- funcionalidade projetada diretamente
- áreas adjacentes e de interação
- funcionalidade comercialmente importante
- o que quebra com mais frequência
- compatibilidade com versões anteriores (se, por exemplo, o formato de metadados for alterado, os dados existentes funcionarão com êxito)
4. Processo de Teste
Diga-nos a que sequência metodológica do trabalho você planeja aderir. Não inventei nada complicado, mas peguei a
idéia do ISTQB e a usei.
Se você seguir o meu caminho, familiarize-se com a sequência de trabalho recomendada pelos autores do ISTQB, esteja ciente de quais etapas você seguirá e como. Começamos com planejamento e controle. Estes dois vivem juntos porque Com base no monitoramento de suas próprias atividades, os planos podem ser redesenhados regularmente. Em seguida, trabalhe com a documentação e escreva casos de teste, colocando-os em operação (usando os dados de teste planejados e um ambiente adequado), concluindo os testes e limpando depois de si mesmo (excluir arquivos temporários etc.)
Usaremos o processo de teste descrito no plano de estudos ISTQB de nível básico: Planejamento e controle de teste, Análise e projeto de teste, Implementação e execução de teste, Avaliação de critérios e relatórios de saída e Atividades de fechamento de teste.
5. Responsabilidades
Identifique as suas responsabilidades e de outras pessoas no campo da melhoria da qualidade do produto. Relate sua missão.
Primeiro, enfatize novamente que
cada membro da equipe é um testador por si só , todos estão testando com o que se relacionam. Escreveu código - teste-o.
Em segundo lugar, esclareça e entenda a direção do seu desenvolvimento contínuo.
O engenheiro de controle de qualidade é o principal especialista em funcionalidade do produto : ele sabe como e o que funciona, é capaz de explicar como e o que precisa ser testado. Ele é uma pessoa que prevê o comportamento operacional do cliente, o que significa que ele não permitirá que problemas sérios se desenvolvam.
Terceiro, indique
como você interage com gerentes e desenvolvedores . Por exemplo, pare na
abordagem ágil de Três amigosColaboração entre negócios, desenvolvimento e controle de qualidade
a. Negócios - Que problema estamos tentando resolver?
b. Desenvolvimento - Como podemos criar uma solução para resolver esse problema?
c. Testes - E quanto a isso, o que poderia acontecer
6. Níveis de teste e estratégia de automação do controle de qualidade
Hoje, esta seção se tornou um documento auto-suficiente para mim. Porém, no nível da organização do processo de controle de qualidade inicial da equipe, indique que tipos de teste serão executados por quem. O que será feito manualmente, o que será automatizado e por que princípio. Quem é responsável por quais autotestes.
Por exemplo, no projeto atual, escrevo apenas testes de ponta a ponta, cuja operação suave é estrategicamente importante do ponto de vista comercial. Ao mesmo tempo, olho para a solicitação de recebimento do desenvolvedor e, se necessário, dou recomendações sobre a cobertura do teste. Todo o resto (unidade, integração, carga, etc.) é obra de desenvolvedores. No projeto anterior, o teste de carga estava comigo e escrevi testes de integração junto com os desenvolvedores.
7. Fluxo de trabalho dos recursos
Hoje, meu projeto trabalha no Scrum usando sprints de duas semanas. Portanto, tenho um documento do ciclo de vida escrito passo a passo para cada história.
Qualquer que seja a metodologia adotada pelo projeto, descreva como fazer o trabalho diário passo a passo. Se acima falamos mais sobre táticas de ação, deve haver indicações claras do que vem primeiro e depois do que.
Por exemplo, minha versão é
O fluxo de trabalho abaixo detalha o processo que adotaremos internamente.
1. Receba a história antes de planejar a sessão
2. Crie uma lista de verificação de acordo com os critérios de aceitação e a descrição
3. Observe detalhes / perguntas pouco claras
4. Esclareça perguntas sobre planejamento
5. Atualize a lista de verificação
6. Destaque todas as dependências e como você as superará
7. Quando a matéria estiver em revisão, verifique se os critérios de aceitação estão cobertos por autotestes
8. Incentive o desenvolvedor a cobrir todos os critérios de aceitação com autotestes ou faça você mesmo
9. Quando a história estiver pronta para o teste, faça o teste manual usando a lista de verificação
10. Crie bugs para a história, se existirem, e retorne o item ao desenvolvimento
11. Quando os erros forem corrigidos, execute o teste manual usando a lista de verificação novamente
12. Verifique se todos os autotestes foram aprovados
13. Crie uma tarefa para implementar autotestes de integração adicionais, se necessário
14. Mova a história no estado Aprovado pelo controle de qualidade
8. Plano de Teste
Escolha o tipo de plano de teste, a plataforma na qual você o armazenará e o objetivo de sua existência. Forneça uma maneira de qualquer pessoa procurar lá.
Neste projeto, meu plano de teste é um conjunto de listas de verificação para cada história. Com o nível atual de automação, isso é suficiente por enquanto.
No projeto anterior, o Plano de Teste foi usado para testes manuais completos e como base ideológica para futuros autotestes.
Se você tiver muitos testes manuais, escreva os casos em detalhes, para que qualquer novo engenheiro de controle de qualidade, vindo ao projeto, possa executá-los independentemente.
Como trabalhar com um documento
Escrever todo esse plano e palavras eficazes é muito legal. As autoridades apreciarão, não tenho dúvida. Mas há um ponto importante na existência deste documento. Estas são respostas honestas para perguntas para quem e por que tudo isso está escrito?
Ao escrever cada frase, seria bom pensar nas perguntas:
"Eu realmente quero trabalhar assim?" ,
"Vou realmente trazer isso à vida no projeto?"Se ambas as respostas forem positivas, imprima com confiança.
Se uma das respostas for "Não", na minha opinião, este é um sinal claro de que não haverá pendências desnecessárias.
Se uma das respostas for da série "Ainda não sei", deixe-a em suas páginas por enquanto.
Eu tenho esses momentos na lista do que será revisto em alguns meses.
Antes de tudo, escrevi meu documento para mim. Tenho momentos em que me afasto dos processos descritos e até vou contra eles um pouco. Adaptar-se à situação para usar recursos com eficiência aqui e agora é normal. Mas a maioria esmagadora, com o trabalho de rotina habitual, meu documento é meu guia. Mais de uma vez eu estava convencido de que o plano / estratégia existente em qualquer campo sempre aproxima os resultados desejados mais rapidamente e com menos dor do que sua completa falta. Desejo que você construa seu trabalho com facilidade e eficiência!
Antes da publicação em si, o artigo era bastante reduzido, dolorosamente grande para o Sandbox. Ficarei feliz em continuar este tópico mais tarde. No entanto, estou sempre feliz em desenvolver, se há algo que eu esqueci completamente, por favor, escreva-me um comentário.
Obrigada