Gerando Conhecimento – Divã de uma Tester
Arquivo da categoria: Gerando Conhecimento
Publicado em 2015-11-10 por Patrícia Gonçalves
Aproveitando o assunto abordado no artigo do Daniel Amorim sobre Agile Tester 3.0, acredito que para quem teve a oportunidade de assistir a palestra deste artigo tenha recebido vários insights para evoluir na carreira. Entretanto, para os profissionais que estão inseridos dentro de um contexto mais tradicional deve ter ficado um pouco complicado de se localizar neste novo contexto, que o Daniel apresenta.
O artigo traz uma perspectiva de que o papel de QA tenha 3 dimensões: Negócio, Técnico e DevOps. O profissional de teste poderá ter conhecimento em uma ou mais dimensões. Com tudo, na maioria das vezes, ao menos uma das dimensões o QA terá mais domínio.
Algumas dúvidas surgiram após a apresentação dessas dimensões. Muita gente deve ter se perguntado… "mas como faço para me tornar um Agile Tester 3.0?". Acho que a pergunta correta seria… "Qual é a dimensão que é mais dominante no meu perfil?" Eu também me fiz essa pergunta e, a partir dela, pude refletir como foi a minha trajetória na área de Teste de Software, nos contextos que já trabalhei até então.
Pois bem, metade da minha experiência profissional eu trabalhei com metodologias tradicionais. Logo, a dimensão predominante neste período é a de Negócio. A outra metade da minha experiência eu venho trabalhando com boas práticas de metodologias ágeis, onde estou me desenvolvendo dentro das outras dimensões, Técnico e DevOps. Atualmente, além de realizar testes funcionais manuais, que ainda ocorrem na maioria das vezes, estou conseguindo me dedicar aos poucos para a automação dos testes. Temos uma equipe madura e isso nos ajuda muito a planejá-los nos sprints, o que me direciona para dimensão Técnica. À medida que as suítes de testes automatizados estão sendo criadas, haverá a necessidade de disponibilizá-las em um ambiente de integração contínua, para que outras pessoas do time tenham acesso. Então, terei que buscar informações sobre como criar um deploy automatizado, onde esses testes poderão ser executados. Logo, estarei dando os primeiros passos para a principal atividade de um QA na dimensão DevOps.
Para quem não sabe por onde começar, acho que vale destacar que todos os QAs iniciam na dimensão de Negócio mesmo dentro de contextos com metodologias tradicionais. Mesmo assim, existem profissionais que ainda questionam "Preciso ter pleno domínio nas 3 dimensões?". Não creio que haja necessidade, porém considero importante ir trilhando a sua caminhada de acordo com as oportunidades que surgem nos projetos e também estar alinhado com sua estratégia de crescimento na carreira. Um ponto que vale destacar é que é preciso ter uma mudança na cultura profissional, pois não basta o seu gestor cobrá-lo. O mercado de trabalho também está se adaptando às novas características no profissional de Teste de Software. É essencial enxergar valor nestas novas dimensões e que realmente são particularidades relevantes para sua carreira.
Postado em Gerando Conhecimento	Com a tag Agile Tester, Perfil Profissional	1 comentário
Postado em Gerando Conhecimento	Com a tag Agile Testing, Artefatos de Teste, Plano de Teste	2 Comentários
Utilizando a Adaptação da Ferramenta 5W2H para Análise de Teste no Contexto Ágil
Uma das coisas que me deparei quando comecei a trabalhar no contexto ágil foi como extrair os requisitos de uma user story e elaborar a minha análise de teste. Bem… para quem já está adaptado a este contexto, isso pode parecer trivial, ou seja, no a partir dos critérios de aceitação. Entretanto, se coloquem no lugar de quem está iniciando no agile testing… 😉
Depois de participar de treinamentos voltados aos Métodos Ágeis, tive alguns insights para melhorar a qualidade do meu trabalho. Um desses insights foi justamente a ferramenta 5W2H. Eu buscava motivações para evoluir como profissional e agregar qualidade no trabalho do time, tais como:
—Auxiliar na identificação dos critérios de aceitação dos requisitos;
—Minimizar possíveis lacunas na análise de requisitos;
—Melhorar a comunicação;
—Incentivar a pró-atividade;
—Melhoria contínua.
—É uma ferramenta de planejamento muito utilizada na área de Administração, que consiste em um checklist contendo determinadas atividades nas quais os colaboradores da organização precisam desenvolver com o máximo de clareza. —Auxilia na eliminação por completo qualquer dúvida que possa surgir sobre um processo ou atividade.
A ferramenta compreende as seguintes atividades:
What – O que será feito (etapas)?
Why – Por que será feito (justificativa)?
Where – Onde será feito (local)?
When – Quando será feito (tempo)?
Who – Por quem será feito (responsabilidade)?
How – Como será feito (método)?
How much – Quanto custará fazer (custo)?
Adaptando a Ferramenta…
Após analisar a ferramenta vi que precisava fazer algumas adaptações para atender às necessidades do projeto. Claro que não só para a análise de teste, mas também auxiliar no entendimento dos requisitos para o desenvolvimento.
Formato adaptado:
Qual é o objetivo do requisito?
Por que o requisito deve ser implementado?
Onde poderá ser visualizado o requisito?
Quais são os pré-requisitos para este requisito?
Qual é o perfil de acesso para este requisito?
Quais são os critérios de aceitação para este requisito?
Quais serão as mensagens de validação para este requisito?
Para facilitar o entendimento, vou dar um exemplo de user story para utilizarmos esta adaptação.
** User Story **
Como operador de compras, necessito que seja implementado um ambiente de compra de matéria-prima para a fabricação de medicamentos manipulados, pois assim poderei receber as ofertas dos fornecedores e obter o melhor preço.
Só poderão participar do processo de compra os fornecedores previamente cadastrados e com acesso ao Módulo Fornecedor liberado.
Cada fornecedor deverá apresentar apenas uma cotação por produto.
Toda cotação deverá possuir prazo de validade de 72 horas.
Cada fornecedor irá receber uma nova solicitação de compra através do Módulo Fornecedor.
Um fornecedor será considerado escolhido quando na sua cotação atingir 75% dos itens da solicitação de compra e ter oferecido o menor valor para cada item.
O processo de compra deverá ter, no mínimo, 3 fornecedores participantes.
Para participar do processo, o fornecedor não deverá apresentar no seu histórico atraso na entrega dos produtos superior a 24 horas da data prevista.
O Módulo compras deverá ser integrado aos demais sistemas da rede.
** Utilizando a Ferramenta 5W2H Adaptada no Entendimento dos Requisitos **
1. Qual é o objetivo do requisito?
Seja implementado um ambiente de compra de matéria-prima para a fabricação de medicamentos manipulados.
2. Por que deve ser implementado?
Para receber as ofertas dos fornecedores e obter o melhor preço.
3. Onde poderá ser visualizado o requisito?
Não está claro na user story.
4. Quais são os pré-requisitos para este requisito?
5. Qual é o perfil de acesso para este requisito?
Perfil/papel Operador de Compras
6. Quais são os critérios de aceitação para este requisito?
7. Quais serão as mensagens de validação para este requisito?
Não foi descrito na user story.
A partir das informações coletadas, já é possível identificar os cenários de teste. Caso as informações ainda estejam incompletas, é necessário contatar o Product Owner para maiores esclarecimentos. O importante é que antes de identificar os cenários de teste, as dúvidas sejam sanadas e, consequentemente, as perguntas respondidas. Novos dados poderão ser informados e assim ampliar o escopo dos testes.
** Cenários de Teste Identificados **
Em uma visão macro, temos os seguintes cenários de teste para o requisito:
Validar a permissão de acesso ao Módulo Compras.
Validar o fluxo do processo de compra.
a) perfil dos participantes
b) quantidade de participantes
c) quantidade de cotações por produto dos fornecedores.
d) prazo de validade das cotações.
3. Validar a integração do Módulo Compras com os demais sistemas da rede.
De posse dos cenários de teste identificados, é hora de elaborar o artefato de teste adequado ao processo de desenvolvimento da sua empresa! 😉