Impressões do 9º Encontro Mensal da ALATS-SP

O nono encontro mensal realizado pela ALATS-SP teve a participação do Claudio Schoeps, palestrando sobre “X-Zone – Framework de Teste Open Source” e ocorreu na Globalcode (Paraíso).

Eu tive o prazer de participar desse encontro e a seguir compartilho as minhas impressões sobre o mesmo. 🙂

O José Correia, diretor da ALATS-SP, iniciou o encontro com a posse dos novos Diretores Regionais Adjuntos no mandato 2010, que assumiram o compromisso de trabalhar de formar voluntária em pró do crescimento e aperfeiçoamento da área de Teste de Software e Garantia da Qualidade.

Na sequência o José passou a palavra para o Claudio Schoeps, mas antes fez uma importante observação sobre o X-Zone, falando que é um produto criado no Brasil e por um brasileiro, o Alexandre Bartie, é nós brasileiros devemos ter mais consideração com o que é criado aqui no Brasil, ao invés, de ter o pré-conceito de que tudo é de fora é melhor do que o que é produzido aqui.

Primeira parte

O Claudio começou a palestra falando um pouco da história do X-Zone, que nasceu de um sonho do Alexandre Bartie, e cujas primeiras versões eram utilizadas por ele nas empresas em que atuava, e assim com o passar do tempo foi evoluindo-o.

Quando o X-Zone foi lançado no mercado ele era comercializado, porém o Alexandre percebeu que se ele fosse distribuído de forma gratuita, ele teria um maior uso. Aliás, aqui cabe um parênteses a respeito do título da palestra, até onde eu sei, o X-Zone é distribuído de forma gratuita, porém não é open source, pois o código dele não está liberado para download (só agora percebi esse erro no nome da palestra rs).

O X-Zone não é apenas uma ferramenta, ela também traz em si um processo, segundo o Claudio, tanto que abrange toda a área de Teste de Software, conforme imagem abaixo (retirada da apresentação disponibilizada pelo Alexandre Bartie).

O Claudio foi bem sincero a respeito de como está o X-Zone hoje, falando que ele ainda não é completo, mas o básico (arroz com feijão) funciona bem. Mas precisamente, atualmente o X-Zone atua bem no caminho crítico do processo de Teste de Software, que como podemos ver na figura acima, compreende as atividades de preparação de ambiente, processamento dos testes e a análise dos resultados.

Na sequência foi falado sobre o porquê de investir em um framework de teste, onde o Claudio apresentou os seguintes motivos:

  • Redução de retrabalho;
  • Controle da terceirização do desenvolvimento;
  • SLAs de Qualidade;
  • Amadurecimento da concorrência;
  • Reforço da cultura de qualidade;
  • Melhoria da imagem institucional da empresa em relação ao seus clientes;
  • Metodologia para aumentar a confiança sob o produto produzido;
  • Redução do impacto das mudanças.

E o Claudio ainda apresentou os benefícios em relação a produtividade e o custo:

  • Produtividade
    • Redução do ciclo de desenvolvimento, atendimento dos serviços de testes sem impor gargalo as demais etapas;
    • Gerenciamento de riscos com detecção antecipada de defeitos, durante a construção do aplicativo;
    • Mudança cultural e comportamental sobre as práticas de desenvolvimento de software;
    • Redução de prazos e aumento da satisfação do cliente.
  • Custo
    • A Busca pela Excelência exige uma maior cobertura possível dos cenários de testes, o que cria a necessidade de automação;
    • Um sistema pode possuir de 100 a 500.000 situações diferenciadas de negócios;
    • Redução de custos por caso de teste.

O palestrante disse que hoje o X-Zone é uma realidade em três empresas:

  • Mega Sistemas (na qual o Robson Agapito trabalha);
  • BDS;
  • E um banco pequeno que o Claudio não pôde divulgar o nome.

Não há ainda cursos, manuais, tutoriais, etc sobre o X-Zone e ele não é tão simples de ser usado, o que exige coaching. No momento apenas o Claudio presta consultoria do X-Zone, e ele disse que a consultoria acaba saindo mais barata, do que se o profissional fosse tentar aprender a usar o X-Zone sozinho, uma vez que ele irá gastar muito tempo e seria mais fácil se ele tivesse alguém ao lado, para poder guiar o seu trabalho.

Antes de fazer a pausa para o coffee break o palestrante mostrou um sistema que na segunda parte seria testado utilizando o X-Zone com o TestComplete.

Segunda parte

Após o coffee break, que mais uma vez muito bom para poder conhecer o pessoal, o Claudio focou na apresentação de uma demostração de uso do X-Zone, mostrando:

  • Mostrou o X-Zone User Desktop, onde é feita toda parte de gerenciamento;
  • O cadastro das funcionalidades a serem testadas e os detalhamento do campos que serão preenchidos, informações essas que são usadas depois para gerar sugestões de casos de testes;
  • Exportação e importação de dados usando o Excel;
  • Criação de uma bateria de teste automatizada;
  • Execução da bateria de teste feita com o X-Zone Services Agent (outro módulo do framework);
  • A integração com outras ferramentas, na demonstração foi mostrada a integração com o TestComplete.

Ou seja, o X-Zone tem funcionalidades bem interessantes.

Conclusão

Na minha opinião, o X-Zone pode ser uma boa opção dependendo da sua realidade e necessidades. Ele é uma solução bem abrangente, focada na automação dos testes e no gerenciamento do processo de Teste de Software, mas como o Claudio disse, no momento ele faz bem a parte de gerenciamento, mas a automação feita com o uso de um robô ainda está beta.

