Monster Bug

Evento - TDC 2012 - Florianópolis

noreply@blogger.com (Maira Stella da Silva) — Sun, 05 Aug 2012 18:54:00 +0000

Nos dias 24, 25 e 26 de agosto acontece o evento The Developer's Conference em Florianópolis. O evento é dividido em 7 trilhas por dia, num total de 21 trilhas com assuntos diferentes, além das trilhas Stadium que são uma seleção de palestras das trilhas do dia e acontece num auditório. As inscrições pelo valor de R$ 40,00 encerram hoje.

Ano passado eu participei da trilha de testes, e foi muito interessante. Aprendi muita coisa nova, conheci muita gente disponível para trocar conhecimento, e foi o que me motivou a criar o blog.

Informações sobre o evento:

Como é uma trilha ?

Cada trilha na agenda do evento é realizada em uma sala e tem um dia inteiro de palestras. As trilhas Stadium são um mix de todas as trilhas do dia, são realizadas no auditório principal e abertas para que todos inscritos no evento possam aproveitar um pouquinho das outras trilhas.

O que são as trilhas University ?

As trilhas University são destinadas a estudantes e profissionais que estão iniciando na tecnologia discutido na trilha. As palestras têm nível mais introdutório, foco educacional e sempre que possível prático. Para que os participantes possam encerrar o dia com sentimento de aprendizado e ainda mais motivados.

Especial para estudantes

Estudante com carteira de estudante e aluno da Globalcode paga meia nas trilhas University!

Antes de fazer sua inscrição, é necessário solicitar seu código promocional enviando cópia de sua carteira de estudante para tdc@globalcode.com.br. Não faremos devolução após a inscrição feita.

E para quem quiser palestrar, basta clicar aqui e submeter as informações sobre a palestra.

Estudando para a Certificação CTFL - Quarto Capítulo Parte II

noreply@blogger.com (Maira Stella da Silva) — Tue, 24 Jul 2012 01:57:00 +0000

Continuação do resumo do quarto capítulo do syllabus CTFL.

Técnicas baseadas em estrutura ou caixa-branca

Nível de componente
- A estrutura é o próprio código.

Nível de integração
- A estrutura pode ser uma árvore de chamadas.co

Nível de sistema
- A estrutura pode ser a estrutura da página.

Teste e cobertura de sentença
- A cobertura de sentença é avaliada pela porcentagem de sentenças executáveis por um conjunto de casos de testes;

Teste e cobertura de decisão
- Porcentagem dos resultados da decisão;

Gerenciamento do Teste

Os principais benefícios da independência da equipe de testes são:

- Imparcialidade;

- Enxergar defeitos;

Tarefas do Líder de Testes

- Planejamento, monitoração e controle;

- Coordernar estratégias de testes;

- Escrever ou revisar uma estratégia de testes;

- Planejas os testes;

- Preparar o gerenciamento de configuração do testware;

- Métricas para avaliar o progresso dos testes;

- O que pode ser automatizado;

- Relatório com base nas informações obtidas;

Tarefas de um Testador

- Revisar e contribuir no planejamento;

- Analisar, revisar os requisitos do usuário;

- Especificação de testes;

- Configurar o ambiente de teste;

- Implementar os testes em todos os níveis;

- Utilizar ferramentas (quando necessário);

- Automatizar testes;

- Rever testes desenvolvidos por outras pessoas;

Só para reforçar, os resumos são apenas para relembrar o que deve ser estudado no Syllabus.
;D

Estudando para a Certificação CTFL - Quarto Capítulo - Parte I

noreply@blogger.com (Maira Stella da Silva) — Wed, 30 May 2012 03:47:00 +0000

Resumo sobre o quarto capítulo do syllabus, que trata a respeito de técnicas de modelagem de testes.

Durante a modelagem são criados os casos de testes e os dados de testes. Os casos de testes devem possuir as seguintes informações:

- Valores de entrada;
- Pré-condições;
- Resultados esperados (devem ser definidos antes da execução dos testes);
- Pós-condições;

O padrão IEEE 829-1998 define a documentação.

Categoria das técnicas de modelagem de testes

Testes de caixa-preta

Nos testes de caixa-preta, a estrutura interna do sistema é desconsiderada. Testa-se apenas o que é visível ao usuário. Engloba tanto os testes funcionais como os não funcionais.

Testes de caixa-branca

O teste de caixa branca é baseado na estrutura interna do software. Pode ser chamado de teste de estrutura.

Técnicas baseadas em caixa-preta

Partição de equivalência

- As entradas do sistema são divididas em grupos que tenham um comportamento familiar;

- Pode ser um conjunto de dados válidos, ou dados inválidos (rejeitados pelo sistema);

- Aplicável a todos os níveis de testes;

Análise do valor limite

- Nos limites de uma partição de equivalência é onde existe maior probabilidade para identificar defeitos;

- Valores máximos e mínimos;

- Valores válidos e inválidos;

- Pode ser aplicada em todos os níveis de testes;

Tabela de decisão

- Podem ser usados para regras de negócio;

- As condições de entradas são declaradas como verdadeiro ou falso;

- Cada coluna possui uma regra de negócio que define uma única combinação que resulta na execução de ações;

- A tabela cria combinações que geralmente não foram exercitadas durantes os testes;

Teste de transição de estados

- Permite ao testados visualizar o software em termos de estado;

Teste de caso de uso

- O caso de uso possui pré-condições que precisam ser garantidas que funcionem;

