Cobertura CInTeQ 2010 – Dia 2 (parte 1)

Agora irei falar sobre como foram as palestras da parte da manhã, que ocorreram no segundo e último dia do CInTeQ 2010, um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB. Se você quiser saber como foram as palestras do primeiro dia, pode acessar esse post e esse.

Mauro Spínola – Qualidade e Produtividade em Sistemas e Software: Um Desafio Brasileiro

No segundo dia também cheguei um pouco atrasado, e perdi o início da palestra do Mauro, quando cheguei ele estava falando sobre produtividade.

O Mauro Spínola é Doutor e Livre-docente em engenharia pela Poli-USP e atua como consultor na área de TI e Qualidade de Software, ele também realiza treinamentos e assessoria através da Fundação Vanzolin.

A palestra teve como foco apresentar e discutir as exigências que as empresas enfrentam atualmente, assim como falar sobre a potencial contribuição que os modelos e normas podem ter nelas, quando as mesmas buscam a qualidade de sistemas e software.

Ao falar sobre produtividade o Mauro levantou a questão sobre o que é produtividade, que seria a relação entre o que a gente produz, com o quanto que a gente gasta para produzir.

Medir produtividade não é fácil, e medir produtividade em software é bem mais difícil, por isso precisamos saber qual tipo de produtividade nos interessa. Mas antes, precisamos ter a coragem de medir a produtividade.

Como obter maior produtividade?

O Mauro disse que as técnicas não são muito diferentes das usadas para obter qualidade, sendo elas:

• Arquitetura definida;
• Processo definido;
• Padrões;
• Ferramentas, automação;
• Reuso/componentização.

Logo após, o palestrante falou um pouco sobre qualidade, primeiro a de produto e depois de processo, citando as características que podemos avaliar no software (Norma NBR 13596):

Do ponto de vista de produto podemos avaliar o seguinte (Norma NBR 13596 [que hoje é a NBR ISO/IEC 9126]):

• Funcionalidade;
• Confiabilidade;
• Usabilidade;
• Eficiência;
• Manutenibilidade;
• Portabilidade.

Agora para falar sobre qualidade de processo o Mauro, citou vários modelos e normas que ajudam a obter um bom padrão, sendo alguns deles:

• ISO9000-2000/ISO90003;
• ISO12207;
• ISO15288;
• ISO1550;
• CMMI;
• MPT.BR.

Sobre CMMI e MPS.BR o Mauro citou alguns números interessantes:

• CMMI
  • Já foram feitas quase 5000 avaliações, boa parte das avaliações são feitas fora dos EUA, muitas empresas passaram para o nível gerenciado e definido;
  • O Brasil se encontra 117 avaliações no Brasil e 9 são de nível 5.
• MPS.BR
  • 205 avaliações MPS.BR foram realizadas até agora.

Alguns pontos interessantes levantados pelo Mauro foram:

• Uma empresa que não tem um padrão, dificilmente irá obter bons resultados mesmo com gênios;
• Só consegue avaliar a qualidade tendo claro as características que definem um bom software;
• Testes e codificação são atividades de menor cognição, quando comparadas com atividades de requisitos por exemplo.

O Mauro falou sobre pessoas, fazendo uma analogia onde disse, que uma alfaiataria é diferente de uma fábrica de ternos, e nas faculdades estamos formando bons alfaiates, que não estão preparados para atuar numa fábrica de ternos. Ele ainda enfatizou a necessidade de uma boa formação, para que o profissional possa lidar com as mudanças, afinal na área de tecnologia, mudanças ocorrem de forma constante, sempre precisamos nos manter atualizados.

Ainda foram citados alguns desafios que as empresas enfrentam:

• Manterem-se atualizadas;
• Investir em seus funcionários;
• Desenvolver processos maduros.

Por fim, o Mauro falou que as fábricas de software tendem a industrialização do software, e a “modularização” das atividades é necessária, pois não há sentido em continuar no desenvolvimento vertical.

Impressões da palestra

O Mauro falou sobre um assunto que realmente é um desafio, e na minha opinião a qualidade será cada vez mais um diferencial entre as empresas. E a necessidade da produtividade é inerente ao panorama atual, no qual o que é desenvolvido hoje, passa a ser ultrapassado, cada vez mais cedo.

