Lean Software Testing : 1. As raízes do Lean

Depois da apresentação da Palestra “Lean Software Testing” no evento OctoberTest, algumas pessoas entraram em contato para saber um pouco mais sobre o assunto. Então decidi escrever 3 posts iniciais: “As raízes do Lean”, “Lean Software Development” e “Lean Software Testing”. Este é o primeiro post da série.

Continuar lendo

Lean-Agile Software Testing na OctoberTest

O evento OctoberTest (http://www.octobertest.com.br/) aconteceu no sábado passado aqui em Florianópolis e contou com grandes profissionais da área de Testes!

Foi excelente participar e assistir as palestras com grandes profissionais como Marcelo Andrade, Marcos Bicalho, Kleitor Franklin, Willian Reis, Thiago Cordeiro, Roberta Lingnau e José Correia!

Pude também participar, levando o Lean a  um Talk de 15 minutos falando sobre “Agile Lean Testing” e como podemos usar as raízes do Lean na área de Testes de Software. /

Falei um pouco também da experiência que temos tido na Resultados Digitais nos adequando ao processo de desenvolvimento Agile-Lean através do levantamento de cenários de Testes de Aceitação em paralelo ao desenvolvimento e como temos atuado como Agile Tester apoiando o time com todo o tipo de Testes, além de repassar conhecimento à equipe acerca da área de Testes e aprender muito com as Specs funcionais do Ruby.

Tem sido uma experiência gratificante! =D

Aliás, agradeço em especial ao Elias Nogueira por estar lendo meu blog (fico extremamente honrada!) e agora tenho ainda mais motivos para CAPRICHAR!  =D

Segue a apresentação no evento:

Overview de Níveis, Técnicas e Abordagens de Testes de Software

Hoje apresentei o primeiro de uma série de Seminários envolvendo o tema “Testes de Software”, o objetivo foi levar um mindset de Testes ao pessoal de Desenvolvimento.

Apesar da grande maturidade em termos de Testes dos Desenvolvedores, é sempre possível se descobrir novos meios de elaborar uma cobertura mais coberta em termos de Testes.

Metodologias Ágeis – princípios, conceitos e prática

Princípios do Manifesto Ágil:
  • Indivíduos e interação entre eles mais que processos e ferramentas
  • Software em funcionamento mais que documentação abrangente
  • Colaboração com o cliente mais que negociação de contratos
  • Responder a mudanças mais que seguir um plano
Conceitos de Scrum:
O Scrum é um framework para a resolução de problemas. Ou seja, um conjunto de diretrizes e ferramentas que podem auxilia-lo a gerir um projeto. A vantagem do Scrum em relação a outros métodos ágeis é que ele é relativamente simples de implantar e extremamente útil em situações onde é difícil prever os problemas futuros. O método também é mais democrático já que as opiniões de todos são igualmente ouvidas e desta maneira fica muito mais fácil estimar prazos, definir funções e criar soluções.
O Time Scrum é um conjunto multidisciplinar de profissionais. Estes times devem ser auto geridos, ou seja, não existe hierarquia ou a figura de um líder. O time deve decidir, em conjunto a melhor forma de completar o seu trabalho ao invés de receber ordens externas de alguém que não faz parte da equipe e por isto não tem o conhecimento empírico para determinar prazos, por exemplo. A opinião de todos deve ser igualmente ouvida e respeitada. Mas existem alguns papéis fixos para auxiliar o bom andamento do trabalho.
Product Owner representa a voz do cliente, do dono da empresa, enfim, de todas as pessoas externas a equipe. Ele é responsável por traduzir as histórias dos usuários em uma lista de tarefas concretas, expressar claramente quais são as funcionalidades a serem desenvolvidas e definir a prioridade de cada uma de uma forma objetiva.
O Scrum Master é o facilitador, ele acompanha o bom andamentos dos jobs e garante que todos tenham as ferramentas necessárias para cumprir suas tarefas. Tipicamente o Scrum Master é o cara que conhece melhor as regras do Scrum e portanto consegue organizar o jogo de maneira mais efetiva.
Scrum na prática:
No Scrum, os projetos são divididos em ciclos (tipicamente mensais) chamados de Sprints. O Sprint representa um Time Box dentro do qual um conjunto de atividades deve ser executado. Metodologias ágeis de desenvolvimento de software são iterativas, ou seja, o trabalho é dividido em iterações, que são chamadas de Sprints no caso do Scrum.
As funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida como Product Backlog. No início de cada Sprint, faz-se um Sprint Planning Meeting, ou seja, uma reunião de planejamento na qual o Product Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do Product Backlog para o Sprint Backlog.
A cada dia de uma Sprint, a equipe faz uma breve reunião (normalmente de manhã), chamada Daily Scrum. O objetivo é disseminar conhecimento sobre o que foi feito no dia anterior, identificar impedimentos e priorizar o trabalho do dia que se inicia.
Ao final de um Sprint, a equipe apresenta as funcionalidades implementadas em uma Sprint Review Meeting. Finalmente, faz-se uma Sprint Retrospective e a equipe parte para o planejamento do próximo Sprint. Assim reinicia-se o ciclo. Veja a ilustração abaixo:
Imagem

 

Fontes da Pesquisa:

Testes Ágeis

Voltei a trabalhar com metodologia ágil e montei uma apresentação simples para os colaboradores da empresa dando um overview na área de Teste e Qualidade, também sobre como os testes funcionam na metodologia ágil. Segue a apresentação:

Palestra sobre Agile Testing – Por Elias Nogueira

Palestra apresentada dia 10/11/2012 no Rio Agile Talks (@rioagile) por Elias Nogueira mostrando a importância do Agile Testing e das visões que mudam sobre modelos, como o quadrande de Brian Merick que pode ser mudado/atualizado pelo novo uadrante proposto por Elisabeth Hendrickson, mas onde uma coida não muda: a pirâmide de automação de teste

Test Case Design Techniques – BS-7925-2 (Parte IV)

Esta seção do padrão fala breviamente sobre as técnicas no ponto de vista de Análise e de Modelagem, mas no mesmo documento do BS-7925-2 existe o capítulo 4 que é o “Test Measurement Techniques” e fala no cálculo de cobertura de cada técnica. Além disso, existe um anexos que acredito ser muito bacana: “Guidelines for Testing Techniques and Test Measument”… acabei descobrindo ele por acaso, porque não tinha intenção em ler tudo. No final das contas o anexo passa muito mais informação que o próprio documento do padrão.

Então assim…. nos próximos post vou fazer diferente. Para cada técnica vou colocar as seguintes seções:

1. Análise

2. Design (modelagem)

3. Cobertura

4. Exemplo

A parte “4- Exemplo” é muito extensa no “Anexo B”, mas vou tentar simplificar um pouco… de qualquer forma, se ficar muito extenso deve dividir cada Técnica em “Parte 1” e “Parte 2”.

Acompanhe os próximos post se quiser saber um pouco mais sobre as técnicas de criação de casos de teste, que na minha opinião é a parte mais interessante e é também super-importante profissionalmente. Lembrando que veremos estas técnicas no ponto de vista do BS-7925-2 (British Standards for Software Component Testing).

Valeu!
Fiquem com Deus!