- Casos de testes baseados em casos de uso facilitam na descoberta de defeitos durante a utilização do sistema no mundo real;

Estudando para a Certificação CTFL - Terceiro Capítulo

noreply@blogger.com (Maira Stella da Silva) — Wed, 30 May 2012 00:56:00 +0000

Resumo do terceiro capítulo do syllabus, referente a técnicas de testes estáticos.

Os testes estáticos não pressupõem a execução do sistema. Podem ser manuais, revisões em documentações, ou automatizadas através da análise estática.
A revisão pode ser realizada bem antes da execução dos testes dinâmicos. Quanto antes, no ciclo de desenvolvimento, for identificado o defeito, mais barato será para corrigir.

Benefícios da revisão:
- Detecção e correção antecipada de defeitos;
- Redução do tempo no desenvolvimento;
- Redução do custo e tempo de teste;
- Menos defeitos;
- Melhoria na comunicação;

Processo de revisão

Planejamento
- Definir critérios de revisão;
- Selecionar equipe;
- Alocar funções;
- Definir critérios de entrada e de saída;
- Selecionar quais partes do documento serão revisadas;
- Checar critérios de entrada;

Kick-off
- Distribuir documentos;
- Explicar os objetivos;

Preparação individual
- Análisa da documentação;
- Anotar os defeitos em potenciais, questões e comentários;

Reunião de revisão
- Discussão ou registro, com resultados documentados;
- Anotar os defeitos e fazer recomendações para o tratamento de defeitos;
- Examinar, avaliar e registrar questões durante a reunião;

Retrabalho
- Resolver defeitos encontrados, tipicamente feitos pelo autor;
- Registrar os status atuais dos defeitos;

Acompanhamento
- Checar se os defeitos foram encaminhados;
- Obter métricas;
- Checar os critérios de saída;

Tipos de revisão

Revisão informal

- Pode haver programação em pares ou um líder técnico revisando a modelagem e o código;

- Documentação opcional;

- Dependendo do revisor, a importância pode variar;

- Principal propósito: Uma forma de obter algum benefício a baixo custo;

Acompanhamento

- A reunião é conduzida pelo autor;

- Cenários, grupos de discussão e exercícios práticos;

- Sem restrição de tempo;

- Opcionalmente há um redator;

- Pode variar de informal para formal;

- Principal propósito: aprendizagem, obtenção de entendimento e encontrar defeitos;

Revisões técnicas

- Documentado;

- Processo de detecção de defeitos;

- Idealmente deve ser conduzido por um moderador;

- Preparação dos revisores;

- Elaboração do relatório de revisão, contendo informações sobre a lista de defeitos encontrados, se o software corresponde aos requisitos;

- Pode variar de informal para formal;

- Principais propósitos: discussão, avaliar alternativas, encontrar defeitos, resolver problemas técnicos e checar a conformidade;

Inspeção

- Conduzida pelo moderador;

- Análise por pares;

- Utilização de métricas;

- Processo formal baseado em check-list;

- Entradas especificadas e critérios de saída para a aceitação do produto;

- Acompanhamento formal;

- Principal propósito: encontrar defeitos;

Análise estática

- Encontrar defeitos no código fonte do software e na modelagem;

Benefícios

- Detecção de defeitos antes da execução do teste;

- Identificação de defeitos dificilmente encontrados por testes dinâmicos;

- Prevenção de defeitos se as lições forem aprendidas pelo desenvolvimento;

Defeitos mais comuns descobertos por ferramentas de análise estática:

- Referências a uma variável com valor indefinido;

- Código morto;

- Inconsistências entre as interfaces dos módulos e componentes;

- Vulnerabilidade na segurança;

Ferramentas de análise estática são tipicamente usadas por desenvolvedores.

Estudando para a Certificação CTFL - Segundo Capítulo

noreply@blogger.com (Maira Stella da Silva) — Mon, 28 May 2012 04:05:00 +0000

Continuando os resumos do syllabus para a CTFL:

O segundo capítulo aborda informações sobre os níveis de testes, tipos de testes e teste de manutenção. Abaixo, segue uma breve descrição e resumo sobre cada item:

Níveis de Testes

Teste de Componentes

- Os testes de componentes ocorrem com acesso direto ao código;

- Verifica o funcionamento do software através de módulos, objetos, classes, e são testados separadamente;

- Envolve o desenvolvedor;

- A correção geralmente é realizada no momento da identificação do defeito, e não há documentação ou registros formais de incidentes;

- TDD (Test Driven Development);

Teste de Integração

- Testa-se a interface entre os componentes, interações de diferentes partes de um sistema;

- Testar a integração entre os diferentes componentes do software, e geralmente é realizado após os testes de componentes;

- Teste de integração para verificar as interações entre diferentes sistemas. Pode ser realizado após os testes de sistemas;

- Quanto maior o escopo de testes de integração, maior será a dificuldade para encontrar e isolar o defeito;

Teste de Sistema

- Refere-se ao comportamento de todo o sistema, definido pelo escopo do projeto;

- O ambiente de teste deve simular ao máximo o ambiente de produção;

- Podem ser baseados em: especificação de riscos, ou requisitos, processos de negócios e casos de uso;

Teste de Aceite

- Frequentemente é de responsabilidade do usuário;

- Estabelecer confiança no sistema;

Formas de teste de aceite:

- Teste de aceite do usário;

- Teste operacional de aceite;

- Teste de aceite de contrato e regulamento;

- Alfa e Beta Teste;

Tipos de Testes

