Arquivo mensal: dezembro 2009

Gerente X Capataz

A motivação desse post ocorreu após assistir o vídeo do “Funk da Gerência” (será mais um hit do verão 2010, junto com o “Funk do Anel” rs) nesse excelente post do Rodrigo Panachi.

Pela minha experiência, a analogia do capataz não se encaixa muito quando analisamos bons gerentes. Eu prefiro mais a analogia dos gerentes como os donatários das capitanias hereditárias, afinal segundo a Wikipédia o donatário “constituía-se na autoridade máxima dentro da própria capitania, tendo o compromisso de desenvolvê-la com recursos próprios, embora não fosse o seu proprietário”, ou seja, bem próximo da realidade de um gerente.

Gerenciar não é só sobre controlar pessoas, até porque o modelo de comando-controle já está em declínio na área de TI, principalmente devido a explosão do Scrum nesse ano, ser gerente é saber lidar com as pessoas, saber negociar, liderar, pensar, agir, inspirar, motivar e a lista é longa.

Não é fácil ser gerente, e uma prova disso é que a maioria das pessoas no mundo não são nem gerentes das suas próprias vidas, quanto mais um dia terão capacidades de gerenciar uma área de Teste de Software, por exemplo.

O que leva a pensar que gerentes são meros capatazes é que ainda há MUITOS gerentes capatazes, e o pior é que muitas vezes tais gerentes pensam que são o dono da empresa, eles se iludem com as cifras que caem todo o mês na sua conta bancária, acham que são intocáveis e ainda pensam que chegaram no apíce de suas carreiras  e por isso param no tempo. E tais gerentes não são bons nem para a empresa em si, quanto mais para os seus subordinados.

Portanto, gerentes de plantão e aspirantes tomem cuidado para não serem capatazes. Busquem serem líderes, desenvolver o seu time, ser um intraempreendedor, ter uma excelente relação com os clientes, não parem de aprender e evoluir e entendam a sua empresa e o mercado.

Pra encerrar, segue o vídeo na íntegra da participação do Waldez Ludwig no programa Sem Censura, recomendo: 😉

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

O melhor da semana 20/12 a 26/12

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

O melhor da semana 13/12 a 19/12

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários. 🙂

Abraços! E tenham uma ótima semana!

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

Quando documentar não é preciso?

O tema da última Mesa Redonda DFTestes de 2009 foi “Quando documentar não é preciso?”, e teve 18 respostas e 7 participantes: eu, Felipe Silva, Milton Vopato, Sarah Pimentel, Rodrigo Almeida de Oliveira, Marcelo Andrade e o Eduardo Gomes.

A discussão foi bem produtiva, e ao longo dela novas dúvidas e assuntos foram abordados sobre documentação em geral. No próximo parágrafo começa o resumo da sétima mesa redonda, e mais uma vez, fica o convite para ler toda a discussão, caso o tema seja de seu interesse. 😉

Quando documentar não é preciso?

O Felipe Silva iniciou uma lista dos momentos que é preciso documentar, e depois eu adicionei dois itens a mesma:

  • Necessitar arquivar evidências;
  • Arquivar banco de conhecimentos (todos aqueles que servem como consulta para quaisquer tarefas);
  • O contrato obrigar;
  • Alta rotatividade na equipe;
  • Disseminar o conhecimento (nesse caso há outras alternativas também (como reuniões, trabalhar em par), mas a documentação é a forma menos volátil).

Uma segunda lista foi iniciada pelo Felipe Silva, com todos os documento que são necessários em qualquer projeto de testes e aqueles que podem vir a ser úteis em casos separados, e depois adicionei alguns itens:

  • Documentos necessários em qualquer projeto:
    • Casos de Testes;
    • Registro de bugs;
    • Relatórios.
  • Necessários? Vocês usam? Independente se usam, acham bom ter?
    • Cenários de Testes;
    • Plano de Testes;
    • Estratégia de Testes;
    • Especificação de Projeto de Teste;
    • Especificação de Procedimento de Teste;;
    • Relatório de Sumário de Teste;
    • Relatório de Incidente de Teste;
    • Log de Teste.
  • Outros:
    • Plano de automação de testes;
    • Estratégia de automação;
    • Relatório de Encaminhamento de Item de Teste.

Eu entendo que documentar serve para os seguintes fins (pensando em documentação de Teste de Software):

  • Ajuda o entendimento do sistema, quando você cria a documentação de Teste de Software, você entende melhor o sistema, e ainda abstrai as informações para o mundo de Teste de Software;
  • Compartilhamento de conhecimento com a equipe, se fizer todos os meus testes de forma exploratória como que uma outra pessoa poderá realizar os mesmos testes?
  • Transmitir informações para os stakeholders do projeto;
  • Gerar uma base histórica, que poderá auxiliar em futuros projetos.

E tudo depende da sua realidade, por exemplo: se o cliente não exige documentação de Teste de Software, você tem conhecimento do sistema sob teste e o prazo é curto. Você pode testar só de forma exploratória, sem documentar os seus testes, e poderá até mesmo passar os defeitos diretamente para os desenvolvedores (informalmente).

Lógico que o exemplo citado acima, não é muito correto e bem extremo. Só que nessas situações você precisa fazer escolhas, e entre garantir a qualidade do sistema sob teste ou garantir que todas as atividades do Teste de Software sejam cumpridas, eu fico com garantir a qualidade do sistema sob teste.

Eu não vejo nenhum problema em documentar, com tanto que essa documentação tenha alguma finalidade, documentar por documentar, é perda de tempo, e por consequência, perda de dinheiro.

Para o Milton Vopato:

A documentação dos testes é fundamental, para melhoria continua e além disso, pensando no dia a dia, para segurança da própria equipe de teste, pois é uma evidência de cobertura dos scenarios propostos.

A Sarah Pimentel compartilhou um pouco da sua experiência com documentação:

Já estive em um projeto de consultoria de testes, onde o nosso papel era analisar requisitos e casos de uso e gerar documentação para realização de testes por uma outra equipe.

Documentos gerados:

  • Casos de teste (obvio :))
  • Roteiro de testes (em que ordem devem ser executados os testes gerados)
  • Massa de dados (listagem de dados necessários para a execução dos testes)
  • Matriz de rastreabilidade de testes (o caso de teste gerado refere-se a que/quais caso de uso entregues pelo cliente)
  • Registro de desvios (gaps encontrados na documentação enviada)

Em um outro projeto o trabalho foi configurar uma ferramenta (no caso, Quality Center), gerar casos de teste para a aplicação, treinar a equipe de testadores (inclusive para fazer atualizações posteriores no teste).

E já trabalhei em projetos com um MONTE de documentação também. Isso pra dizer que “tudo é relativo” 🙂 O que importa é gerar o que vai ser útil e o que você consegue manter. Não adianta produzir toda a documentação do RUP se você não consegue mantê-la alinhada entre si e se o próprio time não a consulta.

