quarta-feira, 24 de fevereiro de 2010

Financeiro X Emocional

" Toda empresa deve ter uma cultura e uma filosofia. Sem cultura e filosofia planejadas e assumidas, a empresa move-se apenas em função de números. Ela se torna um péssimo ambiente para seus funcionários e uma péssima prestadora de serviço para seus clientes. Os clientes passam a ser não mais seres humanos especiais, mas apenas consumidores em potencial. Uma empresa que não é capaz de pensar 10 ou 20 anos a sua frente é autodestrutiva.
A empresa portadora de uma excelente filosofia tem consciência de que existe para a sociedade, e não a sociedade para ela. Sua meta é contribuir para tornar a sociedade melhor. Sua vocação é colaborar para o crescimento humano. Seu sonho é gerar qualidade de vida em todas as pessoas que ela atinge direta ou indiretamente. Para ela o lucro financeiro caminha paralelamente ao lucro emocional.
As empresas que não possuem uma filosofia sólida costumam perpetuar seus defeitos ao longo das gerações de funcionários. Entre esses defeitos estão a falta de comunicação, a carência de solidariedade, o falso trabalho em equipe, a competição e os mecanismos maquiavélicos."

segunda-feira, 22 de fevereiro de 2010

Autom.ação.

Vários amigos [analistas/desenvolvedores] sempre me fazem a mesma pergunta: "Por que não automatizar?".
Antes da resposta gostaria de fornecer algumas definições.
1) O que significa a palavra "automação"?
Aplicação de técnicas computadorizadas ou mecânicas para a diminuição do uso de mão-de-obra em qualquer processo.
2) Qual o objetivo da automação?
Diminuir os custos e aumentar a velocidade da produção.
3) Quando automatizar?
[A RESPOSTA!]
A automação de testes pode ser um sonho, mas se não for bem planejada será um pesadelo.
Analisando uma Equipe de Teste, a automação é bem-vinda quando:
- o processo de teste é bem definido
- os profissionais são qualificados e treinados para o uso da ferramenta escolhida
- o teste manual foi anteriormente executado e validado
- os testes possuem mais de 4 ciclos
Sua equipe e o sistema possuem todos esses pré-requisitos?
Sim!
Então estamos aptos a automatizar, mas caso contrário -> Não! 
Podemos automatizar qualquer fase do processo de teste que seja repetitiva e que gaste muito tempo.
O Testlink, por exemplo, pode automatizar a criação dos casos de testes e a geração de métricas.
Já o Selenium, pode ser útil nos testes de regressão, nos testes com cálculos matemáticos, teste de performance, teste de integração e nos testes unitários [realizados pelos desenvolvedores].
...
Obs: pensando na equipe de desenvolvimento, os testes automatizados são de extrema importância. Se os programadores não escreveram testes para os seus respectivos códigos, eles já produziram um código legado.
...
Automação é sim redução de custos, mas o objetivo do teste é mitigar os riscos provenientes do desenvolvimento em relação a qualidade. A equipe de teste precisa de alternativas que garantam que o seu trabalho será realizado com eficiência. Precisa, pelo menos, garantir a mesma qualidade obtida na execução dos testes manuais, afinal de nada adianta um número elevado de suítes de testes automatizadas se elas não testam nada. Se os programadores não conseguem escrever um código sem erros, como os testadores podem confiar um sua própria codificação para um script?
Portanto, ressalto, nenhum teste automatizado substituirá um teste manual.
Reflitam!

quinta-feira, 18 de fevereiro de 2010

Time de Teste

Um time de teste de software também possui uma hierarquia pré-estabelecida. 
Um modelo básico e muito utilizado pela comunidade brasileira de teste de software é:

Gerente de Teste -> Líder de Teste -> Arquiteto de Teste -> Analista de Teste -> Testador

Definindo:
[As funções descritas abaixo podem variar conforme a necessidade da empresa]
Gerente de Teste:  tem como função primordial a documentação do processo de teste frente ao processo de desenvolvimento de software e a iniciação/finalização do projeto de teste a ser realizado no produto a ser testado. Suas qualificações e competências se assemelham a um gerente de projeto: elaborar o plano do projeto de teste, aquisição de novos recursos, orçamento, riscos, prazos, elaboração de relatórios, limitações do escopo do projeto de teste e outras atividades gerenciais.
Líder de Teste: profissional responsável pela condução dos testes e pela tutoria da equipe de testes. Geralmente é um profissional com alto grau de conhecimento em ciclos de vida e ambientes de testes. O Líder de Testes "ajuda" o gerente de Testes a elaborar os relatórios básicos para o acompanhamento do projeto.
Arquiteto de Teste: responsável por montar e garantir o funcionamento da infra-estrutura e ambientes de teste. É também a pessoa que cuida da instalação/configuração/documentação das ferramentas e que garante o correto funcionamento das mesmas.
Analista de Teste: responsável por traduzir os requisitos do sistema em casos de teste. Identifica e define os testes necessários para cada cenário. Monitora e avalia a qualidade obtida ao testar.
Testador: técnico responsável pela execução dos casos de teste e scripts de teste.