Teste de função (teste funcional)

- Testes baseados nas funções descritas em documentos;

- Pode ser realizado em todos os níveis de teste;

- Considera o comportamento externo do software (caixa-preta);

Técnicas de teste funcional:

- teste de controle;

- teste de interconexão;

- teste paralelos;

- teste de requisitos;

- teste de regressão;

- teste de suporte manual;

- teste de tratamento de erros;

Teste de características do produto de software (testes não funcionais)

- É o teste de "como" o sistema trabalha;

- Pode ser realizado em todos os níveis de teste;

- Medir as características;

- Modelo de qualidade: ISO 9126

Técnicas de teste não funcional:

- teste de performance;

- teste de carga;

- teste de estresse;

- teste de usabilidade;

- teste de interoperabilidade;

- teste de manutenibilidade;

- teste de confiabilidade;

- teste de portabilidade;

Teste de estrutura (teste estrutural)

- Caixa-branca;

- Pode ser feito em todos os níveis de teste;

- Baseado na arquitetura do sistema;

Teste relacionado a mudanças (teste de confirmação e regressão)

- O teste de confirmação certifica que um defeito encontrado foi realmente resolvido e removido;

- Teste de regressão: teste repetido de um sistema, após sua modificação, para descobrir a existência de algum defeito que pode ser originado;

- Realizado quando o software ou ambiente é modificado;

- Forte candidato a automação;

- Podem ser realizados em todos os níveis de testes;

Teste de Manutenção

- Após o sistema ser desenvolvido e estar disponível em produção, o mesmo poderá sofrer manutenções periódicas, seja para acrescentar melhorias, ou para corrigir defeitos não detectados anteriormente;

- Além de ser testada a modificação realizada no software, o teste de manutenção inclui testes massivos de regressão;

- O escopo do teste está diretamente relacionado com os riscos que a versão de melhoria ou corretiva poderá causar;

Estudando para a Certificação CTFL - Primeiro Capítulo

noreply@blogger.com (Maira Stella da Silva) — Mon, 30 Apr 2012 04:10:00 +0000

Estou me preparando para a certificação CTFL - Certified Terster Foundation Level da ISTQB - International Software Testing Qualifications Board, e pensei: por que não escrever no blog um resumo do capítulo que estou estudando? Pra mim, funciona muito bem a regra de aprender ensinando. Enfim, ao terminar de estudar cada capítulo, vou atualizar o blog, e com isso, espero poder ajudar quem está se preparando para a prova também. Como a minha memória é muito visual, eu vou usar esquemas para facilitar o entendimento.

As informações foram retiradas da apostila de certificação, versão 2011br.

Testes no Internet Explorer: Brace Yourself

noreply@blogger.com (Maira Stella da Silva) — Tue, 17 Apr 2012 01:06:00 +0000

Quando chega o momento em que é necessário iniciar os testes no Internet Explorer, essa é a minha reação:

Talvez eu esteja sendo injusta, afinal de contas, o IE está melhorando aos poucos nas versões mais recentes. Mas para desenvolvedores e testadores, o lançamento de versões pode ser a causa de trabalho dobrado, pois o layout pode funcionar na versão mais recente, mas na anterior pode ficar totalmente desconfigurado. O número de usuários que navegam pelo IE é consideravelmente alto, 56% ainda o utilizam. Além desse fato, é necessário considerar que muitos dos usuários demoram para atualizar a versão, então, não nos resta opção, a não ser testar o site em mais de uma versão do IE. Simples, não é mesmo? Não. Uma vez instalada a versão mais recente do nosso querido navegador, as anteriores são totalmente substituidas, obviamente. Uma primeira alternativa para ter acesso a várias versões do navegador seria através da máquina virtual e a outra alternativa seria instalar o IETester.

O IETester é uma ferramenta free para Windows, que contém desde a versão 5 do Internet Explorer até a versão 9. No sistema, é possível abrir abas com todas as versões, e acessar o site a ser testado.

Mas para testes automatizados, há apenas a opção de máquina virtual.

Além de simular as várias versões do Internet Explorer, há ferramentas para o desenvolvedor, como por exemplo, visualizar o código fonte.

Você poderá realizar o download clicando aqui.

Usabilidade - Técnica de Observação

noreply@blogger.com (Maira Stella da Silva) — Thu, 12 Jan 2012 01:27:00 +0000

Olá pessoal,

A observação do usuário interagindo com o sistema é uma técnica muito eficaz quando existe a necessidade de melhorar a usabilidade de interação entre o usuário e o software.

É importante selecionar usuários com níveis de conhecimentos diferenciados, e principalmente, focar nos perfis de usuários que mais farão uso do sistema. Por exemplo, se o sistema será disponibilizado para consultas de produtos em supermercados, os perfis de usuários são abrangentes, mas provavelmente o público maior serão donas de casas que tem pouca familiaridade com tecnologia. Depois de definir os perfis dos usuários para a técnica de observação, é necessário preparar o ambiente. Certifique-se de que o sistema esteja funcionando corretamente, e garanta as condições necessárias para que a cobaia, ou melhor, o colaborador, possa se sentir a vontade. Outra etapa que pode ser incluída na preparação do ambiente é a elaboração de scripts contendo tarefas. Com os scripts elaborados é mais fácil de identificar em que parte do sistema há mais dificuldade de interagir, e o usuário não fica sem rumo, clicando na primeira opção que aparece. A tarefa pode ser: "cadastre-se no site" e durante a técnica, o observador detecta se o usuário demorou para achar o botão para se cadastrar ou se a tarefa como um todo demorou muito tempo para ser concluída.