Se você está buscando o ferramenta para automação e gerenciamento do processo de Teste de Software, recomendo você baixar o X-Zone e fazer uma avaliação, aproveite que a versão atual é gratuita para avaliar todo o potencial da ferramenta e analisar se ele se encaixa bem para as suas necessidades. 🙂

Mais uma vez o encontro mensal da ALATS-SP foi bem legal, deu para sair com uma noção bem melhor do X-Zone (eu já tinha brincado uma vez com ele, mas não tinha entendido muito rs), e ainda conhecer pessoas que só conhecia por troca de e-mails.

Aproveitando, parabéns ao Claudio pela palestra e ao Alexandre Bartie pela iniciativa e coragem de criar um framework, que visa facilitar e tornar mais efetivo o nosso trabalho.

Fique por dentro das novidades, assine o feed do QualidadeBR.

9º Encontro Mensal da ALATS-SP

O  nono encontro Mensal da ALATS-SP terá a participação do Claúdio Schoeps falando sobre o X-Zone, framework open-source de teste criado pelo Alexandre Bartiê.

O encontro acontecerá no dia 6 de março (sábado) das 08:30 até às 12:00. Abaixo, segue maiores detalhes do evento, retirados do site da ALATS-SP:

Data: 6 de março (sábado)
Horário: 08:30 – 12:00
Local: Iterasys – Av. Paulista, 726 – Auditório – próximo a estação de metro Brigadeiro

Objetivo:
Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro:
X-Zone

Conteúdo:
Apresentação do X-Zone e de suas funcionalidades. Trata-se de um framework de teste criado no Brasil por iniciativa do notório Alexandre Bartiê e distribuido como software de código aberto, em que profissionais e empresas podem baixar a ferramenta e utilizá-la gratuitamente, além de poder adaptá-la as suas necessidades.

Agenda:

08:30 Credenciamento e networking entre os participantes
09:00 Posse dos novos Diretores Regionais Adjuntos no mandato 2010
09:15 Claudio Schoeps – X-Zone
10:30 Coffee break e networking
11:00 Continuação da palestra
12:00 Encerramento

Palestrantes:
Cláudio de Vilhena Schoeps, graduado em Engenharia Eletrônica pela FAAP e especialização em Gestão Empresarial pela Business School São Paulo, com mais de 20 anos de atuação em desenvolvimento de sistemas, trabalhos realizados no Brasil e contratados pela Dinamarca, França e Alemanha para empresas dos setores Financeiro, Telecomunicações, entre outros. Atualmente, é responsável pela unidade de consultoria da Auditeste. Atuou como diretor das empresas Dataware, Flexsys e Simplify..

Inscrições:
– Não Associados: R$ 30,00

– Associados ALATS 15% de desconto

A participação na palestra Vale 3 PDTS para a renovação da CBTS
Reserve pelo e-mail sp@alats.org.br

Fique por dentro das novidades, assine o feed do QualidadeBR.

Impressões do 8º Encontro Mensal da ALATS-SP

Ontem ocorreu a oitava edição do já tradicional Encontro Mensal da ALATS-SP, na Av. Paulista em São Paulo.

Tive o prazer de estar presente nesse encontro que teve como tema Modelos da Qualidade e o MPT.BR, onde foram apresentadas duas palestras: a primeira feita pelo José Correia, diretor regional da ALATS São Paulo, com o título de Introdução a Verificação e Validação no CMMI e MPS.BR, e a segunda apresentada pelo Emerson Rios, presidente da ALATS, com o título Introdução ao MPT.BR.

A seguir segue minhas impressões sobre o evento, espero que gostem. 🙂

Organização

A organização do evento foi bem realizada, só ocorreu um problema: a mudança do local do evento na última hora, mas a mesma foi avisada de forma eficiente aos participantes, e o novo local é bem perto (cerca de nem 100 metros) do local que estava previsto a realização do encontro.

A divulgação foi feita com uma boa antecedência, por meio das listas de discussões de Teste e Qualidade de Software, twitter da ALATS-SP, em blogs e além claro na própria página da ALATS-SP.

Local

O evento ocorreu em uma sala da DoMore, que possui uma boa infraestrutura (tem até um XBox 360 na sala de espera rs), boa climatização e espaço adequado para o número de participantes, aliás, a sala literalmente lotou! 🙂

Pré-palestras

Agora vamos parar de lenga-lenga, pois como puderam notar, não sou um bom relator de ambientes (uma pessoa que comenta sobre a presença de um XBox não pode ser levada a séria), e ir para o que realmente interessa, o encontro.

Antes do início das palestras, cada participante fez uma breve apresentação, contando sobre trabalha com Teste de Software, a quanto tempo e em qual empresa.

Após a apresentação ocorreu a posse dos Diretores Regionais Adjuntos (DRA) no mandato 2010, que assumiram o compromisso de trabalhar de formar voluntária em pró do crescimento e aperfeiçoamento da área de Teste de Software e Garantia da Qualidade. O time da ALATS-SP passou de 7 para 12 pessoas, e esse número ainda deverá aumentar no próximo mês, no qual haverá uma nova seleção de voluntários.

