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! 😉

E quando não há um processo de teste definido, o que fazer? Parte 2

** DEFININDO UM PROCESSO DE DESENVOLVIMENTO DE SOFTWARE **

Dando continuidade ao assunto abordado no post anterior, em termos de processo de desenvolvimento e que contemple a etapa de testes, eu sugiro algo baseado no ciclo PDCA, que considero dinâmico e incremental.

Etapas do Processo de Desenvolvimento em um Ciclo PDCA

Vamos alinhar alguns conceitos utilizados neste ciclo:

•  Release – termo utilizado para designar uma demanda a ser desenvolvida pelo time. Nesta demanda poderá ter uma ou mais funcionalidade. Uma release poderá ter uma ou mais iterações.
• Iteração – termo utilizado para classificar um ciclo de desenvolvimento. Uma iteração poderá contemplar uma ou mais funcionalidades para ser(em) desenvolvida(s).
• Backlog – termo utilizado para designar o estoque de funcionalidades de um projeto.

1. PLAN

1.1. Planejamento da Release
– O analista de negócio revisa a visão do produto, estratégia e objetivos.
– O analista de negócio revisa as datas chave e milestones.
– O analista de negócio apresenta o backlog de produto priorizada.
– O time faz perguntas para entender os requisitos.
– O time estima os requisitos em um alto nível (story points, dias ideais, function points).
– O time estima sua velocidade inicial e/ou capacidade por iteração.
– O time formaliza os objetivos da entrega em um plano de release.
– O facilitador da reunião registra decisões chave, premissas, riscos e/ou questões.
– Consenso de stakeholders é alcançado e o consentimento de prosseguir é dado.

=> O Analista de Teste/Testador participa através…
– Questionamentos para entender as regras de negócio das funcionalidades a serem desenvolvidas pelo time.
– Identificação os critérios de aceitação de cada requisito.
– Estruturação da estratégia de teste da release.
– Realização do planejamento dos testes, onde já é possível identificar os principais cenários de teste para validar as funcionalidades.

1.2. Planejamento da Iteração
– O analista de negócio revisa a visão do produto, estratégia e objetivos.
– O analista de negócio revisa as datas chave e milestones.
– O analista de negócio apresenta parte do backlog de produto priorizada.
– O time faz perguntas para entender os requisitos.
– O time estima os requisitos em um alto nível (story points, dias ideais, function points).
– O time estima sua velocidade inicial e/ou capacidade por iteração.
– O time formaliza os objetivos da entrega em um plano de release.
– O facilitador da reunião registra decisões chave, premissas, riscos e/ou questões.
– Consenso de stakeholders é alcançado e o consentimento de prosseguir é dado.

=> O Analista de Teste participa através…
– Caso tenha surgido alguma dúvida sobre os requisitos durante o planejamentos dos testes, este é o momento de esclarecer!
– Complementa os cenários de teste, se for o caso.
– Realiza a estimativa de teste.
– Identifica a necessidade de massa de dados para teste, ambiente específico, etc.
– Verifica a viabilidade da automação dos testes funcionais e/ou a atualização dos scripts já existentes.

2. DO

2.1. Execução
– Ferramenta de qualidade de software configurada para monitorar a qualidade do código gerado.
– Automatizar sempre que for viável! Tanto testes funcionais quanto unitários.
– Documentação deve ser gerada a medida que o software é criado/alterado.

=> O Analista de Teste participa através…
– Enquanto o desenvolvedor codifica, o analista de testes/testador cria os artefatos de que se façam necessários.
– A medida que as demandas são liberadas pelo desenvolvedor, o analista de testes/testador realiza os testes funcionais, tanto manuais quanto automatizados.
– Reporta os problemas encontrados para o desenvolvedor.
– Refaz os testes para verificar a correção dos problemas reportados.
– Cria/atualiza scripts de testes automatizados, de acordo com o planejamento e estratégia dos testes.

2.2. Acompanhamento Diário
– O time reúne-se durante 15 minutos para compartilhar as atividades realizadas, impedimentos, angústias, onde respondem as seguintes perguntas:
a) O que você fez desde nosso último encontro?
b) O que você está planejando fazer até que nos encontremos de novo?
c) Quanto tempo falta para você concluir a atividade atual?
d) O que, se for o caso, você está encontrando de obstáculos que estão impedindo você de fazer progresso?

3. CHECK

3.1. Revisão da Iteração
– O time verifica as funcionalidades concluídas com o analista de negócio.
– O time identifica qualquer histórias incompletas.
– O analista de negócio move e/ou divide histórias incompletas ou itens de backlog para próxima iteração ou as retorna para product backlog, se não for uma prioridade.
– O analista de negócio fecha a iteração e aceita funcionalidades adequadas.
– O time demonstra o software funcional para as partes interessadas.
– Quaisquer questões em aberto/obstáculos e itens de ação são verificadas e atribuídas.

=> O Analista de Teste participa através…
– Acompanhamento da validação da versão pelo analista de negócio/cliente.

4. ACT

