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:

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

 

Project Component Test Plan – BS-7925-2 (Parte III)

Objetivo deste documento:

O Plano de teste de componente deve especificar as dependências entre testes de componentes e a sequência deles. Suas derivações devem incluir consideração das abordagens escolhidas para teste de componente, mas também podem ser influenciados por todo gerenciamento de projeto e considerações de calendário de trabalho.

  • Component test planning

Deve especificar como o documento de estratégia de testes e o ‘project component test plan’ são aplicados a um dado componente sub teste. Isto deve incluir identificação específica de todas as exceções para a estratégia de teste de componente e todo o software com o qual o componente sob teste irá interagir durante a execução do teste, bem como drivers e stubs.

  • Component test specification

Casos de teste deve ser projetados usando as técnicas de ‘test case design techniques’ na atividade de planejamento de testes
Os requisitos específicos de especificação para cada técnica de design de test case são definidos na cláusula 3. Cada TC deve ser especificado para definir seus objetivos, o estado inicial do componente, seus inputs e saídas esperadas. O objetivo deve ser indicado em termos de técnica de projeto de TC utilizado, bem como os limites de particção exercidas. A execução de cada TC deve ser repetível.

  • Component test execution

Cada TC deve ser executado

  • Component test recording

Os registros de teste para cada TC devem registrar, sem ambiguidade, as identidades e versões do component sob teste e a especificação de teste. A saída atual deve ser registrada. Deve ser possível estabelecer que todas as atividades de teste especificados foram executados por referência aos registros de teste.
A saída atual deve ser comparada contra a saída esperada. Qualquer discrepância encontrada deve ser logada e analisada a cim de estabelecer onde o erro se situa e a primeira atividade de teste que deve ser repetida a fim de remover a discrepância na especificação de teste ou verificar a remoção da falha no componente O nível de cobertura de teste atingigo por aquelas medidas especificadas como critério de completude de teste deve ser registrados

  • Checking for component testing completion

Os registros de teste devem ser checados contra o critério de completude de teste previamente especificado. Se estes critérios não são cumpridos, a primeira atividade de teste que deve ser repetida a fim de cumprir o critério deve ser identificada e o processo de teste deve ser re-startado daquele ponto.
Deve ser necessário repetir a atividadede especificação de teste para projetar test cases adicionais para cumprir o objetivo de cobertura do teste.

 

Component Test Strategy – BS-7925-2 (Parte II)

1. Component Test Strategy

Objetivos deste documento:

  •  Deve especificar as técnicas a serem empregadas na modelagem dos test cases e na racional escolha deles (a seleção de Técnicas veremos mais a frente).
  •  Deve especificar o critério de completude(ou conclusão) dos testes e a racional escolha deles. Estes critérios deve indicar o nível de cobertura de teste cuja medição deverá ser conseguido através da utilização das técnicas de medição de teste.
  •  Deve documentar o grau de dependência necessária específica para projetar os casos de teste, tais como:
    • São projetados por pessoas que definem/criam os componentes sob teste?
    • São projetados por outra pessoa que não aquela que definiu o componente?
    • São projetados por uma pessoa de uma seção diferente?
    • São projetados por uma pessoa de uma organização diferente?
    • Entre outros…
  • Deve documentar se o teste de componente é realizado usando isolamento, abordagens bottom-up ou top-down, ou alguma mistura destas
  • Deve documentar o ambiente no qual o teste de componente será executado. Isto deve incluir a descrição do hardware e do software no qual os testes de componente serão executados.
  • Deve documentar o processo de testes que deve ser usado para o teste de componente.
  •  A documentação de processo de testes deve definir as atividades de teste a serem realizadas e os inputs e outputs de cada atividade.
  •  Para qualquer TC, a documentação de processo de testes deve requerir que as seguintes atividades ocorram na seguinte sequência:
    1. Component Test Planning;
    2. Component Test Especification;
    3. Component Test Execution;
    4. Component Test Recording;
    5. Checking for Component Testing Completion.

Obs:  Sempre que um erro é corrigido através de uma alteração ou alterações nos materiais de teste ou no componente sob teste, as atividades afetadas devem ser repetidas.