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 5296lei 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.