4.1. Retrospectiva
– O time revisa o plano de ação da última reunião de retrospectiva.
– O time revisa o que foi bem durante a última iteração.
– O time revisa o que não foi tão bom ou como planejado durante a última iteração e por que.
– O time analisa os números do projeto.
– O time analisa a causa-raiz da ocorrência de não conformidades e propõe ações de melhoria e/ou preventivas.
– O time identifica as questões mais importantes para focar na próxima iteração.
– O time verifica qualquer impedimento que os impeça de adotar as melhorias no processo.

=> O Analista de Teste participa através…
– Leva para a reunião de retrospectiva os pontos positivos e negativos ocorridos durante a iteração.
– Se prontifica a atuar em algum foco do plano de ação.

Portanto, um processo organizacional, seja do desenvolvimento de software como um todo, seja da etapa de teste, deve ser simples e facilmente repetido. As pessoas precisam ver o valor deste processo e passar a adotá-lo naturalmente. Destaco também a relevância do papel do analista de teste/testador como um facilitador dentro do time, ou seja, terá um papel vital para que a comunicação flua dentro do time. Em times de Scrum, poderá exercer o papel de Scrum Master dentro do sprint.

Não se esqueça: faça babies steps! 😉

E quando não há um processo de teste definido, o que fazer? Parte 1

Logo após a minha palestra na Trilha de Testes do TDC 2012 em Florianópolis, eu recebi um e-mail de uma testadora que havia lido os slides da palestra. Ela queria uma ajuda em como conduzir o desafio que foi dado a ela: estruturar o fluxo de testes da equipe de desenvolvimento. Quem aqui que está na área de Teste de Software já não se deparou com um desafio desses?! Pois então, para quem está começando a trabalhar na área tem uma certa dificuldade de dar o primeiro passo. Em uma sequência de 2 posts, irei explanar sobre como iniciar a estruturação do fluxo de testes e também sobre o processo de desenvolvimento como um todo.

** ESTRUTURANDO O FLUXO DE TESTES **

Vou elencar os pontos que eu acredito que sejam primordiais para iniciar este trabalho. Vejamos:

1. Mapear as atividades realizadas pelo time – quando me refiro ao time, quero dizer desenvolvedor + testador/analista de teste. É muito importante observar a forma de como as atividades são executadas, caso elas existam. Isso nada mais é do que mapear a situação atual, mesmo que ela seja informal.

2. Identificar o tempo do ciclo de desenvolvimento – saber quanto tempo o time leva para analisar, desenvolver e testar a demanda solicitada.

3. Verificar o retrabalho do time durante o ciclo de desenvolvimento – a partir dos registros dos bugs encontrados em uma ferramenta de bug tracking, é possível identificar o índice de retrabalho. Aqui destaco outro ponto importante: classificar o retrabalho! Por exemplo:

a) o time teve um retrabalho por causa de uma análise de requisito que não estava contemplando algumas regras de negócio relevantes.

b) o testador identificou um bug por problemas na codificação.

c) outro bug encontrado por causa de configuração de ambiente.

Como disse, esses são apenas alguns exemplos. O ideal é identificar no contexto de seu projeto o que seja mais relevante classificar!

4. Coletar o índice de não conformidade no ambiente de produção – após a publicação da versão no ambiente produtivo, seria interessante monitorar as ocorrências de não conformidade principalmente se forem oriundas das implementações realizadas na versão publicada.

A partir dessas informações, é possível ter um retrato atual do time e identificar pontos de melhoria serem propostos. Crie um plano de ação para registrar a sugestões! Se uma das sugestões é elaborar um processo de desenvolvimento, comece por algo simples e intuitivo! Não pense em modelos de processos, se sua empresa possui projetos de curto e médio prazos. As pessoas têm que enxergar valor no processo, para que ele consiga ser institucionalizado. Ter um processo muito burocrático não é uma boa ideia, pelo menos não neste início de trabalho.

Outro ponto é a questão das ferramentas para a parte dos testes. A primeira ferramenta a ser definida é de bug tracking para registrar o retrabalho e não conformidades em produção. Depois temos a questão da gestão do artefatos de teste. Estes poderão ser elaborados, inicialmente, em formato de planilhas e/ou arquivos.doc. Caso depois optar por utilizar uma ferramenta, seria interessante que estes artefatos pudessem ser importados. No mercado temos diversas ferramentas open source e pagas. Veja a que melhor se adapta à sua realidade.

Gerar métricas é outro ponto importante! É necessário medir para saber como o time está e no que pode melhorar para visar a melhoria contínua. São exemplos de métricas:

• número e/ou índice de não conformidades no ambiente de produção;
• número e/ou índice de retrabalho durante a iteração;
• número de requisitos entregues por iteração.

Sobre a automação de testes funcionais, vale destacar que nem sempre haverão funcionalidades passíveis de automação. Considero importante a priorização das funcionalidades e classificá-las a partir da análise de impacto dentro do nicho de negócio. O que isso significa? Criar testes automatizados dos pontos mais críticos do sistema! E se o projeto é novo? Pode-se considerar a automação de testes de funcionalidades mais estáveis.

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! 😉