Não concordo com alguns pontos levantados pelo Mauro, principalmente sobre testes e codificação serem atividades menos cognitivas do que atividades de requisitos, isso me remete a visão de um gerente fora da realidade, que pensa que codificar é igual montar peças de Lego e que testar é só inserir dados num formulário. Além disso, não acredito na tendência da industrialização do software, pelo menos não da maneira que deu a entender, onde o desenvolvimento de software estaria cada vez mais próximo de uma montadora de automóveis. Ainda sou da opinião de que desenvolver software é um processo muito mais artesanal do que industrial.

Neli E.Duarte – Test Mirror: a test strategy using Scrum in an outsourcing project

A Neli, Engenheira de Software na IBM, iniciou a sua palestra falando sobre as características do projeto, no qual eles usavam Scrum, FDD (Feature Driven Development) e outsourcing.

Como no FDD o desenvolvimento é dirigido a features (funcionalidades), havia o feature leader, que era o responsável pelo desenvolvimento da feature do começo ao fim.

E neste contexto, surgiu a necessidade de criar um papel para fazer interface com o feature leader, e aí “nasceu” o test mirror, que é justamente um  espelho do feature leader, só que voltado para os testes.

A Neli detalhou como era o relacionamento entre o feature leader e o test mirror:

• Na Sprint Planning a interação entre o test mirror e o feature leader ocorria o tempo todo;
• O feature leader precisava manter o test mirrors ciente de todas modificações feitas na features. Com essas informações o test mirror modelava os testes;
• Os desenvolvedores davam todo o feedback do que ocorreu, inclusive dando dicas de onde seria necessário fazer testes, e entre eles (feature leaders) também haviam troca de informações
• Na Sprint Review quem atua é o test leader, baseado nos reports levantados pelo test mirror, ele criando um relatório de qualidade (era o output do processo de teste) e o feature leader apresentava as funcionalidades. Ou seja, o test mirror agia apenas como um suporte ao test leader, durante a Sprint Review.

Também foram citadas alguns características do processo:

• O output da Sprint Planning era o plano geral dos testes;
• A primeira tarefa do tet mirror era a modelagem dos testes;
• Tudo era de acordo com a feature, então no mesmo sprint poderiam ocorrer várias fases em paralelo;
• Haviam reuniões semanais, onde participam o time Scrum e os core members das outras equipes, onde todos davam um panorama de como estavam as atividades da sprint;
• Haviam builds semanais;
• Os test mirrors eram os responsáveis por executar o teste de sanidade que ocorria no mesmo dia da liberação do build;
• Uma das funções do teste de sanidade era dá informações para o planejamento dos testes (ex.: se o teste de sms não funcionou, não tem como fazer o teste de envio
• do sms concatenado).

Depois ela falou sobre a interação com o outsourcing (4 empresas trabalhando no mesmo produto 3 de desenvolvimento e 1 de teste[não que uma só fazia testes e a outra as outras só desenvolviam]):

• Uma equipe entregava o cenário e a outra equipe criava os outros testes;
• Haviam troca de informações entre as equipes;
• O test mirror solicitava a execução dos testes, feitas pelo recurso externo, e esse enviava o report da execução dos testes;
• O test mirror validava todos os bugs reportados pela equipe da outra empresa, fazendo assim um filtro dos bugs;
• O test mirror era capaz de fazer a filtragem de bugs, pois tinha ciência da funcionalidade, já que estava sempre interagindo com o feature leader.

Por fim, a Neli mostrou os resultados obtidos utilizando essa dinâmica:

• A comunicação melhorou muito (esse  é geralmente um dos primeiros sintomas, quando iniciamos o Scrum);
• Melhorou a rastreabilidade dos incidentes;
• Pacotes entregáveis mensalmente;
• Aplicação foi entrega no tempo e sem bugs críticos;
• Uma dinâmica muito intensa durante a sprint, um planejamento bem feito, sendo realizado duas vezes – o planejamento em si e o refinamento;
• Testes mais esperto!

Impressões da palestra

Sabe aquela palestra que você balança com a cabeça todo o tempo, afirmando o que foi dito? Foi esse o comportamento que tive durante a palestra da Neli.

Até comentei no twitter, que a melhor palestra “coadjuvante” do CInTeQ  foi a da Neli. E essa impressão deve-se aos seguintes fatores:

• Foi a palestra que mais se aproximou da minha realidade;
• A Neli apresentou um conceito novo, o Test Mirror;
• Mesmo com pouco tempo (meia hora de palestra apenas) a Neli conseguiu passar muito bem o conteúdo da apresentação.

Além disso, a palestra da Neli, na qual ela contou uma experiência de um projeto, mostrou que é possível aplicar práticas ágeis até mesmo na IBM (essa foi para os “ateus” em metodologias ágeis rs). 🙂

Adalberto Nobiato Crespo – Teste de Software no Contexto do Software Público Brasileiro

A palestra do Adalberto, Doutor em Engenharia Elétrica e membro da equipe técnica do CTI –  Centro de Tecnologia da Informação Renato Archer – Campinas, foi mais a título informativo sobre o Portal do Software Público Brasileiro, falando mais sobre o 5CQualiBr.

Ele começou falando sobre o que o a atuação do CTI e depois explicou sobre i que é o Software Público Brasileiro, que é um conjunto de soluções de tecnologia da informação e comunicação (TIC), disponibilizado para uso público, por meio de um portal Web.

Dentro desse ambiente existe um outro portal, chamado 5CQualiBR, no qual é tratado a qualidade do Software Público Brasileiro, que possui 6 vetores:

• Ecossistema;
• Qualidade de produto;
• Desenvolvedores de software;
• Prestadores de serviços;
• Interoperabilidade;
• Teste de Software.

O propósito é construir e disponibilizar no Portal do SPB uma Estrutura Tecnológica de Teste de Software, para os diversos usuários do SPB, além de tentar diminuir a distância que hoje existe entre a teoria e a prática.

Durante a sua apresentação o Adalberto enfatizou bastante o desenvolvimento junto com a comunidade do portal, pois quem faz ele é justamente as pessoas que tem experiência na área de Teste de Software.

Impressões da palestra

A palestra cumpriu a sua proposta de divulgação do SPB e do portal 5CQualiBr, eu já tinha visto ambos antes, e tinha achado interessante a ideia. Sem dúvidas o SPB e seus portais são excelentes fontes de conhecimentos, agora se ele realmente se tornará um portal da comunidade, só o tempo dirá.

Erik van Veenendaal – Test Maturity Model

Erik Van Veenendaal, uma das maiores referências da nossa área, apresentou sobre o TMMi (Test Maturity Model integration), que como a própria sigla já deixa claro, é um modelo de maturidade voltado para a área de Teste de Software.

O Erik começou falando que existimos para prevenir que defeitos vão para o mercado e estamos sempre enfrentando desafios e eles estão sempre crescendo, alguns números a respeito disso:

• O número de software dobram a cada 2 anos na Philips, temos mais softwares para testar;
• O número de requisitos para celulares dobram a cada 6 meses, segundo a Nokia;
• Defeitos dificilmente reduzem.

E tendo ciência desses desafios fica claro a necessidade de fazer testes de forma mais eficaz e profissional. Ou seja, precisamos de testadores de classe A, e visando essa necessidade foi criado o TMMi.

Mas antes de falar sobre o TMMi, o Erik disse que há três direções que podemos falar sobre teste:

• Pessoas;
• Infra-estrutura;
• O processo de teste.

Um dos comentários mais legais que feitos pelo Erik foi quando ele disse que para melhorar os testes é necessário buscar uma melhoria nesses três pilares, não adianta apenas focar em um dos pilares. Ou seja, ele mesmo assumi que o TMMi em si, não é a solução definitiva, o que demostra o profissionalismo e preocupação com a qualidade do Erik, e ainda complementa dizendo que melhoria não é apenas processo é também pessoas e infra-estrutura.

A respeito de pessoas, há pelo menos quatro área de habilidades necessárias para um testador:

• Conhecimento em Teste de Software;
• Conhecimento em TI (estamos nos aproximando dos desenvolvedores);
• Conhecimento sobre domínio;
• Habilidades não técnicas: comunicação, pensamento crítico e apresentação.

Já sobre infra-estrutura, o Erik citou algumas práticas fundamentais:

• Requisitos bem documentados e gerenciados;
• Existência de um planejamento do projetos;
• Gerenciamento de configuração.

Alguns pontos interessantes levantados pelo Erik:

• Você precisa de um orçamento para fazer a melhoria do processo;
• O gerenciamento precisa de suporte de bons testes, lembre-se que qualidade é fundamental;
• É preciso compreender o porquê que você está fazendo a melhoria;
• Testar é dar informações sobre riscos.