Agora você já tem os usuários, o ambiente e os scripts, então o próximo passo é iniciar a técnica de observação. Durante a observação, o ideal é que o observador não interaja com o usuário, evitando influenciar ações que normalmente seriam tomadas sem a ajuda de alguém. Além do observador detectar as principais dificuldades, é necessário anotá-las, para posteriormente reportar ao setor de webdesigner e desenvolvimento, para que sejam realizadas as alterações necessárias.

Com a imagem do mapa mental abaixo, é mais fácil de visualizar o processo.

A técnica é simples, e o tempo de conclusão depende do tamanho do script e do tamanho do sistema. Mas o mais importante nessa técnica, é o fato de poder identificar o que pode ser feito para melhorar a qualidade do sistema, conforme as reais necessidades e conhecimentos dos usuários. Para quem está muito familiarizado com o sistema, não faz diferença se um botão está posicionado discretamente, enquanto deveria ter mais destaque.

Clicando aqui você poderá conferir uma entrevista feita com a antropóloga britânica Charline Poirier sobre um estudo de usabilidade no Ubuntu, conduzido aqui no Brasil.

Amor a primeira vista!

noreply@blogger.com (Maira Stella da Silva) — Tue, 29 Nov 2011 12:58:00 +0000

Eu preciso me declarar! Não posso mais esconder esse amor!

No início eu tive uma mistura de sentimentos e emoções. Medo de assumir um compromisso, medo de não me adaptar as mudanças que com certeza seriam exigidas ao longo do tempo, assim como em todo relacionamento. Mas resolvi seguir meu coração, e hoje eu já não me imagino vivendo sem o seu companheirismo, praticidade, organização e cumplicidade. Testlink, eu te amo!

Foi simplesmente amor no primeiro acesso!

O Testlink é uma ferramenta open source para gerenciamento de testes. Permite que o usuário cadastre casos de testes, cadastre planos de testes, defina o escopo dos testes para uma determinada versão (release, build...), e durante a execução dos testes, é possível informar em quais houve falhas, e quais foram aprovados. Após finalizar o processo, o software também permite que o usuário gere relatórios contendo informações sobre os testes executados, a quantidade de casos em que houve erro, entre outras informações que auxiliam no feedback. O sistema apresenta muito controle sobre o processo, impedindo que o usuário execute um passo sem ter concluído o anterior. Por exemplo, o usuário só poderá cadastrar um release se a versão do projeto for cadastrada primeiramente.

A tela inicial do Testlink é extremamente simples.

O primeiro passo, é cadastrar um projeto (produto). Dentro desse projeto serão cadastrados os casos de testes, e posteriormente os planos de testes.

Para cadastrar um caso de testes, um dos projetos deverá estar selecionado. Depois é só clicar em "Test Specification", criar suites de testes (separação por módulos, para que fique mais organizado), e informar os dados para o cadastro. A etapa de cadastro do passo a passo também é muito simples e rápida.

Após cadastrar os casos de testes, você poderá cadastrar o plano de testes.

O plano de testes é composto por builds. Em cada build é possível determinar quais testes, dentro do conjunto de suites de testes, serão realizados.

Após selecionar e organizar cada build, inicia-se a etapa de execução.

Em cada caso de teste é possível especificar se o teste passou ou falhou.

E depois é só gerar relatórios!

Fluxograma do processo de testes no Testlink, que eu fiz e se encaixa na realidade em que eu trabalho:

É válido comentar que com o Testlink o processo de homologação se tornou mais rápido, mais confiável e muito mais organizado.

O que eu acho que poderia melhorar:

1. Contabilizar o tempo gasto para a execução de um determinado build/release.

2. A etapa toda poderia se tornar mais simples ainda, se após um determinado cadastro o sistema já redirecionasse para a próxima tela dando continuidade ao procedimento automaticamente.

Leitura interessante:

As Cinco Melhores Razões (Erradas) Para Você Não Ter Testadores

Evento PHPSC Conf 2011 na Univali

noreply@blogger.com (Maira Stella da Silva) — Wed, 16 Nov 2011 22:31:00 +0000

Olá pessoal!

O Grupo de Usuários de PHP de Santa Catarina (PHPSC), em parceira com a UNIVALI, estará realizando no dia 19/11 (sábado) o PHPSC Conf 2011 - Conferência Catarinense de PHP.

Programação (grade de palestras): http://www.phpsc.com.br/2011/11/programacao-phpsc-conf-2011/

Formulário de inscrição: http://www.phpsc.com.br/conf/inscricao.php

Inscrição: R$ 10,00

Minicurso: R$ 15,00

Os acadêmicos da Univali com comprovante de matrícula em mãos não pagam para assistir as palestras.

Sobre o grupo PHPSC

O Grupo de Usuários de PHP do Estado de Santa Catarina (PHPSC) é uma entidade aberta de profissionais da área de TI criada em 2007, que possui entre os seus participantes empresários, professores, profissionais de desenvolvimento, alunos e entusiastas de tecnologia. E que tem por objetivo promover o uso da tecnologia PHP e seus correspondentes no campo de software livre em todo o estado de Santa Catarina. Além de fomentar discussões sobre melhores práticas no desenvolvimento de software, testes de software e qualidade no desenvolvimento de sistemas. Outros objetivos específicos de atuação do grupo também incluem:

- Realizar eventos regionais no estado buscando a troca de experiência entre profissionais;

