The Bug Bang Theory

Hoje eu resolvi escrever uma histórinha que pode nos ajudar a refletir sobre a nossa carreira, nossa empresa, nossos objetivos e principalmente sobre nossos próximos passos.

A história é totalmente fictícia, não faz referência a nenhum profissional, certificação ou empresa em particular, mas aproveitei um pouco do que ando vendo nos fóruns e lendo em alguns livros sobre carreira e liderança para criar uma história que pode ser a história de muita gente aí fora.

Espero que gostem

Hoje é o primeiro dia da Sophie Kowalsky, nova testadora na BugSoft Corporation. Ela foi selecionada entre os mais de 150 candidatos a vaga de estágio no departamento de qualidade da BugSoft. Nessa seleção, a BugSof se preocupa não no conhecimento que o profissional já tem, mas sim nas características pessoais dos candidatos. Ser criterioso, detalhista, crítico e comunicativo é mais importante do que dominar linguagens, ferramentas ou ter certificações.

Hoje ela está começando a sua carreira de estagiaria como testadora, mas nunca viu nada sobre teste na vida, afinal de contas, na faculdade que ela estuda não existe nenhuma matéria exclusiva de teste de sioftware.
Ela está entusiasmada com as novidades, aos poucos começa a pegar o ritmo sobre como fazer testes exploratórios, em algumas semanas já consegue executar testes de casos de teste e reportar ótimos defeitos.

A BugSoft é uma empresa responsável e visionária, seis meses depois contratou a Sophie mesmo sem ter terminado a graduação, agora ela é uma testadora e já conhece muito sobre a malícia de encontrar defeitos.
Um ano e meio depois, a Sophie terminou a sua graduação, agora com dois anos de experiência já começa a ajudar Julien, analista de teste certificado, com a especificação de alguns casos de teste menos complexos e já está estudando para ser uma profissional certificada.

A BugSoft é uma empresa responável e visionária, acredita em pessoas como Sophie e resolveu ajudá-la na conquista da sua primeira certificação com os custos, materiais e algumas horas de estudo durante o expediente. O resultado não podia ser diferente, a Sophie passou com 90% de aproveitamento na prova da certificação, e agora é uma profissional certificada. A empresa reconheceu o valor da certificação, mas informou que existe mais um tempo de aprendizado até que ela possa se tornar uma analista de teste de software.

Com a certificação, a Sophie que acompanha diversas listas de discussão sofre por várias vezes a tentação de mudar da BugSoft para uma outra empresa que esteja pagando um alto salário para um profissional certificado, mas ela resiste pois confia na posição dos seus líderes que tem uma carreira pronta para ela na organização, seu amigo Julien, analista de teste, resolveu abandonar a BugSoft para ir para a CertifiedSoft.

Seis meses depois, Sophie é promovida a Analista de Teste. Ela fica muito contente, tem um aumento considerável e está novamente recarregada e motivada. Ficou aliviada em não tentar ir para a nova oportunidade, pois Julien, acabou descepsionado. Ele confessou que apesar do salário, os projetos não eram tão interessantes, os líderes não tinham as habilidades necessária e o clima de competição enfraquecia o companheirismo, já que as certificações valiam ouro e ele executava na maioria do tempo atividades de testador, quando na verdade gostaria de trabalhar como analista de teste.

Passado um ano, o envolvimento da Sophie cresceu muito em alguns projetos, e no principal seguimento da BugSoft, o que fez com que os líderes da empresa começassem a vê-la de uma forma diferente. Sua líder direta, Christelle, ressaltou a capacidade de organização e a facilidade ao lidar com pessoas de Sophie e em um acordo com os diretores da empresa, mesmo sem o conhecimento da Sophie, começou a direcioná-la para uma carreira de liderança.
Em conversas informais sobre livros, sobre, MBAs e etc., começou a influenciar Sophie de uma maneira a orientá-la a um crescimento dentro da empresa.

Sophie decidiu se matricular em uma pós graduação de Gerência de Projetos e a BugSoft colabora com 50% das despesas com educação da Sophie. Depois de um ano ela já está na metade da pós graduação e a empresa está crescendo em um ritmo muito estável, consequentemente, com projetos maiores. A empresa decide então promover Sophie para Coordenadora de Teste.

Agora ela coordena os novos testadores e analistas de teste, os orienta quanto as mesmas dúvidas que ela teve nos últimos quase quatro anos e organiza os projetos em que participa para otimizar os recursos de teste. Toma decisões importantes, mas sempre consultando sua líder, Christelle.
Claro que Sophie almeja um dia ser líder de teste, mas ela é demasiadamente leal a Christelle, que retribui com a mesma lealdade e atenção, e durante todos esses anos a ajudou em sua carreira.  As duas comemoram vitórias umas das outras como se fossem suas próprias.

Ao mesmo tempo, Julien já é líder de testes. Claro que ele teve que enganar um pouco daqui, enganar um pouco dali, puxar o tapete de algumas pessoas, inclusive do seu líder que de tanta pressão acabou pedindo demissão. Julien hoje suporta uma pressão maior ainda do que seu antigo líder. A CertifiedSoft despenca em faturamento pelo terceiro ano consecutivo, além dos altos salários que paga para os profissionais certificados que não param de sair para outras oportunidades, ela enfrenta uma crise, pois sua principal certificação não foi aprovada na reavaliação RightProcess, o que custou o título de qualidade que foi conquistado por anos e anos de consultorias e horas gastas, naquela época em que a CertifiedSoft contava mais com pessoas motivadas sem certificação.

Mais dois anos se passaram e a BugSoft cresceu e conquistou um novo mercado em outro país. Uma mudança no organograma foi feita e agora a Christelle foi promovida para Gerente de Teste do mercado atual, enquanto o seu superior foi promovido como diretor do novo pólo. Obviamente Christelle se lembrou imediatamente que Sophie havia terminado a sua pos graduação e agora já estava com mais de 12 pessoas no seu comando. Sophie tinha conseguido elevar a produtividade dos colaboradores sem modificar o clima harmonioso da fábrica de testes e agora estava prestes a começar o seu MBA em Planejamento Estratégico de Pessoas, MBA em que Christelle tinha concluído a um ano atrás. Com o cenário atual, Sophie foi promovida para Líder de teste, não só no departamento em que Christelle liderava, mas também em outras duas filiais.

