images (2)

Gestão de defeitos no github

Segundo Rex Black, presidente do ASTQB (American Standards Testing and Quality Board), Fundador da empresa RBCS Consultants e autor de vários livros na área, risco é a possibilidade negativa de um evento ou saída indesejada. Um risco em específico é qualquer problema que pode ocorrer e diminuir as percepções do cliente ou usuários em termos da qualidade do produto ou do sucesso do cliente. Mas e como fazemos um paralelo do Lean, Riscos e Gestão de Defeitos de uma forma prática?

Continuar lendo

Quality Assurance vs. Quality Control

Na área de Qualidade de Software algumas mudanças estão ocorrendo relacionadas ao papel das pessoas que “cuidam” para que tudo esteja funcionando de acordo com as expectativas dos usuários. A missão é a mesma, mas a tarefa mudou um pouquinho de acordo com o tempo e as últimas alterações de metodologias e de pensamento.

O que antes era “testar no final” ditou por muito tempo as regras e foi considerado tarefas de Quality Control mas, agora mudou! As empresas não estão mais interessadas em chegar na ponta com defeitos de produção e entrar no famoso ciclo constrói/testa/conserta/re-testa, querem fazer certo desde o primeiro momento! E isso é bom, nos traz uma infinidade de possibilidades em como atuar em todo o flow de desenvolvimento do software.

Continuar lendo

Papo de Menina: Hangout with Testers Girls!!

Nesta Terça, 15 de Dezembro das 21:00 as 22:00 vai acontecer o Hangout With Testers 2.0 – Papo de Meninas promovido pelo GUTS-RS!

Segue o convite!

ehnois1.gif

Também aproveito e convido às girls aqui de Floripa para participarem do “Anitas“, um movimento aqui de Floripa para engajar e trocar conhecimento entre as “meninas” da área de TI.

Ainda sobre eventos….

O GUTSC está ressurgindo, que bacana!!! E já tem várias formas de acompanhar nas Redes Sociais, segue:

E o primeiro evento também está agendado, vai ser agora em Janeiro, dia 23 na CESUSC. Bora lá?  =D

Inscreva-se!

 

 

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.

Lean Toyota

O Sistema Toyota de Produção é um sistema de produção que foi desenvolvido pela Toyota entre 1948 e 1975, no fim da segunda guerra mundial a partir de um cenário de um Japão pós-guerra devastado e que não dispunha de recursos para realizar os altos investimentos que são necessários para a produção em massa (que caracterizava os sistemas de produção de Henry Ford e General Motors).

lean-software-testing

Toyota Sedan

O sistema basicamente parte de alguns princípios que aumentam a produtividade e a eficiência, evitando o desperdício, como a de tempo de espera, superprodução, gargalos de transporte e inventário desnecessário etc. Este sistema foi desenvolvido por Taiichi Ohno e integra o lean manufacturing, just-in-time,[1] kanban e o nivelamento de produção ou heijunka.

Segundo o Lean It Institute, existem 5 princípios no pensamento Lean (Lean Thinking):

#1 Valor

No Lean thinking, não é a empresa que decide o que é valor, mas o cliente. Para o cliente, a necessidade gera valor, ou seja, aquilo que ele enxerga como útil para alcançar o sucesso nas atividades diárias dele, nos esforços dele, isso tem valor para ele. Então o valor nasce de uma necessidade do seu cliente, e não do que você acha que é melhor para ele.

#2 Fluxo de Valor

Para encontrar o fluxo de valor, é preciso dissecar a cadeia produtiva do cliente, entender como funciona os processos dele e separá-los em três tipos:

  1. Processos que geram valor
  2. Processos que agregam valor
  3. Processos que não geram valor

O valor que realmente importa é o valor percebido pelo cliente, pois segundo Shultz et al. (1994, p. 25) “para o consumidor, a percepção é a verdade. A percepção pode não estar correta, mas é o que ele conhece, e o que ele conhece é tudo o que ele precisa conhecer”

Os processos que não geram valor devem ser imediatamente “eliminados”. Assim, as empresas começam a ter um olhar mais crítico olhando para o processo como um todo e não apenas para indicadores e números em curto prazo.

# 3 Fluxo Contínuo

Os processos precisam ter “fluidez”, não podem haver gargalos nem impedimentos que façam a linha de produção parar. Depois de eliminados os processos que não geram valor, produzir com as etapas restantes é mais difícil mas também mais estimulante!

Obter a capacidade de desenvolver, produzir e distribuir mais rapidamente gera ao produto um ar de inovação. Desta forma a empresa pode atender à necessidade do cliente quase que instantaneamente.

# 4 Produção Puxada

A produção puxada é basicamente inverter o fluxo de produção. No fluxo tradicional as empresas desenvolvem um produto que acreditam ser interessante e oferecem aos clientes. Ao inverter este fluxo, as empresas não empurram mais o produto ao consumidor, quem passa a puxar o Fluxo de Valors são os próprios clientes reduzindo a necessidade de estoques e valorizando o produto.

# 5 Perfeição

O objetivo de todos os envolvidos no fluxo de valor deve ser a qualidade. A busca pelo aperfeiçoamento de cada etapa leva a um estado ideal que deve nortear os esforços da empresa em processos transparentes onde todos os membros da cadeia tenham conhecimento profundo do processo como um todo, podendo dialogar e buscar continuamente melhores formas de se criar valor.

No próximo post vamos falar sobre “Lean Software Development” e mais à frente falaremos também sobre “Lean Agile Testing” e como usar o melhor das duas abordagens.

Acompanhe deixando seu contato aqui!

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: