Oi Meu nome é Misha e sou QA sênior com experiência comercial de mais de 6 anos. Agora, trabalho no Provectus, mas iniciei meu percurso de testador quando participei de testes alfa e beta de vários jogos. Em algum momento, pensei: "Por que não começar a fazer isso profissionalmente?" E lá vamos nós. Durante esse período, consegui participar de vários projetos: de startups a empresas, de pequenos jogos de unidades educacionais a grandes aplicativos com forte lógica de negócios.
Mas muitas vezes eu fui introduzido em equipes pequenas, nas quais havia de 5 desenvolvedores para 1-2 testadores e, como regra, havia muito calor no projeto. Na verdade, quero compartilhar com você como aprender a entender onde você está e como começar a avançar na formulação de processos de controle de qualidade.
Primeiro de tudo, você deve entender em que projeto está.
Tendo adquirido experiência ao participar de projetos, eu os dividiria em três tipos:
- projetos sem teste;
- projetos com testes injustos;
- projetos de teste.
No momento do meu envolvimento, cada um deles estava em seu estágio de desenvolvimento. Comecei a observar essas situações e a desenvolver minha visão - como promover processos de teste nelas. Depois de algum tempo, deparei-me com o Modelo de Maturidade, e ela deitou uma a uma nas minhas bases. Isso fortaleceu minha crença de que este é o lugar para estar.
O que é o Modelo de Maturidade
E aqui estou muito habilmente inserir uma citação da
Wikipedia :
CMMI (Capability Maturity Model Integration) - um conjunto de modelos (metodologias) para melhorar processos em organizações de diferentes tamanhos e atividades. O CMMI contém um conjunto de recomendações na forma de práticas, cuja implementação, de acordo com os desenvolvedores do modelo, permite atingir os objetivos necessários para a implementação completa de determinadas áreas de atividade.
Em resumo e simples, este é um conjunto de modelos que mostram como os processos estão bem organizados na organização, de acordo com certos critérios. Tendo essa avaliação, é possível avaliar sobriamente se vale a pena dar uma ou outra ordem a um contratante em particular.
Na verdade, a partir disso, começou o desenvolvimento do Modelo de Maturidade. Nos anos 80, o Departamento de Defesa dos EUA percebeu que não podia avaliar com precisão a qualidade do trabalho dos empreiteiros de desenvolvimento de software. E como essa estrutura de governo também é de tal nível, isso é inaceitável. O dinheiro é de propriedade do Estado, os prazos são claramente delineados e um software confiável para armas permitirá que todos durmam mais pacificamente. Com base nisso, o Ministério instruiu o Instituto de Engenharia de Software a criar esse sistema de classificação e, um ano depois, o primeiro questionário foi criado e, quatro anos depois, a primeira versão do modelo.
Níveis do Modelo de Maturidade
Estes são 5 níveis, dentro dos quais o trabalho / confiabilidade / estabilidade da empresa é avaliado.
Onde no Modelo de Maturidade está testando
Para testadores, existe um MM especial, chamado TMMi. Ele também contém cinco níveis, nos quais gostaria de me aprofundar mais e considerar o que é típico para cada um deles.
O primeiro nível é "Iniciante"No primeiro nível, o teste não é estruturado e caótico. Não há ambiente estável para suportar processos de teste. A equipe não presta atenção ao planejamento e padrões.
O principal objetivo é entregar o produto no prazo, sem problemas críticos, porque o teste é usado aqui apenas para mostrar que o aplicativo funciona sem falhas sérias. Freqüentemente, o sucesso de tais projetos depende apenas do heroísmo e das habilidades dos indivíduos, e não dos processos estabelecidos.
Como resultado:
- nenhuma documentação de teste;
- o produto é instável;
- recusa de processos durante situações problemáticas;
- o teste nada mais é do que assistência para depuração.
Segundo nível - “Repetível”No segundo nível, o teste se torna um processo controlado. A disciplina e o progresso alcançado garantem que essas práticas sejam mantidas durante o estresse. O teste ainda é considerado como a atividade que segue o desenvolvimento. Os planos de teste são desenvolvidos e implementados, com a ajuda de que eles determinam claramente que tipo de teste é necessário, quando e por quem.
O objetivo principal é garantir que o produto atenda aos requisitos especificados.
Como resultado:
- existem os principais tipos e tipos de teste (integração, modular, regressão, aceitação);
- planos de teste implementados;
- as atividades de teste são monitoradas e controladas;
- o processo está documentado e pode ser repetido.
Terceiro nível - "Definido"No terceiro nível, o teste não é mais considerado atividade após a programação. O teste é totalmente integrado ao projeto. O planejamento de teste é realizado em estágios anteriores e é fixado no plano mestre. Testes não funcionais (por exemplo, usabilidade) estão sendo introduzidos.
Como resultado:
- o teste começa com a fase de requisitos;
- são adicionadas atividades que permitem trabalhar com mais eficiência (treinamentos internos, revisões adicionais);
- testes não funcionais estão sendo introduzidos.
Quarto Nível - “Mensurável”No quarto nível, o teste é um processo bem definido, bem estabelecido e mensurável. O teste é percebido como uma avaliação e consiste em todas as operações do ciclo de vida de desenvolvimento de software. A prática de medir a qualidade dos testes está sendo introduzida. Essas medidas são usadas para prever o desempenho e o custo dos testes.
Como resultado:
- testar como um processo mensurável;
- medições são usadas para previsão;
- a equipe está procurando maneiras de tornar o processo de teste mais eficiente.
Quinto nível - "Inovador"No quinto nível, todas as abordagens e processos estão bem estabelecidos. A equipe não para nesta fase, mas continua a melhorar sistematicamente os processos, tentando constantemente reduzir o tempo do ciclo de testes e do tempo de colocação no mercado sem comprometer a qualidade do projeto. O teste se concentra na prevenção. A automação é adicionada para um uso mais eficiente dos recursos.
Como resultado:
- melhoria contínua do processo;
- foco na prevenção e otimização.
Como o conhecimento dessa estrutura ajuda
Caso nº 1. Teste injustoUma vez cheguei a um pequeno projeto onde os testes eram realizados por um cliente, seus amigos ou um gato. Tendo avaliado a situação e analisando o modelo, podemos entender que estamos no nível 1 e que devemos nos concentrar no nível 2 durante o planejamento da atividade. Depois de colocar o Jira em ordem, onde havia um grande número de bugs (a maioria duplicados ou não reproduzíveis), comecei a compilar a documentação do teste na forma de listas de verificação e organizar os processos básicos de teste. Como testes de regressão e verificações de sanidade durante grandes mudanças.
Caso No. 2. Sem testeNa minha opinião, projetos desse tipo podem ser em três casos:
- o projeto está apenas começando;
- não havia necessidade de um testador no projeto enquanto havia pouca funcionalidade;
- A equipe de pilha cheia encerrou a falta de testadores com revisão de código de qualidade e teste de desenvolvimento.
Uma vez em qualquer um desses projetos, muitas vezes você pode ver o benefício do fato de estar em um nível zero secreto. Podemos pular o primeiro nível e imediatamente fazer tudo qualitativamente, com um bom senso, sentimento, disposição, guiados pelos objetivos do segundo. Frequentemente, podemos implementar planos de teste, com base nos quais todos os tipos necessários de teste serão realizados. Você pode identificar imediatamente o mesmo fluxo de trabalho com a equipe de desenvolvimento, que está ausente nos projetos desde o primeiro caso.
Caso nº 3. O teste foiNa verdade, o caso mais raro: um homem, devido a certos eventos, decidiu mudar de equipe / departamento / trabalho e dá a você suas próprias idéias. Nesta situação, você já possui um sistema estabelecido de interação com os desenvolvedores, uma certa base da documentação de teste. Outros caminhos de desenvolvimento podem incluir a melhoria do processo estabelecido ou a mudança para o terceiro nível - introduzir testes em estágios anteriores ou adicionar testes não funcionais.
Número do processo 4. Três em umQuando cheguei ao meu projeto em Provectus, me deparei com uma situação em que havia apenas um pouco dos três casos descritos acima. Como no caso número 1, a primeira coisa a fazer foi colocar Jira em ordem. Como no segundo caso, foi decidido fazer tudo imediatamente com alta qualidade para ser guiado imediatamente pelo segundo nível. Portanto, comecei imediatamente a desenvolver documentação de teste e implementar ferramentas de gerenciamento de teste. Também tentei extrair o máximo dos artefatos de iterações passadas, como foi o caso na terceira.
Depois de um tempo muito curto, posso dizer com segurança que já estamos deliberadamente subindo para o terceiro nível - até conectamos os testes no estágio de requisitos de negócios :)
Conclusões
Na minha experiência, a maioria dos projetos ucranianos, bem como projetos que não são projetados por um longo período de tempo, podem ser levados com sucesso ao Go live no nível 3. Mas se você tem um projeto de longo prazo, as possibilidades de aprimorá-lo são infinitas e você pode ser guiado com segurança pelas conquistas dos níveis mais altos.
Concluindo, gostaria de dizer que o objetivo deste artigo foi mostrar não muito como trabalhar com o próprio MM ou TMM clássico, mas que, com sua ajuda, você pode entender claramente em que estágio do projeto está envolvido e quais movimentos tomar e quais não valem a pena. Além disso, tomando seus princípios como base, você pode criar seu próprio modelo, que pode ser aplicado não apenas no desenvolvimento, mas também em várias áreas da vida. E o mais importante - é testado e funciona :)