Arquivo mensal: julho 2010

Não se limite

Ontem participei de um treinamento sobre Scrum na empresa, ministrado pelo Rodrigo Yoshima.

O treinamento em si é excelente, com bastante prática, temperado com a visão lúcida do Rodrigo sobre desenvolvimento de software.

Quando o Rodrigo falou sobre o time no Scrum, ele enfatizou que as pessoas podem até ter uma função específica, onde possuem mais afinação e experiência, mas elas não devem se limitar a exercer apenas as tarefas associadas a essa função. Por exemplo:  ahh… eu sou testador, então eu só testo. Um time ágil necessita ser multidisciplinar.

Na minha opinião, o profissional deve ter muita prudência ao buscar uma especialização em determinada área/função, pois a especialização pode acaba se tornando um problema para o profissional.

No entanto, isso não significa que o profissional não pode buscar conhecer mais afundo uma determinada área, principalmente se for uma área que ele tem mais afinade e prazer em atuar.

A especialização da qual não gosto, é aquela cega, onde a pessoa abaixa a cabeça e só quer saber de estudar e/ou trabalhar em determinada área. Na minha opinião isso é um desperdício de potencial humano.

E o grande problema é que nós somos condicionados a especialização. Afinal, a nossa geração foi fortemente influenciada pela fase industrial, na qual a especialização era bem vista e necessária, pois boa parte dos profissionais atuavam em tarefas manuais, que exigiam conhecimentos específicos e eram exercidas durante toda a carreira do profissional.

Mas hoje na fase pós-industrial

Muita coisa mudou desde daquela época onde as linhas de produções ainda eram compostas por homens, mulheres e até crianças, que trabalhavam muito mais do que 8 horas diárias. Principalmente no que tange a expectativa de vida. Hoje vivemos MUITO e o bastante para que possamos fazer umas três faculdades e atuar em áreas bem diferentes entre si, se quisermos.

E no nosso caso, atuamos num mercado onde a grande moeda de troca é o conhecimento e por isso precisamos estar sempre atualizados, pois caso contrário, podemos nos tornar profissionais obsoletos.

Lógico, que ainda hoje a especialização é importante em várias outras áreas, por exemplo na Medicina. Porém, na área de TI há uma forte tendência para que os profissionais de TI, se tornem especialistas generalistas.

Putz Fabrício, você está ficando louco! A especialização é fundamental, o mercado demanda de profissionais especializados, essa coisa de especialista generalista é besteira.

Bem se você acha isso, recomendo fortemente a leitura desse artigo e o vídeo abaixo:

E não é só isso, hoje se formos olhar as vagas em empresas como Google, Yahoo! e ThoughtWorks (só para citar algumas), iremos ver que o perfil que pedem é justamente o de especialistas generalistas!

Por favor, não se limite

Isso é sério. Por favor, não se limite!

O ser humano tem uma capacidade incrível, porém somos condicionados a subutilizar as nossas capacidades.

E como não se limitar?

  1. Fazendo o que você gosta. Isso é essencial, pois você irá evoluir muito mais rápido na área e geralmente, será natural não se limitar a apenas uma função específica;
  2. Buscando novos conhecimentos (não apenas na sua área de atuação). E é bom estar preparado, pois nessa busca há um alto risco em você se interessar por outras áreas, que antes você não tinha o mínimo interesse ou era totalmente ignorante.

Por que não me limitar?

Tentando ser objetivo: porque hoje a nossa expectativa de vida é muito alta, e por isso temos mais tempo para explorar as nossas capacidades.

Sendo prático: porque o mercado de TI está cada vez mais demandando de profissionais especialistas generalistas. Mas tome cuidado para não se tornar um pato. 😉

Sendo realista: há tantos fatores e pessoas que nos limitam, que nós mesmos não podemos nos limitar. Pisa fundo!

Pra encerrar deixo uma frase do Oscar Wilde, que nos provoca, e faz pensar que podemos tirar muito mais de nós mesmos, e um bom começo para isso, é não se limitar.

Viver é a coisa mais rara do mundo. A maioria das pessoas apenas existe.

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

O melhor da semana 18/07 a 24/07

