Preciso dominar todas as dimensões do perfil de Agile Tester?

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.

Artefatos em Agile Testing – Caso de Teste

Seguindo a ideia do post anterior Artefatos em Agile Testing – Plano de Teste, vamos falar um pouquinho sobre caso de teste. De um modo geral, podemos dizer que caso de teste seria um conjunto de condições (passos) utilizado na execução de teste de software. Tais condições não mais são mais do que a definição dos dados de entrada e os seus resultados esperados. Os casos de teste são extraídos a partir da especificação de requisitos.

No contexto tradicional, para identificarmos os requisitos de teste, utilizamos os casos de uso (especificação de requisitos). Podemos dizer que um requisito de teste poderá ter “N” cenários de teste, onde cada cenário de teste poderá ter “N” casos de teste.
Este artefato deve ter, no mínimo, os seguintes dados na sua estrutura:
– Resumo
– Pré-Condições
– Entradas
– Ação
– Resultados Esperados
– Pós-Condições
O nível de detalhamento dependerá das premissas do time ou até mesmo do processo de desenvolvimento definido.

Já no contexto ágil, os cenários de teste são identificados a partir dos critérios de aceitação das histórias de usuário (especificação de requisitos), onde um critério de aceitação poderá ter “N” cenários de teste, que poderão ter “N” casos de teste (passos/condições). O foco é justamente validar o comportamento do requisito. Para isso, podemos utilizar o BDD (Behavior Driven Development) como design dos cenários de teste. Nesta estrutura temos:
– Título do cenário
– Dado que… (cenário atual)
– Quando… (ação do usuário)
– Então… (comportamento do software)
Ainda podemos criar cenários de teste mais ricos e para isso podemos utilizar o “E” e o “Ou” a cada ação do usuário e/ou comportamento do software. Para facilitar o entendimento, elaborei um modelo de cenários de teste na estrutura do BDD.

Independente do contexto do seu projeto, é importante termos em mente que…

* a partir de uma especificação de requisito, podemos identificar os requisitos de teste.
* um requisito de teste poderá ter “N” cenários de teste.
* um cenário de teste poderá originar “N” casos de teste.

Espero que tenha ajudado mais uma vez! 😉

Clique aqui para fazer o download:  Modelo Cenários de Teste – Formato BDD – Agile Testing

Artefatos em Agile Testing – Plano de Teste

Para quem trabalha na área de Teste de Software, principalmente no modelo Tradicional, elaborar artefatos de teste faz parte da rotina de trabalho. Os artefatos mais comuns são: planos de teste, casos de teste e relatórios de defeitos. Obviamente exitem outros artefatos e com outras nomenclaturas. 😉

Para quem está trabalhando em uma equipe que está começando a utilizar algumas boas práticas de Agile Testing, logo surgem dúvidas quanto à elaboração de artefatos. Não é que não existam artefatos em Agile Testing, mas busca-se documentar o que de fato trará valor ao projeto. É importante ter em mente que haverá a necessidade de dar manutenção nesta documentação e que o tempo é reduzido nos sprints!

Uma leitura torna-se obrigatória neste contexto, o livro Agile Testing, a pratical guide for Testers and Agile Teams da Lisa Crispin e da Janete Gregory. Além do famoso quadrante do teste ágil, o livro traz um modelo de Plano de Teste, onde busca-se identificar possíveis problemas e dependências, mostrar os riscos que poderão impactar no projeto, para que o time possa discutir a respeito da visão do todo.

Diante nisso, elaborei um modelo de Plano de Teste para facilitar essa fase de transição para o contexto ágil. É importante destacar que cada projeto é diferente. Então, não espere que uma solução sirva para todos.

Um ponto que deve ficar claro é que este artefato deverá conter a estratégia dos testes, que serão realizados no sprint. Ele poderá ser elaborado a partir da definição do objetivo do sprint, bem como definição da capacidade do time em atendê-lo dentro do prazo. O QA/Tester terá a visão do todo do escopo e assim estabelecer como deverão ser os testes. Neste caso, este artefato não seria “executável”. Quanto à utilização de ferramentas para a sua elaboração, fica a critério do que cada empresa utiliza para armazenar a documentação dos projetos.

Com o tempo, o amadurecimento do time e os desafios que surgirão a cada sprint, o QA/Tester encontrará a melhor forma de fazer o seu trabalho para agregar valor ao projeto. Espero que tenha ajudado!

Clique aqui para fazer o download: Modelo Plano de Teste by Lisa Crispin and Janet Gregory

Como fundamentar seus argumentos para buscar investimentos em Qualidade de Software?

Vamos ao 1º post de 2015! 🙂

Na maioria das vezes quando nos deparamos com o desafio de estruturar um processo de desenvolvimento de software que contemple teste de software. Ficamos preocupados em justificar o investimento na área, coletamos métricas da situação atual para nos embasarmos e projetamos os objetivos que seriam alcançados, caso a empresa tivesse um processo definido, por simples que fosse. Dependendo da empresa, principalmente da visão de Qualidade de Software que seus gestores possuem, pode ser algo que se faça com uma maior facilidade.

Entretanto, se os gestores possuírem uma visão mais ortodoxa (por diversas razões), esta atividade poderá se tornar um trabalho árduo, uma vez que será necessário utilizar outras formas para justificar tal investimento. Quando isso ocorre, algumas perguntas poderão surgir, tais como: o que podemos fazer? Para que lado eu vou? Quem poderá me mostrar o “caminho das pedras”? Se subíssemos um ou mais níveis para analisarmos a organização como um todo, veríamos que não seria apenas definir um processo de desenvolvimento e implantá-lo.

Contextualizando…

