Todos os dias, no campo da TI, há cada vez mais tarefas novas, inclusive no campo de testes. Se antes um testador precisava simplesmente testar de acordo com os requisitos (ou sem eles), agora ele precisa primeiro entender como ele pode ser testado, quais tecnologias são necessárias para isso, o que pode ser automatizado e como incluir um ciclo de liberação em toda essa desgraça e etc. Quem deve responder a essas perguntas? Quem se comunicará com o cliente e esclarecerá os requisitos? Quem criará as abordagens e a arquitetura de teste, requisitos?
Trabalhando como líder e coordenador de testes de projetos para grandes empresas e resolvendo todos esses problemas ao longo de três anos, percebi que é importante ainda atrair um indivíduo que responderá à pergunta principal: "Como realizar testes?"
Realizei uma pequena investigação e constatei que essa função já existe, e é chamada de TST (Arquiteto de Soluções de Teste), mas poucas pessoas sabem disso. E a descrição das vagas da TSA nos sites dos empregadores surpreende com sua lista de deveres e habilidades, mas acho que isso é mais provável devido à falta de entendimento de quem é a TSA.
Com base na minha experiência nessa direção, decidi mostrar pelo exemplo de um dos projetos reais quem é a TSA e quando é necessário.
Breve Descrição do Projeto
O objetivo do projeto era substituir um banco de dados por outro, mais precisamente, Cassandra e seu apêndice na forma de FilloDB foram substituídos pelo SnowFlake, no processo comercial de um fluxo diário, a cada hora e até minuto a minuto, de entrega e processamento de dados. Havia mais de 50 desses fluxos e, conforme planejado pelos arquitetos, isso deveria resolver um grande número de problemas relacionados ao desempenho, perda de dados, custos de manutenção e compra de licenças adicionais para Cassandra, etc. Mas quais dessas expectativas foram atendidas e quais não são - esse é o tópico de outro artigo.
Quais funções de teste estavam no projeto?
Historicamente, as seguintes funções foram distinguidas no teste: um testador manual ou funcional, uma ferramenta de automação de testes (aquele que escreve o código e os testes) e um gerente de testes (aquele que resolve todos os outros problemas). Nosso projeto não foi exceção. O projeto envolveu:
- 1 Líder ou líder de teste
- 40 testadores manuais que trabalharam com equipes de scrum (7 equipes)
- 2 desenvolvedores (isso é uma exceção, porque os desenvolvedores não gostam de trabalhar em tarefas de automação) e 2 de automação de teste
- 2 testadores que fizeram testes de estresse
- 1 testador funcional para produtos de teste desenvolvido por desenvolvedores e automação de testes
Teste manual
O principal objetivo dos testadores funcionais era testar o aplicativo e dizer se ele atende aos requisitos do cliente. Para isso, os testadores geralmente:
- Crie planos de teste.
- Crie uma estratégia de teste.
- Crie casos de teste com etapas agendadas (com o resultado esperado e atual).
- Realize casos de teste e conclua sobre a qualidade do aplicativo.
Não tínhamos requisitos do cliente ou descrições do sistema. Havia apenas o sistema antigo, o novo e o desejo: "Faça funcionar, mas com uma nova base". Portanto, só poderíamos usar a abordagem like-for-like - comparando os resultados dos sistemas antigos e novos. Tudo ficou complicado pelo fato de trabalharmos com um sistema de produção e com dados atualizados diariamente. Infelizmente, não foi possível iniciar nosso sistema ao mesmo tempo que o sistema de produção, e o iniciamos mais tarde, e isso levou ao fato de que os dados nos sistemas antigo e novo eram diferentes.
Nesse estágio, começaram a surgir perguntas:
- Como concluir que nosso sistema funcionou corretamente se, devido a uma mudança de horário, obtivemos resultados diferentes daqueles que obtivemos no sistema antigo?
- Podemos nos afastar da produção de dados e trabalhar com dados estáveis? Quais são os riscos?
- E, no entanto, se chegarmos a dados estáveis, como provar que nosso sistema funcionará corretamente com dados atualizados diariamente?
Esta é apenas a ponta do iceberg da lista de perguntas semelhantes que surgiram no projeto durante testes funcionais / manuais.
Automação de teste
Os engenheiros de automação de teste (e desenvolvedores) tinham o objetivo de criar aplicativos que pudessem testar e / ou facilitar automaticamente o trabalho dos testadores funcionais:
- autotestes que seriam integrados ao CI / CD;
- aplicativos que ajudaram a testar testadores funcionais;
- e outros desenvolvimentos necessários para as necessidades internas do projeto.
No projeto, todos os aplicativos desenvolvidos para teste deveriam ter sido um produto separado, que obedecesse a todas as regras de desenvolvimento e teria sido entregue ao cliente como resultado. E, consequentemente, surgiram perguntas:
- Quem, juntamente com o cliente, desenvolverá requisitos não funcionais para testar aplicativos? O arquiteto de soluções disse que esse não é o trabalho deles, pois As SAs trabalham com o aplicativo que foi solicitado pelo cliente.
- Quem desenvolverá os requisitos de funcionalidade para testar aplicativos? Existem requisitos óbvios, mas existem requisitos não óbvios. Por exemplo, precisamos armazenar os logs de nossos aplicativos e analisá-los?
- Quem elaborará o ambiente para aplicativos com o cliente e corrigirá esses requisitos? Por exemplo, especificamente neste projeto, houve uma restrição no spark 1.4, e isso foi descoberto somente após a criação do aplicativo.
E isso também está longe de todos os problemas que surgem no projeto em termos de automação de teste.
Líder de teste, também conhecido como líder de teste
O líder de teste deve organizar os processos de teste no projeto. Suas funções incluíam a distribuição de tarefas, realização de reuniões internas com testadores, organização do trabalho com o cliente (descoberta de detalhes, revisão dos resultados), etc. Ou seja, ele estava focado no processo atual e na solução de problemas / tarefas diárias, e não no trabalho das tarefas da abordagem, estratégia, arquitetura de teste.
Se estamos falando sobre o líder técnico de testes, ele ficou encarregado das soluções técnicas: organizar o desenvolvimento de aplicativos para teste como um processo de criação de um produto de software separado que obedece a todas as regras de desenvolvimento, por exemplo, criação de testes de unidade, integração com processos de CI / CD e etc.
Em nosso projeto, esses papéis foram desempenhados por duas pessoas, e cada cronograma era assim:
Nos dois casos, o Líder de Teste está ocupado trabalhando em uma estratégia de teste já selecionada, mas ninguém é responsável por escolher a própria estratégia, justificando essa escolha para o cliente, adaptando-a a mudanças e outros problemas. Por exemplo:
- Desenvolvimento de um plano com o cliente para entrar no estágio de teste de aceitação pelo cliente (UAT).
- Estudo dos requisitos com o cliente quando se considera que a funcionalidade pode ser transferida para o UAT.
- Estude com o cliente as premissas de teste em diferentes tipos de ambientes (um ponto muito delicado). Como geralmente o ambiente de teste não corresponde à produção, todas as questões relacionadas ao teste em outro ambiente devem ser trabalhadas com o cliente.
- Estude com o cliente uma discrepância aceitável de métricas em vários tipos de teste. Por exemplo, que resultado um cliente espera ver durante o teste de desempenho? Talvez seja suficiente para ele que o sistema não funcione pior.
- A coleta de todas as métricas possíveis em números, por exemplo, discrepâncias de dados para esta tabela é permitida em não mais que 10%, ou o script deve ser executado em não mais que oito horas.
O que há de errado aqui?
As perguntas acima geralmente são colocadas sobre os ombros do líder de teste, mas há uma abordagem falha:
- Eles não aprendem os processos nos quais o Líder de Teste deve resolver todos esses problemas com o cliente. Na maioria das vezes, um líder de teste experiente entende isso e, talvez, até saiba como, mas muito provavelmente, uma parte tão importante quanto a meta do negócio ou melhorias específicas permanece fora do escopo de seu entendimento. Consequentemente, prioridades incorretas podem ser definidas.
- O líder de teste geralmente entra em um projeto quando o desenvolvimento já está em andamento ou está apenas começando, ou seja, ele se depara com as condições de que já existem alguns acordos ou mesmo tudo já foi consertado. É uma sorte se o SA for uma pessoa suficientemente experiente e competente e for para o teste - isso ajudará a adaptar os acordos iniciais com o cliente às necessidades do teste. Em outro caso, o lead precisa reinventar a roda.
E este não é todos os problemas que caem no Test Lead quando não há TSA.
Então, quem é esse TSA e por que é necessário?
O arquiteto de soluções de teste é uma pessoa que considera a tarefa do ponto de vista dos negócios, da informação e da tecnologia, coordena e desenvolve requisitos com o cliente, elabora um roteiro com prazos e desenvolve soluções no nível da interface.
Os projetos agora ditam outras condições. Os projetos se tornaram maiores, mais complicados em termos técnicos e de processo, podem abranger vários setores e tecnologias. Os testes tornaram-se não apenas um serviço, mas também um fornecedor (desenvolvedor) de software para o cliente. Portanto, nos testes, é necessário destacar um papel semelhante. Além disso, essa pessoa deve entrar no projeto junto com a SA, que está envolvida no aplicativo de produção, e começar a trabalhar em todos os problemas ao mesmo tempo.
Especificamente, em nosso projeto, o papel da TSA foi desempenhado pelo Test Lead, que ingressou no projeto 3 meses após o início do desenvolvimento, e isso envolveu muito trabalho adicional na harmonização de requisitos, ambientes, para descobrir a visão dos resultados finais do teste do cliente. Como resultado, o projeto não cumpriu os prazos da maior parte da vida e os clientes ficaram insatisfeitos com os suprimentos e o resultado do teste. Não porque o trabalho foi mal executado, mas porque o resultado produzido pela equipe não atendeu às expectativas do cliente.
Quando o TSA não é necessário?
É claro que esse papel não é necessário em todos os projetos. Abaixo, proponho a maneira mais simples de determinar a necessidade de TSA em um projeto, dependendo de como o cliente vê a abordagem de teste.
O primeiro tipo de projeto - o cliente fornece a configuração dos processos de teste a critério da empresa que contratou.Nesse caso, o TSA entra no projeto a partir do momento em que começa a trabalhar nele, juntamente com a SA, desenvolve requisitos de teste, desenvolve um esquema de teste de alto nível, decide o que será automatizado / desenvolvido como aplicativos separados, determina os requisitos para esses aplicativos e, é claro, coordena com o cliente, prioriza os objetivos do projeto de acordo com as expectativas do negócio.
O segundo tipo de projeto - o cliente tem seu próprio entendimento de testes, uma imagem clara e processos simplificados.Nesse caso, a TSA pode não ser necessária; o teste é necessário apenas para se encaixar na imagem existente do mundo e apoiá-la. Mas se o entendimento for superficial, o TSA precisa não apenas executar todas essas ações como no primeiro tipo de projetos, mas também provar ao cliente que tudo isso é necessário.
O terceiro tipo de projeto - o cliente não precisa de serviços TSA.Os motivos podem ser diferentes:
- Um projeto pequeno e de curto prazo com funcionalidade simples.
- O cliente tem seu próprio TSA.
- O cliente se recusou a testar, etc.
TSA Skills
A prática do Solution Architect é aplicada com sucesso no desenvolvimento há muito tempo. Com base nessa experiência bem-sucedida, e também levando em conta o volume e a complexidade dos projetos, questões que excedem a área de responsabilidade do líder de teste, podemos dizer que a alocação do papel da TSA é um desenvolvimento natural de eventos. Além disso, o TSA deve ser treinado nos mesmos processos, técnicas e abordagens que o SA.
Em resumo, na minha opinião, o TSA deveria ter:
- Com conhecimentos técnicos, tanto em geral como na área de domínio em que trabalha, para conhecer os problemas dessa área, erros típicos, problemas e formas de verificá-los.
- Boas habilidades de comunicação, ser capaz de chamar a atenção do cliente para problemas de teste, elaborar requisitos de teste, abordagens de teste, relatórios de teste e muitos problemas relacionados, como o ambiente de teste.
- Habilidades de liderança e ser proativo porque Os testes muitas vezes tentam sair para mais tarde.
- Bons conhecimentos de testes em geral, documentação de testes, processos de teste, relatórios de testes, abordagens, etc;
- Bom conhecimento das regras de desenvolvimento de software: políticas de lançamento, políticas de versão, entender processos de CI / CD, etc.
Com base no exposto, a TSA deve ter o mesmo conhecimento que o SA, mas deve se concentrar nas tarefas de fornecer ao cliente um produto de qualidade. O trabalho da TSA é complicado pelo fato de que muitas vezes é necessário mudar a opinião do cliente sobre o teste como exclusivamente sobre a cozinha interna do projeto.
Foi precisamente o conhecimento que recebi na escola Solution Architect que me permitiu restaurar a confiança do cliente no projeto descrito acima, resolver muitos problemas de teste e concluir com êxito a entrega de todas as funcionalidades quase dentro do prazo, além de estabelecer processos e assinar contratos para trabalhos futuros.
Conclusão
O setor de TI está se desenvolvendo, novas tarefas aparecem (desafios, se você quiser) e, no caso de testes, a posição de TSA destacada tornou-se urgente. Naturalmente, tudo depende do projeto, mas nos projetos em que é necessário um TSA, você precisa se envolver no trabalho no estágio inicial, isso evitará problemas no futuro e ajudará o desenvolvimento do projeto.