Pessoal,

Com um pouco de atraso, segue abaixo o melhor da semana:

Conhecimento a um clique, esse é o QualidadeBR 🙂

Abraços! E tenham uma ótima semana!

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

Até tu, brutus?

Sempre tive uma curiosidade para saber de que forma empresas como Apple e Sony desenvolvem produtos com tanta qualidade. Ao nível de muitos adquirirem os seus produtos, mesmo esses custando bem mais do que os concorrentes.

Logicamente que ambas empresas não são “perfeitas” e muito menos os seus produtos. E isso ficou bem claro no ano passado com a falha no PS3 e mais recentemente com o problema da antena do novíssimo iPhone 4.

Não vou falar sobre essas falhas (embora no final eu não resista, e faça uma “análise” da falha da antena do iPhone 4), afinal muito já se falou sobre a falha no PS3 e mais ainda estão falando do problema da antena do iPhone 4.

O que quero falar é sobre esse mega investimento que a Apple fez para testar a antena do iPhone 4, que mesmo assim acabou dando problema.

Testar uma antena de um iPhone não deve ser um dos testes mais fáceis de se fazer, principalmente, testes de desempenho. Afinal, o número de cenários que é preciso simular são muitos e tais simulações não são fáceis de serem feitas.

Para tanto a Apple investiu 100 milhões de dólares (isso mesmo 100 milhões!!!) para poder construir 17 câmaras anecoicas, onde é testado o iPhone.  Nesses laboratórios se consegue simular estações de celular, redes Wi-Fi, aparelhos Bluetooth e até satélites de GPS.

Se você quiser saber mais sobre esses laboratórios de testes da Apple, acesse o link abaixo, onde tem maiores informações e um vídeo mostrando como são esses laboratórios:

http://www.apple.com/antenna/testing-lab.html

Puxa, Fabrício! Muito legal esse laboratório, mas como que mesmo com toda essa infraestrutura, uma falha tão “grotesca” acabou acontecendo”?

Eu diria que errar é humano, ou melhor, shit happens (rs).

Alguns estão falando que um engenheiro da Apple já tinha avisado o Steve Jobs, que o design do novo iPhone prejudicava a recepção do sinal. Portanto, aí seria devido a uma falha estratégica, não sei se do próprio Steve que bateu o martelo, ou de um grupo de pessoas, que decidiu lançar o iPhone 4 mesmo assim.

Não tenho um iPhone 4, portanto não posso dá uma opinião mais precisa, mas pelos relatos que li, parece que a falha de perder o sinal ocorre dependendo da forma que a pessoa segura.

hmmm… então, você acha que eles acabaram não realizando tantos testes em campo, ou melhor, na rua mesmo, com pessoas diferentes?

Exato, essa é uma possibilidade bem plausível, que pode nos ajudar a entender porque tal falha foi só detectada em “produção”. No vídeo do site da Apple, vi que os testes são feitos com o aparelho sozinho numa “pilastra” e alguns com o engenheiro segurando o aparelho. Mas não vi nenhum teste com usuários de verdade (tirando os que o pessoal do Gizmodo fez rsrs).

Ou seja, me parece que a Apple investiu tanto ($$$) em um super laboratório de testes e acabou se esquecendo de fazer testes mais simples e baratos (se pedissem para eu fazer um teste beta do iPhone 4, faria sem nenhum problema rs).

E a lição que podemos tirar de tudo isso, é que não podemos esquecer de incluir a “variável” usuário nos nossos testes, pois de nada adianta você testar com as mais variadas frequências de rede o iPhone e não testar com usuários de verdade. Afinal,  perder o sinal do seu novíssimo iPhone 4, só porque você está segurando ele de uma forma diferente da que o engenheiro estava segurando nos testes, não tem cabimentos  #epicfail (mas veja o lado bom, o seu iPhone ainda faz boas fotos e vídeos rs – ahh… bem que a Apple poderia dá cartões telêfonicos para quem comprou um iPhone 4 haha).

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

Fonte imagens:

http://www.apple.com/antenna/testing-lab.html

O melhor da semana 11/07 a 17/07