Atualmente, grande parte dos negócios não conseguem se manter sem a tecnologia. Com isso, a tecnologia tornou-se parte indispensável para as transações das organizações. Além disso, o mercado está cada vez mais competitivo, onde ter um produto com qualidade traz para a imagem da empresa a confiança de seus clientes, o que faz aumentar seu faturamento. A partir da implantação da Governança de TI na organização, é possível identificar como pode ser feita a medição do desempenho da TI através do ponto de vista da Qualidade de Software, uma vez que irá auxiliar no processo de tomada de decisão na gestão da TI, utilizando como base os níveis de maturidade do framework CobiT.

Governança de TI

A Governança de TI busca o compartilhamento de decisões de TI com os demais dirigentes da organização, assim como estabelece as regras, a organização e os processos que darão um rumo para o uso da tecnologia da informação pelos usuários, departamentos, divisões, negócios da organização, fornecedores e clientes, determinando como a TI deve prover os serviços para a
empresa. A Governança de TI vai muito além do que simplesmente implementar modelos de melhores práticas. Diante disso, a Governança de TI possui os seguintes papéis:
* Garantir o alinhamento da TI ao negócio, em suas estratégias e objetivos, tanto em relação às aplicações como à infraestrutura de serviços de TI;
* Garantir a continuidade do negócio contra interrupções e falhas;
* Garantir o alinhamento da TI aos marcos de regulação externos como Sarbanes-Oxley, Basiléia II e outras normas e resoluções.
Seu objetivo principal é alinhar a TI aos requisitos de negócio, onde está baseado na continuidade do negócio, no atendimento das estratégias e no atendimento dos marcos externos de regulamentação. O ciclo de vida da Governança de TI é composto por 4 etapas:

Podemos destacar alguns dos principais modelos de melhores práticas para implantação da Governança de TI. Os mais conhecidos são: CobiT, CMMI, ITIL, ISO/IEC 27001 e ISO/IEC 27002, Modelos ISO, PMBOK, BSC e Seis Sigma.

Framework CobiT 

O CobiT (Control Objectives for Information and related Technology) possui padrões internacionais técnicos, profissionais, regulatórios e específicos para controle dos processos de TI. Tem como principal objetivo auxiliar no êxito da entrega de produtos e serviços de TI, baseando-se nas necessidades do negócio da organização com objetivo de controle.
Seus pilares estão fundamentados em 5 áreas-foco: Alinhamento Estratégico, Agregação de Valor, Gerenciamento de Recursos, Gerenciamento de Riscos e Medição do Desempenho. O modelo está estruturado em 4 domínios: Planejamento e Organização, Aquisição e Implementação, Entrega e Suporte e Monitoração e Avaliação. Cada domínio dá cobertura a um conjunto de processos, para que se possa garantir a gestão da TI, onde ao todo totalizam 34 processos. Além disso, o CobiT possibilita utilizar como matriz o ciclo tradicional de melhoria contínua (ciclo PDCA).

Qualidade de Software

É um processo sistemático que focaliza todas as etapas e artefatos produzidos com o objetivo de garantir a conformidade de processos e produtos, prevenindo e eliminando defeitos. O produto final do processo de desenvolvimento é exatamente o somatório de todas as decisões e realizações geradas durante todo o ciclo de desenvolvimento. Se for desejado produzir software com alta qualidade, será necessário investir em qualidade em todos os pontos do processo.

Seja método tradicional ou incremental, a disciplina de Teste de Software dará suporte ao processo de desenvolvimento estruturado, assim como a adoção de ferramentas para auxiliar na realização das atividades. Estas informações deverão constar no Portfólio de TI, que faz parte do Plano de TI.

Conclusão

Independente da escolha do modelo de qualidade de software mais adequado ao negócio, a melhoria do processo deve ser uma preocupação constante para empresas que desenvolvem aplicações, pois cada vez mais o mercado exige qualidade dos produtos por eles contratados. As empresas que tiverem a capacidade de integrar, equalizar e catalisar seus processos de desenvolvimento e, principalmente, dar manutenção nos produtos de forma mais efetiva e mais agilidade obterá supremacia diante dos seus concorrentes.

Este ponto de vista traz argumentos que vão além do famoso ROI, que nada mais é do que Retorno sob o Investimento. Muitas vezes, esta métrica pode ser um pouco complicada de ser mensurada, principalmente quanto aos seus benefícios.

Aqui vale o gancho do CobiT… ciclo PDCA! Acredito fortemente que um processo de desenvolvimento de software tenha que ser algo relativamente simples, mas efetivo, e que as pessoas vejam valor nele. Como fazer isso? Eliminando os desperdícios… mas isso é assunto para outro post! 😉

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.

O que é a Ferramenta 5W2H?

—É 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:

1. Qual é o objetivo do requisito?
2. Por que o requisito deve ser implementado?
3. Onde poderá ser visualizado o requisito?
4. Quais são os pré-requisitos para este requisito?
5. Qual é o perfil de acesso para este requisito?
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?

Para facilitar o entendimento, vou dar um exemplo de user story para utilizarmos esta adaptação.

** User Story **

Módulo Compras

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.

Para aceitar:

1. Só poderão participar do processo de compra os fornecedores previamente cadastrados e com acesso ao Módulo Fornecedor liberado.
2. Cada fornecedor deverá apresentar apenas uma cotação por produto.
3. Toda cotação deverá possuir prazo de validade de 72 horas.
4. Cada fornecedor irá receber uma nova solicitação de compra através do Módulo Fornecedor.
5. 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.

Para considerar:

• 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?

• 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.

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?

• 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.

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:

1. Validar a permissão de acesso ao Módulo Compras.
2. 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! 😉