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!

 

 

Testes de software em Pequenas Empresas

Quando entrei para a área de testes de software, saída de um ambiente de programação, eu comecei com testes unitários em uma empresa cujo cliente era da Bélgica. Então realizei também testes de componentes, mas sempre trabalhando com a equipe de desenvolvimento em um ambiente ágil.

Foi aí que eu conheci Scrum e entendi conceitos de Backlog, Sprint, etc…

Era um ambiente maduro onde todos estavam sempre preocupados com a qualidade da entrega. O ambiente era de integração contínua onde os builds da aplicação deveriam sempre estar  funcionando. Ou seja, a qualquer momento que eu subisse a aplicação ela estaria funcionando para realizar os testes de interface e qualquer outro teste. Além disso, todos os testes unitários, de componente e de integração deveriam estar “passando” também.

Mas este era um ambiente atípico do ambiente que tenho trabalhado nos últimos 3 anos, costumo trabalhar em empresas pequenas porque há mais “liberdade” (entre aspas mesmo) para realizar os testes no sistema. Eu faço esta observação porque não existe uma consciência da importância dos testes de software. Geralmente as equipes são imaturas e não compreendem que testar é exercitar o software e não apontar os defeitos da equipe de desenvolvimento e muito menos os erros de cada desenvolvedor individualmente.

O foco de um testador é, e sempre deve ser, atacar o software. Ainda mais, desvendar sua complexidade, colocá-lo à prova e realizar  a melhor cobertura de testes possível em cada entrega.

O problema maior é que quando um testador adentra uma empresa pequena ele também leva junto muitos desafios… o primeiro deles é ser incompreendido pelos demais membros da equipe. Para tal é necessário que ao menos o Gerente ou o Líder Técnico conheça um pouquinho sobre testes de software para que haja uma conversa sensata. Se isto não for possível… é necessário um esforço maior em disseminar o conhecimento acerca da área de teste de software, identificar quais os maiores riscos da aplicação e promover um estratégia para aplicação dos testes.

É necessário que todos estejam cientes de como serão realizados os testes e qual seu critério de saída… ou seja, irei parar de realizar os testes assim que: todos os Test Cases planejados sejam executados + os itens do checklist estejam verificados + os testes exploratórios (talvez limitado por tempo) sejam executados.

Outro desafio é deixar transparente a todos em qual nível o teste de software esta sendo aplicado. Exemplo: serão feitos testes de aceitação? Serão realizados testes de sistema? Será realizados testes de componente e de integração pela equipe de testes? A usabilidade também será avaliada? É um erro achar que o teste de software irá encontrar todos as falhas na aplicação, principalmente porque apesar de naturalmente os testadores terem um conhecimento maior sobre as regras de negócio, mas o domínio é geralmente do Product Owner(no caso das metodologias ágeis) ou do Analista de Negócio se extendendo ao cliente.

O importante é que se a empresa não tem um papel central de uma pessoa que tenha domínio do negócio para passar as informações mais importantes ao testador, então o testador deveria participar das reuniões com o cliente para poder verificar o que é realmente importante para ele e o que não é. Já vi clientes dizerem que o mais importante para eles era que as informações da tela estejam auto-explicativas porque estava sendo gasto muitos recursos em suporte técnico… e quanto mais a aplicação tivesse usabilidade e menos complexidade de informações na tela, isto evitaria um gasto muito maior.

Há aplicações que o fator crucial é a parte financeira… para um sistema de cartões de crédito onde de cada transação é aplicado um conjunto de taxas a ser debitada do estabelecimento credenciado, ou onde as vendas com juros é debitada do portador, o mais importante é que os cálculos estejam absolutamente corretos e prestar atenção também em arredondamento de valores, na precisão de cada operação dentro do sistema. Imagine que eu vá em um supermecado e compre apenas um chocolate de R$ 1,50, mesmo assim todas as taxas devem ser cobradas de maneira correta.

Então é realmente complicado definir quais os testes devem ser realizados para cada tipo de aplicação quando não se sabe ao certo quais são os itens de maior risco e importância para o cliente e, principalmente, quando não há ninguém na empresa que constrói o software para responder este tipo de pergunta. Na minha opinião, neste caso a empresa deveria abrir o relacionamento da área de testes junto às reuniões com o cliente.

Mas… nem sempre é assim. #fato