Utilize um ambiente de testes local Se você é um testador trabalhando com automação de testes, há chances de você ter a base de código da aplicação rodando localmente em seu computador. É mais fácil sair usando esse código que já está rodando em seu ambiente local para conduzir seus testes de histórias. Os benefícios são … Continue lendo Em que tipo de ambiente devemos testar?
Autor: Walmyr
I'm a software engineer that loves testing. I'm also a clean coder, blogger, YouTuber, Cypress.io 🌲 ambassador, writer, online instructor, mentor, consultant, speaker, an active member of the testing automation and JavaScript communities, and a fan of good music, tattoos, vegan 🌱 food, and skateboarding.
Hangout with testers 12 - QA DEVOPS. Quer saber mais a respeito? Será dia 7 de Abril, às 21hs. (horário de Brasília). Te vejo lá! =D PS.: Link na imagem.
Com as técnicas de implantação contínua de software, é comum entregar novos softwares em produção múltiplas vezes por dia. Uma suite de testes de regressão, independente que quão bem é projetada, leva ao menos uns 10 minutos para ser executada, o que pode levar a gargalos na entrega de mudanças em produção. Então, você ainda … Continue lendo Só podemos testar isso em produção?
"Ninguém testa a profundidade de um rio com os dois pés" ~ Provério africano Teste automatizado é melhor do que teste manual Testes automatizados são muito explícitos (preto no branco) então você tem uma chance maior de reproduzir um bug se achado por um teste automatizado ao saber o que o teste automatizado executou para … Continue lendo O que é melhor: Teste manual ou automatizado?
Boards físicos são melhores do que boards virtuais Não há nada como ver o status de uma iteração ao usar um grande board físico: várias colunas e post-its coloridos que se movem enquanto as iterações progridem. Avatares são grudados nas cartas enquanto as pessoas trabalham nelas (as quais podem limitar o trabalho em progresso) e é muito fácil de … Continue lendo Os board são melhores quando físicos ou virtuais?
Você deve especificar seus critérios de aceitação como Dado/Quando/Então Dado/Quando/Então é uma forma quase onipresente* de especificar cenários de usuário: Dado uma condição Quando faço alguma ação Então espero algum resultado Se você escreve seus critérios de aceitação neste formato, isso não só provém uma estrutura consistente, mas se seus testes de aceitação automatizados também … Continue lendo Seus critérios de aceitação devem ser escritos como Dado/Quando/Então ou como checklists?
Na semana passada fui convidado pelo amigo e colega de profissão Daniel Wildt para um bate papo sobre carreira. Apesar da pauta, sempre surge algo a mais que queremos falar e as vezes esquecemos. No papo pude me apresentar, falamos de comunidades de prática as quais participo (GUTS-RS e GUMA-RS), conversamos sobre o mercado de qualidade … Continue lendo Um pouco mais de carreira
Para não perder o costume, hoje resolvi falar de um assunto um tanto quanto polêmico. Há algum tempo tenho a crença cada vez maior que os dias do profissional focado especificamente na garantia da qualidade de software estão contados. É isso mesmo, se você é um QA e está lendo isso, pense em como evitar ser … Continue lendo A extinção do profissional de QA
"O entendimento é o conhecimento do mal entendido" ~ Zivarnna Smithies Os critérios de aceitação devem ser implícitos Todas as coisas na vida são implícitas. Quando minha esposa pergunta 'você pode ir ao mercado e comprar um pouco de leite', ela também não tem que me dizer 'e não compre nada mais', 'e certifique-se que … Continue lendo Os critérios de aceitação devem ser implícitos ou explícitos?
TALKING ABOUT TESTING 