Pessoal,

Temos duas estreias hoje no “o melhor da semana”. A primeira um post muito bom do Flávio Steffens sobre uma técnica de prototipação, a Story Writing Workshop. Para quem não sabe, o Flávio e a sua equipe iniciaram no mês passado a Start-up Woompa, cheios de energia e compartilhando o que estão aprendendo no blog da Woompa.

A segunda estreia é o post bem completo sobre Plano de Teste da Renata Eliza e da Vivian Lagares, que estrearam na semana passada o blog As Especialistas, voltado para a área de Teste de Software.

Conhecimento a um clique, esse é o QualidadeBR 🙂

Abraços! E tenham uma ótima semana!

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

Você precisa de Agile?

Parece que de repente, “todo mundo” começou a buscar ser ágil.

A primeira vista isso pode até ser visto como bom, uma vez que vários métodos ágeis são bem mais sensatos do que os métodos tradicionais. Porém, infelizmente, muitos estão apenas indo na “onda do Agile”, e esses correm um alto risco de morrer na praia.

Por experiência própria, posso dizer que Agile não é pra qualquer empresa/equipe.

E dentre as várias coisas que aprendi (a duras penas), foi que nem sempre precisamos de Agile, ou melhor, nem sempre o que mais precisamos é Agile.

Para ilustrar esse aprendizado, vou utilizar o exemplo da famosa XPTO Solutions.

A XPTO Solutions também conheceu o Agile, por meio de materiais de terceiro é claro (uma dica: busque primeiro o conhecimento da fonte original). E após ver que os seus concorrentes já estavam utilizando métodos ágeis, decidiu adotar também. E como a maioria, começou com Scrum.

No começo tudo parecia uma maravilha, vários post-its coloridos na parede, o gráfico burn-down correndo bem, etc. Porém, após algumas sprints, percebeu-se que tinham finalizados várias funcionalidades, porém nada tinha ido para a produção, e nem o cliente tinha visto o software que estava sendo desenvolvido, pois estava distante, e o máximo de participação que ele tinha na sprint, era feita por e-mail ou telefone com o Scrum Master.

Outro problema que apareceu, foi que muitas tarefas eram retrabalhos e resoluções de bugs, pois eles não faziam testes unitários e 70% dos desenvolvedores ainda eram juniores, e não conheciam práticas como TDD e ainda não tinham uma base sólida na linguagem de programação que é usada na XPTO.

O problemas que aconteceram na XPTO não são incomuns. E se formos analisar muitos desses problemas não têm nenhuma relação com o Agile, e iriam acontecer independente da metodologia utilizada.

Problemas como equipe inexperiente, cliente distante, gestão de conhecimento ineficiente, falta de motivação, acomodação, etc são comuns em qualquer empresa. E a solução ou medidas que poderiam amenizar os seus efeitos não estão numa metodologia de desenvolvimento de software.

Por isso que eu enfatizo, que antes de implementar Agile, precisamos analisar o ambiente a nossa volta, assim como um agricultor verifica o terreno para saber o que pode plantar nele. Não adianta forçar ser Agile, o seu desenvolvedor não irá testar só porque agora é Agile, o seu cliente não irá participar mais e/ou aceitar o contrato de escopo negociável, só porque agora a sua empresa é Agile.

E é bom lembrar, que Agile não é um fim, e sim um meio para você construir software com mais eficiência e qualidade, ter uma equipe mais motivada e um cliente mais satisfeito.

É importante ter em mente, que Agile não é apenas uma questão de mudança de hábito, mas também cultural . Vários paradigmas precisam ser quebrados quando implementamos Agile, e alguns deles já foram quebrados por pessoas como o Ricardo Semler, muito antes do Manifesto Ágil surgir, como por exemplo: uma participação mais democrática da equipe no dia-a-dia e nas decisões da empresa e valorizar mais pessoas do que processo.

Podemos fazer uma implementação de Agile de forma mais harmoniosa e sensata, ao buscar saber o que realmente precisamos antes do Agile em sí, uma vez que muitos dos problemas que enfrentamos, não estão relacionados com a metodologia que está sendo usada. Lembre-se, que “para que a semente dê frutos, é necessário preparar a terra.”

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