O Rodrigo Almeida expôs a sua opinião dizendo:

Na minha opinião, documentar só por documentar não se justifica. Toda atividade num processo precisa gerar valor. Se não é só pedágio!

Existe um mínimo que é obrigatório no nosso processo hoje: O caso de teste e/ou uma evidência de teste e um relatório de painel de bordo das homologações.

Quando fazemos um projeto aí temos também o Plano de Testes.

Para o Marcelo Andrade, não é necessário documentar quando o documento:

  1. Não seja de fato útil, mas precise ser feito apenas por que o processo assim determina;
  2. Não é mantido atualizado (de certa forma, uma consequência do item 1);
  3. Não é compreendido pelas pessoas para quem ele foi escrito (outra consequência do item 1).

O Marcelo ainda comentou sobre documentos difíceis de serem compreendidos e compartilhou o link para um bom artigo sobre documentação:

Se sua equipe de desenvolvimento gera documentos difíceis de entender, que não atendam ao seu propósito, que estejam sempre muito defasados e não sejam efetivamente utilizados, isso não é valorizar a documentação. Longe disso. Valorizar a documentação é dar real importância aos documentos gerados, fazendo com que eles agreguem valor ao cliente e sejam usados de fato para apoiar o trabalho da equipe.

Volto a indicar este esclarecedor artigo do InfoQ sobre o assunto:

http://www.infoq.com/br/news/2009/08/agile-documentation

Outro link bem legal sobre documentação ágil, é esse abaixo, de um vídeo que o Vinícius Teles fez sobre documentação ágil:

http://blog.improveit.com.br/articles/2008/08/01/documenta%C3%A7%C3%A3o-%C3%81gil

O Eduardo Gomes compartilhou a sua opinião dizendo:

A necessidade de documentação é sempre motivo de debate e gera argumentações apaixonadas, tanto a favor como contra. Quando falamos da documentação dos testes, essa discussão fica ainda mais acalorada, pois muita gente entende que a documentação do sistema já é um “trabalho jogado fora”, quanto mais documentar os testes. É uma visão característica dos desenvolvedores, que estão preocupados em construir as soluções e veem na documentação um entrave ao seu trabalho. E em muitos casos isso é realmente o que acontece.

Mas se observarmos os modelos de maturidade de software, percebemos que a documentação é peça chave no esforço pela melhoria de processos e para a qualidade dos produtos. Sem uma documentação, automatizada ou não, dificilmente conseguimos atingir níveis satisfatórios de maturidade nos processos. Prefiro enxergar a documentação como um investimento e não como um trabalho jogado fora.

Quanto à documentação de testes, utilizamos atualmente, 04 artefatos básicos:

  • Plano de Testes (Escopo, riscos, estratégia, ambiente, intervenientes, aprovações, etc);
  • Roteiros de Testes (Casos de teste, massa de teste relacionada, especificidades do teste etc);
  • Relatórios de Testes (Resultados da execução dos testes, evidências, gestão dos defeitos etc);
  • Relatório Final (Resumo dos testes, pareceres, validações etc).

Esse conjunto completo de artefatos é aplicado somente sobre projetos, que possuem um escopo maior de teste e também outros artefatos relacionados ao desenvolvimento, que servem de insumo para a construção da documentação de teste. Em intervenções menores, somente os relatórios de testes são exigidos, principalmente para evidenciar os testes realizados, na maioria dos casos pelos próprios desenvolvedores. Mas tudo isso faz parte de uma estratégia de melhoria dos nossos processos, que deve alcançar níveis mais elevados de maturidade em breve.

Como tornar a documentação do Teste de Software eficaz?

O Felipe Silva acredita que:

As documentações devem ser efetivas, e sou favor de casos de testes diretos e objetivos – sem steps desnecessários à validação, sei que muitos vão discordar de mim, mas assim que é legal (gerar discussões).

Devemos sempre gerar apenas documentações que serão lidas, digo isso porque já vi casos onde são gerados vários artefatos só pra ficar no repositório (o contrato obriga) e no pior dos casos o próprio processo de testes da organização que diz que tal artefato – que não serve pra nada – deve ser gerado só para mostrar para o cliente, e piora, pois o sistema muda por alguma solicitação de mudança ou versão de requerimento nova e o tal artefato fica do mesmo jeito, nem quem escreve se importa em atualizá-lo pois sabe que ninguém irá usá-lo como base pra nada.

Eu vejo que esse é um grande desafio. Acho que o primeiro passo a fazer é listar quais documentos que estão sendo gerados pela equipe, e responder as seguintes questões (deve ter outras):

  • Qual o objetivo desse documento?
  • O documento está otimizado? (tem apenas os tópicos adequados para o projeto)
  • Alguma sugestão de melhoria para o documento?
  • Há alguma dificuldade em manter o documento? (ex.: mudanças de requisitos constantes)
  • Há alguma ferramenta que possa auxiliar a criação do documento?
  • O tempo levado para a criação do documento é o esperado?
  • O documento está armazenado em um local seguro e acessível?
  • As pessoas estão seguindo algum padrão para a criação do documento?
  • Quais são as pessoas que irão utilizar esse documento? A linguagem está adequada com esse público?

Um segundo passo é tornar a documentação “viva”, ou seja, automatização dos testes, sempre que possível e viável. 🙂

O Eduardo Gomes acredita que:

Qualquer documentação deve ser a mais simples possível, mas que permita o registro das informações que a organização considera imprescindíveis. E nessa análise cada organização deve definir sua documentação básica, mas deve também explicitar a seus colaboradores os objetivos a serem alcançados e as estratégias utilizadas, para que consiga da equipe o comprometimento e a motivação necessários. Sem isso, vai ser realmente “trabalho jogado fora”.

Durante a discussão a Sarah Pimentel colocou três novas questões para esquentar o debate.

Eu posso ao invés de criar test cases, basear meus testes nos requisitos ou user stories?

A própria Sarah respondeu dizendo que:

Essa é uma abordagem estranha pra mim. Me sinto mais confortável com a idéia da criação de uma documentação criada para o propósito de teste. Mas considerando que no caso de uso, requisito ou user story tem todos os fluxos (pode-se assegurar isso com revisões da equipe de teste), é uma documentação que poderia servir como base para testes…

Na minha opinião deixar de criar os casos de teste é um pouco perigoso nesses casos, e quando eu digo criar um caso de teste, pode ser tanto um manual (no Test Link), ou um automatizado (no JUnit, por exemplo).

Mas não vejo problemas em basear os testes nos requisitos, até porque eles são a fonte principal, quando escrevemos testes de aceitação, por exemplo. E as user stories dão uma visão geral da funcionalidade, mas só com ela como base, fica difícil explorar a árvore de possibilidades da funcionalidade, geralmente é preciso ter algum outro documento para apoiar ou conversar diretamente com o desenvolvedor.

E se ao invés de requisitos, documentarmos apenas os testes? Colocarmos as solicitações do cliente não como requisitos mas como cenários de teste? Perderíamos alguma coisa?

O pessoal que pratica BDD (Behavior Driven Development), costuma comentar que é possível utilizá-lo para detalhar os requisitos funcionais. Neste caso você já estaria documentando e escrevendo um teste (e a sintaxe do teste é bem fácil de entender, e há ferramentas, como o Cucumber, que até permitem escrever em português).

Acho que não iremos perder, mas corremos o risco de detalhar muito cedo as coisas. E nem sempre isso é possível, pois o cliente também poderá consultar os requisitos, futuramente, e se estiver em uma linguagem muito técnica, ele poderá ter dificuldade de entender.

Em uma abordagem TDD, como fica a criação de documentação de teste? Ela se torna dispensável em alguns pontos? Passa a ser apenas o Unit Test?

Eu vejo que a documentação passa a ser “viva”, pode ser executada a qualquer momento, e o desenvolvedor terá um rápido feedback se a funcionalidade que ele está desenvolvendo está ou não de acordo com a documentação criada (testes).

Em relação ao documentos gerados, normalmente, por uma equipe de Teste, acho que eles continuar existindo (até porque só estamos documentando os casos de testes de forma automatizada), principalmente, se houver uma equipe de Teste de Software no projeto. E ainda haverão os testes manuais, que necessitarão ser documentados, da forma tradicional. E a própria equipe de Teste de Software, pode deixar de criar um caso de teste no Test Link e automatizá-lo no Selenium, por exemplo, e mesmo assim, a equipe não está deixando de documentar.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

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

O melhor da semana 06/12 a 12/12

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

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

Utilização de Processos Ágeis no Teste de Software (SCRUM, XP, TDD…)

A discussão da sexta Mesa Redonda DFTestes foi sobre a “Utilização de Processos Ágeis no Teste de Software (SCRUM, XP, TDD…)”, discussão que gerou13 respostas, e teve 8 participantes: eu, Renata Eliza, Marcelo Andrade. Juliana Kryszczun, Felipe Silva, Ronaldo Cruz, Jorge Diz e o Vitor Machel.

Abaixo, segue um “resumo” do que foi discutido na mesa redonda, lembrando que é altamente recomendável, a leitura de toda a discussão caso você tenha interesse pelo assunto.

Metodologias Ágeis e Teste de Software, tudo a ver ou não?

Para o Marcelo Andrade, “não há como se seguir qualquer técnica dita “ágil” se não se tiver uma forte disciplina em teste de software” e ainda complementou dizendo:

Escrevi um post sobre isso há algum tempo no Blog do TaSAFO – http://tasafo.wordpress.com/2009/05/14/se-voce-nao-testa-voce-nao-e-agil/

Para simplificar, ao falar de testes, me refiro especificamente a testes de aceitação, uma vez que testes de unidade, a rigor, são parte do desenvolvimento de software. Assim, é importante levar a etapa de testes a sério, automatizar os testes, reforçar seu uso, etc. Um pensamento interessante que por acaso li hoje num post do InfoQ é que “automatização de testes de software É software”.

Enfatizo, entretanto, que se você não tem disciplina para conduzir seus testes adequadamente, de nada adiantará tentar “implantar agilidade”, com muito se diz. Isso me remete a outro tema proposto para a mesa redonda sobre como evitar o “Testa aí”, bem como também reforça uma opinião pessoal que tenho de que a palavra “ágil” é ruim, pois pode descambar muito facilmente para ser um mero termo mercadológico ou como marketing para empresas.

A respeito do que o Marcelo disse sobre a palavra “ágil”, acredito que o problema aqui é a interpretação das pessoas, e não a palavra em si. Quanto a ser um “mero termo mercadológico ou como marketing para empresas”, é fato mesmo, infelizmente, muitas empresas que antes diziam que utilizavam uma metodologia própria, agora dizem que usam metodologia ágil, pelo simples fato, de que está na moda ser ágil.

E outro ponto interessante, é que empresas que se dedicaram e se dedicam ainda, no estudo e no uso de metodologias ágeis, acabam sempre utilizando uma mescla das metodologias ágeis, e até alterando algumas coisas. Exemplo, a globo.com … ou seja, não existe a melhor metodologia, principalmente numa área tão volátil como a nossa.

A Juliana Kryszczun lembrou sobre o maior problema ao tentar implantar uma metodologia ágil:

O primeiro problema, na minha opinião, é a quebra de cultura. Estamos tão acostumados ao processo tradicional que ficaria um pouco complexo implantar um novo modelo de teste em uma equipe ‘velha’ e já definida.

O Felipe Silva ressaltou que o importante é o resultado a ser obtido com a mudança, se for melhorar vale a pena lutar:

O fato à ser considerado é, melhorar, melhorar e melhorar. Se existe algo, independente do nome, seja SCRUM, XP, LEAN, KAN BAN, e por aí vai, se isso for te acrescentar Benefício então vamos à “guerra”, mas não um contra o outro, porque senão “a casa cai”, mas vamos à guerra em equipe como um exercito, traça-se as estratégias, as táticas (ler A Arta de Guerra por Sun Tzu), analisa-se o terreno e o tempo, as fraquezas e as forças, conscientiza, motiva e integra os soldados no “problema”, o “problema” tem que ser de todos, uma vez o benefício também será de todos. Levantados os dados e os riscos é hora de marchar, repetindo e analisando a palavra “Marchar”, uma marcha é o exército todo em formação e alinhado cada um na sua posição dado passo à passo em sincronia, levantando e abaixando o pé ao mesmo tempo, seguidos pelas direções do general e pelo ritmo dos tambores, passo a passo (Não de uma vez, como tentam fazer alguns, que pensam que um processo novo cai de sem pára-quedas e irá funcionar), o general atento é quem observa se muda a direção ou o ritmo da marcha, ainda que esteja chovendo se o general diz “Marchem” assim deve ser feito para que se alcance o objetivo da estratégia traçada.

Para o Ronaldo Cruz para ser veloz, os testes são mais necessários ainda:

Claro que sim, uma vez que a elaboração de um produto tem de ser feita de forma mais rápida, os teste são ainda mais necessários, o risco de em meio a extrema velocidade se perder ou esquecer de alguma coisa é bem alto.

Segundo o Jorge Diz:

Sim: há uma grande sinergia. De fato, grande parte do (re?)nascimento do interesse em teste de software se deve à adoção de práticas de teste integradas ao desenvolvimento ágil. A comunidade ágil introduziu novos formalismos (ex: BDD, ATDD com planilhas, DSLs), novos mecanismos de isolamento de unidades  para teste (ex: test doubles/mocks), novas ferramentas (ex: JUnit) e, principalmente, novas formas de olhar  para os testes não apenas como mecanismos de controle da qualidade mas também como uma forma de especificação verificável mecanicamente, como forma de comunicação e como instrumento de gestão.

A automação cresceu em importância (inicialmente, talvez exagerada) e puxou avanços na tecnologia de testes  como nunca antes na história da nossa área.

Para o Vitor Machel é necessário que o Teste de Software se adapte a nova metodologia:

Sim tem tudo a ver, como qualquer processo de desenvolvimento de sistemas, mas não se pode ficar com o mesmo pensamento com metodologias tradicionais, tem que se enquadrar também.

Na minha opinião, boa parte das metodologias ágeis (para não falar todas), nasceram da prática, da tentativa de fazer coisas diferentes para tentar obter resultados diferentes, E dentre essas “coisas” diferentes, os profissionais perceberam que Teste de Software é essencial, pois ajuda a garantir a qualidade do produto, e perceberam também, o quanto é importante executar o Teste de Software o mais cedo possível, seja por meio da revisão, proporcionada pela programação em par, seja pela própria criação de testes unitários pelos desenvolvedores.

Scrum e Teste de Software combinam?

A Renata Eliza acredita que sim:

Acredito sim, que as “Metodologias Ágeis” e o Teste de Software têm tudo a ver.

Falando especificamente do SCRUM, não há quem diga que ele pode ser utilizado em qualquer área da vida?!
Por quê não no Teste de Software?

Um projeto que utiliza Scrum terá uma maior facilidade para responder às mudanças que podem ocorrer.

Focando nos princípios dos processos ágeis aplicados pelo Scrum, é possível enumerar centenas de motivos para implantá-lo.

O maior objetivo continuará sendo a garantia da qualidade dos sistemas, porém, através o Scrum será possível gerenciar de forma rápida os testes.

Os objetivos são melhores definidos e as tarefas demandadas de forma mais direta, com prazos que são cumpridos quase em sua maioria. O foco, que geralmente se perde em alguns projetos, é levado a sério.

A Renata ainda citou alguns dos benefícios da implantação do Scrum:

  • Verificar o andamento de cada projeto como um todo;
  • Permitir a detecção e remoção de riscos e impedimentos;
  • Oferecer uma estimativa mais apurada;
  • Controlar conflitos de interesses e necessidades;
  • Compartilhar o conhecimento entre a equipe.

O Ronaldo Cruz lembrou que é de extrema importância a atitude dos envolvidos com o projeto:

Sim. Na verdade, todo modelo de desenvolvimento combina com teste. A questão é o quanto as pessoas e empresas estão dedicadas em fazer as coisas acontecerem. De nada vale dizer que usa SCRUM, XP, RUP, abobrinha, chuchu ou cenoura, se a empresa e os envolvidos não estão realmente engajados em implementar o modelo e fazê-lo acontecer.

O Jorge Diz acredita que sim e complementa:

O conceito de pronto-pronto, aplicado às user stories, tem que incluir testes. Apesar de Scrum ser um framework de práticas de gestão, ele acaba puxando a necessidade da adoção de práticas técnicas que permitam  entregas com qualidade, o que puxa a necessidade de investir na garantia e controle da qualidade: as práticas técnicas de XP casam bem nesse contexto.

Um anti-pattern comum é ficar só nas práticas de gestão, ignorando os sinais evidenciados pelo choque de transparência proporcionado pelo Scrum (radiadores de informação, reuniões diárias, retrospectivas). A necessidade de melhoria de processo envolve necessariamente as técnicas que usamos para entregar software.

Assim, é impossível melhorar o produto de software sem mudar as técnicas de requisitos, de desenvolvimento,  de integração e de teste. Se não houver mudanças, a equipe não consegue dar vazão às entregas. Como disse Einstein, é loucura continuar fazendo as mesmas coisas e esperar resultados diferentes: os post-its na parede não possuem  superpoderes.

O Vitor Machel acredita que não:

Se pensar à risca, não porque teste de software por equipe de teste, não entra no conceito de SCRUM

Eu acredito que Scrum combina com qualquer tipo de projeto, desde para organizar uma faxina na casa com a família, até a construção de um foguete.
E para nós, um dos pontos mais importantes do Scrum, é trazer o cliente para próximo do time, seja esse cliente, ou melhor PO (Product Owner), interno ou externo.

Preciso seguir a risca a metodologia ágil ao implantá-la?

Segundo o Ronaldo Cruz:

Não. Como o próprio nome diz, é um modelo, um meio estruturado de executar o trabalho. Cada empresa tem sua particularidade, seja do projeto, dos funcionários, do cliente, da cultura em si. Você pega as praticas do modelo e as adapta ao seu ambiente.

O Jorge Diz compartilhou a sua opinião dizendo:

Não creio que exista “a” metodologia ágil. Aliás, uma das premissas embutidas no conceito de agilidade é a crítica contínua ao processo. De alguma forma, a agilidade é uma reação ao “the one right way¨ de Taylor, imposta por decreto, que sobrevive neste início do século XXI como o eufemismo “melhores práticas”.

Reformulando a pergunta, dada uma metodologia documentada (Scrum, FDD, XP, …) identificada com os princípios da agilidade, é necessário implementar de acordo com o livrinho?

Alguns (o Kent Beck do XP, por exemplo), dizem que sim, por causa da sinergia entre as práticas. Minha posição é que precisamos ter jogo de cintura, mas sem descaracterizar as práticas que fazem a dinâmica funcionar. Sempre existem limitações e precisamos contorná-las.

O problema é que, quando somos iniciantes, ainda não temos incorporados os conceitos de uma metodologia: só aprendemos de verdade fazendo, descobrindo o que é importante e o que é acessório, onde precisamos bater o pé e onde podemos ceder, o que funciona bem num certo contexto e o que precisamos evitar. Por este motivo é importante também, se possível, ter um acompanhamento de pessoas mais experientes durante o início de uma transição para a agilidade (sou suspeito para falar, porque faço esse tipo de serviço)

É bastante comum que as organizações que adotam uma nova metodologia façam adaptações não por restrições externas, e sim para evitar as práticas que mais mudam a forma de trabalho à qual estão acostumadas, por acomodação ou por medo da mudança. Isto é tão comum no Scrum que já ganhou um nome: “Scrum, but …”.

“Estamos fazendo Scrum, mas dispensamos as reuniões diárias”. “Estamos usando XP, mas não temos testes unitários”. Neste anti-pattern, muda-se o processo muito precocemente, descaracterizando-o. O resultado é que a chance de sucesso diminui drasticamente, e a metodologia em questão aparece mal na foto.

Para mim o by the book está LONGE de ser a melhor maneira de implantar algo, principalmente na nossa área. Adaptação é a palavra chave, e adaptação não é feita uma única vez, temos que está sempre evoluindo e melhorando, e para isso a adaptação é essencial. 🙂

O que o XP tem a ver com o Teste de Software?

O Jorge Diz fez uma bela explanação respondendo a questão, deixando bem clara a relação entre o XP e o Teste de Software:

Muita coisa. XP representou no início uma visão bastante peculiar em relação a teste de software. Simplificando:

Há os “testes do programador”, de um teor mais técnico, e que funcionam como apoio ao desenvolvimento: o desenvolvedor é o responsável. Precisam passar integralmente o tempo todo, e ser muito rápidos para não quebrar o fluxo de trabalho do desenvolvedor (na ordem de alguns segundos).

Há os “testes do cliente”, mais próximos do negócio, que ajudam a detalhar os requisitos funcionais, e que são de responsabilidade do “cliente presente”, representante dos solicitantes. Funcionam como testes de aceitação e precisam passar para que a user story seja declarada pronta.

As atividades de inspeção se fundem dentro da prática de trabalho em pares (“pair programming”). Esta  inspeção contínua “dentro do fluxo” é em geral mais eficaz que as inspeções tradicionais “fora do fluxo”  (estilos Fagan e Gibbs). Está ai um exemplo de prática que faz sentido dentro da dinâmica, mas que é  resistida por problemas culturais e políticos: não podemos simplesmente ignorar a necessidade de inspeções. Se não podemos implementar inspeções no fluxo, precisamos substituir por outras formas de revisão ou inspeção fora do fluxo.

É grande a ênfase na automação dos testes. Isto puxou uma série de inovações técnicas para tornar o teste possível no ritmo necessário para apoiar o desenvolvedor. Na cultura de XP, inicialmente não era dada tanta importância aos  testes manuais.

Mais recentemente, têm sido dada importância aos testes manuais, principalmente pela contribuição da escola de “context-driven testing” para testes exploratórios gerenciados.

Uma ressalva: TDD = “test driven development” é considerada uma prática de apoio ao desenvolvimento (design de API, principalmente) e não uma prática de teste. TDD é a junção de duas práticas: “test-first” (escrever o teste automatizado logo antes que o código sob teste) e “refactoring” (limpeza do código sem alterar o comportamento funcional, tal como validado pelos testes). Brian Marick propõe substituir a frase “TDD” por “example-driven development” para esclarecer este fato.

Como foram as experiências de vocês ao utilizarem processos ágeis?

O Ronaldo Cruz compartilhou a sua experiência dizendo:

Para mim foi muito boa. Tornou o trabalho mais fácil por ter uma interação maior com todos os envolvidos. Mas também exigiu uma mudança maior na postura. Qualquer membro da equipe, seja desenvolvedor, banco ou teste, tem de se tornar ágil. Sair da cadeira e correr atrás, seja para desenvolver a atividade de outro membro ou tirar duvidas de teste ou negócio, não importa, cada um da equipe precisa deixar de ser acomodado e se tornar pró-ativo, buscar a solução e ajudar os demais a concluírem as suas atividades. Na equipe em que trabalho, me tornei analista de teste, negócioe dou suporte ao pessoal do desenvolvimento.

O Jorge Diz compartilhou um pouco da sua experiência como consultor, citando os problemas da disciplina de testes neste contexto:

É comum as pessoas empacarem justamente por dificuldades na automação de testes no nível necessário para  suportar a agilidade. Alguns pontos de atenção:

  • Código legado difícil de testar;
  • Falta de disciplina de test-first por parte dos desenvolvedores;
  • Não domínio das técnicas de isolamento para testes unitários;
  • Investimento excessivo em testes frágeis (GUI), que pode diminuir a velocidade das atividades de teste;
  • Indisponibilidade de ambiente próprio para teste, onde a aplicação possa ser testada sob controle total da equipe de desenvolvimento/testes;
  • Testadores ainda perdidos numa nova forma de organizar as equipes (testador residente em vez de operário de uma fábrica de testes);
  • Dificuldade para satisfazer o pronto-pronto;
  • Resistência à programação em pares.

O Vitor Machel contou um pouco da sua experiência:

Totalmente satisfatórias, os documentos (NÃO SÃO TODOS) que só serviram para ir para o lixo, nem existe mais. O conceito que estamos usando é “faça somente documentos para usar e entregue o software funcionando”, dificilmente estamos trabalhando (tanto teste quanto desenvolvimento) depois das 18 e sábados e domingo, o que eu mais gostei. Em resumo aqui, todos estão aprovando, cliente satisfeito é tudo, o resto é resto.

Eu tive ótimas experiências e também experiências ruins. 🙂

Abaixo, algumas conclusões tiradas dessas experiências:

  • A cultura das pessoas e da organização é o que mais influencia a implantação de uma metodologia ágil;
  • A maturidade das pessoas também é um fator bastante influenciador, principalmente, em relação ao tempo que a implantação vai levar e como ela ocorrerá;
  • A comunicação é essencial, tanto interna quanto externa;
  • O PO é o cara (no bom sentido é claro), a sua participação é essencial para o sucesso do projeto;
  • As pessoas são o diferencial de qualquer projeto. As pessoas certas com domínio da tecnologia, conhecimento do projeto e determinação são capazes de resultados incríveis, e a adoção de metodologias ágeis potencializa esses resultados;
  • A metodologia utilizada pode ter dado certo em um projeto, mas isso não garante que ela também irá funcionar em outro;
  • Busque ter uma pessoa da área de Teste de Software, no seu time Scrum;
  • Antes de implantar uma nova metodologia, der treinamentos a respeito dela para todos;
  • Se algo deu errado, com certeza não é culpa da metodologia, e sim sua! 🙂

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

Acessibilidade – uma questão de qualidade de vida

Esta semana estou participando do primeiro Encontro Internacional de Tecnologia e Inovação para Pessoas com Deficiência (em breve as minhas impressões do evento no Ensinar).

E hoje tive o prazer de assistir o painel “Acessibilidade Digital e Governo Eletrônico”, no qual o Ricardo Kobashi, Assessor Técnico da Imprensa Oficial do Estado de São Paulo, foi o moderador do painel, e os participantes foram: Tânia Virginia, Superintendente de Operações do Poupatempo; Vagner Diniz, Gerente Geral do Escritório Brasil do W3C; e o Marco Antonio de Queiroz (MAQ), Consultor em Informática do Centro de Vida Independente Araci Nallin e autor do “A Bengala Legal“.

O ponto do painel que achei mais interessante e que abriu a minha visão em relação a acessibilidade e a sua importância na Web, foi a apresentação do vídeo abaixo, produzido pelo Acesso Digital:

A mensagem do vídeo é muito clara. A acessibilidade, não é uma frescura, ou detalhe, é uma questão de inclusão.

Vou utilizar o exemplo dado pelo MAQ, que perdeu a visão em 1978 com 21 anos, para ilustrar a mudança que o computador e a internet causaram na vida de uma pessoa cega:

Antes o cego precisava pedir para uma pessoa ler o jornal para ele. Hoje com o computador, a internet e o software de leitura de “tela” o cego consegue acompanhar as notícias de todo o mundo em tempo real sozinho.

Eu até às 16 horas de hoje, era totalmente ignorante sobre a relação do cego com a internet. E fiquei impressionado como a internet é uma tecnologia capaz de modificar a vida de uma pessoa cega. E profundamente incomodado com o fato de existirem sites que fornecem uma acessibilidade porca, e às vezes, nenhuma, como no caso dos sites feitos em flash.

O Ricardo Kobashi compartilhou a sua experiência em tornar os sites do governo acessíveis, projeto esse que começou com o site da Secretaria dos Direitos da Pessoa com Deficiência, e contou que eles pensavam que tornar um site acessível seria um processo muito complexo e caro, porém para surpresa de todos, tal processo se revelou simples e barato, e deixou o amargo fato: Poderíamos ter feito antes o site.

Ou seja, não é preciso investir milhões para tornar um site acessível, basta seguir padrões e estar de acordo com a lei: decreto 5296,  lei 10.098 e o Web Content Accessibility Guidelines (WCAG).

Portanto, nós profissionais de Teste e Qualidade de Software, devemos estar atentos a essas leis, padrões e boas práticas, e além disso, buscar sempre fazer testes de acessibilidade com pessoas com deficiência, e é importante, frisar que um site acessível, não é apenas para cegos, mas também para pessoas com deficiência motora, auditiva, etc.

E para encerrar, deixo abaixo uma frase que ouvi em uma das palestras de ontem, é que retrata muito bem a importância da tecnologia para as pessoas com deficiência, é mais ou menos assim:

A tecnologia tornar as coisas mais agradáveis para as pessoas, já para as pessoas com deficiência, a tecnologia torna as coisas possíveis.

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

O melhor da semana 29/11 a 05/12

Pessoal,

Segue abaixo, a lista com o melhor da semana, espero que gostem:

Você leu algo interessante, relacionado a área de Teste e Qualidade de Software, e quer compartilhar? Sinta-se à vontade em colocar nos comentários.  🙂

Abraços! E tenham uma ótima semana!

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

MPT: Melhoria do Processo de Testes

A quinta Mesa Redonda DFTestes foi sobre MPT – Melhoria do Processo de Testes. A discussão teve 13 respostas e 8 participantes: eu, Ueslei Aquino, Shmuel Gershon, Felipe Silva, Edwagney Luz, Robson Agapito, Wesley Baldan e o Wagner Duarte.

Na sequência, segue um resumo da discussão, quem quiser conferir a discussão na íntegra, pode acessá-la no DFTestes.

O MPT.BR

O Ueslei Aquino explanou sobre o que é o MPT.BR:

O MPT é um modelo que está em desenvolvimento, com o objetivo  principal será garantir que áreas de teste de software de tamanho reduzido possam ser avaliadas e estimuladas a alcançarem níveis maiores de maturidade, sem que para isso tenham que incorrer em altos custos de operacionais.

Este Modelo está sendo elaborado com base em algumas áreas de processo do MPS.Br e também com referências ao CMMI e PMBOK (para termos de projeto).

O modelo foi projetado inicialmente com 7 níveis de maturidade, mas possivelmente será alterado para 5 tornando-o assim mais leve que previsto anteriormente (está em fase de aprovação). Mas esta mudança aconteceria do Nível 4 em diante, ou seja os níveis até agora definidos serão mantidos (Nível 1 e 2). O Nível 3 está em fase terminal de desenvolvimento e o Nível 4 em Desenvolvimento.

No meu Blog tem um pequeno post sobre o modelo com sua estrutura inicial, com 7 níveis.

A estrutura com 5 níveis deve ficar da seguinte forma:

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

Atualmente 4 empresas encontram-se com processo de implementação do MPT nível 1 (GPT – Gerência de Projeto de Teste). Empresas como DataSus e iTeste (que provavelmente se certifica até o início de 2010), além de outras.

Ser certificado MPT vale a pena?

Segundo o Ueslei Aquino:

O modelo está em “gestação”, mas aqueles que gostam da área de processo e/ou pretendem investir nessa área, acho que é uma boa sim.

Por que os “selos” de qualidade e melhoria, são tão criticados hoje em dia, principalmente pelos agilistas?

O Ueslei Aquino acredita que:

Pelo fato de muitas empresas buscarem o selo apenas para serem melhor colocados em licitações mas depois que o avaliado vira as costas engavetam toda documentação e volta a vida normal. Implantar processo seguir práticas é um tanto quanto burocrático, se na organização não tiver o apoio da alta gerência para q tudo seja seguido nada funciona. Acredito que MPS resolveu essa situação colocando validade de 3 anos para a certificação, se uma empresa não se re-certificar sai da lista dos certificados em determinado nível.

Segundo o Shmuel Gershon:

Os agilistas não inventaram as críticas aos selos de qualidade… As reclamações são antigas, é só olhar para as críticas ao ISO9000 e ao Six Sigma.
Uma das limitações de todos os processos uniformizados, é, bem, a uniformidade do processo :). Como ele é estático e uniforme, quem tem que se adaptar é a empresa e os empregados. Empresas não são  uniformes, e elas são compostas por interações não uniformes entre pessoas não uniformes.
Empresas são diferentes, e programam software diferentes. O processo para tratar de qualidade é o mesmo em um produto web-based e embedded? Um controlador de equipamento médico e um administrador de conteúdo? Uma empresa com 700 empregados e uma com 7?
O comentário do Ueslei aparece como uma boa surpresa, pois o foco em “áreas de teste de software de tamanho reduzido” implica na fé de que existem contextos diferentes e o tamanho é um dos parâmetros – uma boa novidade na área de estandardização de processos, que tende a ver tudo como ‘tamanho único’.

Por outro lado:

a) O tamanho da empresa é um parâmetro fraco sobre seu contexto;

b) Comumente empresas com tamanho reduzido sentem menos a falta de processos do que grandes;

c) O comentário implica que tamanho reduzido resulta em níveis menores de maturidade

Sobre a limitação citada pelo Shmuel, acredito que é uma verdade, e o pior é como alguns profissionais encaram esses selos. Infelizmente, muitos ganham os seus uniformes (adorei essa analogia rs) e percebem que ficam bonitinhos com ele, daí então, a sua maior preocupação é deixar o uniforme bem limpinho.