Em seguida o José Correia apresentou o balanço da ALATS e da diretoria de São Paulo, e também as metas para o ano de 2010:

  • Em 2009 189 pessoas participaram do encontro mensal;
  • Para 2010 a meta é de 400 pessoas!
  • Os DRAs realizaram 24 palestras em 2009, totalizando um público de cerca de 1.500 pessoas;
  • Para 2010 a meta é de 200 palestras, atingindo um público total de 10.000 pessoas!

Um verso que achei bem interessante, colocado pelo José no início da sua apresentação, foi:

Um sonho que se sonha só,

é só um sonho que se sonha só,

mas sonho que se sonha junto é realidade.

(Raul Seixas)

E isso é a pura verdade, por isso que foi e é tão importante o aumento de voluntários na ALATS-SP, que estão cultivando e espalhando a cultura de Teste de Software aqui no estado de São Paulo. E em outros estados isso também é possível, só é preciso união, seja ela por meio de uma associação, grupo de amigos, companheiros de trabalho, etc, e também vontade. 😉

Palestra do José Correia

O José Correia deu uma verdadeira aula sobre modelos de maturidade, e com a já conhecida, excelente didática (cheia de analogias).

O primeiro ponto esclarecedor apresentado sobre modelos de maturidade, foi a desmistificação que as pessoas tem sobre eles:

  • Não é algo mágico! Você não irá ter um salto de melhoria grande de “um dia para noite” é preciso tempo e compromisso, até porque não é a toa, que há níveis de maturidade;
  • Um modelo de maturidade não tem verdades absolutas;
  • Ele é focado no que você faz, NÃO como  você faz. Até por isso ele não te diz como fazer, apenas o que deve ser feito;
  • São modelos para você se inspirar, mas como somos preguiçosos, adoramos seguir a risca #fail!
  • Busca tornar o desenvolvimento de software mais previsível;
  • São uma base, não são completos e abrangentes.

Depois o José falou sobre CMMI (Capability Maturity Model Integration), explicando o seu surgimento, seus níveis e focando em apresentar onde está a área de Garantia da Qualidade de Processo e Produto e as de Verificação e Validação, nível 2 e nível 3 respectivamente.

Abaixo, uma figura apresentando os 5 níveis do CMMI:

O José explicou algo que geralmente não é muito bem interpretado por nós brasileiros, a palavra Capability (o C do CMMI), cuja tradução em português, capabilidade, não traz o mesmo sentido da palavra em inglês. Capability é a capacidade de fazer algo constante, fazendo uma analogia, o McDonald’s tem uma excelente capability, pois o Big Mac tem um Mc de São Paulo é igual ao de um em Campinas, por exemplo.

Após a introdução sobre o CMMI, o assunto em pauta foi o MPS.BR, uma versão brasileira do CMMI, e assim sendo, adaptado a realidade brasileira.

O José começou a sua explicação sobre o MPS.BR, falando do seu surgimento, que ocorreu em 2003, e depois já abordou os 7 níveis de maturidade.

Uma experiência interessante relatada pelo José, foi que algumas empresas utilizam o MPS.BR (Melhoria de Processos do Software Brasileiro), como forma de início para depois poderem estarem melhor preparados para alcançar um nível de CMMI, já que há uma relação entre os níveis do CMMI e o MPS.BR, como pode ser visto na figura abaixo, além disso o custo de um processo de implantação do MPS.BR é mais em conta do que o do CMMI, e esse é um dos principais motivadores de algumas empresas fazerem isso.

Ou seja, a pessoa pode alcançar o nível A do MPS.BR e depois já tentar o nível 5 do CMMI.

E por fim foi comentando um pouco sobre o Modelo V, mais para ilustrar como que pode ser o processo de Verificação e Validação em uma empresa.

Coffee Break

Pra quem já leu sobre os coffee breaks dos encontros passados, fica até sem graça falar que mais uma vez foi excelente, pena que eu já tinha tomado café em casa (rs). Foram 30 minutos para aproveitar pra conhecer o pessoal melhor, enquanto come uns pãezinhos de queijo (e vice-versa rs).

Palestra do Emerson Rios

O Emerson Rios iniciou a sua palestra falando sobre o porquê da criação do MPT.BR (Melhoria de Processo de Teste Brasileiro):

  • Necessidade de ter um modelo de melhoria focado na área de Teste de Software;
  • Adaptar um modelo de Teste de Software para a realidade brasileira;
  • Ausência de implementadores estrangeiros, de outros modelos, aqui no Brasil;
  • Criar um modelo leve para Teste de Software.

O MPT.BR é um modelo que ainda está em desenvolvimento, mas já estão sendo feitos 3 projetos pilotos, em três empresas no Rio de Janeiro. Os três estarão se encerrando no mês de março desse ano, portanto a fase de piloto do MPT.BR estará terminada.

O modelo é compatível tanto com a MPS.BR quanto com o CMMI, principalmente pelo fato de ser baseado justamente no MPS.BR, que por sua vez é baseado no CMMI. O MPT.BR propõe-se ser um modelo leve, para que não sejam onerados os processos e para que também seja possível aplicá-lo em áreas de Teste de Software pequenas, que é muito comum existirem no Brasil.

Na sequência o Emerson falou sobre os 5 níveis do MPT.BR, apresentando de forma mais detalhada os dois primeiros:

Nível 1 Gerência de Projetos de Teste – GPT
Nivel 2 Gerência de Requisitos de Teste – GRT
Nivel 3 Aquisição – AQU (opcional)
Gerência de Configuração – GCO
Garantia da Qualidade – GQA
Medição – MED
Nivel 4 Gerência de Recursos Humanos – GRH
Gerência de Reutilização – GRU (opcional)
Gerência de Riscos – GRI
Nivel 5 Verificação – VER
Validação – VAL