TMMi

O Erik começou a sua explicação sobre TMMi Foundation, dizendo que ela é uma organização sem fins lucrativos. O TMMi é baseado no CMM e considera toda as práticas já existentes, suas origens são: CMMI, ISTQB, TMM, IEEE e TPI.

Assim como o CMMI, o TMMi é dividido em 5 níveis, lembrando que o primeiro é onde todas empresas estão no nível 1 (Inicial).

Os Cincos Níveis do TMMi (fonte)

O Erik acredita que o nível 2 é bom para todas organizações e necessário para lidar com os projetos atuais, sendo que para chegar nele, geralmente leva 2 anos, pois é o nível que provoca mais mudanças. Já para ir para o nível 3, costuma levar 1 ano.

Para se certificar é necessário pedir uma avaliação formal. No processo de implementação e avaliação temos dois papéis principais, o Lead Assessor e o Assessor, sendo que dentro dos conhecimentos para ser um Lead Assessor e um Assessor estão:

• Lead Assessor
  • 5 anos de experiência e ISTQB avançada;
• Assessor
  • 3 anos de experiência e ISTQB fundamental.

Na sequência o Erik falou mais especificamente do nível 2 e nível 3.

O TMMi nível 2 leva a redução de tempo e atingi mais a parte funcional. Estando no nível 2 você está de acordo com o que pedido pelo CMMI nas áreas de Verificação e Validação.

Já o nível 3 atingi mais a parte organizacional, e significa um envolvimento mais cedo dos testes no desenvolvimento do software.

As seguintes melhorias no testes, na perspectiva e engenharia, foram citadas:

• Teste mais profissional;
• Responsabilidades claras;
• Planejamento de testes;
• Teste baseado em riscos;
• Testes parte do ciclo de vida do desenvolvimento;
• Envolvimento cedo;
• Uso de técnicas de modelagem de testes;
• Controle sobre o processo de Teste de Software.

Alguns dos resultados que podem ser reportados pela área de teste são:

• Detecção dos defeitos;
• Tempo do lançamentos das versões;
• Desvio entre o tempo do gasto X planejado;
• Satisfação do funcionários.

Depois o palestrante falou sobre como podemos começar a implantação do TMMi, dizendo que:

1. Defina uma política de testes e obtenha aprovação da gerência.
2. Tenha ciência que melhoria é um projeto e calcule a porcentagem de recursos e esforço;
3. Implante a maturidade do desenvolvimento na organização.

Algumas dicas dadas pelo Erik sobre como ter implantar o TMMi:

• Faça pequenos ciclos;
• Você não vai mudar só pela mudança;
• Não responsabilidade as tarefas de melhoria para um consultor, pois ele irá embora, deixe isso para alguém da sua organização, a sua organização deve ser o impulso não a consultoria;
• “Institualize” as melhorias;
• Tudo tem haver com mudar a gerência;
• Revise os objetivos (política), de forma contínua;
• A sua melhoria tem que ser visando o negócio.

O Erik também apresentou o Manifesto da melhoria do testes:

• Flexibilidade, sob detalhados processos;
• Melhores práticas, sob templates;
• Orientado ao deployment, sob orientado a processo;
• Revisões, sob departamentos de QA;
• Guiado pelo negócio, acima do guiado pelo modelo;
• O melhor não é o melhor do mundo é o melhor no seu contexto;
• Definir processo é fácil, difícil é instituir esse processo para as pessoas.

Por fim o Erik finalizou dizendo que o TMMi é ótimo quando feito da forma certa, sempre dirigido ao negócio.

Impressões da palestra

O Erik é uma palestrante muito bom, conseguiu passar bem as informações, descontrair a plateia com algumas brincadeiras e atingir a proposta da sua palestra. Eu já tinha uma noção do TMMi, mas com a palestra ficou muito mais claro a sua proposta, seus níveis e os resultados que podem ser obtidos com a sua aplicação. Uma pena que ainda não existem Lead Assessors e Assessors no Brasil, o que dificulta a popularização dele no Brasil (enquanto isso podemos acessar o material disponibilizado no site do TMMi).

Encerro aqui a primeira parte do segundo dia do CInTeQ, até a segunda parte, onde estarei terminando a cobertura das palestras do CInTeQ.

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