- Facilitar a procura por profissionais por empresas que necessitem de mão-de-obra;

- Divulgar vagas de trabalho existentes no estado;

- Atuar junto a outros grupos do Brasil para auxiliar na adoção do PHP como base tecnológica para o desenvolvimento de sistemas;

- Promover metodologias ágeis de desenvolvimento como Scrum e Extreme Programming no desenvolvimento de software;

- Atuar junto ao php.net na correção de problemas e sugestão de melhorias da linguagem;

- Auxiliar entidades públicas e privadas que buscam utilizar software livre e ter um contato com PHP.

- Buscar oportunidades de negócios entre os seus participantes;

Sobre o PHPSC Conf

O evento acontece anualmente, sempre em uma cidade diferente do estado, e é realizado em parceria com uma instituição de ensino do local do município aonde o mesmo venha a ocorrer.

Isto está de acordo com os objetivos do grupo, que é percorrer o Estado de forma que mais pessoas possam participar, apresentando o PHP através de profissionais que realmente utilizam a linguagem, e que levem a qualidade técnica das informações discutidas. Trazendo, para este fim, palestrantes de fora do estado e que são referência no Brasil, mas também contando com palestrantes locais. O evento não tem fins lucrativos.

Este evento também ajuda a divulgar a instituição de ensino onde o mesmo é realizado, além do que palestrantes (professores e alunos) desta instituição também são convidados a participar do evento.

O PHPSC Conf é um ótimo canal para que empresas divulguem seus produtos de tecnologia e atinjam seu público, sendo que muitos dos participantes do evento são pessoas com poder de decisão dentro de suas organizações.

Usabilidade no Site Itaú

noreply@blogger.com (Maira Stella da Silva) — Thu, 13 Oct 2011 21:46:00 +0000

Acredito que todos que trabalham com software, seja desenvolvendo ou testando, quando acessa um site ou um sistema analisa de uma modo mais técnico a usabilidade, eficácia e eficiência das funcionalidades e do layout.

Recentemente, na aula de Engenharia de Usabilidade, cada grupo de pessoas teria que escolher um sistema ou site para fazer a análise de usabilidade. Meu grupo escolheu o site do Itaú, porque um dos integrantes encontrou muita dificuldade para gerar a segunda via de boleto.

E realmente, o site do Itaú é muito confuso, contém erros, e não respeita alguns princípios de usabilidade.

Na página inicial do site o cliente se depara com muita densidade informacional e ao mesmo tempo com muito espaço em branco na parte inferior da tela. O fundo é branco e as letras além de serem pequenas, são na cor cinza, e não há opção para aumentar o tamanho.

O tamanho do site não se adapta ao tamanho da resolução da tela. Então, ao acessar com uma resolução widescreen, no canto direito é exibido um espaço em branco, conforme é possível visualizar na imagem abaixo:

O site também não é compatível com qualquer tipo de navegador. No navegador Internet Explorer e no Chrome, são exibidos caracteres inválidos.

As mensagens de restultado não são padronizadas. Em uma determinada tela foi identificada a seguinte mensagem: "Digite uma palavra!!!"

Como há muita informação, em praticamente todas as telas, o usuário perde a linha de raciocínio, e tem dificuldades para encontrar uma determinada função.

Para quem quiser visualizar a apresentação do trabalho completa, basta clicar aqui!

Desprezo infinito: Testadores x Desenvolvedores!

noreply@blogger.com (Maira Stella da Silva) — Wed, 05 Oct 2011 19:55:00 +0000

Olá testadores!

Ultimamente nos blogs de humor (que eu acesso fora do horário de trabalho, que fique bem claro), vejo muitas tirinhas de "desprezo infinito", onde duas pessoas possuem preferências opostas e portanto se desprezam por isso.

A relação entre desenvolvedores e testadores pode não ser das melhores. Já li muito isso, em livros, artigos, e culturamente a ideia difundida entre os programadores é: "um testador?! Mas pra que? O sistema sempre funcionou, tudo funciona...". E o testador já pensa: "in God we trust, the rest we test.". Enquanto o programador desenvolve o software para que atenda os requisitos e funcione, o testador tem que se esforçar para encontrar erros. São pontos de vistas divergentes, objetivos diferentes, certo?

Errado!

Muito errado!

A equipe deve ter plena consciência de que o objetivo é o mesmo: GARANTIR A QUALIDADE DO SISTEMA!

Quando eu comecei a fazer testes, a ideia de rivalidade era muito concreta. Sendo assim, eu evitava de conversar com os programadores, e se caso possuísse alguma dúvida em relação a erros, eu tentava me expressar da maneira menos ofensiva possível. Os erros identificados eram cadastrados, posteriormente corrigidos, retestados, e pronto.

Com o tempo, e com as dúvidas que surgiam durante o processo de testes, a liberdade de perguntar e conversar sobre o erro foi aumentando.

"O que é isso? Por que isso acontece? Em qual módulo poderá acontecer esse erro?"

É claro que a maneira como você se expressa ajuda muito em adquirir uma relação amigável. O testador jamais deverá ser ofensivo, ou usar um tom inapropriado para relatar o erro, principalmente porque se refere ao trabalho desempenhado por outra pessoa.

Depende muito de cada empresa, e da maturidade da equipe, mas manter uma relação "amigável", e um espírito de união entre testadores e programadores funciona muito bem. Então, essa história de desprezo infinito entre desenvolvedores e testadores é só uma questão de ponto de vista.