Mas… e o cliente? ahh… ele terá uma primeira impressão muito boa da empresa uniformizada, e como dizem a primeira impressão é a que fica (ou não)

No entanto após um tempo, o cliente vai perceber que as aparências enganam.

O mais importante para qualquer fornecedor é atender bem o cliente, isso é tão “lógico”. Selos, certificações profissionais, etc são plus, primeiro você tem que comer o feijão com arroz, pra depois comer a sobremesa!

O Edwagney também fez um comentário sobre as colocações feitas pelo Shmuel, a respeito da padronização dos processos:

Excelente exemplo Shmuel,

Isso vem ao encontro de um texto que escrevi em meu blog sobre padronização com o título: “Padrão, todos nós deveríamos ter um.” (https://itqualityview.wordpress.com/)

Minha visão é exatamente essa. O ponto crucial de alguns processos de qualidade, e processos em geral, não darem certo em algumas organizações é que elas não lançam mão da sua cultura, da sua política, não usam o que tem de melhor. Não adaptam um determinado padrão aos padrões já existentes na empresa.nas empresas nas quais trabalhei, vi acontecer muito isso. A questão era: “Vamos implantar isso de qualquer forma.” Conhece o ditado: “Top-guela-down”? é mais ou menos por aí… 🙂

Usar padrões e processos faz parte da inovação e da melhoria da qualidade, porém, arrisco dizer que 80% do sucesso de um projeto nesse sentido, se ganha usando o lado bom do conhecimento e cultura da empresa.

Qual a posição do mercado em relação as empresas certificadas?

O Shmuel Gershon acredita que:
Em um primeiro momento, pareceria uma questão de oferta e demanda. É igual ISO9001… se a empresa vai perder mercado por falta de certificação, enão certamente vale a pena. Se a empresa consegue manter diferenciação comercial sem o certificado, então não vale a pena. Certo?
O único problema na situação descrita é que no caso de uma certificação sobre testes, quem cria a demanda são as próprias empresas certificadas.
Assim como nas certificações de indivíduos, existe tanta confusão ao redor do que testes e testadores fazem, que é fácil apresentar uma certificação e dizer “Aqui oh, não se preocupe, nos somos certificados, por isso somos melhores que a concorrência”. Ao criar a demanda, criamos um circulo vicioso aonde quem não se certifica fica pra traz.
No fim das contas, se uma empresa acredita que deve passar pelo processo de certificação, tudo bem, mas com cuidado e delicadeza…
É muito importante que o processo seja guiado por alguém (interno ou externo) que está atento as interações e os métodos implícitos no dia-a-dia, para que o processo não estraguem alguma área que já anda bem – ou para que o processo não esconda a realidade sobre uma área aonde existe incompetência.

No cenários em que a certificação representa um diferencial competitivo para a empresa, mas irá “atrapalhar” os processos internos da empresa, costuma haver uma grande resistência interna, um exemplo bem básico:

Se você é o Gerente de Teste e acaba de ser informado que a sua empresa irá tentar se certificar em um selo X, e sabe que isso irá trazer um grande impacto para o processo atual de Teste de Software, talvez você possa ser resistente a essa decisão, pois está olhando só para o seu nível.

Agora se você for analisar num nível macro a decisão, você poderá perceber que o selo X irá trazer grandes benefícios a nível de negócio para a empresa, podendo resultar em contratos importantes, que ir.

Moral da história: Precisamos sempre buscar ter uma visão ampla do nosso mundo. Para alcançar o sucesso, é necessário sacrifícios. (“O importante é termos a capacidade de sacrificar aquilo que somos para ser aquilo que podemos ser.” – Charles Dubois)

Para uma empresa cujo core business não é o Teste de Software, é interessante a certificação?

Para o Ueslei Silva:

Bom, se esta empresa usa SW e possui profissionais que testam o SW, acredito que sim. Trabalhei em uma empresa que mantém no mercado um grande ERP. A empresa possui uma fábrica de desenvolvimento de aproximadamente 70 desenvolvedores e um departamento de teste com 8 testadores, para o mercado seria interessante mostrar para os clientes que a qualidade do SW é assegurada por processos estabelecidos, maduros, etc. (eu era o gestor da área de testes, mas a empresa não estava preparada culturalmente para implantar um processo assim).

Para o Shmuel Gershon depende:

Uma possibilidade: Sim! – pelo menos vai ter um processo mais estruturado.
Outra: Não! Aonde existia incompetência caótica, agora existirá uma incompetência organizada e rigorosa. O problema desta última, é que agora ninguém mais percebe que tem que melhorar.
Ou ainda: Depende! Pode ser que o dono da empresa se sente inseguro e a certificação vai deixá-lo mais cordato para guiar a empresa. Ou pode ser que a equipe é madura o suficiente para não deixar a certificação ou o rigor do processo atrapalhar a operação. Pode ser que o gerente de testes não quer a certificação de jeito nenhum, e certifica-se vai criar rixas desnecessárias. Pode ser que a equipe é tão madura e com ótima performance que inserir as mudanças da certificação vai atrapalhar. Tudo pode ser.
A melhor resposta depende de cada empresa, gerente, líder e equipe. A equipe deve se conhecer o suficiente para escolher.
A respeito do caos citado pelo Shmuel, nessa semana ouvi uma história interessante, de um amigo meu, sobre uma grande empresa que estava se preparando para o CMMI:
Ele trabalhava na empresa XPTO, e essa empresa estava se preparando para o CMMI, daí o cliente X, pediu uma nova funcionalidade no sistema dele, esse cliente estava acostumado com o processo antes o CMMI, sabe aquele processo padaria? (me ver um pãozinho aí = me ver uma funcionalidade X), porém o Gerente do Projeto, não podia mais seguir o processo padaria, e para explicar isso para o cliente? rsrs (para não chorar)

Alguém já participou de uma avaliação, avaliando ou sendo avaliado? E poderia relatar a experiência.

O Ueslei Aquino compartilhou um pouco da sua experiência com o MPT:

Eu mesmo conduzi as reuniões de implantação das práticas do nível 1 na iTeste, num projeto em que o Cliente encontra-se na Bélgica, o Desenvolvimento na Índia e os Testes são feitos aqui no Brasil (RJ). Detalhes:(1) O desenvolvimento utiliza scrum e ja estava com 1 ano iniciado sem muitas documentações. Foi necessário mapear casos de uso para que os casos de testes fossem realizados; (2) A fábrica de Teste não Fala com o Desenvolvimento, a comunicação é direta com o cliente e este passa os bugs para o Desenvolvimento. Apesar de todo este cenário, o Projeto está andando muito bem e seguindo as práticas do MPT nível 1.

O Shmuel Gershon compartilhou a sua experiência com o TPI:

Eu participei de processos TPI (Test Process Improvements), e no meu departamento tiramos nossas próprias conclusões sobre o que ajuda e o que deveríamos ignorar. Também faço parte de um grupo para a discussão de metodologias, mas não seguimos nenhum processo público. Judy Bamberger foi uma das autoras do CMM, e ela escreve que “acredito que ele (o CMM) não foi concebido para ser usado de maneira em que determinada empresa tem que alcançar o nível X em determinado tempo, ou que a empresa precisar “ser” um certo nível antes que outros negociem com ela” (tradução minha). Ou seja, as documentações normalizadas de processos são apenas auxiliares, mas não devem dominar o procedimento.

A CQA

Para o Felipe Silva:

“A hora” de certificar-se é quando o ambiente está pronto. Fazendo uma analogia, a empresa é um quarto, pode estar bagunçado e cheirando mal ou arrumado e cheiroso, a certificação seria uma placa que você colocaria do lado de fora da porta “Quarto organizado”, dai já dá pra tirar as conclusões de quando tentar colocar a placa ou não e os impactos de tentar colocar a placa no momento errado, já pararam pra pensar se o cliente resolve abrir a porta e ver como está realmente este quarto por dentro e vê algo assustador?

O fato é, se o quarto está arrumado, por que não sinalizar isso ao mercado? Sim, vale a pena para a empresa estes selos.

A respeito do ponto de vista do Felipe Silva, o Shmuel Gershon fez o seguinte comentário:

Seu exemplo é muito bom, mas eu gostaria de adicionar que ele falha em perceber a limitação das certificações de processos. Por exemplo: Meu jeito de arrumar o quarto e o de minha esposa são diferentes, os métodos de trabalho e os critérios de qualidade de nos dois difere também. Porém, ela performa com rapidez e segurança no seu modo – e consegue encontrar qualquer coisa em um piscar de olhos.
Se eu criar a CQA (certificacao de quarto arrumado), ela terá que mudar seu modo de trabalho – o quarto vai ficar do jeitinho que eu quero (e defini na documentação)… Mas será que ela vai estar executando a tarefa com a mesma satisfação? Será que ela vai encontrar as coisas com a mesma agilidade agora que as roupas estão guardadas por ordem alfabética?
E, mais importante: Será que a imposição de um método não natural a sua personalidade não vai afetar uma serie de outras áreas que a CQA não mede? Ou que eu não percebi serem cruciais para  o bom funcionamento da família?
Enquanto o método de melhoria de processo de testes estiver aí para ensinar e guiar e deixar cada empresa criar seu próprio caminho para a excelência, maravilha. Mas ao tratar o conteúdo como uma ‘certificação’, o material acaba se tornando mandatório e standardizado – e o que pode ser bom para uma empresa pode ser perigoso para outra.
A resposta ao “vale a pena?” é “depende” – cada empresa e equipe deve analisar sua situação e necessidades.

Experiências com o MPS-BR

O Robson Agapito compartilhou a sua experiência com o MPS-BR:

Vou contar uma história verídica que aconteceu conosco na Mega em relação ao MPS-Br… estávamos procurando melhorar a qualidade de nosso produto, e buscamos o conhecimento oferecido pela Softex chegando então a certificação do Nível G… mas desde o início lutamos não pela certificação, e sim pela melhor qualidade e melhor controle de tudo que entrava (solicitações) pelos clientes e tudo que saia (melhorias e correções) do desenvolvimento/testes. E tínhamos em mente que a certificação seria uma conseqüência da melhoria de nosso processo.

Com certeza no inicio “travou” um pouco, mas com o andamento dos projetos e adaptações ao modelo proposto, melhorias foram identificadas durante o andamento do trabalho, e esta melhoria foi identificada por todos, inclusive pelos clientes que hoje sentem um produto final mais maduro e com uma melhor qualidade.

Então digo, o importante não é a certificação (claro que ajuda muito em uma venda), mas sim o conhecimento e a bagagem na melhoria da qualidade que conquistamos na implantação de processos para garantir a maturidade de nossos processos… a certificação foi conseqüência. Mas a cada dia batalhamos pela melhoria do processo, pois sempre podemos melhorar e jamais se acomodar.

Creio que o MPT vem para se tornar um apoio à todos da área de testes, ajudando a criar e melhorar processos de testes pelo Brasil, e futuramente pela América Latina.

O Wesley Baldan também compartilhou uma experiência com o MPS-BR:

Onde eu trabalho, foi um pouco diferente. Para obtermos o nível F (se eu não estou enganado, enfim, é o 2º nível) do MPS-Br a principal preocupação era com a aprovação, mas por conseqüência houve uma grande melhora… Claro, se está se preparando para obter um nível de qualidade as mudanças tem que ocorrer e por conseqüência há melhoras no produto final.

No começo foi muito difícil, porque antes era organizado, mas não tanto, então travava muito no começo o processo, mas depois de um tempo todos perceberam a melhora que aconteceu… É aquela coisa de quebrar a rotina, quando há uma mudança muitas pessoas não gostam.

Depois de obtido o nível, a empresa foi adquirida por outra e um dos pontos positivos da área de Desenvolvimento era a atenção com a qualidade.

Para encerrar o “resumo”, segue abaixo o comentário do Wagner Duarte, que levantou um ponto muito importante a atitude das pessoas, principalmente, dos que estão liderando a implementação:

Essa questão (mudança cultural) é e sempre foi um obstáculo na implementação de quaisquer melhorias e/ou mudanças em qualquer tipo de grupo.

Creio eu, que o problema não está apenas em quebrar paradigmas, mas principalmente no perfil daquele que propõem as mudanças.

Vejo hoje, que têm muitos “líderes” que não têm perfil ou apenas que não aprenderam algumas das boas práticas de um “bom líder”, para exercer tal atividade.

  • A forma em que a solução/mudança é proposta pode causar discordância e desmotivação dos membros da equipe;
  • Um “bom líder” tem que ter visão – para analisar um “Modelo” proposto e verificar o que se adéqua melhor à sua empresa/instituição;
  • Os membros que participam da implantação das mudanças/melhorias devem ter qualidade nas veias, para proporem ainda mais melhorias e não, contaminarem e desestimularem o restante do grupo, por não gostarem de mudanças e serem comodistas.

O ponto levantado, faz-se bastante pertinente ao dizer que “o MPT diz o que deve ser feito e não como”, ou seja, isso o torna um modelo proposto que, para se  alcançar um determinado nível faz-se necessária a implementação/modificação de uma metodologia. Porém, como a empresa fará para se atingir o nível esperado, depende muito do “líder” que conduzirá o movimento.

Se você quiser saber mais sobre o MPT.BR, recomendo o blog do Ueslei e a página oficial do MPT.BR.

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