Os bugs também têm sentimentos

Muitas vezes uma imagem diz mais do que mil palavras. No blog Cartoon tester, Andy Glover faz uso de imagens extremamente simples, mas que transmitem de maneira objetiva conceitos e práticas interessantes relacionadas com as atividades do engenheiro de testes.
A imagem abaixo é do post do blog, que fala de maneira correta sobre algumas atitudes que devemos ter no nosso dia a dia quando encontramos bugs. Abaixo, uma breve explicação dos pontos mencionados.



Se você encontrar um bug:


1 – Reporte-o, bugs não gostam de ser esquecidos.
Diversos motivos podem levar um testador a esquecer de reportar algum defeito encontrado, prazos apertados, tarefas acumuladasdesorganização ou simplesmente o fato de que algumas vezes os defeitos são encontrados antes mesmo dos testes, em conversas informais, treinamentos, etc.. e nem sempre os envolvidos tomam as devidas ações nessas situações.

2 – Conheça-o melhor, bugs gostam de ser compreendidos.
Antes de reportar um defeito, devemos entender por completo seu comportamento, sua abrangência e quais são seus impactos.

3 – Tire uma foto, bugs gostam de guardar recordações das ocasiões.
Screenshots, fotos e inclusive vídeos ajudam a evidenciar melhor a reportagem de um defeito, facilitando o entendimento do desenvolvedor e evitando CRs reabertas.

4 – Conheça seus companheiros, bugs são socialites.
Ao encontrar um defeito é comum que outros bugs estejam localizados nas suas redondezas, por isso é importante a varredura nas funcionalidades relacionadas para rapidamente detectar novas falhas.
5 – Reporte rapidamente, do contrário os bugs se estabelecem e fazem moradia.
Agilidade na reportagem permite que sua correção também seja antecipada, evitando que outros bugs causados pela falha já existente sejam revelados.

6 – Seja honesto, bugs não gostam de fofocas.
Classificação de severidade e prioridade supervalorizadasmelhorias registradas como defeitos, entre outros problemas frequentes, causam problemas na comunicação da equipe e atrapalham o andamento das atividades.

7 – Guarde como o conheceu, bugs são românticos.
Ao encontrar um defeito, a primeira tarefa é sempre de verificar quais foram os passos prévios para detecção do problema, reportar como podemos reproduzir o issue é essencial para os desenvolvedores durante a correção e também para os testadores no momento da verificação das correções.

8 – Não o ignore, bugs podem morder quando não apreciados.
Em meio a tantos bugs, normalmente encontrados durante os testes, é comum que em alguns momentos desprezemos alguns defeitos encontrados, por acreditarmos que os mesmos são irrelevantes ou nunca serão corrigidos. Porém, já cansei de ver defeitos ignorados sendo reportados posteriormente por clientes ou quando vistos por outros ângulos gerando consequências graves para o sistema.
Adicionaria a lista de atitudes a verificação dos defeitos já existentes, prática bastante simples, mas que muitas vezes é relegada, e que pode evitar trabalho desnecessário de diversas pessoas.

E vocês concordam com os tópicos? Sentiram falta de mais alguma atitude?
Compartilhar no Facebook:
Compartilhar no Linkedin:

Preparatório intensivo CBTS

Fundamentos em teste de software: preparatório intensivo CBTS


DATA E HORÁRIO: 04 e 05 de novembro (sexta das 18h30 às 22h30 e sábado das 9h00 às 18h00).
CARGA HORÁRIA: 12 horas
MODALIDADE: A distância (aula ao vivo via webconferência, com interação com o instrutor).
INVESTIMENTO: R$ 290,00 até 18/outubro e R$ 350,00 após esta data. Desconto de 10% para pagamentos à vista.
INCLUI:
  • Certificado impresso
  • Acesso ao material oficial certificado pela ALATS em formato virtual
  • Dicas e simulados para a prova
INSTRUTORA: Érika Hmeljevski: Instrutora oficial da ALATS, tendo atuado como instrutora do treinamento CBTS desde 2007. É certificada CBTS e CTFL.
Implementadora oficial do MPT.BR, Modelo Brasileiro de Processo de Teste de Software. Representa a Associação Latino Americana de Teste de Software (ALATS) como Diretora do estado de Santa Catarina. Atua na área de testes e qualidade de software há 8 anos. Hoje coordena a equipe de Qualidade e Teste de Software do Instituto Stela, além de atuar como consultora e instrutora em teste de software pela Supreme Quality.
INFORMAÇÕES E INSCRIÇÕES:
treinamento@supremequality.com.br
48 4052-9897
47 8848-7076
EMENTA:
  • Introdução ao Processo de Teste
  • Processo de Teste
  • Ambiente de Teste
  • Análise de Risco
  • Planejamento de Teste
  • Elaboração do Teste
  • Executando o Plano de Teste
  • Gestão de Defeitos
  • Teste de Aceitação
  • Relatórios de teste
  • Estimativa de teste