Fonte imagens:

http://bit.ly/aevP0r

http://bit.ly/c2t8zd

http://bit.ly/a8Y15t

Teste de Software: resultado da imperfeição

Ontem comecei a ler o livro “O Ócio Criativo” do Domenico de Masi. E logo no começo, em uma das perguntas feitas pela entrevistadora Maria Serena Palieri ao de Masi, ele traz um insight muito interessante, no qual valoriza as imperfeições do ser humano.

Para entender melhor, reproduzo abaixo o trecho do livro em questão:

Quais foram, então, os momentos da História nos quais nós, seres humanos, atravessamos encruzilhadas, vimos que o mundo virava de cabeça para baixo, se torna “um outro” mundo?

Um primeiro longo período da história humana vai de setenta milhões a setecentos mil anos atrás. Durante esse período, quem vivia não percebia nenhuma mudança, se sentia sempre igual. Trata-se da longuíssima fase na qual o homem criou a si mesmo: aprendeu a andar ereto, a falar, a educar a prole.

Se refletirmos bem, estas são mudanças extraodinárias, todas elas decorrentes da compensação dos nossos defeitos. Rita Levi Montalcini explicou isso muito bem no seu livro L’elogio dell’imperfezione (O elogio da imperfeição). Tínhamos um olfato fraco, portanto não podíamos perseguir a caça farejando a terra, como fazem os animais, mas tínhamos que avistá-la: para isto devíamos caminhar de pé, já que a caça frequentemente fugia, desaparecendo na vegetação. Isto fez com que se tenham salvado somente aqueles indivíduos da nossa espécie que se tornaram mais aptos para caminhar eretos.

Tal fato nos faz entender melhor o surgimento de várias áreas e tecnologias. E uma das áreas decorrentes da imperfeição humana, é a de Teste de Software.

Todos conhecem aquela frase que diz que “errar é humano”. E a probabilidade da ocorrência do erro ainda pode ser maior dependendo do ambiente em que estamos inserido. Sendo que quando falamos de um ambiente de desenvolvimento de software, logo lembramos de palavras como: prazo, complexidade, pressão, dentre outras.

Portanto, os profissionais de TI acabaram ao longo do tempo, percebendo a importância de se testar o software, sendo ela uma ação derivada da imperfeição humana. Afinal, seria um desperdício de tempo e esforço testar algo produzido pelo ser humano, se ele fosse perfeito.

É interessante notar, que graças as nossas imperfeições, fomos forçados a nos adaptar melhor ao ambiente em que vivemos e ao longo da história da humanidade, grandes inventos foram feitos, justamente para tentar contrapor tais imperfeições.

Voltando ao texto do livro, podemos interpretar que ao aprender a andar ereto, diminuímos os riscos de não conseguir comida. E pensando no mundo do desenvolvimento de software, o Teste de Software acaba também diminuindo riscos, no caso, os riscos associados a qualidade do produto/serviço que iremos entregar ao cliente.

E a lição que podemos tirar de tudo isso, é que é importante reconhecer as nossas limitações e erros, e mais importante ainda, é buscar agir para contrapô-los. Sendo assim, testar um software acaba sendo uma das ações que podemos executar, para contrapor o fato de que não produzimos software perfeito.

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

Em busca da produtividade

Já há um bom tempo venho procurando formas de melhorar a minha produtividade. E ao longo desse tempo, encontrei soluções interessantes, algumas coloquei em prática e deu certo, outras não.

A motivação para escrever esse post, é compartilhar a minha atual receita para a produtividade e também fazer alguns comentários sobre o assunto. Porém, já vou avisando, que não há uma receita de produtividade que funcione para todos, o segredo é a combinação e adaptação de técnicas existentes.

Simples mas nem tanto

A minha receita possui três ingredientes principais, que são bem simples de se encontrar. No entanto, há alguns temperos que já não são tão fáceis assim.