Cinco anos mais tarde, após um longo período de complicações, a CertifiedSoft não resistiu e perdeu muitos de seus clientes para a BugSoft, que reformulou seus objetivos estratégicos e conquistou o nível máximo de excelência nos últimos cinco anos durante as auditorias do RightProcess. A CertifiedSoft teve que realizar cortes e Julien foi demitido.

Julien era uma pessoa que se esforçava pela empresa, mas como a CertifiedSoft tinha uma alta taxa de rotatividade, muitas pessoas conheceram Julien, que por ter sido lapidado por uma empresa com uma cultura voltada a comparações e competições, acabou tornando muitas dessas pessoas “inimigas”, o que dificultou seu retorno para o mercado como líder de teste.

Hoje, cinco anos depois, a BugSoft é uma das maiores empresas do seguimento de software no continente e possui várias filiais e diretorias. A diretoria de Planejamento Estratégico de Qualidade é liderada Pela Dr.ª Kowalsky, que insiste em ser chamada de Sophie. Ela ajuda a organização a tomar decisões importantes, a encontrar talentos e a conquistar novos mercados.  Nessa mesma empresa, está entrando um novo analista de teste chamado Julien. Na verdade, ele já trabalhou aqui a alguns anos, mas isso quando a BugSoft ainda era uma “empresinha” na pequena cidade SmallCity.

A história acima é totalmente hipotética, mas reflete a influência que a empresa tem sobre os colaboradores e o como a pressa por altos salários pode atrapalhar uma carreira promissora. Os personagens também são fictícios e os nomes vieram de um filme francês chamado “Jeux d’enfants” que na verdade é uma história romântica.

Quando pensamos em carreira, não devemos pensar em salários, certificações e títulos, mas sim em experiências, network e conquistas. Essas conquistas podem ser nossas, da nossa empresa, dos nossos lideres, dos nossos colegas de trabalho, dos nossos colegas de blog e mercado ou do nosso seguimento. Quando uma pessoa tem sucesso, todo mundo é afetado de uma forma positiva.

Conhecer o mercado, dominar o ego, trabalhar em equipe, esperar e aproveitar oportunidades, não são habilidades fáceis de aprimorar e na maioria das vezes são mais decisivas na nossa carreira do que certificações, pós graduações ou títulos conquistados.

Uma vez um dos meus lideres me disse: “O segredo para o sucesso é ser lembrado sempre que tocarem em assuntos da sua área de atuação“.

Bons testes

Imagine um grupo de onze viciados em PlayStation lutando pela oportunidade de passar o dia todo com jogos que ainda não foram lançados, consoles para o futuro, periféricos novos e tudo dos videogames da Sony, e ainda ganhar 5000 dólares para viver como testador da Sony.

A Sony lança no próximo dia 18 a inovadora série “The Tester“, com oito episódios, onde onze testadores em potencial vão disputar provas de mentais, físicas e claro, jogar muito PS3 para ganhar esse trabalho. Depois de realizar as provas, os candidatos serão eliminados um a um por uma bancada composta por três juízes.

Pelo preview o seriado parece muito divertido, com provas de resistência e competições em jogos. Funciona mais ou menos como um “britains got talent” para viciados em videogame e será exibido na PlayStation®Network.

Vale muito a pena assistir o vídeo. Para assitir e ler mais sobre o desafio acesse a url abaixo:
http://www.thetester.com/

Bons testes

Deadlock Immunity, também conhecido como Dimmunix, faz com que sistemas uma vez atingidos por um padrão de defeito, desenvolvam a capacidade de evitar ocorrências futuras desse padrão de defeito através do registro de sua assinatura. Ao longo do tempo, programas com um sistema tão “imune” podem aumentar progressivamente a sua resistência aos bloqueios.

“O Dimmunix pode ser comparado ao sistema imunológico humano. Uma vez que o corpo é infectado, seu sistema imunológico desenvolve anticorpos. Posteriormente, ao deparar com o mesmo patógeno, o corpo o reconhece e sabe como combater eficientemente o problema”, explicou George Candea, diretor do Laboratório de Sistemas Confiáveis, onde a ferramenta foi criada.

O Dimmunix fornece a capacidade de um software evitar recorrência de defeitos através de um padrão identificado em cada falha, que é armazenado numa base de dados e comparada durante as novas execuções. Quando um padrão semelhante é identificado, o sistema trabalha de forma a evitar que o defeito ocorra novamente. Com o passar do tempo, o sistema consegue determinar com facilidade o momento em que o defeito pode ocorrer e  evitar os problemas resultantes dessa falha.

Ao que parece, o Dimmunix consegue evitar somente deadlocks ou “congelamentos”, o famoso “software travando”, mas já é um bom começo para criar sistemas inteligente que conseguem recuperar-se de falhas com menos interferência humana.

Segundo os autores do artigo, com o Dimmunix um Browser, “aprende” a evitar o congelamento verificado na primeira vez que ocorreu um bug associado a um plug-in . Além de browsers, o estudo está avançando para SGDBs como o SQLite e o MySQL.

Imagine em um futuro não muito distante, sistemas com a capacidade de diagnosticar suas falhas para outros sistemas que tem a capacidade de corrigi-las. Parece um pouco de loucura, mas IA (Inteligência artificial) é uma das áreas da computação que mais avança e com ótimas perspectivas para o futuro.

Bem utópica essa novidade né? De qualquer forma, esse projeto suíço me chamou muito a atenção, e vou acompanhar as pesquisas. Qualquer novidade comento aqui no blog, afinal de contas, tratando-se de testadores, sendo eles humanos ou não, temos que estar por dentro

O código fonte está disponível em C/C++ e Java, e pode ser baixado assim como toda a documentação e pesquisa realizadas. Para downloads e  outras informações:
http://dslab.epfl.ch/proj/dimmunix

