Quem é um testador de sistema cruzado e por que ele não deveria ser “ágil”?





A metodologia ágil introduz suas próprias regras no processo de teste de software, e cada equipe desenvolve, testa e implanta seus serviços de forma independente. No entanto, em sistemas complexos, quando o trabalho coordenado de dezenas de serviços é necessário para dar suporte ao processo de negócios, é necessário um nível adicional de teste. Portanto, nós da M.Video - Eldorado criamos um departamento especial para testes entre sistemas. Leia sobre como ele foi formado, o que os testadores entre sistemas fazem e como os processos de teste são organizados aqui.



Em um post anterior ( tyk ), já falamos sobre por que o teste entre sistemas é importante para nossa empresa. Hoje vamos nos concentrar em como nossos especialistas trabalham e falar sobre a metodologia desse processo.



Quatro projetos piloto



Para formar uma abordagem típica de teste entre sistemas, precisamos acumular informações e rastrear as interações entre os sistemas. Não foi fácil abordar este assunto, por isso decidimos não ficar sozinhos com ela e recorremos ao empreiteiro.



Juntos, delineamos nossa "dor" e chegamos à conclusão de que nossa empresa deveria ter testadores especializados que estão envolvidos em testes entre sistemas, bem como gerentes de teste que supervisionam esses projetos. Seu trabalho é complementado por analistas de sistemas cruzados que, mesmo na fase de design, monitoram a interação entre os sistemas e criam uma base de conhecimento sobre as relações entre os diferentes componentes dos processos de negócios.



Para estabelecer este trabalho, decidiu-se lançar uma série de projetos-piloto. O primeiro foi um projeto que testava promoções que nossos colegas testavam regularmente. Esse piloto nos permitiu começar a construir a base de conhecimento do departamento (137 páginas de diretrizes foram criadas no Confluence), e os funcionários começaram a trabalhar com instruções padronizadas - o que significa que elas se tornaram mais intercambiáveis.







O segundo projeto piloto foi organizado inteiramente com base e o modelo da nova unidade. Testamos o processo de geração de códigos de produtos digitais. O projeto denominado Conteúdo Digital 2.0 teve duração de 5 meses. Afetou 15 sistemas e 114 casos de teste foram desenvolvidos para sua implementação. Durante esse piloto, percebemos a necessidade de gerenciamento centralizado de ambientes de teste e dados mestres do projeto, e criamos uma equipe de especialistas para apoiar o trabalho de todas as equipes no ambiente de teste.







O terceiro projeto piloto do MarketPlace foi realizado de forma totalmente independente, sem a participação de um contratante. Nossa equipe testou 15 sistemas, o trabalho conjunto que nos permitiu vender produtos do mercado de mercadorias no site M.Video. Outros 209 casos de teste foram desenvolvidos, mas o mais importante, criamos um modelo comum de alto nível para o processo de teste entre sistemas que poderia ser usado em novos projetos.



Durante o MarketPlace, começamos a executar casos de teste em Jira, coletando relatórios e estatísticas de uma forma conveniente.







No decorrer deste projeto, na primavera de 2020, o trabalho de todo o departamento foi transferido para um cronograma de trabalho remoto e tornou-se óbvio que materiais adicionais eram necessários para treinar testadores trabalhando distantes uns dos outros, e começamos a formar uma base de vídeos de treinamento.



O quarto piloto, após o qual nosso trabalho mudou para uma nova qualidade, é testar o aplicativo móvel Eldorado. Testar com o nome Eldo Mobile tornou-se um teste de produto - ou seja, seu cliente não era o Gerente de Projetos, mas o Dono do Produto. E embora tenhamos testado apenas 16 sistemas relacionados durante o estágio piloto de três meses, a nova abordagem possibilitou o planejamento de testes entre sistemas para cada nova versão do aplicativo móvel.



O trabalho da divisão de teste entre sistemas hoje



Hoje, a divisão de teste entre sistemas atua como um provedor de serviços de QA interno para proprietários de produtos e processos. Recebemos inscrições de diferentes departamentos e os gerentes de teste elaboram um cronograma e distribuem as tarefas de teste. O agendamento ocorre uma vez por semana - tarefas grandes e pequenas são distribuídas entre gerentes de teste e testadores, levando em consideração sua carga de trabalho e experiência.







Se um processo complexo estiver sendo testado, o testador pode trabalhar no mesmo projeto durante toda a semana. Em outros casos, o especialista consegue resolver duas ou três tarefas de clientes diferentes. Às vezes, um testador trabalha com dois gerentes de teste ao mesmo tempo, que distribuem seu tempo de acordo com uma programação digital dinâmica.