Mas vamos aos três ingredientes:

  • Quebrar o seu tempo em timeboxes (“caixas de tempo”) – para isso eu utilizo a técnica Pomodoro (até já coloquei uma apresentação que fiz sobre ela no blog);
  • Uma boa trilha sonora: esse já é um ingrediente pessoal e não tão comum nas listas do pessoal. Esse ingrediente pode não ser útil para alguns, pois há pessoas que não conseguem se concentrar escutando música.  No meu caso eu sou 8 ou 80 em relação a esse ingrediente: para me concentrar ou preciso de “muito barulho” (música) ou de silêncio pleno (que em cidades grande só é encontrado à noite);
  • Ficar sozinho – não estou dizendo para ficar trancado na sua sala, mas sim que é importante ficar concentrado durante um timebox, para quem usa a técnica Pomodoro esse timebox é de 25 minutos (um pomodoro), sem nenhuma interrupção externa.

Agora vamos ao porquê do uso de cada ingrediente, lembrando que essa é uma receita caseira e que está funcionando bem para mim atualmente, mas isso não significa que irá funcionar perfeitamente para você (até acho difícil), mas pode servir de base/inspiração.

Tempo X Tarefas

Utilizando a técnica Pomodoro, aprendi a dividir e priorizar melhor as minhas tarefas ao longo do tempo. Um dos grandes benefícios do uso do Pomodoro na minha opinião, é que ele força você a ser “mono-tarefa”, e ao contrário do que se pensa, isso é muito bom.

É importante também saber priorizar as suas tarefas, colocando um peso sobre cada uma, ou simplesmente colocando-as na ordem. Lembrando que não é possível abraçar o mundo e por isso precisamos fazer o que é mais prioritário.

Em relação as ferramentas, eu utilizo o Focus Booster (que é um “contador de pomodoros”) e uma planilha no Google Docs para registrar minhas tarefas e o tempo que gasto em cada uma.

Rock’n Roll

A música me ajuda tanto para evitar as interrupções, por exemplo: evita ouvir outras conversas e querer participar delas, durante o pomodoro, e também me ajuda na concentração. Como tenho um gosto musical variado, e nem todas músicas me ajudam (ex.: bandas como o Mamonas Assassinas e Cuio Limão), acabei criando uma lista de músicas específica para ouvir durante os pomodoros, geralmente com as mais pesadas (ex.: One – Metallica) e as que mais gosto (ex.: It’s My Life – Bon Jovi).

Além disso, como gosto bastante de ouvir música, as tarefas acabam se tornando até mais agradavéis ao ouvir uma boa música (imagina o contrário, você trabalhando ouvindo músicas do ritmo que menos gosta).

Aqui no trabalho o ambiente não é dos mais silenciosos, e não acho ruim, pelo contrário (tem horas que até eu ajudo a bagunçar rs), porém não consigo um bom nível de concentração num ambiente barulhento, por isso a música por mais estranho que pareça, também me ajuda nesse quesito, além é claro de auxiliar na solitude.

Solitude

Muitas pessoas se sentem mais produtivias ou preferem trabalhar a noite, e um dos motivos para isso é que a noite geralmente há menos barulho e pessoas no escritório. No meu caso, não tenho uma preferência por dia e noite, embora concorde que seja mais fácil se concentrar a noite.

É importante lembrar que este ingrediente pode ser útil ou não, dependendo do tipo de atividade que será executada, do perfil da pessoa e das funções que exerce. Eu mesmo no começo não gostava/conseguia ficar queto durante muito tempo, mas quando você percebe a diferença na produtividade, acaba vendo o quanto é bom ficar “na sua” de vez em quando.

Mas por favor, não entendam errado, não quero dá a impressão que devemos nos isolar e cada um ficar na sua baia calado. Até porque isso não é bom num ambiente criativo, como deve ser o de uma equipe de desenvolvimento de software. O que acredito é que há o tempo certo para cada coisa, por isso que o ambiente de trabalho não deve ter o silêncio mórbido de um cemitério, nem o barulho de uma feira, devemos buscar o equilíbrio.

Os temperos

