sexta-feira, 23 de novembro de 2012

Instruções para relatar defeitos do CrowdTest

Relatar defeitos é uma atividade rotineira para testadores. Nem sempre quem está começando consegue relatar com precisão uma falha.

Existe algumas documentações que ajudam nesse sentido. Gosto de sempre reler os guias do CrowdTest para me atualizar sobre as técnicas usadas nesse sentido.

Vale a pena conferir:

http://crowdtest.me/issues_guide?utm_source=mailmarketing&utm_medium=email&utm_campaign=projeto-buscapenahora

Nesse projeto foi orientado com o texto:

2. Instruções para o preenchimento do Formulário de Nova Ocorrência

2.1. Preenchimento do Título

O título deve ser capaz de dar uma ideia concisa e clara da ocorrência encontrada. O título da ocorrência deve permitir que outros testadores identifiquem se a ocorrência encontrada já foi registrada (evitando, assim, ocorrências duplicadas).

2.2. Preenchimento da Descrição

A descrição deve conter uma explicação detalhada da ocorrência encontrada.

2.3. Preenchimento dos Passos para reprodução

Os passos para reprodução devem ser bem detalhados e sem ambiguidades e redundância. Não assuma que determinados passos são óbvios e serão entendidos pelo revisor. Caso existam pré-condições para a reprodução da ocorrência, as mesmas devem ser detalhadas. Este campo deve ser utilizado para convencer de que a ocorrência existe e é reproduzível.
Coloque cada passo separado por marcadores. É mais simples de entender os passos quando estão com marcadores do que apenas texto.
  • Acessar a “Tela de Cadastro de Usuários”;
  • Não informar os campos obrigatórios;
  • Clicar em [Salvar];
É melhor que...
“Acesse a tela de cadastro de usuário sem informar os campos obrigatórios e clique em salvar.”
Vale ressaltar que o vídeo com a evidência do problema não substitui a descrição do passo-a-passo do problema.

2.4. Preenchimento dos Resultados Esperados

Descrição do que é esperado após a execução dos passos e uma comparação com o que é atualmente exibido pelo sistema que difere do resultado esperado.

2.5. Preenchimento das Informações Adicionais

Detalhar qualquer outra informação que achar relevante para o entendimento da ocorrência relatada.

2.6. Preenchimento da Funcionalidade

Associar a funcionalidade correspondente à ocorrência encontrada.
Caso o testador veja a necessidade de inclusão de uma nova Funcionalidade em um projeto, deverá enviar um e-mail para crowd@crowdtest.com.br com o nome do projeto e o caminho onde a funcionalidade se encontra.

2.7. Preenchimento do Tipo

Associar o tipo da ocorrência encontrada de forma correta e que caracterize realmente o tipo da ocorrência. A seguir são descritos cada tipo de ocorrência:
TipoDescrição
ImpeditivoOcorrência que impede o uso do sistema. Não existe forma de contorná-la.
Exemplo: Ao clicar em um botão, o sistema trava e para seu funcionamento.
FuncionalOcorrência não impeditiva relativa ao funcionamento do sistema. Uma ocorrência que pode ser contornada pelo usuário do sistema.
Exemplo: Ao clicar no botão “Limpar”, o campo não é limpo.
SegurançaOcorrência que compromete a segurança do uso do sistema.
Exemplo: acesso a senhas de segurança, dados pessoais de usuários, etc.
InterfaceOcorrências relativas à interface, como problemas de renderização, cores, etc.
Exemplo: O Label de um botão aparece deslocado, fora da área do botão.
TextoQualquer ocorrência relacionada ao uso incorreto de algum idioma.
MelhoriaSugestões de melhorias para o sistema.
Vale ressaltar que nem todos os tipos de ocorrências estarão presentes em todos os projetos. Por exemplo, pode ocorrer de em um projeto só poderem ser registradas ocorrências funcionais.

2.8. Preenchimento do Navegador

Selecionar o navegador no qual a ocorrência aconteceu. Fiquem atentos aos tipos de navegadores autorizados para testes em cada projeto.

2.9. Preenchimento do Sistema Operacional