A primeira coisa que você precisa fazer para saber se você está credenciado ou não para implementar o MPT.BR nível 1, é tratar o Teste de Software como projeto, e se você trata o Teste de Software na sua empresa como um projeto, o próximo passo é responder as questões da Análise de GAP – Nível 1 (disponível na página do MPT.BR).

Na página do MPT há vários documentos que poderão te ajudar a entender melhor o MPT, dentre os quais estão os documentos do Nível 1, Nível 2 e Nível 3 (beta). E o interessante é que como é um modelo que está em desenvolvimento, você pode entrar em contato com o Emerson Rios, para sugerir melhorias, reportas erros, etc.

No final o Emerson Rios passou informações sobre o credenciamento de implementadores, para o qual é necessário que o profissional tenha feito o curso oficial para implementadores da  Riosoft/ALATS e ter o diploma de certificação CBTS.

Conclusão

Confesso, que senti aquela preguiça ao levantar às 6:00 em pleno sabadão, ainda tudo escuro (esse horário de verão é fogo…), mas aí lembrei que é o encontro mensal, ou seja, não é só mais um evento, e sim uma oportunidade de encontrar os amigos e fazer novos, as palestras em si são só uma desculpa pra gente ir (afinal é muito mais fácil você falar pra sua(seu) esposa(o)/namorada(o) que vai em uma palestra de Teste de Software, em pleno sábado, do que falar que vai sair com os amigos…rs).

As duas palestras foram muito boas, ambas cumpriram o que se esperava, e acredito que todos puderam entender melhor porque existem modelos de maturidade, e qual importância que eles podem ter para a sua empresa.

Na minha opinião, eles são no mínimo uma ótima fonte de consulta, e o bom é que tanto o MPS.BR quanto o MPT.BR possuem material para download, em seus sites. Se você deve ou não deve ser certificado em um deles, é uma questão de interesse interno (ação pró-ativa) ou de “pressão” externa (ação reativa).

Tem gente que marca uma cerveja pra conversar com os amigos, outros um futebol, alguns um cinema, e a gente marca uma palestra. 😀 Portanto, se você está aí na sua ilha sozinho, não tem com quem falar sobre Teste de Software, ou simplesmente, gosta de conhecer novas pessoas, participe do encontro mensal que a ALATS-SP promove todo mês, pois você ainda irá poder aprender ou conhecer mais sobre um assunto da nossa área. 😉

Dia 20 de fevereiro é o próximo!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte imagens:

Cachorro fugindo do gato – http://bit.ly/752y8Z

Remédio Genérico – http://bit.ly/4omlvN

CMMI – http://bit.ly/4HwOx3

MPS.BR X CMMI – http://bit.ly/6uAbeO

8º Encontro Mensal da ALATS-SP

O oitavo encontro mensal da ALATS-SP ocorrerá no dia 16 desse mês (em um sábado) e terá como tema “Modelos da Qualidade e o MPT.BR”. Será um encontro especial, com duas palestras: a primeira uma introdução sobre Verificação e Validação no CMMI e MPS.BR, e terá como palestrante o grande José Correia, diretor regional da ALATS São Paulo; já a segunda será uma introdução ao MPT.BR, ministrada pelo presidente da ALATS, Emerson Rios.

Será uma ótima oportunidade para conhecer como a área de Teste e Qualidade de Software é tratada no CMMI e no MPS.BR, assim como conhecer esse novo modelo de maturidade, o MPT.BR, que tem como foco a área de Teste de Software. E você ainda irá conhecer (se ainda não conhece), esses dois grandes nomes da nossa comunidade, que há um bom tempo, dedicam esforços em pró do crescimento da nossa área no Brasil.

Abaixo, segue maiores detalhes do encontro, retirados do site da ALATS-SP:

Data: 16 de janeiro (sábado)
Horário
: 08:30 – 12:00
Local: Av. Paulista, 726 – Auditório – próximo a estação de metro Brigadeiro

Objetivo:
Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro:
Modelos da Qualidade e o MPT.BR

Conteúdo:

Visão geral das área chaves dos modelos CMMI e MPS.BR relacionadas com Teste de Software (Verificação e Validação) e Garantia da Qualidade. Apresentação do modelo de Melhoria do Processo de Teste Brasileiro (MPT.BR) em desenvolvimento pela ALATS e SOFTEX.

Agenda:

08:30 Credenciamento e networking entre os participantes
09:00 Balanço das realizações da ALATS São Paulo em 2009
09:15 Posse dos Diretores Regionais Adjuntos no mandato 2010
09:30 José Correia – Introdução a Verificação e Validação no CMMI e MPS.BR
10:30 Coffee break e networking
11:00 Emerson Rios – Introdução ao MPT.BR
12:00 Encerramento

Palestrantes:
Emerson Rios, graduado em Ciências Econômicas pela UFF, pós-graduado em Engenharia de Sistemas pela COPPE/UFRJ, presidente da ALATS, certificado CBTS, diretor do iTeste, instrutor e consultor dos programas MPS.BR e MPT.BR da RioSoft/SOFTEX.

José Correia, graduado em Processamento de Dados, pós-graduado em Gestão Empresarial, diretor regional da ALATS São Paulo, certificado CBTS, CSQA, CSTE e CTFL, consultor e instrutor da Iterasys.

Inscrições:
– Não Associados: R$ 30,00