Na minha experiência, alguns temperos podem tornar mais eficiente essa receita e outros são essênciais:

  • Autoconhecimento: esse é essencial, pois a implementação e combinação das técnicas existentes dependerá muito do tanto que você se conhece. O autoconhecimento é primordial para conseguir uma boa receita de produtividade para você, e por isso também que a receita irá sempre sofrer modificações (a busca pela produtividade é contínua), pois além da nossa rotina ir mudando ao longo do tempo, vamos nos conhecendo melhor também (ou deveríamos);
  • Organização: é fundamental, tanto em relação as suas coisas (um exemplo que parece até bobo: a sua área de trabalho) quanto as suas tarefas/agenda;
  • Disciplina: esse é difícil, principalmente no começo, pois várias técnicas que ajudam a obter mais produtividade exigem disciplina, por exemplo, a própria técnica Pomodoro. Eu mesmo, não sou nem de longe o melhor praticante desta técnica, pois demorei um bom tempo para usá-la todos os dias, e ainda hoje, em alguns momentos é difícil usar;
  • Uma boa máquina: esse é básico, não tem como ser produtivo trabalhando numa máquina que trava toda hora;
  • Usar dois monitores: pode parecer frescura, mas dois monitores podem ajudar bastante na produtividade. E hoje em dia, com os preços bem mais acessíveis do que antigamente, não é mais um luxo ter dois monitores. Mas confesso que demorei um bom tempo para começar a usar, pois no começo achava estranho, mas hoje o uso de dois monitores facilita bastante a execução de várias tarefas;
  • Caça aos “comedores” de tempo: quando não usamos nenhuma técnica de gerenciamento do tempo, acabamos nem sabendo onde gastamos o mesmo, e em muitos casos, perdemos uma boa porção de tempo em atividades não tão importantes assim. Exemplo clássico são aqueles joguinhos do Facebook, nada contra jogos, mas que eles são grandes “comedores” de tempo, isso eles são, e o valor agregado é quase nulo, tirando a diversão;
  • Fazer o que gosta: esse é ESSENCIAL, se há um segredo para a produtividade deve ser esse. O tempo voa quando você está fazendo uma tarefa empolgante, e isso é muito bom.

Como puderam perceber o segredo dessa receita está no tempero, e cada um pode dá o seu toque especial. 😉

E você, usa alguma técnica para aumentar a sua produtividade ou tem alguma dica?

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

  • Usar dois monitores: pode parecer frescura, mas dois monitores podem ajudar bastante na produtividade. E hoje em dia., com os preços bem mais acessíveis do que antigamente, não é mais um luxo ter dois monitores. Mas confesso que demorei um bom tempo, para começar a usar, pois no começo achava estranho, mas hoje o uso de dois monitores facilita bastante a execução de várias tarefas;

O melhor da semana 04/07 a 10/07

Pessoal,

O melhor da semana está recheado com conteúdo bem variado essa semana, desde um excelente post do André Faria sobre o Agile Brazil, com links para reviews muito boas, até o post do Luiz Vieira mostrando algumas das aplicações web vulneráveis, voltadas para quem quer aprender segurança da informação, uma área que vem crescendo a cada ano e se tornando cada vez mais importante.

Conhecimento a um clique, esse é o QualidadeBR 🙂

Abraços! E tenham uma ótima semana!

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

Por que os desenvolvedores não fazem testes de unidade e integração?

A 27ª Mesa Redonda DFTestes teve como tema “Por que os desenvolvedores não fazem testes de unidade e integração?”. A discussão gerou 8 respostas e 7 pessoas participaram, sendo elas: eu, Janaina Trilles, Sarah Pimentel, Maria Meire, Edwagney Luz, Felipe Silva e Bruno Augusto.

Abaixo segue um resumo da discussão, baseado nas duas perguntas principais da mesa redonda. Quem quiser acessar a discussão na íntegra, pode acessar por meio deste link.

Por que os desenvolvedores não fazem testes de unidade e integração?

A Sarah Pimentel deu a sua resposta baseada na sua experiência, dizendo que:

Alguns casos que vivenciei era mais uma questão de conversar não com os desenvolvedores, mas com os gerentes. Nem sempre é “má vontade” dos desenvolvedores, em alguns casos é falta de tempo mesmo. O gerente não prevê a criação/execução de testes unitários e se o desenvolvedor aumentar a estimativa dele de desenvolvimento para englobar os testes unitários o gerente vai cair em cima e cortar o tempo da estimativa.