INSCRIÇÕES CBTS: www.alats.org.br
Veja Também: SIMULADO CBTS


Compartilhar no Facebook:
Compartilhar no Linkedin:

BRATESTE 2011


IV Seminário Brasileiro de Teste de Software

O BRATESTE 2011 é o maior e mais importante evento sobre Teste de Software da América Latina, um local onde profissionais, a indústria e a academia se reunem para apresentar pesquisas, estudos de caso, produtos, serviços, trocar experiência durante os 4 (quatro) dias do evento, divididos entre tutoriais e seminário.
Não perca a oportunidade de aprender com renomados especialistas em Teste de Software, nas mais variadas áreas de conhecimento, tais como: Testes Ágeis, Gerência de Teste, Melhoria de Processo, Técnicas de Teste, Automação, Métricas e muito mais.
O evento, em sua quarta edição, será realizado de 11 a 14 de outubro de 2011 e terá 2 (dois) dias de tutoriais (pré-seminário) e 2 (dois) dias de seminário, com mais de 20 palestras no total.

Por que participar do BRATESTE 2011?

  • Networking
  • Oportunidade para trocar experiência com outros profissionais e renomados especialistas
  • Serão apresentados e discutidos os assuntos mais relevantes e atuais
  • Oportunidade única para aprender com especialistas renomados e reconhecidos internacionalmente
  • Participação da indústria, da academia e de profissionais e especialistas
  • Conhecer as novidades em produtos e serviços durante a visita aos estandes

Quem deve participar?

  • Diretores
  • Gerentes de Teste e Gerentes de Projeto
  • Profissionais da área de Teste e Qualidade de Software
  • Desenvolvedores
  • Pesquisadores
  • Estudantes

Onde será o evento?

Grand Hyatt Hotel

Avenida das Nações Unidas, 13.301
São Paulo, São Paulo, Brasil 04578-000
Tel.: +55 11 2838-1234
Fax: +55 11 2838-1235

Mais informações: www.alats.org.br/

Compartilhar no Facebook:
Compartilhar no Linkedin:

Qualidade de Software

Autor: André Koscianski, Michel dos Santos Soares
Editora: Novatec
I.S.B.N.: 8575221124
Edição: 2 / 2007
Idioma: Português
País de Origem: Brasil

Este livro aborda as principais tecnologias, metodologias e processos utilizados atualmente em desenvolvimento de software. Os fatores que influenciam a qualidade são discutidos em amplitude, com ênfase nos aspectos práticos, mas sem deixar de mencionar a fundamentação teórica essencial.

Os tópicos são tratados de forma inter-relacionada e abrangem:
  • modelos de processos organizacionais, como CMM e CMMI;
  • modelos de processos individuais e de equipe, como PSP e TSP;
  • o modelo brasileiro MPS.BR, lançado em 2005;
  • metodologias ágeis, como XP e SCRUM;
  • algumas das principais normas internacionais, como SQuaRE, ISO/IEC 25000:2005, ISO/IEC 12207 e ISO/IEC TR 15504;
  • programação e sua relação com a qualidade;
  • teste de software.
São apresentados diversos softwares de apoio, além de ampla bibliografia e referências a sites relevantes.

Trata-se de um verdadeiro guia para profissionais da área, podendo ser usado em cursos de graduação e pós-graduação como referência principal na disciplina de Qualidade de Software e complementar para Engenharia de Software e Programação.
Compartilhar no Facebook:
Compartilhar no Linkedin:

Retificação Simulado CBTS

Pessoal,

Recebi um e-mail de um amigo (Ueslei Silva - mptbr.blogspot.com) referente uma questão do Simulado CBTS com respostas que podem gerar dúvidas.

Segue trecho do e-mail:


Subject: Simulado CBTS

Date: Mon, 3 May 2010 16:55:13-0300



Marcelo,
Analisando a questão acima:
Como testaria o limite máximo de digitação de um campo numérico e que não apresenta essa informação?
Como testaria os limites inferior e superior para um campo numérico que não tenha informado os valores limítrofes?
Considerando as questões acima, minhas opções, seriam milhares de testes... neste caso acho que a opção indicada como correta, não seria a melhor.

E eu concordo com ele.
Realmente. Sem especificação, realizar teste que garanta limites do campo, resultaria em uma infinidade de testes.

Portanto, na próxima versão do simulado (estou corrigindo erros de digitação e coisas do gênero, mas está quase pronta) vou alterar esta questão.

Conto com a compreensão dos que já realizaram o simulado. E obrigado Ueslei pela colaboração.
Compartilhar no Facebook:
Compartilhar no Linkedin:

Comentários Recentes