– Associados ALATS 15% de desconto

A participação na palestra Vale 3 PDTS para a renovação da CBTS
Reserve pelo e-mail sp@alats.org.br

Fique por dentro das novidades, assine o feed do QualidadeBR.

7º Encontro Mensal da ALATS-SP

Pessoal,

Para encerrar esse excelente ano, o ano em que mais tivemos eventos relacionados a nossa área no país. A ALATS-SP irá realizar, o já tradicional encontro mensal em São Paulo, no dia 2 de dezembro.

O encontro terá a palestra do Marco Aurélio Bassi, Diretor de Consultoria e Vendas do Grupo HDI, que irá palestrar sobreAlta Automação.

As inscrições podem ser feitas até o dia às 19:00h, no próprio site da ALATS-SP.

Segue abaixo, os detalhes do encontro, retirados do site da diretoria de São Paulo da ALATS:

Data: 2 de dezembro (quarta-feira)
Horário: 18:30 – 22:00
Local: Av. Paulista, 726 – Auditório – próximo a estação de metrô Brigadeiro

Objetivo:
Aumentar o contato entre profissionais da área de Teste de Software e Garantia da Qualidade, bem como estimular a troca de conhecimentos, experiências e práticas de sucesso.

Tema do Encontro:
Alta Automação

Conteúdo:
Veja as diferenças entre testes manuais, testes automatizados e testes em alta automação. Conheça uma revolucionária maneira de testar criada por brasileiros e exportada para diversos paises.

Agenda:
18:30 Credenciamento e networking entre os participantes
19:00 Início da palestra
20:00 Coffee break e networking
20:30 Continuação da palestra
21:30 Espaço aberto para discussão de temas da ALATS e da comunidade de Qualidade de Software em geral
22:00 Encerramento

Palestrante:
Marco Aurélio Bassi, graduado, pós-graduado e mestre em Engenharia. 30 anos de experiência em Tecnologia da Informação. 19 anos lecionando em cursos de graduação, pós-graduação e MBAs. 10 anos de atuação na área de Teste de Software. Um dos desenvolvedores do conceito de High Automation Testing. Diretor de Consultoria e Vendas do Grupo HDI.

Inscrições:

– Não Associados: R$ 30,00

– Associados ALATS 15% de desconto

A participação na palestra Vale 3 PDTS para a renovação da CBTS
Reserve pelo e-mail sp@alats.org.br

Fique por dentro das novidades, assine o feed do QualidadeBR.

Impressões do 6º Encontro Mensal da ALATS São Paulo – parte 2

Ontem, às 19:00 teve início a segunda parte da palestra “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, feita pelo Jorge Diz, no 6º Encontro Mensal da ALATS. A primeira parte da palestra ocorreu no final do mês setembro (30/09/09), porém teve que ser encerrada, antes do seu término, por ter ultrapassado o tempo disponível.

Abaixo, compartilho as minhas impressões sobre o encontro.

Sprint 1

Como de costume (aliás, um mal costume) cheguei em cima da hora. Ao entrar no auditório percebi que público presente era menor do que da última palestra, totalizando 9 pessoas. E dentro do auditório tinha uma mesinha, com o coffee, o que me fez pensar que não haveria o break, fato que acabou se concretizando. Ou seja, o Jorge planejou passar todo conteúdo numa sprint única.

O início da palestra se deu com o palestrante falando sobre o novo modelo de testes, necessário ao se utilizar metodologias ágeis. Utilizando a excelente explicação do fluxo ponta-a-ponta (erro -> defeito -> falha -> diagnóstico -> correção), influenciado pela metodologias ágeis, onde:

  • O erro pode ser evitado utilizando o conceito de Poka-yoke, como por exemplo, usando linguagens de tipagem forte (ex. Ruby);
  • Outra maneira de utilizar uma ferramenta que execute automaticamente os testes, a cada mudança nos arquivos do projeto relacionados com a mudança, ou seja, uma ferramenta que faça um teste de regressão de acordo com a mudança realizada, para verificar se a mesma não quebrou nada. Exemplo de tal ferramenta é o Autotest (que faz parte do pacote ZenTest);
  • Para encontrar defeitos é necessário… testes :);
  • É possível facilitar a identificação do motivo da falha, analisando a pilha de execução, exceções, logs e utilizando predicados fluentes (uma maneira de torna mais legível o método);
  • Para realizar o diagnostico é necessário ter uma gestão de configuração e depois reportar utilizando uma ferramenta de gestão de incidentes, famoso bugtracking;
  • Após a correção, se faz necessário a realização dos testes de regressão.

Agora você pode está pensando: mas boa parte das coisas que foram citadas eu já realizo no meu dia-a-dia?

Porém, utilizando agile muita dessas tarefas são realizadas de forma automatizada, realizando integração contínua, que acaba minimizando a quantidade de defeitos que seriam encontrados pela pessoa que fosse realizar o teste. E o mais importante é que o foco das metodologias ágeis é que o feedback  possa ser o mais rápido possível (lembra do manifesto ágil: “Indivíduos e interação entre eles mais que processos e ferramentas”. Trazendo isso para a realidade de Teste de Software, significa que o fluxo ponta-a-ponta será mais ágil;) o desenvolvedor pode receber o feedback da existência do defeito em “tempo de programação”, utilizando uma ferramenta do tipo Autotest.

