Testing Day III

O pessoal do Sul está mandando ver nesse mês de setembro, mais um evento será realizado, e pela grade me parece ser muito bom.

O Testing Day é uma iniciativa de compartilhar conhecimento, a Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS), as empresas Dell Computadores do Brasil, HP Brasil, Stefanini IT Solutions e Zero-Defect Test House, se uniram para promover o intercâmbio de informações e experiências na área de Teste de Software entre a academia e as empresas envolvidas no processo de desenvolvimento, a fim de gerar debates e fomentar o progresso da área.

A terceira edição do evento ocorrerá no dia 14/09/2010 das 13:00 às 21:30, no Auditório da Faculdade de Informática (Prédio 32 – Térreo) da PUCRS.

Maiores informações podem ser obtidas no site oficial do evento:

http://www.pucrs.br/eventos/testingday

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

Anúncios

3° Seminário Catarinense de Qualidade e Teste de Software

O 3° Seminário Catarinense de Qualidade e Teste de Software será sediado em Blumenau, na FURB. O evento está sendo oferecido pela Qualister, empresa que atua na área de Qualidade e Teste de Software e com apoio da ALATS.

O seminário irá ocorrer nos dias 17 e 18 de setembro de 2010. Maiores informações podem ser obtidas no site oficial:

http://www.scqts.com.br/

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

3º Encontro Mensal do Interior – Regional Sorocaba

Pessoal,

Quem mora em Sorocaba e região já deve conhecer o Encontro Mensal do Interior, organizado anteriormente pelo Robson Agapito e André de Oliveira, ex-membros da ALATS-SP. Agora os dois, junto com o Alexandre Marketti e a comunidade Testadores estão realizando mais uma nova edição do evento.

Desta vez o encontro terá a Renata Fidelis, palestrando sobre “O que é o SCRUM e como adaptar o processo de teste de software para o seu uso”.

O encontro será realizado no dia 24 de junho (uma quinta-feira) das 19:30 até às 22:00 no auditório da UNIP-Sorocaba.

As inscrições podem ser feitas gratuitamente até o dia 23 de junho,  sendo que as vagas são limitadas (50 vagas).  E no dia do evento é necessário levar 1 Kg de Alimento não perecível entregue no dia, que será doado para um instituição carente.

Maiores detalhes do evento podem ser obtidos no link abaixo, para o folder do encontro:

http://bit.ly/3EncontroMensalDoInterior

Você pode também acessar a página do evento no LinkedIn:

http://events.linkedin.com/3o-Encontro-Mensal-do-Interior-Regional/pub/348010

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

Como ser produtivo? Contando tomates

Ontem realizei uma apresentação com o título “Como ser produtivo? Contando tomates”. A palestra foi feita no 2º Desembucha Aí!, um evento que ocorre aqui na Voice Technology, no qual são realizadas palestras rápidas, de no máximo 25 minutos sobre determinado tema.

O objetivo dessa palestra foi apresentar em 1 pomodoro, o que é a técnica Pomodoro e como ela pode te ajudar a ser produtivo.

Abaixo, compartilho a apresentação utilizada no evento:

Muito obrigado a todos que estiveram no evento! 🙂

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

2º Encontro Mensal do Interior da ALATS-SP Regionais Itu/Sorocaba

Pessoal,

No dia 8 de abril (próxima quinta-feira) das 19:30 às 22:00 o André de Oliveira, estará palestrando sobre “Processo de Teste de Software apoiado por ferramentas Open-Source.” na FATEC Sorocoba. A palestra faz parte do 2º Encontro Mensal do Interior, e é uma iniciativa dos membros da ALATS-SP.

Segue abaixo, maiores informações do encontro retiradas da página da ALATS-SP:

Data:08 de abril de 2010 (quinta-feira)

Horário: 19h30min – 22h00min

Local: FATEC – Sorocaba – Av. Engenheiro Carlos Reinaldo Mendes, 2015, Alto da Boa Vista.

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: Processo de Teste de Software apoiado por ferramentas Open-Source.

Conteúdo:

  1. Processo de Teste de Software
  2. Planejamento e Especificação de Testes
  3. Ferramentas de Planejamento e Especificação de Testes
  4. Ferramentas de Execução de Teste de Software
  5. Gestão de Defeitos
  6. Ferramentas de Gestão de Defeitos
  7. Geração de Métricas e Relatórios

Agenda:
19h30min – Credenciamento e networking entre os participantes
20h00min – Palestra sobre Teste de Software
21h15min – Encerramento e Confraternização

Palestrante: André de Oliveira, graduado em Processamento de Dados pela Fatec Sorocaba, com especialização em Engenharia de Software pela UNICAMP. Atua á 5 anos na área de informática, sendo destes 2 anos e meio como Analista de Sistemas Responsável pela Qualidade de Software da Agiw Sistemas na cidade de Sorocaba, empresa desenvolvedora de ERP. É Diretor Regional Adjunto da ALATS-SP e certificado CBTS (Certificação Brasileira de Teste de Software).