Como Ingressei na Área de Teste?

O ano era 2004. Naquela época eu trabalhava na área administrativa de sucursal de uma seguradora e estava preocupada com a minha vida profissional, pois faltavam 3 semestres para a minha formatura (2005/1). Até então, o máximo de contato que eu tinha tido com a área de TI era quando um colega da infraestrutura saía em férias e eu o substituía. Isso me angustiava demais, pois sabia que, após me tornar bacharel e ainda sem a vivência na área, as oportunidades ficariam mais restritas.

Certa vez conversando com uma colega (minha amiga até hoje) antes da aula, ela me contou que tinha saído do emprego efetivo e que tinha começado a fazer um estágio na área de Teste de Software. Eu achei que ela tinha sido corajosa por ter feito uma escolha dessas. Na realidade era o que eu mais queria fazer, mas me faltava justamente uma coisa: CORAGEM!

Passaram-se alguns meses após essa conversa e, quando me dirigia ao laboratório da faculdade, vi um anúncio de uma vaga de um estágio que não fazia muitas exigências de conhecimentos e experiências. Me interessei e anotei o e-mail para enviar um currículo, mas só que eu não fazia a menor ideia do que se tratava a oportunidade de estágio. Confesso que levei alguns dias para enviá-lo, mas menos de um dia após enviar o currículo, a secretária da empresa me contatou querendo marcar uma entrevista para o outro dia. Nossa… eu nem acreditei! Parecia que tudo estava conspirando a favor, pq justamente naquele dia seria o meu último dia de trabalho na seguradora após um acordo. Me enchi de esperanças, mesmo desconhecendo do que se tratava.

A empresa ficava no Parque Tecnológico da PUCRS (TecnoPUC) e a entrevista estava marcada perto do final da tarde, pois depois eu iria para o laboratório escrever um pouco do meu TCC. Quando cheguei na empresa, eu tive uma grata surpresa: o dono era meu colega em uma das disciplinas daquele semestre! Aí, ele me apresentou a empresa, que era uma empresa incubada (futuramente chamada start up), que havia surgido de um spin-off do Centro de Pesquisa em Teste de Software da Faculdade de Informática da PUCRS (CPTS). O CPTS tinha parcerias com as multinacionais HP e DELL, que estão instaladas no TecnoPUC. Também me explicou a respeito da oportunidade: era para trabalhar com Teste de Software na HP.

Pois bem… além da entrevista, fiz uma prova, que consistia em aplicar os testes na calculadora do windows, que estavam descritos em um plano de testes em inglês. Eu teria que reportar os bugs encontrados, também em inglês, contendo um passo-a-passo. E assim eu o fiz! Como sempre fui uma pessoa muito observadora e detalhista, reportei cada passo que havia feito para encontrar os bugs. Entreguei a prova e me disseram que entrariam em contato, caso eu teria sido a candidata escolhida, pois ainda tinham que entrevistar mais um candidato. Me dirigi para o laboratório para escrever um pouco mais do meu TCC, afinal logo em seguida eu iria encontrar a minha orientadora.

Para a minha surpresa (mais uma vez naquele dia) não demorou muito para receber um retorno do processo seletivo: eu tinha sido a pessoa escolhida para a vaga de estágio! Não acreditei!! Fiquei muito contente, pois um novo recomeço estava por vir. Um dia antes do dia combinado para o início na HP, eu passei por um breve treinamento na empresa. Este treinamento consistia na troca de experiência com os colegas que já estavam trabalhando na HP, de como funcionavam as coisas por lá e o que eu teria o que fazer.

Portanto, eu entrei na área de Teste de Software meio que sem querer! Até porque durante a faculdade eu havia me interessado pela a área de Auditoria de Sistemas e gostaria de trabalhar com isso. No final das contas, as duas áreas estavam relacionadas! Eu não fugi da Programação por não ter afinidade. Eu não tinha tido oportunidade de programar além das disciplinas do curso. A partir disso, eu teria um “novo mundo” para explorar…

Por que ter um blog?

Depois de pensar, pensar… relutar… pensar de novo, optei em ter um local aonde eu pudesse compartilhar um pouco das minhas experiências e, porque não, dilemas que tenho em torno da área que escolhi atuar. Podem estar se questionando: “Mas porque ela relutou em ter um blog?”. Bom… eu não queria ter “mais um blog” sobre Teste de Software.

Na realidade, o que me motivou a criar este espaço foi um post da Katrina the Tester, que foi repassado pelo meu amigo @GpaOliveira, sobre Women in Testing on Twitter. Achei super interessante e, ao mesmo tempo, me fez pensar na atuação feminina da comunidade brasileira de Teste de Software. Então, por que não fomentar uma maior participação feminina dentro da comunidade, não é mesmo? 😉

A minha ideia é ter uma abordagem sutil para assuntos mais técnicos, dúvidas sobre por onde começar, angústias e no que eu puder colaborar. Todas as contribuições serão bem-vindas! 🙂