The Bug Bang Theory

(8 votes, average: 9,63 out of 10)

 Loading ...

A especificação de cenários e casos de teste é uma das atividades mais abrangentes entre os analistas de teste.

Existem dezenas de técnicas de especificar casos de teste e cenários de teste, algumas baseadas em casos de uso (como essa), outras baseadas em engenharia reversa, outras em componentes visuais (tela) e assim por diante.

A pedido de um leitor do meu blog, o Heiber, da cidade de Bogotá na Colômbia, que faz um esforço para entender meus textos “mediamente” elaborados em português e um esforço possivelmente maior para conversar comigo em espanhol, vou disponibilizar um rascunho de uma das técnicas que uso para modelar cenários e casos de teste (ou casos de prueblas em espanhol).

Para isso vamos imaginar um típico caso de uso, bem simples. Digamos que ele possui algumas regras, um fluxo principal, alguns alternativos, outros de exceção e pontos de extensão. A primeira coisa a fazer, supondo que o caso de uso já tenha sido aprovado em revisões e outros procedimentos para garantir que esteja preparado para ser implementado, é ler atenciosamente o caso de uso, tentando entender bem o contexto e seus objetivos. Em seguida, criar um desenho dos fluxos que esse caso de uso possui, bem abrangente, se possível com todos os fluxos desenhados no mesmo lugar, como um mapa mundi do caso de uso. Para isso é recomendável usar um diagrama de atividades disponível em qualquer ferramenta case open source na internet, mas em qualquer situação, pode ser feito no “papel de pão mesmo”.
Nesse momento temos algo mais ou menos como a figura abaixo:

Esse “esqueleto” nos da uma idéia um pouco próxima do que precisamos para mapear os casos de teste, mas ainda é insuficiente para dizer o que temos de cobertura com as regras de negócio vinculadas ao caso de uso.

Existe uma prática muito comum que é criar um caso de teste para cada regra do caso de uso, que inclusive é a mais recomendada em casos de sistemas críticos onde temos muitas horas para especificar e testar, mas, muitas vezes temos de usar uma técnicas chamada “pair wise” para especificar nossos casos de teste. Nesse exemplo, os cenários de teste permitem que os dois modelos sejam aplicados, comum caso de teste por regra ou tendo em um único fluxo, várias regras:

*Supondo que a regra R06 foi cancelada

O diagrama acima nos mostra os vários caminhos possíveis para o mesmo caso de uso. É importante que nenhuma regra possa modificar o fluxo do caso de uso. Regras com condições como “Se . . . então . . .  senão. . .” podem ser muito prejudiciais aos casos de uso, escondendo a complexidade e induzindo a modelagens incorretas.

Agora vamos dar um nome para cada um dos cenários, baseando em seu significado no caso de uso:

Com o desenho acima podemos entender melhor cada cenário e seu fluxo. Ainda podemos ver que cenários podem ser combinados resultando em novos cenários, como por exemplo, o FA02 que pode continuar no FA03 ou pode voltar para o FP.

Por ultimo, consolidamos as duas visões e “voilà“,  temos boa parte do que precisamos para escrever bons casos de teste.

A partir do desenho acima já podemos especificar vários casos de teste, com entradas diferentes e saídas diferentes, com validações para cada uma das regras ou para múltiplas regras. A configuração daqui para frente, depende muito do nível de detalhamento que será usado, mas a rastreabilidade continua sendo a mesma:

{N Procedimentos**, Entradas e Saídas} ∈ {1 Caso de Teste}
{N Casos de Teste} ∈ {1 Cenário de Teste}
{N Cenários de Teste} ∈ {1 Caso de Uso}
*∈ = Pertence

**O conceito de procedimentos de teste é um dos mais confusos. No dia a dia eu uso ele para chamar o passo a passo dos casos de teste.

O desenho acima foi feito com caráter ilustrativo e para isso foi usado o MS Power Point, mas eu recomendo a utilização de ferramentas apropriadas como o IBM – Rational Software Architect ou o Enterprise Architecture.

Desenhar os cenários e casos de teste é uma coisa que fazemos mesmo que mentalmente quando especificamos, mas é muito importante ter um esboço físico dessa atividade, para perceber falhas, minimizar riscos e compreender melhor o que será testado.

Espero que esse post possa ajudar pessoas com a mesma dúvida do nosso amigo da Colombia. O modelo acima é um dos mais usados e é muito eficiente, mas é um modelo de muitos disponíveis no maravilhoso mundo da engenharia de software.

Fico aberto a comentários, críticas e sugestões.

Bons testes

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

(5 votes, average: 9,80 out of 10)

 Loading ...

A maioria dos analistas de teste e testadores não sabe onde estão o defeito que eles encontram, ou em outras palavras, não analisam nem acompanham o defeito após encontrá-lo, ou quando fazem, podem fazer de maneira incorreta, o que de certa forma é mais prejudicial do que se não fizessem.