Um ponto interessante que o Jorge Diz levantou, foi a carência de fontes falando sobre Teste de Software em metodologias ágeis, porém há uma excelente fonte, o livro da Lisa Crispin e Janet Gregory chamado Agile Testing (eu tenho ele, e recomendo fortemente aos interessados, é sem dúvida, a melhor bibliografia sobre o assunto até o momento).

Em seguida, o palestrante apresentou novamente a pirâmide frágil, na qual a maioria dos testes executados são testes de interface e poucos testes de unidade e integração são realizados. E o modelo ágil propõe uma inversão dessa pirâmide, como pode ser visto na figura abaixo.

TestingPyramid

Uma boa metáfora existente para explicar a diferença entre os três níveis de teste apresentados na pirâmide, feita pelo Patrick Wilson-Welsh, citado no livro Agile Testing, é a do três porquinhos. A camada de baixo é feita de tijolos, os testes são sólidos, e não vulneráveis ao sopro do lobo mau. Já a camada do meio é feita de madeira, precisa ser modificada com uma frequência maior do que a camada de tijolos, para permanecer resistente ao sopro do lobo mau. Por fim, a camada do topo é feita de palha, é difícil ela ser mantida no seu lugar e o lobo pode facilmente derrubá-la. Ou seja, se temos muitos testes feitos de palha, iremos precisar gastar muito tempo colocando-os no lugar.

Logo após, a explicação sobre a pirâmide dos testes, Jorge Diz falou sobre as escolas de teste, e os consensos que existem em comum entre elas:

  • Não é possível testar tudo;
  • Quem testa deve ter atitude crítica;
  • Testes tem custo;
  • Testes informam sobre risco;
  • Áreas concentram defeitos (bug clusters).

Encerrada a parte dos consensos, chegou a hora de falar sobre automação de testes no contexto ágil. Parte na qual foi apresentada uma série de ferramentas, de acordo com cada nível de teste e também uma explicação de alguns conceitos.

Para iniciar o assunto, o Jorge Diz logo apresentou as vantagens e desvantagens da automação:

Vantagens

  • Menos sujeita a falhas humanas, desatenção;
  • Menos sujeita a interpretações;
  • Executar testes automatizados é muito mais barato que manualmente, quando repetidos;
  • Regressão torna-se mais abrangente.

Desvantagens/Dificuldades

  • Dependência de sistemas externos;
  • Dependência internas do sistemas;
  • Controle sobre o ambiente;
  • Lentidão em alguns tipos de teste;
  • Fragilidade da API/interface usuário;
  • Custo da automação pode ser alto;
  • Necessidades de pessoas especializadas, o que geralmente, gera um maior custo.

O Jorge explicou um paradoxo bem interessante, o do campo minado,  no qual ficou bem claro a necessidade de realizar variações de cenários/caminhos de teste. Afinal, o intuito testes é que as minas explodam. 😉

Continuando a explicação sobre automação de testes, foi a vez de falar sobre as ferramentas existentes para realizar testes de sistemas Web:

  • Simular o browser – htmlUnit, Webrat;
  • Executar in browser em javascript – Selenium;
  • Adicionar browser a partir de um programa em Java – Selenium RC;
  • Acionar browser a partir de um plugin do browser – Selenium IDE;
  • Acionar browser a partir de um wiki – StoryTest IQ (Selenium + FitNesse);
  • Acionar browser a partir de um editor de workflow – CubicTest (Selenium + plugin Eclipse).

E necessário ter conhecimento sobre o que estamos testando, com determinada ferramenta, e para explicar isso, o Jorge citou as seguintes ferramentas:

  • Xunit – Módulos, classes isoladamente;
  • FIT – regras de negócio;
  • Cactus – funcionalidades de componentes web;
  • Selenium– Interface usuário;
  • JMeter – Estresse/desempenho.

Depois foi a vez de falar sobre as ferramentas XUnit, onde o Jorge começou falando que o programador gosta de programa e não gosta de tarefas manuais e repetitivas e por isso devem investir na utilização de tais ferramentas, para realizar os testes de forma automática e aumentar a qualidade do código.

Com testes automatizados,  os programadores conseguem gostar de testes, e testar torna-se uma tarefa central do desenvolvimento.

Em um time focado em automação de testes, há algumas mudanças:

  • Testes passam a ser ferramentas de desenvolvimento;
  • Teste unitário ocorre paralelo à codificação;
  • Rede de segurança para refatoramento;
  • Exemplos de uso do código sendo desenvolvido;
  • Complementos à compilação passam a existir (testes unitários, por exemplo);
  • Especificação de comportamento;
  • Validação para a integração contínua;
  • Adoção de um ambiente comum;
  • Infraestrutura para outros tipos de teste.

É importante também salientar as premissas para os testes unitários:

  • Teste unitário centrado no desenvolvedor;
  • Resultado independente da ordem de execução;
  • Independência entre métodos de teste;
  • A suíte de testes deve ser executada em alguns segundos;
  • Todo recurso está sob controle do programador (não pode depender do link de internet, banco de dados, sistema legado, etc);
  • Não é testada a integração;
  • Testes na mesma linguagem que o código sob teste;
  • Resultado não sujeito a interpretação (ou passou ou não passou);
  • Não colocar if no método de teste, se tiver ele é suspeito.

O Jorge Diz falou que o grande problema de realizar testes unitários é lidar com dependências. Levantando os seguintes pontos:

  • Se não consigo instanciar facilmente, não consigo testar;
  • Dependências podem se manifestar apenas em tempo de execução;
  • Dependências problemáticas precisam ser eliminadas ou substituídas.