A aplicação de testes, de uma forma geral, não só os unitários, mas também os de sistema, está sempre envolta em muitas questões culturais.

O Edwagney fez um comentário bem interessante sobre a questão, colocando que a acomodação é um dos motivos para que os desenvolvedores não realizem testes de unidade e integração.

Esse é um tema bastante interessante e um grande indício de que o ser humano é sim acomodado e gosta de entrar numa zona de conforto e para não sair de lá jogar a culpa no tempo. Explico!

As tecnologias de hoje permitem ganhar muito mais tempo com desenvolvimento do que anos atrás. Quem foi desenvolvedor nas décadas de 80 e 90 sabem do que estou falando. Nessa época não tínhamos ainda o conceito de teste formal de software, como temos hoje e TODA a execução do teste era feito pelos próprios desenvolvedores. Já ouviram falar em “teste de mesa”? Para quem nunca ouviu falar disso, esse é um teste que era feito “à mão” usando papel e caneta onde os desenvolvedores simulavam a entrada de dados nas suas estruturas condicionais e de repetição, e verificavam se essa estrutura iria funcionar da forma como eles imaginavam para o desenvolvimento.
Esse era o teste unitário. Ele era feito por qualquer bom desenvolvedor. Era a forma de garantir que ao menos as principais funcionalidades estavam funcionando de forma isolada.

Esse método também era bastante usado nos testes de integração, onde os próprios desenvolvedores se viam na necessidade de testar seus módulos de forma integrada. O ambiente era direcionado a esse teste. Quem faria isso? Ninguém… Éramos nós mesmos.

Quando começaram a surgir as novas tecnologias, reduzindo o tempo de desenvolvimento e os conceitos de teste, os desenvolvedores entraram em uma tamanha acomodação que hoje nem mesmo os testes básicos eles fazem mais. Como assim? Há não… Vou perder meu tempo testando pra quê, se existe uma equipe só pra fazer isso?

Minha reflexão em relação a tudo isso é, existe culpa dos desenvolvedores por não mais executarem os testes?

Penso que atribuir culpa a alguém ou a alguma área é a forma mais fácil de taparmos o sol com a peneira. Não é assim que funciona. Antes de botar culpa em alguém façamos algumas reflexões:

Qual a política de testes foi adotada pela empresa? Todos na organização conhecem essa política? Todos a conhecem e sabem falar dela para outras pessoas (com propriedade)?

Essa política atribui papéis e responsabilidades bem definidos? A equipe de desenvolvimento sabe exatamente qual teste é executado pela equipe de teste?

O que aconteceu com os desenvolvedores que os fizeram a não executarem mais testes é simples. ACOMODAÇÃO.

De novo, culpa deles, não. Isso é natural do ser humano. Os desenvolvedores se acomodaram, pelo fato de acharem que, se existe uma equipe de teste, eles VÃO executar todos os testes no software. Só que em nenhum momento falaram para eles que não é bem assim. Cada um tem o seu escopo e sua participação no processo, isso É OBRIGAÇÃO DA ORGANIZAÇÃO em comunicar todos e todas as areas na empresa.

Para o Felipe Silva vários fatores contribuem para que o desenvolvedor não realize tais testes:

1. Penso na primeira como sendo a desvalorização de tais testes primeiramente por quem cobra os desenvolvedores (aquele que fica pondo pressão) e consequentemente pelos desenvolvedores (que se mostrarem baixo desempenho – por estarem testado tudo que supostamente deveriam testar – podem acabar perdendo o emprego),
2. O segundo ponto é a cultura de trabalho reativo acomodada na organização, que sem perceber (as vezes por que se negam a aceitar que isso ocorre sempre) preferem fazer duas vezes do que fazer o certo na primeira vez,
3. O terceiro ponto é os desenvolvedores não saberem que o processo de testes é composto por vários testes e que a equipe de teste não faz todos (não ainda), se eles não sabem disso é porque não deram condições para isso.