Bons testes

Alguma coisa diferente no Bug Bang?

O novo theme instalado Inanis é compatível com o despadronizado Internet Explorer, tem um melhor aproveitamento do espaço para texto e possui recursos mais simples para navegação.

Como a maioria dos analistas de teste sabem, quando testamos um sistema que ficará disponível para o publico, a preocupação com o browser deve ser levada em consideração. O antigo tema que eu estava usando apresentava muitos problemas de incompatibilidade com as versões 6 e 7 do navegador Internet Explorer. Tentei resolver de diversas maneiras, mas tive que recorrer a um novo theme.

Esse novo theme possui alguns recursos que facilitam a navegação:

•About this Post:
Sempre que entramos em um post, o blog apresenta um resumo a direita, informando nome do post, data de criação, Autor, Número de comentários, categorias e opções de respoder ao post, ler os comentários e seguir o RSS.

•Rodapé do Post:

Existem as informações sobre criação, autor, tags e categorias a que o . Também tem as ações de enviar por e-mail e ver o link. Ainda no rodapé, podemos ir para o próximo ou para o anterior com um click. Mais abaixo vem o campo para comentários e com ele um icone do RSS para esse post.

•Menu de tarefas
O menu no canto inferior esquerdo, semelhante ao menu iniciar do Windows 7, carrega quatro opções para melhorar e facilitar a vida dos usuários do blog.

->Guia de categorias, com todas as categorias em um menu;
->Nuvem de tags, semelhante a principal, mas aqui somente as tags aparecem;
->RSS do Blog, para assinar o nosso Feed;
->RSS dos comentários do blog, para saber o que os nossos visitantes comentam;
->Menu dos últimos 50 posts;
->Pesquisa rápida;

Além disso, existe um recurso para o mudar de tema, onde podemos mudar o fundo do blog para ficar mais a vontade.

•Mais espaço para o conteúdo
O espaço reservado ao texto do post também aumentou muito, cerca de 30%, o que permite maior facilidade para ler e publicar imagens maiores . Se usar a opção de tela cheia (normalmente ativada pelo F11) o blog fica ainda mais confortavel

Também foram adicionados novos widgets que vão ajudar os leitores a interagir comigo enquanto lêem algum dos artigos.

->O chat onde os leitores podem tirar dúvidas sobre algum post;
->A pesquisa de opinião onde os leitores podem me ajudar a definir o que pesquisar;

Além disso, o novo visual do blog é mais moderno, futurista e sofisticado, mais rápido e mais intuitivo. Funciona da mesma forma em todos os principais browsers do mercado, em todos os que apareceram no meu analytics e combina mais com o nome do blog.

Aceito sugestões e críticas sobre o novo layout e possíveis mudanças.

Bons testes

Ok, ok, sou péssimo para trocadilhos, mas o “teste é ouro” faz sentido sim.

Para quem acha que testador ganha pouco, imagine ganhar mais de dois mil e duzentos reais por bug. Nesse contexto, encontrar 10 bugs em um dia pode equivaler a um carro zero Km.

É isso que foi divulgado pelo Google no blog oficial do Google Chrome na última semana. O navegador oficial do Google está pagando entre 500 e 1337 dólares por bug.

Não precisa mencionar, mas o Google é conhecido no mundo inteiro como uma referencia de qualidade pelos seus softwares instantâneos, intuitivos, inteligentes, confortáveis, “sem bugs” e sempre com um visual sofisticado e inovador. Não é por menos que a maioria dos profissionais de software explicitam sua vontade de trabalhar para o Google.

Numa tentativa de criar um sistema cada vez mais próximos do “zarro bogs”, o Google Chrome abriu desafio para a comunidade de desenvolvedores e testadores. Para cada bug encontrado, será pago, em qualquer lugar do mundo, uma quantia que pode variar de 500,00 dólares a 1337,00 dólares. A variação será baseada no nível do bug. Quanto mais crítico, maior a recompensa.

Claro que estou empolgado com essa novidade. Para quem acompanha meu blog, sabe que eu já encontrei um problema no Google Chrome e publiquei no post “Defeito no GMail causa falha no FireFox e no Chrome“, e se depender de mim, vamos achar muitos novos bugs no meu navegador preferido.

Claro que nem todo bug faz parte dessa investida por qualidade. Ela é restrita a defeitos do Chromium ou Google Chrome, especialmente de segurança e excluindo defeitos de sistemas operacionais e de add-ons de terceiros.

Para saber mais sobre essa novidade tentadora basta acessar o blog oficial no link abaixo, onde podem ser conferidas as regras e detalhes dessa oportunidade:
http://google-chrome-browser.com/find-bug-google-chrome-earn-500-1337

Porquê 1337 dólares? Conheça o 1337 ou l33t (Leet Speak):
http://en.wikipedia.org/wiki/Leet

Bons testes

A alguns dias recebi um e-mail de uma amiga da comunidade de testes DFTestes (Fabiana Maronez), perguntando como usar o TestLink para gerenciar o QA (Garantia de Qualidade).
A maioria de nós certamente pensaria que é uma idéia um pouco distorcida. Usar uma ferramenta de gerência de testes para realizar QA? Mas com um pouco de criatividade e vontade de eliminar as planilhas, pensei em uma solução que pode atender o que a nossa colega solicita.

Para quem ainda não está habituado, podemos dizer que Quality Assurance (ou simplesmente QA) são atividades de auditoria que os processos baseados em modelos de melhoria como o CMMi e as ISO possuem para garantir que o processo está sendo seguido adequadamente. Para isso, normalmente são usadas planilhas e mais planilhas, com vários critérios. Essas planilhas são usadas de várias formas diferentes, desde uma para cada artefato até uma para cada projeto, mas a dificuldade de gerar relatórios e coletar indicadores quase sempre é surreal.

Obs: Para perfeita compreensão desse post, é necessário conhecimento básico em QA e na ferramenta TestLink. Recomendável também um conhecimento básico sobre CMMi.
Termos usados entre parênteses na cor verde ” (exemplo) “ simbolizam o que seria feito no TestLink em um projeto de teste.