Bug encontrado, bug reportado! (Parte II)

noreply@blogger.com (Maira Stella da Silva) — Sun, 18 Sep 2011 22:30:00 +0000

Continuando o post anterior...

Mais alguns conceitos interessantes sobre o registro de bugs que eu aprendi lendo o livro "Lessons Learned in Software Testing":

- Never exaggerate your bugs:

De acordo com o projeto e o tipo de sistema, é necessário ter um critério para definir o que seria um bug crítico ou não. Um erro não poderá ser categorizado como crítico sem ter fatos que comprovem essa escolha. Por exemplo, em um site de ecommerce, um erro durante a etapa de compra de produtos com certeza é crítico, principalmente porque acarreta prejuízo para a empresa. Mas tente ser coerente, e não classificar qualquer bug como crítico, apenas para ser corrigido urgentemente.

- Bug reports should be closed by testers:

Todo bug corrigido deverá ser testado novamente, a fim de indentificar se a correção foi realmente concluída. Caso o bug reportado não ocorra mais, este poderá ser fechado definitivamente pelo testador. Quanto antes for possível testar a correção, melhor será para o programador, que lembrará mais facilmente do código alterado, caso o bug não tenha sido realmente corrigido.

- Never use the bug-tracking system to monitor testers performance:

Não é possível medir a eficiência de um tester se baseando apenas na quantidade de bugs reportados. Quantidade não significa qualidade.

- Keep clear the difference between severity and priority:

A gravidade (severity) é referente ao impacto que o erro causa no sistema. A prioridade indica com que urgência o erro deverá ser corrigido. Geralmente quanto maior a gravidade do problema, maior a sua prioridade para correção.

Clicando nesse link você poderá ler sugestões de como reportar um bug na perspectiva de um desenvolvedor.

A comunidade TestExpert listou vários links sobre teste e qualidade de software. Para conferir basta clicar aqui.

Bug encontrado, bug reportado! (Parte I)

noreply@blogger.com (Maira Stella da Silva) — Tue, 13 Sep 2011 02:34:00 +0000

Saudações caçadores de bugs!

Tão importante quanto encontrar o bug, é reportá-lo de maneira direta e objetiva, para que outras pessoas envolvidas no projeto possam ler, entender e acompanhar.

Lendo o livro "Lessons Learned in Software Testing" dos escritores Cem Kaner, James Bach e Bret Pettichord, eu aprendi algumas lições sobre o conceito de reporte de bugs. Em breve, em outro post, pretendo comentar mais especificamente sobre o livro.

Abaixo, seguem as lições que eu considerei mais interessantes:

- You are what you write:

Reportar um erro é bem mais que apenas descrever o que aconteceu.

Por exemplo, se você simplesmente escrever: "Não é possível cadastrar o produto.", haverá vários programadores furiosos questionando: esse bug acontece em qual ambiente, em quais circustâncias? É necessário algum pré-requisito para reproduzir?

Portanto, é importante informar a prioridade de correção, o ambiente em que foi encontrado, a sequência de ações necessárias, um resultado esperado, imagens, enfim, dados relevantes para os desenvolvedores e os outros envolvidos no projeto. Quanto melhor o conjunto de informações, mais fácil será para o programador identificar o mesmo erro e corrigi-lo posteriormente.

Lembrando que clientes e diretores também poderão ler os bugs reportados. Então "The better your reports, the better your reputation."

- Make you bug report an effective sales tool:

Uma maneira implícita de convencer o seu amigo desenvolvedor, que é realmente necessário corrigir um determinado bug, é adicionar o benefício que a correção resultaria, ou o custo que gera para a empresa caso não seja corrigido. É claro que deve ser utilizado o bom senso, e não exigir que bugs com prioridades baixas sejam corrigidos imediatamente.

Por experiência própria, eu já negociei vários bugs. Felizmente, na empresa onde eu trabalho, a relação entre testers e desenvolvedores é muito amigável. Sempre conversamos sobre a importância da correção, e entramos em um acordo dependendo da necessidade e da urgência na entrega dos sistemas.

Ou seja, quando todos estão realmente envolvidos no projeto, há apenas um objetivo em comum: entregar o sistema da melhor maneira possível dentro do prazo estipulado.

- Report defects promptly:

Assim que o bug for identificado, é necessário registrá-lo. Se demorar muito para reportar, a chance de esquecer dados importantes aumenta e o erro levará mais tempo para ser corrigido.

- Always report nonreproducible erros; they may be time bombs:

Você encontrou um bug, mas não consegue reproduzir? Não deixe de reportar o erro mesmo assim. Antes de fechar a tela com o erro, providencie imagens da cena do crime, para comprovar posteriormente que a falha realmente acontece.

- Every bug deserves its own report:

Mesmo que em uma única tela existam vários erros, cada erro deverá ser reportado separadamente, com suas respectivas informações.

- The summary line is the most important line in the bug report:

O título da descrição do bug deverá ser objetivo, direto. Deve ser uma breve descrição do erro, de maneira que apenas lendo o título já seja possível entender em qual parte do sistema acontece e o que acontece. Pense em um título que, em apenas algumas palavras, você consiga transmitir o erro e os stakeholders consigam entender, sem ter que visualizar mais detalhes. Também poderá ser adicionado o impacto ou a consequência do bug.

Existem outras considerações tão importantes quanto essas. Continua no próximo post!

Curiosidade: Mensagens de Erros Bizarras

Enquanto isso no grupo "Testers Anônimos"...