Selecionar o S.O. no qual a ocorrência aconteceu. Fiquem atentos aos sistemas operacionais autorizados para testes em cada projeto.

2.10. Preenchimento dos Anexos

Os anexos podem receber qualquer tipo de arquivo, mas o principal uso deles é para evidenciar a ocorrência. As evidências das ocorrências são obrigatórias para todos os tipos, exceto as melhorias.
Para evidenciar podem ser anexados print screens ou vídeos. Utilize arquivos com formatos comuns (e.g. MP4, AVI, WMV, PNG, JPG, GIF) e que não exijam a instalação de um software particular para serem visualizados.
Podem ser utilizados serviços de hospedagem de vídeos na Internet, caso o limite de upload não seja suficiente.
Vale ressaltar que a inclusão de anexos não elimina a necessidade de preencher os demais campos com o detalhamento esperado.

terça-feira, 20 de novembro de 2012

CrowdSim software de teste de evacuação de emergência

Alunos da PUC-RS desenvolveram um software que faz teste em situações de evacuação de áreas públicas em caso de emergência. Chama-se CrowdSim, essa ferramenta de modelagem e animação 3D testa como seria uma situação de tumulto ou momentos de pânico.

Como resultados pode simular situações com baixo custo e nenhum risco. Os resultados dos testes existe uma informação para influenciar na tomada de decisão da instalação de saídas de emergência ou câmeras.

Esse teste achei interessante e importante para aprimorar a segurança de estruturas públicas.

Fonte: http://tecnologia.terra.com.br/noticias/0,,OI6314449-EI15607,00-Software+simula+evacuacao+de+locais+com+multidao.html

quinta-feira, 1 de novembro de 2012

Automação de tarefas de interface de usuário com Autoit

Quando comecei na área de teste, precisava de algumas tarefas automatizadas de interface de usuário, como não tinha-mos dinheiro para comprar ferramentas optei por ferramenta freeware. Conheci o Autoit3 que desempenha um papel interessante na automação de UI (user interface).

Endereço: http://www.autoitscript.com/site/autoit/

AutoIt3 é uma ferramenta freeware de linguagem script de formato BASIC desenhado para automatizar tarefas de interface com usuário Windows e de uso geral. Esta ferramenta usa uma combinação de simulações em teclas, movimentos do mouse, manipulação e controle de janelas a fim de automatizar tarefas em uma forma não possível ou fiável com outras linguagens (exemplo VBScript e SendKeys). AutoIt é também muito pequena, auto-suficiente e roda nas versões regulares do windows até hoje, sem exigir problemas em tempo de execução.
O conceito da ferramenta é usar coordenadas na tela para cliques do mouse, sendo as coordenadas relativas a janela ativa ou não, enviar comandos do teclado e ativar janelas de acordo com o nome.

Na minha opinião é uma forma de iniciar em automação de testes com baixo custo e razoavel produtividade.

Um case que vi foi a automação completa do roteiro do PAF-ECF. Onde não era exclusivamente automatizada mas, serviu como guia nas operações e validações do roteiro. Esse roteiro tinha aproximadamente 120 testes e deveria ser feito na sequência.

Para quem não tem nenhum processo automatizado, eu sugiro que conheça o Autoit e veja se consegue aproveitar algum recurso dessa ferramenta nos seus testes. A primeira coisa que eu automatizei com autoit foi entrar na aplicação (informar usuário e senha), já uma economia de tempo sendo que todos os dias eu tinha que digitar sempre o mesmo usuário/senha.

Automação de teste é assim, se já te ajuda nas tarefas diárias a automação pode valer a pena.

terça-feira, 9 de outubro de 2012

Google torna a Octane um projeto open source

Google torna a Octane um projeto open source

Testes feitos em navegadores agora podem ser aprimorados pela comunidade com essa abertura.

Projeto hospedado em: http://code.google.com/p/octane-benchmark/

Estou seguindo o projeto. Achei interessante a comparação do rendimento dos navegadores.

domingo, 23 de setembro de 2012

Test Day 2012 PUC-SP