Uma metodologia pré-construída envolve trabalhar com casos de teste típicos. Graças a isso, uma pessoa pode ser facilmente mudada de uma tarefa para outra. Em nosso trabalho, isso geralmente é necessário, especialmente se algo começar a "queimar" de repente e, para outros projetos, o prazo permite que você altere um pouco o prazo.



Para que nosso departamento possa interagir com os testadores das equipes de produto, também desenvolvemos normas claras para a execução dos casos de teste: critérios para iniciar e terminar o teste, tempo e ordem das tarefas, lista de responsáveis ​​por cada etapa, e assim por diante.



Na verdade, hoje estamos trazendo a metodologia de teste entre sistemas para equipes ágeis estabelecidas. Essa abordagem nos permite evitar aprovações constantes e realizar testes dentro de um prazo claro.



Qualidades de um testador de sistema cruzado



Mesmo quando todo o desenvolvimento está em um ritmo ágil, os testes entre sistemas permanecem inerentemente baseados em projetos, com todas as necessidades decorrentes de planejamento, realocação de recursos, tanto em cada equipe como dentro de todo o grupo.



O ponto é que o ambiente de trabalho para testadores de sistema cruzado e gerentes de teste está mudando constantemente. Por exemplo, recentemente recebemos tarefas de teste entre sistemas de um chatbot, bem como o processo de assinatura de contratos para compras não comerciais. Para completar essas tarefas, os testadores precisam ingressar em uma nova área, entender a funcionalidade e os recursos de sistemas anteriormente desconhecidos.



Nesses projetos, incluímos uma fase de treinamento para testadores, que pode variar de uma semana a um mês. Ao mesmo tempo, as pessoas devem ser capazes de se envolver rapidamente em novos tópicos, se comunicar com analistas de equipes diferentes e gerenciar seu tempo com eficácia.



Porém, mesmo sem isso, há muitas incertezas no trabalho da unidade. Os gerentes de teste podem começar o dia com um plano e alterá-lo drasticamente na hora do almoço. Todos os clientes têm prazos e prioridades diferentes para as tarefas, qualquer sistema pode ficar offline repentinamente e exigir uma realocação de recursos.



Finalmente, o ambiente de teste pode ser sobrecarregado. Portanto, os próprios gerentes de teste devem ser PMs fortes e podem lidar com o planejamento literalmente na hora.



Teste de produto



Após a conclusão de nossos projetos-piloto, a empresa traçou um curso claro para testes de produtos. Devo dizer que essa abordagem facilita o teste multifuncional, porque algumas das tarefas de teste permanecem na equipe do produto.



Determinamos com antecedência em que momento e por que a equipe de teste multifuncional se conecta ao processo e alocamos claramente os recursos dos testadores.



Nesse sentido, o teste do produto é mais fácil de planejar porque segue dentro do cronograma, de acordo com as ondas de desenvolvimento. Quando recebemos uma nova versão, perguntamos à equipe o que precisa ser verificado, ajustamos os casos de teste e começamos o trabalho. Ao mesmo tempo, certos testadores de sistema cruzado são atribuídos a cada produto.



A vantagem da abordagem centralizada é que um testador pode trabalhar com vários projetos ou produtos ao mesmo tempo. Por exemplo, um aplicativo móvel regularmente ocupa 50% do tempo dos especialistas atribuídos. Eles podem gastar os 50% restantes testando outros sistemas - de acordo com as tarefas dos gerentes de teste.



Resultados da nova divisão



Ainda não vivemos no paradigma do teste entre sistemas por muito tempo, mas já está claro que o tempo dos testes tornou-se mais curto (às vezes várias vezes) e a qualidade dos testes é superior.



Uma equipe de testadores de sistema cruzado é mais barata para a empresa do que expandir com um testador adicional para equipes de produto e, graças à presença de um centro de acumulação de competência, os testes de sistema cruzado passam cada vez mais rápido a cada nova tarefa. Além disso, também desenvolvemos uma metodologia para inserir “projetos desconhecidos” para que o lançamento de testes multifuncionais em novas direções fosse mais rápido.



A nova metodologia acrescentou transparência ao trabalho de todas as equipes e melhorou o controle de qualidade. O acúmulo contínuo de experiência e análise entre sistemas torna possível prever com mais precisão quais mudanças em alguns sistemas podem afetar a operação de outros sistemas.



A base de conhecimento está crescendo e hoje já podemos assumir casos de teste que alguns meses atrás não poderíamos realizar sem uma preparação adicional. Portanto, a prática de testes entre sistemas está gradualmente se tornando uma parte natural do ecossistema de desenvolvimento da M.Video-Eldorado e da cultura corporativa da empresa como um todo.



PS Nossa equipe está se expandindo. Precisamos de testadores talentosos . Se você for, bem-vindo a bordo!



All Articles