noreply@blogger.com (Maira Stella da Silva) — Sun, 04 Sep 2011 19:55:00 +0000

Em uma sala obscura, testers, bug detectors, caçadores de bugs estão reunidos:

Timidamente, o primeiro tester se apresenta:

-"Olá, meu nome é Alexandre, e reportei 10 bugs em uma hora!

E então na sala ecoa aplausos e vários parabéns de pessoas orgulhosas da atitude do Alexandre!

Todos olham para o próximo tester a se apresentar:

- "Boa noite a todos! Meu nome é Maira, e… e… vai ser muito difícil o que eu vou dizer agora, mas tenho que ser forte e admitir: eu estou há 1 semana sem reportar bugs."

O silêncio reina na sala e todos ficam espantados pois é muito tempo sem identificar erros. O que será que está acontecendo? Será que a Maira deixou de ser eficiente, não está se dedicando tanto quanto deveria, ou simplesmente está acompanhando blogs como o naointendo.com.br durante o expediente de trabalho?

Vamos desconsiderar esses fatores, e considerar outros baseados em dados e relatórios mais concretos:

Desde o mês de janeiro eu gero relatórios contendo informações sobre a quantidade de bugs reportados e a quantidade de versões lançadas em cada produto desenvolvido. No início do ano, que foi o período em que mais houve lançamento de sistemas, a quantidade de erros identificados era muito grande, e com o passar dos meses foi diminuindo gradativamente. Essa informação indica que o software está em um nível mais estabilizado. Outro dado que pode resultar nessa conclusão, é referente à quantidade de versões lançadas, que também diminui consideravelmente. No gráfico abaixo, a representação fica mais visível:

Então você, que tem experiência em identificar erros, mas que está há mais de uma semana sem reportar bugs, não fique desesperado. Considere se a qualidade do produto realmente melhorou, se o sistema atende aos requisitos e se os usuários estão satisfeitos. Será o resultado do esforço que foi aplicado principalmente nas primeiras versões do sistema.

E o interessante de manter essas informações em relatórios, é que posteriormente você poderá gerar um gráfico comparando a evolução durante os meses, e após enviar aos stakeholders.

Nota de esclarecimento: Eu não fico acessando blogs engraçados durante o expediente de trabalho.

Usabilidade e a Máquina do Tempo

noreply@blogger.com (Maira Stella da Silva) — Fri, 02 Sep 2011 03:34:00 +0000

Imagine que você tenha a máquina do tempo DeLorean, do filme "De Volta para o Futuro", mas ainda não sabe como programá-la para viajar no tempo. Então você acessa o Google e pesquisa o seguinte: "como voltar no tempo com DeLorean".

Clique em "Eu estou com sorte" e de maneira prática e rápida você encontra um tutorial explicando o procedimento necessário. Depois de muita preparação e estudo você programa a máquina do tempo para voltar para o ano de 1998. E então, você revê o jogo em que o Brasil perdeu para a França na Copa do Mundo, e se arrepende profundamente de ter escolhido esse ano. Desesperado, você tenta voltar para o futuro, mas infelizmente, o tutorial foi esquecido, obrigando a realizar a pesquisa novamente. Você abre seu navegador Opera (Firefox surgiu apenas em 2004, e Internet Explorer está fora de cogitação), digita o endereço do Google, e o navegador exibe a seguinte tela:

Independentemente do ano, o Google é um exemplo de simplicidade e usabilidade. É claro que fazer pesquisa é muito fácil, mas todos os aplicativos e sistemas, como o Chrome, Google Earth, Gmail, possuem a mesma lógica de funcionamento, um mesmo padrão de interação entre usuário e interface, focando principalmente em proporcionar facilidade para qualquer tipo de usuário. Sim, eu tenho uma paixão platônica pelo Google.

Ainda viajando no tempo, em 2000, ao acessar o site do Submarino você veria essa imagem (clique na imagem para ampliar):

E comparando com a o site atual do Submarino, é possível claramente perceber alterações na questão de usabilidade, principalmente porque o site é uma substituição do vendedor.

Na versão atual é possível perceber que:

- O campo de "Busca" ganhou muito mais destaque;

- O botão "Meu Carrinho" é de rápido e fácil acesso;

- Promoções e informações interessantes aos consumidores também ganham destaque na tela inicial;

- Central de atendimento ao cliente por telefone está no topo do site, agregando valor ao fator "Atendimento eficiente ao cliente";

- O menu ficou subdivido e não ocupa tanto espaço;

- O site exibe os últimos produtos visualizados (mesmo se você não estiver autenticado no site);

Enfim, é uma série de fatores que sem perceber, facilitam a aceitação do usuário. Entretanto, eu ainda acho que contém muita informação (mas é só a minha opnião).

O que nós podemos constatar é que a preocupação em facilitar o convívio do usuário com o sistema é um ponto determinante para que ele continue acessando seu site. E o usuário busca facilidade!

Para quem quiser brincar de voltar no tempo, visualizando os sites desde sua criação e suas alterações ao longo dos anos, poderá acessar o site http://web.archive.org/.

E só por curiosidade, durante a pesquisa de alguns dados, eu descobri que o site mais antigo do mundo é esse: http://symbolics.com/, criado em 1985.

Testes em Metodologias Ágeis?! E Se For o Contrário?

noreply@blogger.com (Maira Stella da Silva) — Mon, 29 Aug 2011 03:07:00 +0000

O tema "Metodologia Ágil" ganha cada vez mais destaque, e se tornou um assunto muito comentado entre os profissionais de TI.