Todos saem ganhando na formação de um Time de Teste de Software com profissionais qualificados: a empresa, o cliente e a própria equipe. 

quarta-feira, 17 de fevereiro de 2010

Testar - uma questão social.

Até um testador obstinado precisa admitir que já se viu frente a frente com o tédio.
A execução diária de testes e o preenchimento exaustivo dos bugs transforma a disciplica de teste, por muitas vezes, em algo monótono e repetitivo.
Pessoalmente, acredito que essa seja a principal razão pela qual muitos profissionais de teste trocam de área ou continuam testando, mas sem criatividade e ânimo.
Como alterar o fluxo?
Responsabilidade social.
Por várias vezes em reuniões com a minha antiga equipe de teste, perguntei aos testadores/analistas se eles tinham idéia de como aquele trabalho era importante para a empresa que eles trabalhavam, para os clientes da empresa [muitas vezes órgãos públicos] e principalmente para a sociedade.
Um exemplo:
"Imaginem um erro no sistema de cálculos da aposentadoria do INSS. Esse erro não reportado por um teste tedioso afetaria seu avô, seu pai e mais tarde até você."
Será que todos nós pensamos sobre isso quando estamos elaborando, testando e projetando um software?
Todo trabalho tem uma questão social embutida!
O mais importante é aprender a importância da qualidade no desenvolvimento de um produto e como isso reflete no social. Nem todos os "testers" seguirão o caminho da detecção de erros, mas creio que serão melhores em qualquer outra profissão, pois serão responsáveis pelo que produzem e buscarão o seu melhor sempre, e não só por eles, mas pelo meio.

quarta-feira, 10 de fevereiro de 2010

Myers e TDD

Para complementar o post sobre a Regra 10 do JOGO.

segunda-feira, 8 de fevereiro de 2010

Regra 10 - O JOGO!

Toda empresa de desenvolvimento de software deveria ter a Regra 10 de Myers escrita por todos os cantos.
Um cartaz pregado na porta ou perto da catraca seria uma boa solução.
Você [programador, analista de requisitos, gerente de projeto, etc] sabe o que diz a "Regra 10 de Myers"?
Não!?
Defino...
"A Regra 10 de Myers, estabelece que o custo de correção de defeitos tende a aumentar quanto mais tarde o defeito é detectado.A regra projeta um crescimento exponencial do custo de correção de defeitos, numa proporção de 10x. Ou seja, defeitos encontrados em revisões custam X, defeitos encontrados nos testes custam 10X e defeitos encontrados em produção custam 100X para serem corrigidos."
Entenderam?
Para ser mais clara...
Um defeito encontrado durante o levantamento de dados, escrita do caso de uso é mais barato que um erro encontrado no desenvolvimento e muito mais barato que um erro reportado pela equipe de teste. 
E como poderíamos solucionar tal problema?
Começar do zero?
Processos agéis? TDD? 
Hum...talvez.
Nessas técnicas a participação das equipes de teste e desenvolvimento são essenciais desde o início do projeto.
Sua empresa possui uma cultura "engessada" no processo de desenvolvimento de software?
Hum...entendi, mas tenho algumas soluções básicas!
1) Crie um checklist de testes unitários para sua equipe de desenvolvimento.
2) Pratique a política de diminuição de erros - se num determinado projeto vc obteve X erros, no próximo tente X/2. Aprenda com os erros e converse sobre os mesmos.
3) Faça reuniões de repasse - antes de homologar um UC, repasse o mesmo para a equipe de teste e desenvolvimento. Aceite as alterações!
4) Mantenha sempre uma excelente equipe de Análise de Requisitos. 

As pessoas ocasionalmente resistem à mudança e evitam aventurar-se em áreas pouco familiares.
Arrisque!!!
Crie o conceito de TIME e entre no JOGO!

Agradecimento

Farei um agradecimento público aos meus novos e ilustres leitores:

.Paulo Foina [coordenador do curso de Ciência da Computação do UNICEUB] - Manager at Instituto de Pesquisas Eldorado
e
.Vinicius Oliveira [companheiro de vida acadêmica] - ICT Assistant at Unicef


THANKS and LETS GO!