Abaixo vou demonstrar uma forma de gerenciamento das auditorias com redução significativa do esforço:

1 – Criar um produto do TestLink para o QA.
(Criar um produto do TestLink)

É importante usar a opção  “Gerenciar Requisitos”, para futuramente usarmos rastreabilidade das práticas para os Casos de Auditoria*.
*Casos de auditoria é um nome improvisado que eu arrumei para classificar casos de teste voltados para o processo, substituindo os tradicionais critérios.

2 – Cadastrar as práticas.

(Cadastrar especificações de requisitos e requisitos)

O cadastro das práticas é opcional, mas agrega muito valor, pois facilita a compreensão do fundamento da existência de cada”caso de auditoria” . Não existe uma forma definitiva de inserir as praticas, mas no caso do CMMi, uma forma que eu achei muito interessante é criar Especificações de requisitos para cada PA (Process Area) e um requisitos para cada SG (Specific Goal) e SP (Specific Practice), como ilustrado acima.

3 – Criar os casos de auditoria
(Especificar casos de teste)
Ao criar os casos de auditoria, é importante usar o nosso conhecimento em casos de teste para definir pré-condições, procedimentos e resultados esperados, muito próximo do que fazemos com os casos de teste para nossos softwares.
Normalmente, os QAs são realizados somente com critérios, o que torna o processo de auditoria muito custoso, pois qualquer pessoa que precise realizar o QA deve antes ser muito treinada no processo e no modelo de melhoria de processos adotado. A ultilização de casos de auditoria, além de gerenciar e simplificar métricas do QA, torna o processo menos dependente de treinamento, e possivelmente adaptável para testadores ou analistas de teste, porque uma pessoa com muito conhecimento do processo e do modelo pode definir um conjunto de casos de auditoria e pessoas com menos conhecimento podem executá-los, assim como analistas de teste e testadores.

4 – Atribuindo práticas ao caso de auditoria
(Vincular requisitos aos casos de teste)
Nesse momento vinculamos as práticas que devem ser cobertas pelo caso de auditoria, de forma a criar uma rastreabilidade por prática. Isso será importante para verificar quando cada prática é coberta e quais os casos de auditoria são mais críticos.

Quando cadastramos podemos ver o caso de auditoria como a imagem abaixo:
Acima podemos ver como cada caso de auditoria fica no final de sua especificação. Com pré-condição, passos descrevendo a sequencia de ações para executá-lo, resultado esperado e práticas vinculadas.

Assim devem ser feitos todos os “critérios” usados para a auditoria. Uma vez cadastrados, podem ser editados e modificados livremente, da mesma forma que os casos de teste de projetos de software.

5 – Definindo projetos
(Criar um Plano de Teste e adicionar Casos de Teste a esse plano)
Todo o trabalho até aqui, é realizado somente uma vez, e modificado sempre que um critério ou caso de auditoria precisa fica desatualizado. De agora em diante, apenas criamos “projetos” (planos de teste do TestLink) e releases para suas auditorias. O trabalho de armazenar as informações e controlar os artefatos e evidências, fica totalmente a cargo da ferramenta.
Criamos para cada projeto que será auditado, um novo “plano de teste”, que podemos chamar de “plano de auditoria”.
Aqui “começa a mágica”. Podemos definir para cada plano de auditoria um conjunto de casos de auditoria, de forma a permitir a customização do processo.
Para isso, basta selecionar os casos de auditoria no momento de vinculá-los a cada um dos projetos, de acordo com a demonstração abaixo. No exemplo acima podemos selecionar apenas os casos de auditoria que o “Projeto para auditoria 02″ irá usar.

6 – Preparando para executar uma auditoria.
(Criar uma nova release para o plano)
Na demostração acima, ao criar uma release do TestLink estamos criando uma instancia do QA planejado para aquele projeto, ou seja, estamos permitindo a execução dos casos de auditoria para o “Projeto para auditoria 02″.

7 – Executando a auditoria.
(Executar a release)
Agora executamos cada um dos casos de auditoria. A execução é semelhante a tradicional (caso de teste). O resultado pode ser positivo (aprovado), negativo (não-conformidade) ou bloqueado (indisponível), em qualquer caso podemos tomar ações para evidenciar ou complementar a nossa execução.
Evidência de auditoria: Uma evidência como um print do documento, do registro ou qualquer tipo de arquivo que possa comprovar a auditoria pode ser vinculado ao resultado “Passou” da execução.
(Salvar um anexo a execução do caso de teste)
Não conformidade encontrada: Para as não-conformidades encontradas, normalmente é cadastrado um “bug” no bugzilla ou no mantis, de forma a não conformidade adotar o mesmo workflow dos defeitos. Se esse for o caso, podemos usar a integração Defect Tracking System/TestLink para gerenciar as não conformidades.
(Cadastrar um bug no Bugzilla, Mantis, Eventum ou qualquer outra ferramenta integrada ao TestLink)

Caso o resultado do caso de auditoria tenha sido Bloqueado, o Analista de QA deve informar o motivo do bloqueio nas notas.

8 – Visualizando sumário de auditorias.
(Resultados)
Agora temos todos os relatórios do TestLink, usados para gerenciar nossos casos de teste, aplicáveis aos casos de auditoria usados anteriormente.

Alguns relatórios interessantes:
a – Relatório baseado em requisitos:
Nesse contexto ele nos permite avaliar cada uma das práticas que devem ser atendidas pelo CMMi ou outro modelo de melhoria como ISO ou MPS.BR, do ponto de vista de cobertura por auditoria.

b – Métricas gerais do plano de auditoria:
Aqui podemos acompanhar a evolução das execuções de várias “auditorias” (releases) de uma forma simples.

Esse post foi motivado por uma não existência de uma ferramenta própria para a execução de auditorias para processos baseados em modelos de qualidade (pelo menos ao meu conhecimento), como a ISO e CMMi, em fábricas de software, onde, normalmente são usados critério difíceis de compreender, em planilhas controladas manualmente, o que causa um desperdício de produtividade e perda da qualidade.