Ontem aconteceu o Test Day.
Um evento excelente, local fácil de chegar.
Os palestrantes demonstraram conhecimentos sobre testes de software com dinâmica divertida.
Ao meu ver, saiu de "graça", tinha tudo que agente precisava: continious coffe; café da manhã; almoço; participação de todos;
Os organizadores, o patrocinador,
Com muita gratidão escrevo a minha opinião sobre o evento, foi de qualidade excelente.

Agora em nossas mãos divulgar o conhecimento que absorvemos no sábado dia 22/09/2012

E que venha Test Day 2013!

segunda-feira, 17 de setembro de 2012

Investimento do governo em TI para inovação

Ótima noticia que recebemos no começo desse mês: http://blog.planalto.gov.br/com-o-programa-ti-maior-governo-vai-investir-r-500-milhoes-para-a-producao-de-software-no-brasil-diz-dilma/

O governo federal vai investir meio bilhão para a produção de software.

Com certeza, se o governo deseja que a produção científica e tecnológica seja valorizada esse é um começo.

Os estudantes precisam se preparar melhor para conseguir inovar de verdade. Temos tudo a nosso favor (pelo menos a grana está vindo, hehe). Vamos por a mão na massa!

sexta-feira, 14 de setembro de 2012

Automação de testes de software, questões levantadas

Existe sempre um questionamento sobre o investimento de automação e sua validade, esse post apenas relata um outro que fala sobre o assunto
As questões levantadas no post http://left4test.blogspot.com.br/2012/09/automacao-de-testes-for-dummies.html são bem pertinentes a automação, também esta de uma forma divertida.

Gostei do post. Para mim terá um reflexão importante no trabalho.

Espero que gostem. 

quinta-feira, 30 de agosto de 2012

Sou QA, mas o que é isso?

Em uma conversa com meu amigo, também da área, falei que programo mas o que eu gosto mesmo é de ser QA técnico.

Eis que ele me questiona: - Defina QA técnico.

Pensei em falar da palestra "O Mundo Precisa de QAs Técnicos!" mas, preferi criar a minha definição desse termo.

Na minha concepção, QA técnico, é o profissional que ajuda a equipe de desenvolvimento a aprender com os próprios erros, para garantir a qualidade.

QA precisa saber programação, para falar a mesma língua do desenvolvedor. Deve conversar no mesmo nível para conseguir convencer. Mas precisa estar direcionado em como fazer a equipe produzir com mais qualidade.

O QA deve ir além do que a descrição de trabalho: "Encontre o máximo de erros no sistema que for possível". Prestar atenção na equipe, como ela encara os erros, e com comunicação aberta ensinar que os erros são benéficos para o aprendizado. Esse aprendizado em equipe deve ter a essência de colaboração para que não haja conflito.

Tenho certeza que isso é possível. Trabalho a 1 e meio com Testes e Qualidade de software. Meu esforço é para que seja reconhecido pela ajuda a equipe e não como o "testador".

sábado, 25 de agosto de 2012

Desmistificando testes exploratórios Cristiano Caetano

Hoje ocorreu o primeiro seminário paulista de teste de software.

Cristiano Caetano marcou presença com uma palestra excelente.

Segue abaixo a apresentação:


quinta-feira, 16 de agosto de 2012

Dicas de ferramentas e links

Eu estou apenas reblogando o post de Origem.

Olá,
Criamos um site onde testadores e desenvolvedores podem finalmente entender um ao outro. Uma novidade!
Sim, uma novidade que vai mudar de uma vez por todas a maneira de testadores e desenvolvedores trabalhar. Finalmente derrubamos as barreiras existentes e conseguimos fazer com que vocês se entendam e trabalhem de forma mais colaborativa.
Ahhh, não deixe de usar as hastags #boadesenvolvedor se você é testador e quiser elogiar seus amigos desenvolvedores. E você desenvolvedor use a hastag #boatestador para elogiar seus amigos testadores.
Seus twittes serão exibidos na sessão Desabafo da página.
Quer saber mais sobre testes? Curtam os vídeos abaixo:
Abraços,
Rodrigo de Carvalho
Gerente de Produtos Ferramentas de Desenvolvimento

segunda-feira, 6 de agosto de 2012

Material sobre Testes e TI