Muito se fala em introduzir testes em metodologias ágeis, mas porque não introduzir metodologias ágeis no processo de testes?

Atualmente, na empresa onde trabalho, os princípios da metodologia ágil estão no processo inicial, portanto, meu principal contato com o assunto foi durante a matéria de Engenharia de Software na faculdade, ensinada muito superficialmente. Além da faculdade, eu lia algumas matérias e posts sobre o assunto, mas nada se compara com o contato direto no trabalho. Mas enfim, após aprender alguns métodos, eu tentei inserí-los ao processo de testes, e um dos resultados foi esse:

Um scrum board dedicado apenas aos testes. Cada post-it representa uma versão de software lançada, e cada cor representa o segmento dos software. Nesse caso, rosa representa o segmento de supermercados, amarelo o de locadoras e assim por diante. O quadro é separado por quatro grupos:

Para Homologar: Nesse grupo ficam as versões que os testes ainda não foram iniciados, ou versões que serão lançadas futuramente. Nessa primeira etapa, os planos de testes são desenvolvidos, baseados nas principais funcionalidades do sistema, nas alterações e correções realizadas;

Em Teste: Quando uma versão está nesse grupo significa que os testes foram iniciados, e estão em execução;

Em Espera: Versões que foram testadas, mas que estão no aguardo de correções ou alterações, e terão que passar para a fase de teste de regressão, quando for lançado um novo Release Candidate contendo as modificações;

Concluídos: Todas as versões homologadas.

Com o scrum board todos os envolvidos no projeto podem acompanhar o processo de homologação do sistema. É possível verificar também que os desenvolvedores estão concentrando maiores esforços no segmento de supermercados, e que um determinado software possui constantes versões (o que poderá indicar que bugs não são identificados, e são lançadas várias versões corretivas).

Ao final do mês, poderá ser gerado um relatório contendo informações sobre quantas versões foram lançadas, quantos bugs identificados em cada versão, quanto foi investido, e qual foi o gasto para identificar os erros. O scrum board é "zerado" e inicia-se novamente a alimentação de informações.

Esse foi um método interessante que encontrei a fim de monitorar as versões em testes, e possuir dados concretos para tomadas de decisões.

TDC 2011 - Trilha de Testes

noreply@blogger.com (Maira Stella da Silva) — Sat, 27 Aug 2011 22:35:00 +0000

Olá estimados bug detectors!

No dia 20 de agosto, em São José, Santa Catarina, ocorreu o evento TDC (The Developers Conference), com várias trilhas interessantes, como Java, Arduino, Empreendedorismo, e a mais importante no meu caso, Testes de Software. O evento foi muito bem organizado, e as palestras muito bem ministradas por pessoas com grande bagagem de conhecimento. Em todas as palestras eu aprendi muito, mas nesse post eu gostaria de comentar sobre a primeira palestra, a qual mais me agregou conhecimento na parte gerencial e definição de planos de testes.

A primeira palestra foi "Automação Rápida de Testes para Web" ministrada por José Correia, e durante a introdução à automação, ele fez alguns comentários muito pertinentes sobre como identificar e priorizar os testes. Acreditar apenas no "feeling" é muito subjetivo. Abaixo, seguem 4 passos sugeridos para classificar os módulos principais a serem testados:

1. Várias ferramentas para gestão de defeitos reportam relatórios com informações valiosas. É possível gerar um relatório para listar em qual funcionalidade, módulo ou página foram identificados mais bugs. É uma maneira fácil e rápida de descobrir, por exemplo, que no módulo de cadastro de cliente do sistema, foram encontrados mais bugs que em qualquer outro módulo. Portanto, é uma área instável, e deverá ser testada.

2. Gerar relatórios de páginas mais acessadas ajuda a identificar módulos e funcionalidades mais importantes referente às reais necessidades dos usuários.

3. Solicitar aos desenvolvedores um ranking dos arquivos (classes, objetos, módulos do sistema) mais alterados. A probabilidade de conter erros nesses módulos é muito maior.

4. Outro indicador importante e que poderá ajudar muito na priorização de testes, é conversar com o Help Desk, ou solicitar para que seja gerado um relatório contendo informações sobre qual é o módulo ou funcionalidade em que as dúvidas são mais constantes.

Após coletar essas informações, você poderá criar um Diagrama de Pareto, o que torna mais visível o que é realmente necessário ser priorizado e onde concentrar os esforços para a realização de testes.

Para ter acesso a apresentação, basta clicar aqui. E para ter informações sobre as outras palestras da trilha de teste, basta acessar o blog Sem Bugs.

Apresentação do Blog!

noreply@blogger.com (Maira Stella da Silva) — Wed, 24 Aug 2011 19:57:00 +0000

Saudações Bug Detectors!

Depois de tanto pensar em títulos absurdos para o blog, como BugBusters (referência ao filme GhostBusters), BugBugBuster, entre outros que tenho até vergonha de escrever aqui, escolhi "The Monster Bug"! Sim, "The Monster Bug"! O monstro que atormenta a vida de programadores, testadores e usuários!

Meu objetivo inicial é transferir um pouco da experiência que venho adquirindo nessa área, compartilhar notícias, novidades e informações sobre Qualidade e Teste de Software.

Atualmente eu estou cursando Ciência da Computação na Univali, e trabalho com Qualidade e Teste de Software desde 2008.

Espero que com esse blog, eu possa ensinar muito, e aprender muito mais!