Então a dúvida que surgiu foi: como lidar com dependências?

E a resposta: é preciso eliminar ou substituir.

Eliminar

  • Mudança no design para melhorar a testabilidade (exemplo da “vareta” para verificar o nível de óleo do motor);
  • Código-alvo precisa mudar para poder ser testado.

Substituir

  • Colaboradores substitutos em tempo de testes;
  • Dependências configuráveis(injeção de dependência, instrumentação).

E o importante: Se não conseguir eliminar ou substituir, não é teste unitário!

Em seguida o Jorge fez uma bela explicação sobre os colaboradores:

  • Dummy (sub objeto) – esta aí apenas para cumprir tabela;
  • Stub (método) – retorna uma resposta pré-definida;
  • Mock (objeto)- define previamente o comportamento esperado das interações da classe-alvo com o colaborador (proativo se ver algo errado ele já avisa, pois ele já tem incorporado o que tem que ser feito no Play[quando executa o teste]);
  • Fake (serviço/objeto) – substitui um serviço por uma implementação mais apropriada para o testes;
  • Spy (método/objeto)- registra comportamento para verificação posterior.

E há duas maneiras de testar de forma unitária:

  • Teste de estado – Verifica o estado da classe-alvo depois de exercitar uma funcionalidade;
  • Teste de interação- Verifica a comunicação da classe alvo com seus colaboradores.

Logo após a explicação sobre testes unitários e o uso de Xunit, o Jorge começou a explicação sobre o Selenium, e suas variações, que é voltado para testes de interface Web. E na sequência o Jorge falou sobre o FitNesse, voltado para testes de aceite.

O FitNesse tem as seguintes características:

  • Ferramenta wiki, que pode ser utilizada por Analista de Teste e de negócios;
  • Especificação de requisitos em planilhas;
  • É possível utilizar o FitNess usando DSL (Domain specific language), que serve para que seja criada uma linguagem mais próxima do usuário, você cria um conjunto de frases que podem ser utilizados depois;
  • Codificação de fixtures pode ser feita por programadores.

Também é possível importar um arquivo do excel para html, que é interpretado pelo FIT (FiTNess = Fit + Wiki).

Depois o tema foi BDD (Behavior-driven development), no qual há um formalismo para escrita de testes de cenários de negócio, geralmente da seguinte maneira:

  • Parte explicativa: Sendo um <Papel>, eu quero <funcionalidade>, porque <motivação>;
  • Parte executável: Dado que <pré-condições>, quando <ação>, então <verificações>.

Por fim, o Jorge citou as ferramentas que podemos usar com BDD:

Após, o término da palestra começou uma sessão de perguntas, que logo se tornou numa “mesa” de discussão (muito boa por sinal), onde variados temas foram discutidos: CMMI e metodologias ágeis, RUP é ágil ou não, dificuldades de implantar agile, as mudanças que ocorrem na área de Teste de Software e a maneira que ser realiza os  testes e vários outros assuntos relacionados a palestra.

Conclusão

A segunda parte da palestra do Jorge Diz, foi muito boa. Ele começou já falando sobre metodologias ágeis, e a palestra fluiu muito bem, sobrando até um bom tempo para as perguntas, que acabaram gerando uma excelente discussão (não é todo dia que você consegue discutir sobre agile e Teste de Software). 🙂

Com a palestra do Jorge Diz, acredito que ficou claro para todos os presentes, que o tsunami da agilidade pode melhorar muito a maneira como realizamos os testes, tornando o processo muito mais efetivo, além disso, as metodologias ágeis já tem na sua essência a preocupação com a qualidade do software, e ela não é uma preocupação/responsabilidade de apenas uma área, e sim de todos comprometidos com o projeto. 😀

Fique por dentro das novidades, assine o feed do QualidadeBR.

Impressões do 6º Encontro Mensal da ALATS São Paulo

Ontem (30/09/09) ocorreu o 6º Encontro Mensal da ALATS SP. Desta vez, sobre um tema bem atual “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, palestrada pelo Jorge Diz, Mestre em Engenharia Elétrica e Bacharel em Ciência da Computação, pela UNICAMP, e instrutor na Globalcode.

A seguir, relato as minhas impressões sobre o encontro.

Primeira parte

Ao chegar (cheguei alguns minutos atrasados) o Jorge estava mostrando uma cena do filme Matrix.

Em seguida, comentou que tentaria dá uma de Morpheus, referindo-se a apresentação de ambas metodologias tradicional (cascata/modelo-V) e a ágil (Lean, Scrum, XP e Context Driven). E ainda disse que seria necessário tomar a pílula vermelha para entender esse novo paradigma.

Um ponto bem interessante levantado pelo Jorge, logo no início, foi que errar faz parte do aprendizado, e como o desenvolvimento de software, acaba sendo um aprendizado constante, exercido durante um período de tempo (projeto), errar faz parte. E o fluxo do erro é o seguinte: erro -> defeito -> falha -> diagnóstico -> correção.

Portanto, precisamos tomar medidas para que o defeito se revele o mais cedo possível. Afinal, quanto mais cedo ele for descoberto, menor será o seu cu$to.