Importante ressaltar que o TestLink não é uma ferramenta própria para essa finalidade, mas podemos aproveitar o conhecimento do TestLink para adaptar um pouco alguns conceitos, desde que seja para melhor.

Em breve devo disponibilizar os pacotes para importação com todas as PAs do CMMi Dev1.2 em CSV e outro com uma tradução especial em português usando os termos citados acima.

Estou disponível para questionamentos, críticas e sugestões.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Muita gente que me conhece sabe como sou um evangelista dos processos tradicionais como RUP, EUP, UP e MBASE e de modelos de qualidade e otimização dos processos organizacionais como CMM, CMMi, das ISOs entre vários outros modelos, metodologias e normas, que às vezes são conhecidas como pesadas, burocráticas, com pouco valor e pouca aplicabilidade, mas, como sou evangelista sempre digo que ir contra RUP/MBASE é ir contra Engenharia de Software.

Não existe verdade absoluta, falar que RUP é burocrático é imaturidade, assim como falar que SCRUM ou XP é desorganizado também é.

Mas hoje vou falar um pouco sobre como vejo o potencial dos princípios ágeis e como podemos usar algumas das técnicas inspiradas no XP para nosso dia a dia, aumentando a efetividade dos nossos testes sem perder tempo ou sair dos processos das nossas fábricas.

Eu vejo o XP (assim como o SCRUM) como um conjunto de práticas, princípios e orientações que seguem uma quase “doutrina” chamada de Manifesto Ágil (Manifesto for Agile Software Development) ou Manifesto para desenvolvimento Ágil de Software.

Prezado leitor apaixonado pelo Agile, não me crucifique pelo que vou dizer, mas eu, no meu “maravilhoso mundo da Engenharia de Software”, considero o XP uma biblioteca de boas práticas para engenharia e o SCRUM uma biblioteca de boas práticas para gestão e acompanhamento de projetos, sendo que o próprio RUP também agrega essa mesma titulação no meu ponto de vista. Isso porque, um projeto é uma entidade vida,  e precisa de um sistema (processo), com caracteristicas únicas para atender as  suas necessidades.

Como toda biblioteca, podemos livremente usar e deixar de usar essas práticas em qualquer projeto, mas qualquer projeto deve ter um processo definido, caso não tenha, a chance de fracasso é muito alta.

Abaixo, um resumo de alguns princípios e regras que são aplicáveis para melhorar o teste de software. Abaixo, algumas práticas interessantes baseadas nas práticas e regras do XP:

•When a bug is found, tests are created to guard against it coming back
Para todo defeito que não for encontrado por um caso de teste, deve ser criado um caso de teste em uma suíte especial para evitar que esse defeito volte a acontecer futuramente. Essa prática ajuda a aumentar a cobertura e efetividade dos testes, além de criar um conjunto de casos de teste orientados a defeito de forma preventiva. Não gasta mais tempo do que é normalmente gasto, pois essa prática substitui a descrição do defeito pelos procedimentos de teste (passo a passo) do caso de teste, substituindo o teste de confirmação e aumentando a quantidade de testes de regressão.

•All code must have unit tests.
Sim. Se o compilador já faz a cobertura de testes sintáticos de todo o código fonte, por que não deve existir uma cobertura de todos os testes semânticos (unitários)? Os testes unitários são o primeiro filtro no teste do software, mas não é por isso que não são importantes. Para cada classe é interessante ter um conjunto de testes que pode ser escrito antes da própria classe e se possível pela mesma pessoa que vai implementá-la. Quando isso acontece, o desenvolvedor consegue ver detalhes semânticos que antes ele não podia ver, consegue ver possíveis erros e existe uma probabilidade maior de atender a todos os requisitos da funcionalidade. Para ajudar nessa tarefa, é interessante o analista de teste participar com o desenvolvedor da criação desses testes unitários.

•Acceptance tests are run often and the score
Toda release que passe por todos os casos de teste Alpha devem ser encaminhadas para os testes de aceite. Diferente do XP, os testes de aceite que eu proponho nesse post não são baseados em Histórias de Usuários, são baseados em requisitos funcionais do usuário (os mesmos que dão origem aos casos de uso). São escritos testes baseados em cenários de negócio do sistema, de forma a validar os fluxos de trabalho que o sistema deve prover. Sugiro que sejam poucos testes, na linguagem do usuário, cada teste cobrindo o máximo dos requisitos do usuário, sem focar nos detalhes. Após a execução desses testes, é importante coletar o ponto de vista do usuário para futuras melhorias e examinar os defeitos registrados pelos testes, pois eles refletem as principais preocupações dos usuários, e a partir de cada uma dessas iterações dos testes de aceite, temos que repensar na forma como estamos desenvolvendo nossos casos de teste, para que fiquem mais próximos dos detalhes que causam os defeitos que os clientes reportaram. Recomendação: A regra de um caso de teste para cada defeito continua valendo aqui.

•Testing Cicle Velocity (Project Velocity)
Registrar o tempo gasto para executar cada ciclo de teste. Isso é importante para que a gerência sempre deixe um tempo inflacionado dessa base histórica, de forma a prover testes de regressão de todos os casos de teste do sistema e não somente aos casos de teste das novas funcionalidades e das funcionalidades com defeitos corrigidos. Recomendação: Aplicar também aos testes de aceite do usuário.

•All code must pass all unit tests before be released
Existe uma “cascatinha” importante relacionada a esse princípio. Para que um código seja integrado ao repositório, ele jamais pode estar com algum problema sintático, deve estar completo (totalmente implementado) e deve ter passado por todos os seus testes unitários. Dessa forma garantimos que todos os testes unitários tenham sido executados e que defeitos em módulos sejam minimizados. Após todos os códigos da release serem integrados, é recomendado que ao gerar a release seja executado um teste de fumaça para validar se o sistema está realmente funcionando sem problemas grosseiros nos seus fluxos principais. Somente após essas duas validações (teste unitário e teste de fumaça do desenvolvedor) a release alpha deve ser gerada e enviada para que o analista de teste execute um ciclo de teste com todos os casos de teste. Executado esse ciclo com todos os casos de teste, são executados os testes dos cenários de negócios que serão enviados para o cliente e vários testes exploratórios. Se todos os testes até aqui passarem sem problemas ou defeitos, o cliente recebe uma release beta para avaliação.