Inscrições:
– Palestra Gratuita
– Até o dia 07/04/2010
– Vagas limitadas (30 participantes)

A participação na palestra Vale 2 PDTS para a renovação da CBTS.

Reserve pelo e-mail dra_sor_itu@hotmail.com com o assunto: ALATS SOROCABA (necessário enviar o nome, empresa, cargo e data de nascimento para cadastro)

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

Cobertura CInTeQ 2010 – Conclusão

Após relatar como foram as 13 palestras 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, chegou a hora de compartilhar as minhas conclusões sobre o evento.

Abaixo, listo o que achei de bom e ruim no evento:

  • Bom
    • Organização do evento – nem parecia que o CInTeQ estava na sua primeira edição. O pessoal da organização fez um trabalho impecável ao meu ver;
    • Local do evento – embora para eu chegar até o Hotel Caesar Business São Paulo Faria Lima, não seja a coisa mais fácil do mundo, o mesmo fica bem acessível para outras pessoas e principalmente, para aqueles que vieram de outros estados e desembarcaram em Congonhas (6 quilômetros até o hotel);
    • Infraestrutura – excelente a infraestrutura do hotel, todos os participantes ficavam sentados em mesas, o que facilitava a locomoção das pessoas (sabe quando alguém que sair e incomodar todo mundo da fileira de cadeiras rs) e oferecia mais conforto para aqueles que levaram notebooks/netbooks;
    • Palestrantes – sem dúvidas o ponto mais positivo de todos era o nível dos palestrantes, a maioria eram palestrantes de altíssimo nível, como por exemplo Rex Black, Dorothy Graham e Erik van Veenendaal e os nacionais também eram muito bons;
    • Palestras – na minha opinião, de nada adianta bons palestrantes se a temática da palestra for fraca, e isso não ocorreu no CInTeQ. Acredito que a grade de palestras foi o segundo fator que mais motivou a vinda das pessoas (o primeiro foram a vinda do Rex Black, Dorothy Graham e Erik van Veenendall), a maioria das palestras eram sobre temas bem pertinentes e atuais da nossa área;
    • Tutoriais – mesmo não participando de nenhum dos tutoriais, vi que todos são excelentes também, o Elias fez o sobre Automação de Testes, ministrado pela Dorothy e achou muito bom;
    • Continuação do CInTeQ – fiquei muito feliz ao saber que o CInTeQ passará a ser anual, ocorrendo sempre na última segunda e terça-feira do mês de março. Isso é excelente para a nossa área e possibilita as pessoas que não puderam participar nesta edição, a participar das próximas;
    • Apresentador – por último, mas não por isso menos importante, o apresentador do CInTeQ fez um excelente trabalho, o Felipe Mello disse muitas coisas importantes e pertinentes a nossa área, mesmo não sendo dela (rs), uma delas que acho que não falei ainda, é a relação entre Teste de Software com a humildade, pois testar é ser humilde, é aceitar que você pode ter errado, que o trabalho feito pode não está tão bom. Além disso, as intervenções feitas pelo Felipe Mello eram sempre com muito bom humor, o que garantiu momentos de boa descontração.
  • Ruim
    • Preço – bem esse é um ponto que depende muito da pessoa, pois o caro varia de pessoa para pessoa. Eu particularmente, achei o preço do evento bem caro, e por causa disso nem iria participar dele (só participei graças a um convite do José Correia). E conversando com outras pessoas da área, elas também reclamavam do preço da inscrição. Lógico que para fazer um evento do porte do CInTeQ, trazendo grandes palestrantes e num excelente local, o preço costuma sair salgado mesmo. Mas no fim, o preço do evento não acabou sendo um grande problema, uma vez que o auditório estava lotado (no primeiro dia não tanto, mas no segundo estava sim), mais de 250 pessoas participaram (dados não oficiais).
    • Divulgação – não sei se isso aconteceu com todos, mas eu recebia quase todo dia o folder de divulgação do evento, já estava quase criando um filtro (rs). Além do mais, um evento tão bom quanto o CInTeQ poderia ser divulgado em outros canais, como por exemplo em revistas como a Info (eu deixei essa sugestão para eles);
    • Almoço – calma, não é que o almoço era ruim, muito pelo contrário, foi muito bom, o ruim foi ter almoçado de pé, ou sentado em um sofá. O almoço ocorria no foyer do Hotel, onde não haviam mesas, apenas alguns sofás e aquelas mesas altas de café.

Sem dúvidas valeu muito a pena ter ido no CInTeQ 2010, além de ouvir palestras excelentes, pude conhecer novas pessoas e conversar com algumas que só conversava pelas listas e pelo MSN (rs).E além disso, o evento trouxe um mar de informações (eu ainda estou processando elas rs), que ampliaram a minha visão sobre a nossa área.

Parabéns ao BSTQB pela organização e a Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal por terem patrocinado o evento, e que juntos tornaram possível a realização desse excelente evento!

E nos vemos em 2011! 😀

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

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.