É raro encontrar um projeto pelo qual você se apaixone durante a entrevista e do qual você se orgulhe quando conquista novos mercados. É ainda mais agradável quando o profissionalismo dos colegas está no seu melhor e na sua equipa você se sente no seio da sua família. Tive a sorte não apenas de encontrar esse projeto, mas também há algum tempo de começar a influenciar o processo de teste dele. Eu direi o que está incluído em nossa compreensão do processo ideal; como chegamos aos lançamentos mensais e como eles funcionam para nós; e como nos adaptamos às condições de quarentena.
Nosso projeto é um sistema de ensino a distância (LMS, Learning Management System), que é utilizado por mais de 7 milhões de pessoas em diferentes países do mundo. O sistema contém mais de 1000 páginas da web e cerca de 10.000 casos de teste.
Agora, o projeto emprega cerca de 15 equipes de desenvolvimento - do lado do cliente na Noruega e do lado da Arcádia na Rússia. Entrei no projeto há 8 anos como QA; Há 2 anos venho trabalhando como líder de QA, participando da otimização do processo de testes.
O que está incluído no conceito de um processo ideal
Nossa principal tarefa é atender às necessidades dos usuários finais, o que inclui a criação de novas funcionalidades e suporte ao sistema. É dada atenção especial à velocidade do sistema e à estabilidade do trabalho sob condições de carga pesada.
O processo de desenvolvimento deve permitir principalmente a realização sustentável das metas de negócios, como concluir o trabalho no prazo e com um nível de qualidade acordado. Mas o processo também deve ser confortável para a equipe de desenvolvimento, de forma que todos os envolvidos no processo fiquem satisfeitos. Em nossas equipes, estabelecemos um processo ideal para nós, e aqui estão os meios pelos quais isso é alcançado.
Processo de desenvolvimento em geral:
a) Uma abordagem de desenvolvimento que atenda às necessidades da equipe
Trabalhamos usando Scrum e sprints com duração de 3 semanas. Antes do sprint, uma apresentação de seus objetivos ocorre e um conjunto de requisitos para este sprint é formado. Em seguida, vem o planejamento, no qual avaliamos todas as tarefas e determinamos o conjunto de tarefas que serão incluídas no sprint. No final do sprint, ocorre uma revisão do Sprint, onde demonstramos todas as tarefas concluídas e anunciamos os objetivos alcançados. Essa abordagem é ótima para nós: em um sprint, conseguimos criar uma quantidade suficiente de novas funcionalidades e, ao mesmo tempo, consertar e testar um certo número de bugs dos usuários finais - 10% do tempo do sprint é alocado para esses bugs.
Alinhar: líder de equipe, desenvolvedores, testadores. A proporção de desenvolvedores para testadores em nossas equipes é de 3: 1. Essa proporção torna possível atingir o objetivo do sprint de maneira uniforme - não há períodos em que um dos participantes do processo fica ocioso: enquanto os desenvolvedores fazem qualquer alteração, os testadores criam ou atualizam casos de teste relacionados a essa alteração; Quando o desenvolvimento é concluído, os testadores verificam as mudanças e os desenvolvedores passam para as próximas tarefas no sprint ou ajudam com os testes (isso é necessário ao testar mudanças em grande escala).
O Product Owner define metas e requisitos no início de cada sprint e os aceita no final. Além disso, cada equipe tem um Scrum Master para ajudar a resolver problemas emergentes.
Para que a equipe seja capaz de realizar várias atividades que não estão diretamente relacionadas às tarefas do sprint, bem como levar em consideração vários riscos, o tempo calculado para a conclusão das tarefas do sprint é de 80% do tempo total de trabalho da equipe. Ou seja, 2 horas por dia durante um sprint regular são reservadas para comunicações, várias reuniões e seminários, bem como para corrigir bugs encontrados no sprint.
b) Requisitos claros e bom planejamento
A fim de garantir que o planejamento não se prolongue e o sprint não se torne um fracasso devido a detalhes anteriormente desconhecidos e mudanças adicionais trabalhosas adicionadas já durante o sprint, tentamos levar para o sprint apenas as mudanças com requisitos suficientemente claros e precisos. Se a área do projeto que diz respeito às mudanças não for conhecida da equipe, ou durante o planejamento houver muitas perguntas que o Dono do Produto não pode responder, a equipe pode correr uma tarefa para estudar esta área ou uma tarefa de pesquisa, o que resulta em requisitos claros ou mesmo algum tipo de protótipo.
c) Retrospectivas
Corrigir bugs também é importante. Isso se aplica a sprints e lançamentos. Acontece que não temos tempo para algo, ou temos que trabalhar hora extra para cumprir o prazo - por exemplo, se for necessário pré-testar um release (e esse é um custo adicional que a empresa gostaria de evitar no futuro). Portanto, conduzimos retrospectivas nas quais discutimos o que foi bom e ruim no sprint ou lançamento e desenvolvemos medidas para evitar tais erros no futuro.
d) Suporte de gestão
Às vezes surgem questões ou situações que não podem ser resolvidas no nível da equipe - você precisa mudar o processo ou envolver a administração da empresa na decisão. É muito importante ver que eles querem ajudá-lo e estão prontos para apoiá-lo em tal situação. Em nossa empresa, está tudo bem com isso - isso se aplica tanto à Arcádia quanto à gestão por parte do cliente. Todos os problemas são discutidos e sempre é encontrada uma solução que satisfaça todas as partes.
e) E, na minha opinião, o fundamental é uma boa comunicação. E o que temos na empresa, para mim, é uma das principais vantagens do trabalho confortável - a benevolência, a vontade de fazer compromissos.
Isso se aplica a todos: cada membro da equipe, o Product Owner, o Scrum Master, a gestão da empresa e muitos outros participantes do processo. Todos estão abertos a perguntas e discussões, os desenvolvedores consultam os testadores sobre os requisitos e, juntos, decidem a melhor forma (tanto do ponto de vista do desenvolvimento quanto do ponto de vista do teste) fazer esta ou aquela mudança. O Product Owner, por sua vez, está constantemente em contato com a equipe, resolve prontamente todos os problemas e sempre tenta cumprir na metade do caminho para atingir as metas do sprint. O Scrum Master está sempre pronto para ajudar: encontre recursos adicionais (testadores / desenvolvedores, se eles forem necessários para o sprint ou para o lançamento) ou sugira a melhor forma de organizar o sprint no tempo.
Processo de teste:
a) Padrões de controle de qualidade (diretrizes) relacionados à escrita de casos de teste.
Em nosso projeto, os casos de teste são a principal documentação detalhada sobre a funcionalidade do sistema, por isso é dada muita atenção a eles. Para cada mudança feita pela equipe, um novo caso de teste é escrito ou um existente é atualizado.
Anteriormente, quando o sistema ainda não era tão grande, os casos de teste eram escritos de forma bastante detalhada, com várias etapas específicas, mas agora essa abordagem se tornou inaceitável - leva muito tempo para atualizar esses casos de teste. Portanto, nós (líderes de QA) desenvolvemos padrões, cujo principal requisito é escrever scripts de teste com resultados esperados em vez de etapas detalhadas em casos de teste.
b) Padrões de QA relacionados a testes em sprints.
Os padrões de teste da Sprint foram desenvolvidos para garantir que cada equipe faça alterações de boa qualidade.
Esses padrões são baseados na cobertura máxima de teste, que inclui:
- Testar as alterações feitas pela equipe diretamente (funcionalidade e, se necessário, IU);
- Testar o sistema após essa alteração usando uma lista de verificação: são verificações obrigatórias, que incluem testar a acessibilidade para pessoas com deficiência, verificar traduções, verificar dados existentes, testar usando caracteres especiais, verificações de segurança, testar alterações em um aplicativo móvel e outras verificações ...
c) Padrões de controle de qualidade relacionados ao teste de liberação.
O processo de lançamento e os padrões usados nele são discutidos em mais detalhes abaixo.
d) Uso de teste de regressão automatizado.
A criação de testes automatizados para teste de regressão tornou a vida das equipes muito mais fácil - agora, se você precisar verificar alguma área após mudanças de comando, você pode simplesmente executar autotestes de regressão para a área desejada do sistema (se esta área for coberta por autotestes). Além disso, se alguma parte do sistema foi quebrada por mudanças de equipe, os autotestes de regressão irão detectar isso.
e) Assistência mútua de testadores, assistência de desenvolvedores.
Não temos muitos testadores (em média, 1 testador para 3 desenvolvedores), além disso, de vez em quando eles se distraem das tarefas de sprint de versões de teste, e pode não haver tempo suficiente para tudo.
Nesse caso, sempre há alguém dos testadores de outras equipes com menos carga de trabalho no momento que pode ajudar. O líder de QA ou Scrum Master ajuda a encontrar esse testador. Além disso, os desenvolvedores podem ajudar a testar as mudanças no sprint se os casos de teste já tiverem sido escritos para eles.
f) Comunicação entre testadores.
Para a comunicação, é usado um chat no Microsoft Teams, no qual todos podem fazer perguntas e obter respostas prontamente, enquanto o restante dos testadores descobrirá as informações mais recentes. Também realizamos reuniões mensais de controle de qualidade, nas quais os testadores compartilham entre si as tarefas atuais de sua equipe e podem discutir quaisquer problemas - a abordagem de teste e / ou a localização de casos de teste relacionados a uma área desconhecida para o testador; perguntas sobre o lançamento (composição da equipe de lançamento futuro, alteração do cronograma de testes); verificações obrigatórias adicionais adicionadas depois de perder um bug crítico na versão, etc.).
As abordagens acima permitem que você garanta um teste de boa qualidade em um modo de operação silencioso.
:
Costumávamos ter lançamentos trimestrais . Com esse período de tempo, várias mudanças foram feitas pelas equipes a cada lançamento. Essa quantidade de mudança certamente exigia uma regressão pré-lançamento, então havia um período de tempo separado para a regressão e todas as equipes estavam conectadas a ele. Isso geralmente leva cerca de 2 semanas, e os testadores e os desenvolvedores da equipe participaram da regressão.
Depois de algum tempo, os autotestes começaram a ser usados para regressão no processo de teste de lançamento. Nem todos os testes de regressão foram cobertos com autotestes, alguns foram testados manualmente. No geral, isso reduziu o tempo de teste de regressão, mas devido ao tamanho do sistema, a regressão completa ainda consumia tempo.
Todo o ciclo de desenvolvimento parecia mais ou menos assim:
Tornou-se óbvio que esta abordagem para lançamentos não é ideal, é excessivamente trabalhosa e não permite a satisfação rápida e flexível das solicitações do usuário final. A abordagem do processo de lançamento exigia mudanças e foi decidido lançar com mais frequência - uma vez por mês.
Quando mudamos para lançamentos mensais , ficou claro que não havia tempo para executar a regressão durante a fase de teste de lançamento - mesmo com testes de regressão parcialmente automatizados. Agora, o período total de preparação para o lançamento leva apenas 2 semanas. Portanto, agora a regressão é feita em sprints e somente quando necessário (se os desenvolvedores informarem que é necessária uma regressão de uma determinada parte do sistema).
Mas como na fase de testes de lançamento é necessário verificar não só a nova funcionalidade, mas também o estado geral do sistema, passamos a usar a estabilização em vez da regressão.
A estabilização inclui:
a) teste de novas funcionalidades incluídas nesta versão por cada equipe;
b) Teste de áreas críticas é um teste da funcionalidade básica das principais áreas do sistema (que obviamente leva muito menos tempo do que um ciclo de regressão completo);
c) testar bugs encontrados nas mudanças da equipe para este lançamento.
Todo o ciclo de desenvolvimento agora se parece com isto:
Vamos considerar o que mais é necessário para se preparar para o lançamento.
Quando a estabilização é concluída e o pacote de lançamento é de boa qualidade, antes de implementá-lo na produção, a configuração é testada no ambiente de pré-produção. Assim, as Operações praticam a atualização do ambiente e os testadores verificam a configuração com o pacote de lançamento atual antes do lançamento real.
Você pode pensar que 2 semanas de preparação para o lançamento é demais e que resta pouco tempo para os testes no sprint. Mas geralmente leva de 4 a 6 dias para um testador se preparar para um lançamento. Depende de:
- a complexidade e o escopo da funcionalidade que sua equipe vai lançar,
- participação do testador na equipe de lançamento da versão atual.
Todos os testadores do projeto (incluindo a equipe de lançamento) participam do teste de estabilização; testar a configuração e o lançamento em si é feito apenas pela equipe de lançamento.
O cronograma de teste de lançamento geral é semelhante a este:
Como as áreas críticas e a configuração contêm testes constantes, automatizamos parcialmente esses casos de teste. Isso reduziu significativamente o tempo de teste na preparação para o lançamento, portanto, no futuro, planejamos expandir o uso de autotestes.
Do ponto de vista da organização dos testes, um coordenador de QA (alguém dos líderes de QA) é selecionado para cada versão. O tempo de espera para o lançamento é geralmente planejado para um coordenador de QA mais do que para testadores regulares, uma vez que o coordenador de QA tem mais responsabilidades. Esses incluem:
- definir a equipe de lançamento e verificar a disponibilidade de todos os seus integrantes no momento do lançamento;
- elaboração de planos de teste para liberação;
- lançamento de autotestes na fase de teste de estabilização e configuração;
- coordenação do trabalho dos testadores durante o teste de lançamento;
- ajudar os testadores a resolver todos os tipos de problemas relacionados ao lançamento;
- controle sobre a implementação do teste e, se necessário, redistribuição da carga para auxiliar no teste de equipes sobrecarregadas (podem ser testadores de outras equipes que já concluíram o teste de versão, ou desenvolvedores de equipe, ou o próprio coordenador de QA).
E, claro, nenhuma versão está completa sem problemas. Nós os resolvemos e desenvolvemos um plano para evitá-los no futuro. Aqui estão alguns que encontramos recentemente:
- : , - , , - .
: . - : pre-production . — .
: . - : , .
:
a) - ( , ),
b) ,
c) ,
d) , . , , .
Solução: nesses casos, procuramos ter tempo para testar tudo o que é necessário para o lançamento, mesmo que exija a participação no lançamento por 2 semanas ou horas extras de trabalho, já que o lançamento é uma tarefa de maior prioridade do que as tarefas de sprint.
Mas sejam quais forem os problemas que surjam, podemos sempre resolvê-los pelas forças da equipa de lançamento ou envolvendo pessoas competentes numa determinada área - o principal é que este é sempre um trabalho de equipa bem coordenado que conduz a um bom resultado.
Trabalhando em quarentena: como garantir o trabalho dos testadores
Em nosso projeto, trabalhar no escritório é um pré-requisito. Isso é feito para que qualquer participante do processo possa ser localizado durante o horário de trabalho - se de repente ele não responder em chats, as pessoas que trabalham com ele podem informá-lo de que alguns de seus colegas precisam dele. Isso é relevante porque algumas das equipes estão na Noruega e outras em São Petersburgo.
Durante a pandemia, quando tanto a Noruega quanto a Rússia enviaram a maioria da população para o auto-isolamento, tivemos que mudar para o trabalho remoto.
Continuamos a trabalhar normalmente: as equipes ainda terminaram os sprints com boa produtividade e os lançamentos foram lançados no prazo.
A comunicação manteve-se em bom nível - a aplicação Equipas cobriu todas as necessidades: conversas activas no chat, reuniões sem problemas; se houvesse alguma dúvida que precisasse ser discutida com urgência, eles chamavam qualquer participante do projeto.
Do ponto de vista da organização dos testes, não houve problemas: durante o expediente, todos os testadores responderam em chats e participaram prontamente dos testes da versão. Caso precisemos encontrar alguém, mas ele não atenda no chat, preparamos uma lista de números de celulares, mas nunca tivemos que usar.
O único problema que encontramos enquanto estávamos sentados em casa em um trabalho remoto - devido às peculiaridades da VPN, era impossível testar o sistema em um ambiente de equipe de telefones / tablets. Mas esse problema foi contornado - graças ao gerente de projeto e ao serviço de TI, que encontrou uma solução. Começamos a usar proxies ao conectar em uma rede doméstica e agora podemos testar em dispositivos móveis de casa.
Agora estamos parcialmente voltando a trabalhar no escritório, mas parte da empresa continua trabalhando em casa. E mesmo estando em diferentes partes da cidade, continuamos sendo uma única empresa unida que continua a trabalhar em tempos tão difíceis, com tais condições de não trabalho quando crianças e animais de estimação exigem atenção, a Internet fica mais lenta e desaparece periodicamente, as luzes se apagam e há tantas distrações fatores que você não entende de jeito nenhum, como você conseguiu trabalhar de novo?!
Mas, juntos, sobreviveremos a tudo isso e, finalmente, tendo retornado a uma vida de escritório completa, sorriremos um para o outro ainda mais amplamente do que de costume.
Conclusão
Resumindo o que foi dito acima, gostaria de destacar alguns pontos:
- , , . — .
- , , .
- , , , — . , .