Na verdade, é quase impossível, até mesmo para um analista de teste experiente dizer com certeza que o defeito que ele encontrou é de software, requisitos, análise, desenho, configuração etc. Os defeitos mentem, e isso é um fato que vamos ter que conviver cada vez mais, já que a cada dia a complexidade dos projetos de software aumenta e com ela a complexidade dos defeitos e da arquitetura do software em desenvolvimento.

A atividade de gerência de defeitos é uma das atividades mais importantes para o projeto e principalmente para a organização. Com uma boa gerência de defeitos, vários indicadores podem ser utilizados para conhecer e melhorar os processos e a capacitação dos profissionais.

Alguns dos indicadores* são:

•TD (Total de Defeitos)
•DD (Detecção de Defeitos)
•DDG (Detecção de Defeitos Graves)
•TDG (Total de Defeitos Graves)
•ETS (Eficiência de Teste de Software)
•ERR (Eficiência de Revisão de Requisitos)

*Em um próximo post vou falar sobre métricas e indicadores.

Apesar de ser uma ferramenta muito importante, a gerência de defeitos muitas vezes é usada de forma incorreta ou não é aproveitado o seu potencial, ficando limitada a um workflow do Bugzilla ou do Mantis.

Como os defeitos não são analisados, as pessoas não se importam com onde eles foram encontrados, nem com quando eles foram encontrados, até o dia que um determinado projeto está com problemas e alguém pede uma métrica de “bugs” por desenvolvedor, normalmente solicitado por uma pessoa que não tem experiência como analista de testes ou está iniciando na carreira de coordenador/gerente de projetos.

Esse é o grande perigo. Como citado no post Bug is Dead!, a idéia de “bug” da uma impressão muito ruim dos desenvolvedores, pois bugs são de software, e software quem faz são os desenvolvedores e programadores. O ideal para evitar esse tipo de mal entendido, é catalogar os defeitos de forma a saber de onde eles vieram e não quem causou o defeito.

Nenhum defeito pode ser atribuído somente a uma pessoa no projeto, mas sempre a um conjunto de eventos, que, de não conseguiram evitar que esse problema fosse inserido em determinado momento do processo.

Agora vou dizer uma coisa que pode te assustar prezado leitor:

A identificação da origem do defeito não é de responsabilidade do profissional que encontrou o defeito.

Muito simples, o profissional de testes ou quem encontrou o defeito, não pode saber claramente a sua origem, não pode dizer com certeza absoluta onde o defeito estava. Se estava no código, se era no ambiente, uma configuração do servidor, um problema de compatibilidade etc.

A única pessoa que tem essa informação é quem corrige o defeito. Ele é o único que sabe com 100% de certeza onde o defeito estava.

A responsabilidade de acompanhar essa informação e de garantir sua integridade sim, é de responsabilidade do gerente de defeitos, que normalmente é uma pessoa da qualidade ou teste de software. Por isso é importante acompanhar o andamento dos defeitos, preferencialmente todos os dias, de forma a manter o controle e rastreabilidade entre o defeito e sua origem.

Outra situação que acontece com frequência com novos testadores, é que assim como a nossa querida Tia Cida que sem querer escreveu “Café com defeito” quando na verdade o defeito estava no repositório de colheres da máquina de café. É um exemplo bobo e divertido, mas muito próximo do que acontece com algumas pessoas. Por vezes, os defeitos são descritos de forma pouco detalhada, com informações insuficientes para sua reprodução, com falta de atenção ou as vezes detalhado demais, dificultando sua interpretação.

Não existe uma forma de garantir que a descrição do defeito esteja perfeita, mas uma técnica que venho usando com sucesso é a substituição do passo a passo pelos procedimentos (passo a passo) do caso de teste que detectou o defeito.

Dessa maneira, a pessoa que corrigiu o defeito executa um teste de regressão e não um teste de confirmação. O mesmo acontece quando o testador recebe o defeito para verificar/validar, ao invés de executar um teste de confirmação, limitado as condições únicas daquele defeito, ele executa um teste de regressão, garantindo que aquela funcionalidade continua funcionando mesmo após a correção daquele defeito.

Caso o teste tenha sido detectado por um teste exploratório, o testador pode criar um Caso de Teste numa suíte especial, para aquele defeito (considerando o resultado esperado), e somente em seguida deve cadastrar o defeito na ferramenta de gestão de defeitos. Essa é uma pratica do XP que também da muito certo.
*O detalhamento dessa e outras práticas pode ser lido no post “Práticas XP ajudando na efetividade do teste de software“.

Bons Testes

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

(3 votes, average: 10,00 out of 10)

 Loading ...

Hoje eu resolvi escrever uma historinha 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

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

(No Ratings Yet)

 Loading ...

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

(No Ratings Yet)

 Loading ...

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

(1 votes, average: 10,00 out of 10)

 Loading ...

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