Depois o Jorge apresentou o modelo cascata de desenvolvimento de software e na sequência argumentou sobre as suas características relacionadas com a área de testes e seus resultados, que resumindo:

  • Como é necessário que os requisitos sejam precisos, precisamos fazer com que o cliente pense tudo antes! Resultando em um detalhamento precoce dos requisitos;
  • A arquitetura torna-se hipertrofiada, o design especulativo e o desenvolvimento Nostradamus. Pois acabamos tentando atender mais do que as necessidades do cliente, não há muito contato com o mesmo, durante o desenvolvimento. Portanto, pensamos no que achamos que ele gostaria de ter e não no que ele realmente precisa, e além disso o desenvolvedor é orientado ao e se
  • Poucos podem conversar com o cliente, e a orientação e de que é melhor nem ouvir, pois ele sempre irá pedir mais, ou mudar algo;
  • Como há menor feedback do cliente, a chance de desenvolver funcionalidades inúteis é grande;
  • A fase de teste acaba, geralmente, sendo zipada, ou seja, quando ela é iniciada o prazo está quase no fim, isso quando já não está estourado. Resultando numa entrega com um nível inadequado de testes e as falhas aparecem no pior momento possível, em produção.

Durante essa parte da apresentação o palestrante apresentou dois gráficos interessantes, um bem famoso e o outro nem tanto assim:

utilizacaofuncionalidades

O primeiro é o famoso Princípio de Pareto aplicado ao desenvolvimento de software, pelo qual 20% das funcionalidades costumam gerar 80% ou mais do benefício esperado.

Já o segundo apresenta uma comparação entre metodologias ágeis e tradicionais, onde é possível observar que o retorno do investimento (ROI) ocorre mais cedo e é maior do que utilizando metodologias tradicionais.

Para terminar a primeira parte o Jorge falou sobre inspeções e revisões.  Onde ficou claro que é importante realizar inspeções e revisões, porém elas não substituem os testes, até porque encontram outros tipos de defeitos.

Coffee Break

Vinte minutos de um delicioso coffee break, onde o pessoal pode conversar mais e se conhecer melhor, o famoso encontro das ilhas (rsrs).

Segunda parte

Voltando do coffee break o José Correia fez uma breve apresentação sobre a ALATS e o encontro semanal, trazendo novas notícias:

Continuando a apresentação, o Jorge Diz comentou sobre o modelo V, analisando os resultados que ele traz para a área de Teste de Software:

  • O tempo entre o erro e a correção ainda é longo;
  • Ainda ocorre detalhamento precoce dos testes, sem execução para atestar sua validade.

Finalmente, o palestrante chegou ao tema do encontro, dizendo que era necessário um novo modelo para o desenvolvimento, e que esse novo modelo precisava encurtar os ciclos de desenvolvimento.

O Jorge fez uma boa introdução sobre metodologias ágeis explicando o seu nascimento, o manifesto ágil (espécie de pai-nosso das metodologias ágeis) e citou as principais metodologias ágeis:

  • Lean: modelo conceitual;
  • Scrum: gestão;
  • XP: práticas de engenharia;
  • Context-Driven: técnicas de testes.

E “lógico” que numa apresentação sobre metodologias ágeis, o pobre RUP tinha que ser criticado, então Jorge fez a comparação entre os papéis existentes no RUP (muitos) e os 3 papéis existentes no Scrum (solicitante – PO, facilitador – Scrum Master e time). Eu particularmente, não acho que o RUP seja o vilão, o que ocorreu/ocorre é que muitas pessoas não souberam interpretar ele (exemplo: os papéis do RUP são “chapéus”, e não cargos!).

Logo após ter feito a comparação entre os papéis do RUP X Scrum, que já tinha gerado uma discussão com o público, o Jorge comentou que a pessoa de teste está dentro do time de Scrum e que também necessita ter conhecimentos de programação, o que gerou mais uma boa discussão com o público.

Após a discussão, o Jorge Diz fez comparações do que é possível fazer em 15 segundos (entender um método), 15 minutos (gerar um build testado), 15 horas úteis (uma funcionalidade), 15 dias (um sprint) e 15 semanas (uma entrega).

E por fim o palestrante falou sobre o novo modelo de testes, no qual há mais testes unitários do que testes de integração e menos testes de sistemas do que de integração, ou seja, o inverso do que ocorre utilizando metodologias tradicionais. E explicou o quadrante de testes ágil, desenvolvido por Brian Marick.

TestingPyramid

testquad

Considerações finais

Na minha opinião, a palestra teve um excelente início, no qual o Jorge Diz contextualizou muito bem e com uma ótima explicação o cenário do Teste de Software, perante as metodologias tradicionais. Porém, essa parte foi muito longa e comprometeu a parte mais importante do encontro, já que o tema foi “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas” e deu tempo só para ver um pouco sobre metodologias ágeis. Sobre as ferramentas, o Jorge apenas citou algumas (autotest, Cucumber, Junit, FitNesse, etc), de forma rápida, no final da apresentação. Ou seja, acabamos sendo atingidos pelo Tsunami, mas morremos na praia, devido ao tempo. Quem sabe o Jorge Diz não pode voltar num próximo encontro, até porque, estava muito interessante e o pessoal estava com várias dúvidas.

Para encerrar o post, gostaria de agradecer a todos que foram, o auditório estava lotado! E parabéns a todos da ALATS-SP, em especial ao José Correia pela iniciativa do encontro e por seguirem firme, que venha o sétimo!

P.S.: Assim que for disponibilizada a apresentação utilizada no encontro, eu atualizo o post com ela. 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte – Imagens

http://improveit.com.br/xp/desenvolvimento_tradicional

http://agile101.net/2009/07/22/self-funding-projects-a-benefit-of-agile-software-development/