Nosso amigo Toni Isidoro colocou na comunidade DFTestes (http://br.groups.yahoo.com/group/DFTestes/message/18578) uma mensagem retribuindo a ajuda que a comunidade lhe forneceu.

Como distribuir conhecimento é o que faz a humanidade crescer, eu vou compartilhar dessa ótima atitude tomada.

Segue a mensagem:

Cursos, Video Aulas e Materiais GRATUITOS sobre TI

Pessoal como o grupo me ajudou muito durante minha fase de aprendizagem agora chegou a hora de retribuir um pouco com os materiais e links que reuni durante muito tempo. :D...
Como ainda não separei os materiais (e esta uma bagunça) vou passar agora alguns links de universidades e sites que disponibilizam video aulas e materiais gratuitos sobre TI. Acredito que algumas até já foi postado aqui.

http://www.veduca.com.br/ (Portal que disponibiliza varios cursos de universidades gringas legendadas e gratuitas, dentre elas esta Harvard, Stanford, MIT, TED etc...Dentre os cursos estão Metodologias de Programação, Introdução a Ciências da Computação, etc)

http://www.compcederj.com.br/aulas/ (Curso de Tecnologia em sistemas da Computação do CEDERJ - UFF - RJ)

http://jedi.wv.com.br/ (Cursos Online do DFJUG - Brasília Java Users Group)

http://www.ev.org.br/Cursos/Paginas/Cursos.aspx (Cursos rápidos da Fundação Bradesco)







http://qualifico.com.br/curso.asp?curso=MTE (minicurso gratuito de teste exploratorio)

http://www.t2ti.com/curso/video/java/basico/java_starter.php ( JAVA - Tutorial básico gratuito)

http://www.caelum.com.br/download/caelum-algoritmos-estruturas-dados-java-cs14.pdf ( JAVA - Algoritmos e estrutura de dados em Java:)

Tambem não posso deixar de mencionar os materiais que o Cristiano Caetano disponibiliza que ja foi de grande ajuda....


Fora isso tem os sites das comunidades de testes:

Alias estou pensando em montar um blog tambem para disponibilizar os materiais e artigos e compartilhar um pouco de experiencia porém o que tem me faltado é tempo nessa árdua batalha para conseguir um emprego decente na área de testes enquanto faço serviços freelance para ir me virando.
Sou muito a favor do conhecimento compartilhado e se alguém quiser acrescentar algum material a lista que seja bem vindo!

segunda-feira, 16 de julho de 2012

Princípios do teste

Princípios:
1. O teste demonstra a presença de erros 
Os objetivos dos testes (funcionais) são encontrar defeitos para que a qualidade do produto seja melhor ao corrigi-los.

2. Teste exaustivo é impossível 
Todas as combinações de teste em um sistema complexo é inviável, portanto o foco é de acordo com a importância.

3. Teste antecipado
O teste deve começar o mais cedo possível, a partir do momento que se tem uma definição surge a necessidade de teste.

4. Agrupamento de defeitos
Os defeitos tendem a ficar nas partes mais complexas do sistema, em partes simples não é comum se agrupar erros.

5. Paradoxo do pesticida
Manter as técnicas de teste em situações onde não é encontrado erros, pode ser encontrado se for testado de maneira diferente.

6. Teste depende de contexto
É diferente um contexto de um sistema para Nota Fiscal eletrônica do que um sistema para controle de estoque, e necessita de diferentes formas de teste.

7. A ilusão da ausência de erros
Existem erros em potencial em todo sistema, podem existir e nunca serem descobertos.

Referência:

terça-feira, 26 de junho de 2012

Antecipar o teste

Um dos principios do teste de software é que este deve ser antecipado.

Uma forma de antecipar é o planejamento. Assim não devem ser apenas executados os testes, podemos ser antecipado o processo elaborando cenários para as situações a serem testadas. No momento em que é especificado alguma coisa, surge a necessidade de testar (testar documento também é importante).

Portanto, apenas testar depois de pronto o sistema não é o melhor cenário. Vamos nos esforçar para antecipar a atividade de teste e assim ter acuidade.

Técnicas de teste pode ser encontrado nos Syllabi em http://www.bstqb.org.br/

Sucesso em seus desafios!