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:
- Defina uma política de testes e obtenha aprovação da gerência.
- Tenha ciência que melhoria é um projeto e calcule a porcentagem de recursos e esforço;
- 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.