Em nenhum dos 3 casos eu os culpo (desenvolvedores) por isso, pois acho que a coisa começa em cima e reflete em baixo.

Na minha opinião alguns motivos para que o desenvolvedor não realize testes unitários e de integração são:

  • Existe uma rede de proteção chamada equipe de Testes;
  • Não tem
    • motivação;
    • conhecimento sobre testes;
    • noção do quanto dos benefícios de ter testes de unidade e integração;
  • São uns bundões e/ou imaturos;
  • Auto-confiança em excesso, “para que testar fui eu que desenvolvi”;
  • Dão manutenção em sistemas legados;

O grande problema é quando dois ou mais motivos juntam, o que é comum.

O que podemos fazer para incentivar/ajudar os desenvolvedores a realizar tais testes?

A Janaina Trilles compartilhou a sua dificuldade, que acredito que também seja a de muitos, mas acredito que o caminho seja tendo persistência mesmo, tentando ir mudar aos poucos.

Eu tenho grande dificuldade de fazer os desenvolvedores ter a cultura dos testes unitários, é sempre um problema na empresa .Não sei como eu posso mudar esse conceito, já falei que fazendo isso dimínui bastante defeitos e gera menos retrabalho.

Segundo o Felipe Silva, podemos ajudar sim, mas é algo que irá dá trabalho e demorará, uma vez que o problema muitas vezes está na cultura da equipe/empresa.

1. Ter no cronograma condições de se fazer estes testes, e fazer sem ser atropelado. Ter essas condições no cronograma não necessariamente significa aumenta o tempo do cronograma, pode-se pensar em N soluções para otimizar o tempo gasto em certas tarefas ou automatizar as que forem possíveis,
2. A organização, precisa ser “testadora”, digo, ser do mesmo time que nós, não somos “aqueles que apontam os defeitos”, somos “um de nós”, somos amigos do sucesso organizacional (pois tais testes ajudam tanto a ter melhor qualidade no produto entregue quanto ajuda reduzir o tempo gasto com testes funcionais), isso aqui não é da noite pro dia, mas tem que ser trabalhado incansavelmente a nível macro (todos envolvidos no projeto).
3. Alguma estratégia de divulgação da cultura de testes, do dia a dia, do que é feito e o que não é feito pelos testadores, seja por treinamento ou por qualquer outra forma que consiga atingir o objetivo de levar os opressores (líderes) e oprimidos (desenvolvedores) ao conhecimento do efeito negativo de se trabalhar reativamente.

Fácil falar e trabalhoso e não tão rápido de se conseguir, pois é humano, é cultural, é organizacional, envolve métricas, envolve dinheiro, envolve o cliente, envolve o emprego de cada um.

Eu penso, que podemos ajudar divulgando conteúdos relacionados ao assunto, dá uma palestra na empresa sobre esses testes, etc.

Se você tiver conhecimento/domínio sobre alguma linguagem de programação, pode conversar com o desenvolvedor para combinar um dia de sentar junto para tentar escrever alguns testes de uma funcionalidade que ele for implementar.

Realmente, introduzir testes unitários e de integração no desenvolvimento é um processo que costuma ser demorado, não é fácil mudar a cultura dos desenvolvedores, principalmente, pelo fato que eles têm que sentir que testes são importantes, pois é algo que terá que ser mantido, caso contrário, iremos ver a teoria das janelas quebradas na prática.

Bem pessoal é isso. Até a próxima! 🙂

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

O melhor da semana 27/06 a 03/07

Pessoal,

Dentre os links do o melhor da semana, destaque para a apresentação bem humorada e bem feita do André Pantalião, que contou um pouco sobre a realidade da equipe na qual a gente trabalha na Voice, revelando que nem sempre a adoção ao Agile ocorre as mil maravilhas, uma vez que há problemas que são independentes de metodologia. Destaque também para a excelente apresentação do Rodrigo Yoshima sobre Kanban, que também ocorreu na Noite ágil, evento idealizado pelo André e organizado pelo Guilherme Silveira da Caelum.

Conhecimento a um clique, esse é o QualidadeBR! 🙂

Abraços! E tenham uma ótima semana!

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