Menu

Blog

Vou desenvolver um novo produto – quando devo envolver o QA?

Compartilhar no facebook
Facebook
Compartilhar no twitter
Twitter
Compartilhar no linkedin
LinkedIn

Antes de mais nada, vamos elucidar o termo QA. QA é a abreviação de Quality Analyst, que é o profissional responsável por garantir a qualidade do produto final, mas também é o responsável por garantir a qualidade de todo o processo de desenvolvimento de software. É diferente do testador ou analista de testes (TA), que escreve os casos de testes e executa os testes manuais, mas não se envolve na qualidade do processo.

Agora vamos à resposta para a pergunta: Quando devo envolver o QA no desenvolvimento de um novo produto?

Independentemente do estágio do desenvolvimento, de o produto ser novo ou uma atualização em um já existente, a resposta é O quanto antes possível. Mas supondo que seja um produto novo, e que na sua equipe existam um ou mais QAs, esse envolvimento deve ser realmente ainda mais cedo, e vamos entender os motivos ao longo desse artigo. através de uma breve descrição da sua participação em cada fase da construção de um produto.

Na concepção do produto

Um QA pode ajudar no levantamento dos requisitos de DevOps, por exemplo, atuando na definição dos ambientes e das ferramentas necessárias para garantir a qualidade não apenas no nível funcional do software, mas em todo o processo de desenvolvimento. Um bom profissional irá ajudar na definição do fluxo de desenvolvimento, dos artefatos que devem ser gerados para a qualidade, como eles serão administrados, e em vários outros aspectos do desenvolvimento de software. A relação de responsabilidades e habilidades de um bom QA cabe facilmente em um outro artigo, mas muitos deles podem ser encontrados na literatura atual.

Ainda na fase de concepção do sistema, um QA experiente pode ajudar a equipe de análise de requisitos ou de UX (User eXperience) a definir os requisitos do produto e ajudar o cliente a entender quais suas reais necessidades, aproveitando sua vivência em diversos outros projetos /produtos em diferentes clientes.

Fase de análise

Depois, dentro de um contexto ágil, o QA pode (na verdade DEVE) ajudar o Product Owner a escrever os critérios de aceite das stories, e também a melhorar a qualidade dos artefatos, ajudando na tradução das necessidades dos clientes em uma visão facilmente compreendida por um desenvolvedor. A arte de converter requisitos em stories que o desenvolvedor compreenda de forma assertiva não é dominada tão facilmente, e devido ao fato do QA estar sempre próximo da equipe de desenvolvimento e do PO, muitas vezes consegue capturar as nuances que envolvem essa conversão melhor do que ninguém. Dessa forma, também é seu papel ajudar na qualidade dos artefatos gerados na fase de análise.

Desenvolvimento e testes

Nessa fase, o QA já deveria estar totalmente integrado ao time e ao produto, desempenhando, dentro do contexto ágil, suas atividades de analista de testes dentro das sprints: i) escrevendo os casos de testes; ii) executando os testes funcionais (e os outros que ele ache pertinentes); iii) coletando evidências; iv) relatando bugs; v) escrevendo os testes automatizados; e outros.

Caso esse não seja o cenário, e ele tenha sido envolvido no meio do desenvolvimento, terá que correr atrás do prejuízo durante as sprints. O primeiro passo será estudar as regras de negócio, executar testes exploratórios, escrever uma base de testes de regressão, executar os testes funcionais e abrir os muitos bugs que ele irá encontrar (seja em uma ferramenta ou em uma planilha, essa documentação é fundamental). Não menos importante, o QA precisa evangelizar o time nas práticas de qualidade, demonstrando o valor da qualidade a cada iteração.

Ao longo dos sprints, os bugs vão sendo priorizados e corrigidos, até que se chegue a uma estabilização do processo de desenvolvimento dentro da metodologia ágil.

Entrega e manutenção

Em muitas empresas, o QA é responsável por apresentar as entregas para os clientes, devido ao seu conhecimento das regras de negócio e a sua habilidade em manusear o sistema. Tem também a responsabilidade por manter a base de conhecimento não apenas dos produtos desenvolvidos, mas também toda a estrutura de documentação dos testes.

No entanto, se no desenvolvimento do seu novo produto, nenhum QA foi envolvido até agora, por favor não o coloque aqui nessa fase. Tenha compaixão.

Conclusão

Vimos nesse artigo a importância de envolver o QA (ou a equipe de QAs) no desenvolvimento de novos produtos, antes mesmo do início do desenvolvimento. Infelizmente a liderança de algumas empresas ou áreas tem a mentalidade de que o QA é apenas um bug finder, e que envolvê-lo próximo do marco de entrega, ao final de quase todo o ciclo de desenvolvimento do produto, é o suficiente para identificar os bugs e fechar o processo de validação.

A garantia da qualidade é obtida durante todo o ciclo de desenvolvimento, e é de responsabilidade de todo o time. Envolver um QA no final do processo é assumir um risco enorme de colocar no mercado um produto repleto de defeitos, que serão encontrados pelos usuários/clientes e terão de ser tratados pelo time de desenvolvimento ou pós-venda, de acordo com a cadência do time de desenvolvimento ou suporte.

Hoje em dia, em um mercado tão competitivo, é extremamente trabalhoso estabelecer uma relação de confiança entre cliente e fornecedor. Essa relação se inicia pela equipe comercial, passa por diversos níveis na empresa, e termina na manutenção pelo time de suporte do produto final que foi entregue. O vínculo criado durante todo esse processo pode até parecer ser o mais forte possível, mas se no final um produto cheio de defeitos for entregue, essa relação de parceria pode ser destruída em pouquíssimo tempo. Sendo assim, envolva o seu QA para ontem!

Entre em contato

Email: contato@atech.com.br
Tel.: 55 (11) 3103-4600
Rua do Rocio, 313 – 5° andar
Vila Olímpia – São Paulo – SP

Copyright © 2019. Todos os direitos reservados.
Criado pela Intelligenzia