•Integrate testing often (Integrate Often)
Não adianta testar sempre os casos de teste se os cenários de negócio do sistema não forem testados também, principalmente em sistemas orientados a processos como pregão eletrônico, loja virtual, logística etc. Para o cliente um sistema que funcione sem defeitos mas não atenda às suas necessidades de negócios não é melhor que um sistema cheio de defeitos funcionais. Os casos de teste, após executados individualmente, devem ser dispostos em sequências a atender um cenário de negócio ou os requisitos do usuário. Essa prática permite que sejam testados detalhes de cada funcionalidade do sistema em paralelo aos cenários de negócio do cliente (objetivo estratégico do sistema para a organização).

•Refactor whenever and wherever possible.
Assim como os requisitos, os casos de uso e as histórias de usuário mudam constantemente, os casos de teste também mudam, e esses são os artefatos que devem aceitar a mudança com mais facilidade. Vários eventos contribuem para mudança dos casos de teste, ou testing refactoring. Mudanças nos requisitos, mudanças nos casos de uso, melhoria identificada durante a execução etc. Qualquer evento que contribua para uma melhoria do caso de teste ou de qualquer artefato de teste deve ser aceito sem questionar. Os casos de teste devem refletir o “estado da arte” do sistema sob avaliação e devem ser sempre completos, objetivos, claros e o mais simples possível, permitindo a execução correta daquele teste. Refatoração não é um indicador de imaturidade, muito pelo contrário, para o teste de software, aceitar mudanças de braços abertos é uma demonstração de preocupação com o resultado que será recebido pelo cliente e se esse resultado está exatamente como ele espera. Outro indicador importante para mudar o caso de teste é a quantidade de defeitos que ele detecta. Quando o caso de teste não detecta defeitos a muito tempo, é interessante investigar se ele está com um nível de detalhe muito superficial ou mesmo incompleto.

•Dedicated Integration Computer
Dedicar um ambiente de testes para a implantação contínua do produto, sempre validando esse ambiente com o cliente, que deve sempre fornecer informações sobre o que acha do ambiente, sobre os recursos, características especiais etc., para que além do produto, o ambiente de teste esteja em melhoria contínua e mais próximo do ambiente real do cliente. Caso o sistema seja web e para usuários da internet, é importante que o ambiente cliente mude constantemente, exatamente ao contrário do ambiente de teste do servidor. Nesse caso a regra deve ser chamada de “undedicated Integration Computers”. Se for um portal até vale a pena pedir a várias pessoas na fábrica, com seus preferidos browsers para dar uma “navegada crítica” e enviar um feedback por um formulário no próprio portal, com as críticas e defeitos encontrados. Esse formulário deve conter um mecanismo coletando as informações de browser, sistema operacional, resolução etc., de modo transparente para o usuário. Com base nesses defeitos devem ser feitos casos de teste.

•The business analyst is always available.
Sem dúvida isso é fundamental. Penso que a pessoa mais importante para o analista de teste em um projeto é o analista de negócios / requisitos. Ele sim, pode estar no lugar do cliente e deve estar sempre disponível. Acredito que todo mundo, com exceção do Kent Beck e sua turma, sabe que cliente sempre disponível é um sonho distante na maioria absoluta dos casos, mas para suprir essa ausência, o analista de negócios deve estar sempre disponível para o analista de teste e suas dúvidas, assim como o arquiteto também deve estar disponível para testes de requisitos não-funcionais e o analista de teste para o desenvolvedor durante a correção de defeitos e testes unitários.

Essas são práticas inspiradas no XP para melhorar nossas atividades de teste de software, sem gastar muito tempo com processos, análise de processos etc.

Outros princípios interessantes semelhantes, inspirados no agile:
Testar mais que o necessário sobre deixar dúvida na cobertura dos testes;
Cadastrar um defeito inválido sobre deixar de cadastrar um possível defeito;
Testes de regressão sobre testes de confirmação;
Ciclo de teste completo sobre testar novas funcionalidades;
Perseguir o zero erro sobre aceitar que o projeto terá defeitos.

Outras boas práticas:
•Automatizar o controle da execução dos testes e da cobertura dos requisitos pelos testes.
•Manter rastreabilidade dos defeitos para os casos de teste.
•Priorizar os fluxos com maior número de defeitos para testes de regressão.
•Modificar constantemente os casos de teste que não apresentem defeitos.

O mais mágico dessa onda chamada Agile é que qualquer uma das práticas e princípios acima pode ser aplicados em qualquer projeto, em qualquer fase do projeto, com qualquer equipe, individualmente ou acompanhadas de outras práticas, em qualquer metodologia de desenvolvimento de software, e com certeza vão mostrar resultados interessantes se usadas adequadamente.

São baratas, simples, fáceis de implementar e com um retorno muito alto na relação custo/benefício.

Fico aberto para críticas, sugestões e comentários de todas as naturezas. Obrigado

Inspiração e fontes:
Manifesto ágil: http://agilemanifesto.org/
Os doze princípios: http://agilemanifesto.org/principles.html

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Outro dia estava enviando um e-mail com anexo e sem querer descobri um defeito no GMail. Alias, para nós que desenvolvemos sistemas cada vez mais assíncronos, é um defeito até comum nos nossos próprios sistemas.

O defeito acontece no GMail, o sistema de gerenciamento de e-mails do Google. Apesar do defeito, eu devo admitir que eu nunca vi um sistema de gerenciamento de e-mail mais rápido e com usabilidade tão boa quando o GMail, final de contas, além da inovação essas duas características são as chaves do sucesso do Google.

