Em se tratando de um time de QA, ou mesmo das responsabilidades do time de QA dentro de um projeto, geralmente o normal é se deparar com processo de testes, quer sejam testes manuais, automatizados, caixa branca, smoke test, caixa preta, performance , etc. Até aí não há nada de errado nisso pois é de responsabilidade de QA realmente projetar e executar toda essa bateria de testes. Porém, geralmente esse pensamento pode servir para limitar um pouco a linha de atuação que o time de QA tem, ou que pelo menos deveria ter dentro de um projeto e, principalmente dentro da construção ou atualização de um produto.
Quando falamos na criação de um produto, falamos de algo que nasce exclusivamente de uma necessidade, ou seja, de alguma “dor” que o negócio está sentindo e de algo que precisa ser feito para que essa dor seja sanada e o negócio possa prosperar. Para isso são mobilizadas várias equipes com vários espectros de visão, bem como de várias áreas de conhecimento para que justamente e em uníssono, possam responder devidamente a esta dor e saná-la da forma mais eficiente possível. Quem organiza toda essa orquestra em primeiro lugar é o Product Owner, mais conhecido como P.O, que é o emissário e ponte de comunicação entre as áreas de negócio e a tecnologia para transformar essas necessidades em algo tangível, em uma solução sistêmica. É ele quem vai colher os dados, fazer as entrevistas necessárias para tal e criar as histórias / jornadas de usuário que serão transformadas em requisitos funcionais / não funcionais para o desenvolvimento da solução. Porém para que se chegue em algo assim, é necessário entender o que se deve fazer e como chegar às decisões que irão se transformar em um produto. Uma das ferramentas mais utilizadas para isso é um processo já antigo, mas que voltou à carga nos dias de hoje: O Design Thinking.
Em linhas gerais esse modelo é um método para, a partir do estímulo da perspicácia e ideação de uma equipe, problematizar, cercar e gerar possíveis soluções para um problema, por intermédio de uma equipe multidisciplinar que se ajuda nesta etapa. Ou seja, trata-se de um conceito, ao mesmo reativo, pois se trata de consequência da ação das áreas de negócio em identificar uma necessidade e, por intermédio do P.O, acionar um processo que culmina no uso de um ferramental como esse, bem como, se formos pensar mais profundamente, pode ser sim algo preventivo em certas partes do processo como um todo, já que o Design Thinking se faz em diversas etapas que, de forma macro seriam as seguintes:
Descobrir: Também chamada de Discovery, é a fase voltada ao descobrimento do problema do cliente, quais as suas grandes dores e com o foco principal em estabelecer a visão do negócio;
Definir: Essa fase é voltada a pesquisa por soluções e é onde são definidas as jornadas e
histórias dos usuários;
Desenvolver: Fase voltada a definição de soluções que atendam ao problema do negócio;
Entregar: Fase voltada a entrega do MVP (Minimum Viable Product) ou Mínimo produto viável.
A ideia aqui é focar mais na parte de Descoberta, ou Discovery e é onde iremos contextualizar a ideia de o time de QA estar nessa etapa que, para muitas linhas de pensamento, não seria necessário na mesma e isso é até falado por uma linha de pensamento corporativa bem estabelecida.
O Time de QA Reativo?
É normal em muitas empresas ou até mesmo em algumas literaturas, inserir o time de QA como parte de um processo puramente operacional e “nichado” a uma etapa específica de um projeto, onde ele simplesmente recebe uma demanda (no caso uma necessidade de se criar um plano de testes a partir de uma documentação que lhe é passada, seja ela um requisito ou uma história de usuário, e de onde ele irá criar seu plano de testes e o executá-lo. Isso é mais normal do que pensamos e insere o time de QA em uma cate gíria de simples força de trabalho voltada a realizar uma gama de testes em uma espécie de linha de produção, baseado em uma serie de métodos e ferramentas que vão lhes prover uma saída binaria e evidencial para documentação e continuidade da esteira de desenvolvimento dentro do ciclo de vida do mesmo. Esse pensamento, naturalmente faz pensar a equipe de QA de modo redutivo e mecânico, mas sua atuação está muito além disso.
Por natureza, o time de QA deve , e precisa ser, além de um time que realiza testes, um time também que deve ser inserido na estratégia de criação de um produto, já que sua linha de raciocínio e seu ponto de vista em relação ao mesmo são totalmente distintos do ponto de vista de outros times que até pensam diferente, mas sempre olhando o “caminho feliz”. É da natureza do time de QA pensar diferente, olhar o que os outros times como, por exemplo, o próprio desenvolvedor, que está lá para codificar uma ideia já estabelecida e que, no máximo, vai fazer seus testes mínimos unitários e estabelecer que as partes mais simples estão falando entre si. O QA tem por natureza ser pragmático, pensar não fora da curva, mas em curva, saindo o ocasional e do caminho feliz, bem como percorrendo, com sua mente pragmática, outros caminhos que nem o usuário do sistema pudesse pensar. Mas não adianta muito ele fazer algo assim somente em uma parte do projeto onde já existe muita tangibilidade, deixando pouco espaço para o que poderíamos chamar de uma “subjetividade aplicada” onde junto ao P.O, já nas primeiras entrevistas e coletas de informação, poder identificar meandros e “criar problemas”.
A etapa de descoberta dentro do processo de Design Thinking, começa com o que se chama de problematização, ou seja, onde são levantados os conjuntos de necessidades deste negócio mirando um produto que terá em si características que vão atender a um determinado público-alvo. Nesta etapa, a presença de um QA junto ao P.O, ajuda a, principalmente, por meio da visão deste na hora de, por exemplo, traçar um Lean Canvas e definir a visão do negócio, validar o valor final das soluções propostas já que nesta etapa, é muito comum que o usuário de negócios misture o que é necessidade imediata
(sim, pois temos que entender e o intuito aqui é descobrir a nível de MVP, ou Mínimo produto viável) de um desejo que pode ser viável mas, nesse momento, não influi na solução para o problema e, portanto não tem prioridade. Neste ponto, o QA, junto ao P.O, com sua visão Pragmática, consegue se focar mais no que precisa ser solucionado de imediato, separando com mais facilidade esses desejos e mantendo o foco. Em resumo, o QA auxilia na correta problematização da necessidade mapeada e de suas possíveis soluções. E isso não só influi no cerco as melhores prováveis soluções como, a partir disso, influi até em uma maior vantagem competitiva pois é bem normal que também já se faça, mesmo que em menor nível, algum processo de benchmarking , bem como também a própria relação com os custos associados a estas soluções se torna mais confiável.
Em seguida, no processo de descoberta se dá o que é chamado de análise crítica, onde se comumente faz um refino do que fora coleta do na primeira fase, que é mais brainstorming conjectural. Usa-se muito, ferramentas como o SWOT, ou análise SWOT, onde são analisadas as soluções mais possíveis dentro de suas Forças, fraquezas, oportunidades e ameaças, e é aqui onde o QA tem sua participação estendida e já começa ser ainda mais aproveitado pois, dependendo da solução, ou soluções que foram escolhidas, dentro do SWOT, já pode ser iniciado o estudo de um “proto-plano de testes” que pode ser analisado com outro espectro como:
Para a Força: Análise maios aprofundada dos pontos fortes relacionados e a visão de seu ponto de ruptura (Sempre existe um Bug a ser descoberto);
Para a Fraqueza: Aqui a seta se inverte com a força e a análise se torna antagônica, estando o QA em um processo de verificar se dessa fraqueza não pode ser tirado um melhor proveito o a mesma usada para o produto de uma outra forma, outro prisma, onde ela pode ter mais relevância, ou até para salientar sua não confiabilidade com um crivo diferenciado;
Para a Oportunidade: Aqui se pode ter uma análise mais pragmática do entorno deste produto até aplicando os conceitos do DevSecOps por exemplo, analisando em separado os processos, as pessoas e as ferramentas e verificando o que pode ser, junto com esse produto, também de alguma forma afetado positivamente (Uma melhorias em uma integração, a oportunidade de se alterar um processo já existem ou mesmo de criar algum processo mais ágil ou a justificativa para se adquirir um novo serviço ou ferramenta). Isso tudo com a ajuda do QA pode ser mais fácil de se perceber;
Para a Ameaça: É onde o QA se sente mais à vontade e em sua arena principal, pois é onde ele vai exercer seu pragmatismo ao extremo, já que possui conhecimento para ajudar a detectar, até seguindo os mesmos conceitos de DevSecOps, falhas pequenas, média e até graves, quer sejam internas ou externas, que podem prejudicar este produto. Esse processo se torna mais técnico inclusive pois ele pode aplicar um pensamento menos até subjetivo e usar conceitos como TDD ou Test Driven Development para efetivamente criar cenários antecipados, forçar erros e ter uma visão mais técnica e clara de como o corrigi-los. Esse método irá ajudar mais à frente no projeto onde ele pode cruzar essas informações com o BDD, ou Behavior Driven Development em seu plano de testes para criar cenários ainda mais completos e assertivos, com variantes mais relevantes de jornada de usuário.
E por fim com tudo isso dito acima, ou seja, com o QA ao lado do P.O desde o início da descoberta do produto, é possível se fazer uma descoberta ainda mais assertiva, com bases mais solidas e informações muito mais coesas o que leva a decisões gerais nessa etapa crítica do Design Thinking muito mais corretas, o que resulta em outras etapas subsequentes desse processo, como a definição, o desenvolvimento e a entrega, onde sim o QA também estará atuando, etapas muito mais confiáveis pois sua base estará mais solida.
Vejam que não falamos aqui em nenhum momento, sobre processo de testem, tipos de testes e suas ferramentas pois nem é o momento, estando esse ainda muito além da descoberta. Esse ensaio é para demonstrar que, em apenas uma das etapas de um processo bem maior, se já inserimos o QA na equação, o ganho de qualidade no geral aumenta consideravelmente, até antes de existir algum código ou interface a ser testado. Subsequentemente virão as histórias e jornadas de usuário muito mais maduras pois as personas e seus comportamentos também serão criados com base nestas informações verificadas pelo QA que aí também acaba se retroalimentando em seu processo efetivo de testes com base nestas informações pois haverá um entendimento muito mais solido, com documentações mais claras e visão geral mais abrangente para criar um número muito mais complexo de testes, sejam, eles manuais, automatizados, só de Back-end, também de interface ou mesmo de aceitação do negócio junto ao usuário para também garantir um delivery mais tranquilo e sem surpresas, ajudando a fechar o ciclo e deixando a operação mais segura e com melhores resultados financeiros, onde o investimento não vire gasto por causa de Bugs que poderiam, serem evitados e mal-entendidos sobre regras de negócio que poderiam, ser validados mais apropriadamente.
Se você leu até aqui, aproveite e acompanhe a Konia nas redes sociais, comente e compartilhe conosco por aqui.
Fernando Gomes
Posts Relacionados