Quando achei esse defeito, percebi que ele causava uma falha no Chrome, e testei também no FireFox e percebi que também acontecia. Nos outros dois Browsers que uso normalmente eu tentei algumas vezes e a falha não se manifestou.

Daí pensei, “Uma ótima forma de exemplificar o que é defeito e o que é falha”.

Seguindo as definições do ISTQB (International Software Testing Qualifications Board), um defeito é “Falha em um componente ou sistema que pode fazer com que o componente ou sistema falhe ao desempenhar sua devida função.” considera ainda “Um defeito, se descoberto durante a execução, pode causar uma falha no componente ou sistema.”. Uma falha por sua vez é definida como “Desvio do componente ou sistema da entrega, resultado ou serviço esperado. [FENTON]” e um erro é definido como “Ação humana que produz resultados incorretos.[IEEE]“.

Simplificando vamos falar que “Um erro cometido por uma pessoa gera um defeito em um produto, que pode ser manifestado na forma de uma falha em um software”.

Lembrando que todo software tem defeitos, mas nem todo software apresenta falhas.

Abaixo um passo a passo com imagens sobre o defeito no GMail até a manifestação da falha no Google Chrome:

1-Solicite Compose Mail.

2-Informe um Subject e um contato para envio do e-mail (To).

3-Pressione send.

4-Antes que o comando send seja executado, solicite Attach a file.

5-Selecione um arquivo como anexo. O tempo correto para isso é entre 3 e 8 segundos.
-Pode observar que o fundo volta a ser a lista de e-mails, como se o e-mail já tivesse sido enviado

Então a falha se manifesta:

Em resumo, o defeito existe no GMail. Para corrigir ele poderia existir uma validação que ao clicar em enviar, mesmo com o time de envio, o link de Attach a file ficasse desabilitado por exemplo, evitando que um usuário chato ou um testador sem o que fazer no fim de semana identificasse esse defeito

Obs: Google é na minha opinião a maior referência de qualidade de software, mas todos nós somos vulneráveis a cometer erros e deixar passar defeitos em nosso controle de qualidade.

A mesma falha acima acontece no FireFox, mas não consegui reproduzir no Internet Explorer nem no Safari.

Outras manifestações:
Se esperarmos menos de 3 segundos normalmente a falha não ocorre.
Se esperarmos mais de 10 segundos (tempo necessário para enviar o e-mail definitivamente para quem usa o labs: Undo Send) o Chrome eventualmente trava e é necessário reiniciá-lo.

Até mais e bons testes

Como todos sabem, o TestLink é uma ferramenta OpenSource para gerencia de Testes de Software com inúmeras funcionalidades já desenvolvidas e homologadas, mas como todas as ferramentas do mundo, não atende, por si só, todas as necessidades de uma empresa ou de um processo, por isso, a algum tempo vendo estudando os padrões dessa ferramenta e as oportunidades de melhoria.

Uma das melhorias, foi a inclusão do escopo dos requisitos no plano de teste, que já documentei no post “Exibindo corpo dos requisitos nos relatórios do TestLink“, para a versão 1.8.3, inclusive essa modificação está presente nos fontes que estão disponíveis no final desse post atualizadas para a versão 1.8.4 (incluindo as modificações descritas abaixo).

Outra razão me levou modificar a estrutura do testlink, e essa modificação eu acredito ser mais interessante que a anterior.

O testlink possui duas funcionalidades que não são integradas. Uma é o relatório de execução de teste ou simplesmente “Relatório de Teste” e a outra é o anexo de arquivos após a execução dos testes.

Para exemplificar eu criei um projeto chamado “Favorite series” e algumas suítes de teste com nomes de alguns seriados que eu assisto como The Big Bang Theory, Dexter, Flash Foward etc. Optei por usar esses casos de teste para esquecermos um pouco a implementação dos casos de teste e observarmos a nova funcionalidade sem distrações.

“Executei os testes” desse projeto e tentei cobrir as 3 condições:
-Execução sem evidência: Quando não temos evidências anexadas a execução do caso de teste
-Evidência no formato de imagem: Quando anexamos por exemplo, “o print da tela”
-Evidência em formato diferente de Imagem: Quando anexamos um arquivo qualquer como xml, rar etc.

Outras hipóteses também demonstradas:
-Quando temos múltiplas evidências
-Quando temos múltiplas evidências de tipos diferentes
-Quando temos Título na evidência
-Quando não temos Título na evidência

Primeiramente, vamos entender como é o relatório:
O TestLink nos disponibiliza a opção de emitir o relatório para execução dos testes com as seguintes  sessões:
-Mostrar índice: Exibe o índice por suítes de teste
-Descrição da Suíte de Teste: Exibe a descrição que cadastramos na criação das Suítes
-Mostrar Pré-condição: Exibe as pré-condições dos casos de teste
-Mostrar corpo do caso de teste: Exibe o passo a passo dos casos de teste
-Palavras-Chave relacionadas ao CT: Exibe as palavras chave que estão vinculadas ao caso de teste
-Campos personalizados do caso de teste: Exibe os campos customizados dos casos de teste
-Requisitos Relacionados ao CT: Exibe o título requisitos vinculados a cada caso de teste
-Corpo dos requisitos do caso de teste(*): Exibe o escopo dos requisitos vinculados aos casos de teste
-Resultado testes: Exibe o status da ultima execução do caso de teste
(*)  - Essa funcionalidade não é nativa do TestLink, para mais informações clique aqui.

Abaixo um exemplo que está descrito acima:

Se imprimirmos a suíte de teste “The Big Bang Theory” nesse modelo temos o seguinte relatório:
* A cor vermelha no Último Status “Com falha” é outra melhoria que ainda estou terminando.

As informações acima são suficientes para sabermos quem executou o caso de teste, se ele foi ou não aprovado e em qual release ele foi executado, mas para ser mais completo poderia exibir a evidência para facilitar a identificação do defeito ou para provar a execução do teste já nesse relatório.

Por esse motivo, incluí uma nova opção chamada “Evidências de teste” de acordo com a imagem abaixo:

O mesmo relatório apresentado acima, agora exibindo as evidências de teste:
Exibição da evidência sem título:
Exibição da evidência de teste com título:

*Dividi em duas imagens para facilitar a visualização e exemplificar duas situações.

Agora vou mostrar outros exemplos atendendo a nossas situações acima:
-Quando não temos evidências anexadas a execução do caso de teste

-Quando anexamos um arquivo qualquer como xml, rar etc. / Quando temos múltiplas evidências

A customização acima pode ser implementada em qualquer TestLink com algumas adaptações, ou na versão 1.8.4 apenas usando os arquivos abaixo:

Arquivos modificados:
.\testlink\lib\functions\print.inc.php
.\testlink\lib\results\printDocument.php
.\testlink\lib\results\printDocOptions.php
.\testlink\locale\pt_BR\strings.txt
.\testlink\gui\javascript\testlink_library.js

Os arquivos cima estão disponíveis para downloado no pacote Evidence.zip disponível no final do post.

Modificações:

print.inc.php
Nesse arquivo é que fazemos a maior parte das modificações, na verdade, aqui é que estão as verdadeiras modificações.
Vou separar as modificações desse arquivo em três partes:

Parte 1 :  Inclusão da Label “test_evidence”, “without_evidence” e “not_img”
Incluímos a label “test_evidence” para que a modificação fique no padrão mult-language do TestLink.

Parte 2 :  Inclusão da dos filds typeEvidence, FilePath, file_name, atttitle e de multiple touples
Incluímos os seguintes campos:

typeEvidence: tupla que indica qual o tipo da evidência (anexo).
FilePath: caminho da evidência (anexo)
file_name: nome da evidência (anexo)
atttitle: Título da evidência (anexo)
Também mudamos o terceiro parâmetro do “get_recordset” para 999 para que exiba mais de uma evidência.

Parte 3 : lógica de exibição
Aqui informamos quando as evidências que serão exibidas , os títulos e a formatação apresentada.

Também usamos uma comparação para determinar quais são as evidências que devem ser apresentadas na linha 608.
Note que hoje, a customização aceita 3 tipos de imagens, PNG, JPG e BMP.
-Sugiro usar somente png, pois ocupa menos espaço que bmp e tem mais qualidade que jpg.

printDocument.php
Nesse arquivo vamos tornar a implementação disponível de acordo com a necessidade, incluindo no array uma nova posição chamada evidence.

printDocOptions.php
Nesse arquivo vamos tornar a implementação disponível de acordo com a necessidade, incluindo uma opção de exibir ou não as evidências de teste.

strings.txt
Nesse arquivo incluímos a string “test_evidence” para atender ao padrão multilanguage do TestLink

testlink_library.js
Nesse arquivo incluímos a opção de Evidência de teste para funcionamento do extJS

Arquivos Fontes: Evidence.zip

ATENÇÃO: O implementado acima foi testado e homologado por mim e algumas pessoas da minha equipe, ainda existem bugs conhecidos, mas nenhum que tenhamos considerado crítico. Algumas das funcionalidades implementadas ainda não estão de acordo com o padrão do TestLink e futuramente uma nova implementação para corrigir esses problemas. Caso tenha deseje essas melhorias, sugiro que me encaminhe um e-mail (camilo@camiloribeiro.com) solicitando ou e acompanhe a publicação no meu blog (blog.camiloribeiro.com). Caso encontre algum defeito ou tenha uma sugestão de como essa “melhoria pode ser melhorada” pode ser encaminhada também. Antes de qualquer modificação, eu sugiro fortemente que sejam feitos os backups, testes em um ambiente diferente do de produção e que a melhoria/atualização seja feita por uma pessoa com conhecimentos em PHP, MySQL e preferencialmente do próprio TestLink. Não me responsabilizo pelas modificações, mas fico disponível a ajudar em eventuais problemas ou mesmo a prestação de consultoria acordada em todo o Brasil.

Outras observações:
-Funciona somente para versão do relatório HTML. (não para Word, Writer, etc)
-Homologada somente para pt_br.
-Versões 1.8.3 e 1.8.4

Gostaria de avaliar essa melhoria ou experimentar o testlink antes de gastar tempo estudando a ferramenta?
Acesse: http://testlink.camiloribeiro.com
Usuário: visitante
Senha: visitante*2009

Obrigado por experimentar com responsabilidade!
Aproveite para me indicar defeitos encontrados e sugerir melhorias. Obrigado!

Caso tenha interesse em implementar essa funcionalidade ou outra qualquer nos sistemas TestLink, Bugzilla ou Mantis, eu ficarei disponível para ajudar ou colaborar em qualquer aspecto

Bons Testes

Agradecimento especial:
Vanessa Vaz pela revisão do post.

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

O nosso amigo Cristiano Caetano, uma das referencias em teste de software no Brasil, está desenvolvendo a pesquisa de cardos e salários de 2010.

Ele já desenvolveu pesquisas em anos anteriores que foram publicadas para todos os usuários da comunidade de teste de software testexpert.com.br.

“Esta pesquisa se propõe a desenhar o mapa dos profissionais de teste e qualidade de software do Brasil. Considerando que a área de teste e qualidade de software é uma das áreas em franca expansão da atualidade, o resultado dessa pesquisa será de grande interesse para todos vocês.”

É importante participar, para conhecermos o mercado, os papeis que são mais valorizados, as certificações, regiões e o número de analistas e testadores.

Ter um mapa do profissional de teste de software é um passo fundamental para que possamos traçar nossas metas e objetivos nesse ano.

A pesquisa é muito rápida, tem poucos campos e é totalmente anônima.

Para preencher a pesquisa, acesse o seguinte endereço:
http://www.testexpert.com.br/pesquisa/index.php?sid=35766&lang=pt

A pesquisa ficará aberta para preenchimento até março e os resultados serão divulgados no portal TestExpert.com.br.

A participação de todos é fundamental.

Para conhecer a versão anterior dessa pesquisa acesse:
http://www.testexpert.com.br/?q=node/231

Vamos construir um lugar melhor para o profissional de qualidade de software no Brasil.