O documento discute verdades e mitos sobre testes de software. Ele aborda três mitos comuns: que testes não são importantes, que só acontecem no final do processo de desenvolvimento e que são responsabilidade apenas do time de teste. O documento defende a importância dos testes e a necessidade de envolvimento de toda a equipe desde o início.
Planejamento de testes em um mundo ágilAriane Izac
Palestra da Jacqueline Costa no Meetup Devtests na HST - 18/09/2018.
Nesta palestra o intuito é compartilhar ideias em relação a forma como o time de qualidade planeja e executa seus testes. Deixando de lado a ideia que o QA é inimigo do desenvolvedor e que não temos que ter contato com código (e que o dev não precisa testar rs), diferente disso, temos que pensar como nós podemos melhorar o trabalho do nosso time e prover maior qualidade para o nosso cliente :)
Espera ai, eu nunca tive contato com automação, o que isso vai me agregar? Uma visão diferente de abordagem de testes!
Mas eu já trabalho com automação, o que isso vai mudar na minha vida? Sempre digo que é importante termos contato com o que já conhecemos e o que não conhecemos, a troca de experiências é uma das melhores formas de melhorar como fazemos algo!
Planejamento de testes em um mundo ágilAriane Izac
Palestra da Jacqueline Costa no Meetup Devtests na HST - 18/09/2018.
Nesta palestra o intuito é compartilhar ideias em relação a forma como o time de qualidade planeja e executa seus testes. Deixando de lado a ideia que o QA é inimigo do desenvolvedor e que não temos que ter contato com código (e que o dev não precisa testar rs), diferente disso, temos que pensar como nós podemos melhorar o trabalho do nosso time e prover maior qualidade para o nosso cliente :)
Espera ai, eu nunca tive contato com automação, o que isso vai me agregar? Uma visão diferente de abordagem de testes!
Mas eu já trabalho com automação, o que isso vai mudar na minha vida? Sempre digo que é importante termos contato com o que já conhecemos e o que não conhecemos, a troca de experiências é uma das melhores formas de melhorar como fazemos algo!
Meetup SP - O QA & a Especificação Por ExemploSamanta Cicilia
Especificação por exemplo é um conjunto de patterns que ajudam a construir o produto certo da maneira certa. Muitas pessoas atribuem sua utilização apenas a parte de teste de software, porém ela vai muito além disso e tem dicas valiosas sobre o quanto a colaboração pode nos ajudar a descobrir o que nossos clientes realmente precisam.
Nessa palestra relato minha experiência não como um desenvolvedor de software altamente sinistro com duzentos anos de experiência e mil livros publicados - mas sim como um "mero mortal", um desenvolvedor "de verdade", do "mundo real" aplicando a teoria que aprendeu do TDD.
Introdução ao TDD (Test-Driven Development) - #guma10anosDionatan default
Introdução ao TDD (Test-Driven Development) palestrado no #guma10anos. Fazendo uma relação com o TFD (Test First Development) e Refatoração, xUnit, Baby Steps, Clean Code, Patters para TDD, Agile Testing e ATDD (Acceptance Test-Driven Development). Ao final os Coding Dojos já realizados pelo RSJUG. Ao final um Prepared Kata demonstrando o TDD na prática.
O Teste de Usabilidade é um método para verificar a facilidade de uso de uma interface para seus usuários finais. Esta oficina explica como fazer na prática testes.
Estratégias e Técnicas de Testes - Parte1Lorena Caldas
Slides da da palestra sobre Estratégias e Técnicas de Testes, apresentada por mim, na data de 19/11/2013 aos formandos do curso de Análise de Sistemas da instiutição IBES
Palestra Teste de Software: princípios, ferramentas e carreiraTaís Dall'Oca
A palestra inicialmente abordará os princípios do Teste de Software como o que é teste de software, níveis de teste, tipos de teste, como testar um software, gestão de testes, gestão de defeitos, certificações entre outros. Durante a palestra serão mostradas as principais ferramentas que auxiliam os testadores e qual a funcionalidade de cada uma. E por fim será discutido sobre a carreira e os papéis em relação ao mercado atual.
Meetup SP - O QA & a Especificação Por ExemploSamanta Cicilia
Especificação por exemplo é um conjunto de patterns que ajudam a construir o produto certo da maneira certa. Muitas pessoas atribuem sua utilização apenas a parte de teste de software, porém ela vai muito além disso e tem dicas valiosas sobre o quanto a colaboração pode nos ajudar a descobrir o que nossos clientes realmente precisam.
Nessa palestra relato minha experiência não como um desenvolvedor de software altamente sinistro com duzentos anos de experiência e mil livros publicados - mas sim como um "mero mortal", um desenvolvedor "de verdade", do "mundo real" aplicando a teoria que aprendeu do TDD.
Introdução ao TDD (Test-Driven Development) - #guma10anosDionatan default
Introdução ao TDD (Test-Driven Development) palestrado no #guma10anos. Fazendo uma relação com o TFD (Test First Development) e Refatoração, xUnit, Baby Steps, Clean Code, Patters para TDD, Agile Testing e ATDD (Acceptance Test-Driven Development). Ao final os Coding Dojos já realizados pelo RSJUG. Ao final um Prepared Kata demonstrando o TDD na prática.
O Teste de Usabilidade é um método para verificar a facilidade de uso de uma interface para seus usuários finais. Esta oficina explica como fazer na prática testes.
Estratégias e Técnicas de Testes - Parte1Lorena Caldas
Slides da da palestra sobre Estratégias e Técnicas de Testes, apresentada por mim, na data de 19/11/2013 aos formandos do curso de Análise de Sistemas da instiutição IBES
Palestra Teste de Software: princípios, ferramentas e carreiraTaís Dall'Oca
A palestra inicialmente abordará os princípios do Teste de Software como o que é teste de software, níveis de teste, tipos de teste, como testar um software, gestão de testes, gestão de defeitos, certificações entre outros. Durante a palestra serão mostradas as principais ferramentas que auxiliam os testadores e qual a funcionalidade de cada uma. E por fim será discutido sobre a carreira e os papéis em relação ao mercado atual.
Introdução ao Teste de Software - Uma abordagem práticaFabrício Campos
Apresentação do curso "Introdução ao Teste de Software - Uma abordagem prática", ministrado por Fabrício Ferrari de Campos no primeiro Ensina aí! realizado na Voice Technology.
DevCamp - O papel de um testador em uma equipe ágilElias Nogueira
Nesta apresentação são colocados alguns pontos/papéis do testador em uma equipe ágil e as principais dúvidas de uma equipe quando alguém "veste o chapéu" de teste ou teremos um testador na equipe.
Apresentação sobre alguns conceitos iniciais de teste de software.
Fala sobre tipos de teste, agile testing, papéis envolvidos, cultura de testes.
Apresentação feita em conjunto por Roberto Espinha e Anelise Bastos.
Melhorando a qualidade do software com testes de ponta a-pontaGuilherme Cardoso
No processo de desenvolvimento de software precisamos garantir a qualidade do software de ponta-a-ponta. Nessa palestra veremos alguns princípios utilizados utilizados no desenvolvimento de software e como aliar isso a gestão garantindo uma melhor qualidade.
Você ja pensou que quando a sua suite de testes começa a apresentar falhas sem motivos, a causa disso pode estar em nós mesmos?
Por que isso acontece? Nessa palestra, baseados em uma apresentação do selenium conf de 2017, nós iremos abordar essa questão e boas maneiras que aprendemos para tentar lidar com isso e mitigar esse problema.
Você sabe o que é Perfil Tipo T ? Por que no mercado atual os testadores precisam ter esse perfil ? Essa palestra vai mostrar a importância cada vez maior que os testadores estão tendo para o sucesso nos projetos de software. Veremos os tipos de testes que o mercado exige e a razão que devemos nos adaptar para realiza-los da melhor forma possível. Conhecer bem os requisitos é importante para meu trabalho ? Preciso entender de ferramentas de automatização ? Preciso saber programar e também entenderdo negócio ? Vamos ter uma palestra colaborativa onde tentaremos juntos responder todas essas perguntas e desvendar o que esse perfil T tão buscado pelo mercado e que vantagens tem em termos esse tipo de profissional na empresa
Semelhante a Verdades e mitos sobre testes que eu gostaria (20)
1. Verdades e mitos sobre testes
que eu gostaria que tivessem
me avisado
Livia Gabos
2. Objetivos da palestra
• Não é fazer vocês desistirem da área de testes.
• Não é fazer vocês pensarem que eu estou reclamando da vida.
• Não é fazer vocês pensarem que o pessoal de testes leva a pior
(sempre).
• Não é fazer vocês pensarem que testes são chatos.
3. Objetivos da palestra
• Contar um pouco sobre as minhas experiências.
• Coisas que vi e ouvi em eventos e outras pessoas da área.
9. Testes não são importantes
• Engano de uma pessoa produz um passo incorreto
• Era para ser x>=4 e virou x>4Defeito
• Estado inconsistente ou inesperadoErro
• Resultado é diferente do resultado esperado
• 1, 2, 3 e 4 não passa...xiii, acho que não funcionouFalha
11. Testes são importantes!
• Testes são uma parte da qualidade.
• Já ajudam muito para garantir a qualidade.
• Processo de desenvolvimento deve possuir qualidade.
• “Sem testes, sem defeitos” by @ProgramadorREAL
13. Testes só acontecem no final
• Final do que?
• Da iteração?
• Do desenvolvimento da funcionalidade?
• Do ciclo de desenvolvimento?
• Da semana?
• Do mês?
• Do software ter sido produzido por inteiro?
• Do meu salário?
14. Testes só acontecem no final
• “O produto final do processo de desenvolvimento é exatamente o
somatório de todas as decisões e realizações geradas durante todo o
ciclo de desenvolvimento.
• Se for desejado produzir software com alta qualidade, será necessário
investir em qualidade em todos os pontos do processo.”
• https://patiaragon.wordpress.com/
17. Testes só acontecem no final
• Por que isso acontece?
• Ninguém gosta de alguém falando que você está errado.
• Ninguém quer alguém questionando suas ideias.
• “Do seu jeito é melhor? Então desenvolve aí...”
18. Testes não acontecem apenas no final
• Existem testes que são papel do desenvolvedor.
• Se você pensa: qualidade = testes, como você deixa a qualidade para
o final?
26. Se testar só a última versão está tudo bem!
UI
Integração
Unitário
UI
Integração
Unitário
Manuais
Manuais
VS
SIM NÃO
27. Se testar só a última versão está tudo bem!
• Acham que programar script de teste é complicado.
• Acham que teste automatizado é usando ferramenta de play-record.
• Por conta disso, ninguém quer testar antes de nunca mais mexerem
um pixel na tela.
• Daí o teste fica tudo no final.
30. Você não precisa de documentação para
testar!
• O que você considera documentação?
• Diagrama de classe?
• Documento de requisitos (atualizado)?
• Casos de uso (atualizado)?
• O que você considera documentação de testes?
• Plano de testes
• Casos de testes
• Relatório de teste
31. Acho que a função de
controle e integração
entre o departamento
de marketing e da
controladoria pode
ser.....
32. O que ele estava pensando
quando escreveu essa
funcionalidade?
33. Você não precisa de documentação para
testar!
• Documentação serve para comunicar.
• Preciso fazer um longo documento de requisitos (que eu não vou
atualizar depois da terceira iteração)?
• Não
• Posso escrever de um jeito mais simples o que aquela funcionalidade
precisa fazer?
• Sim
34. Você não precisa de documentação para
testar!
Cenário <descrição do teste>
Dado <uma pré-condição>
Quando <passo>
Então <resultado esperado>
Cenário: Consultando um triângulo
Escaleno
Dado que eu estou na página de
consulta de triângulos
Quando eu informo os lados do
triangulo como 3 – 4 – 5
Então o sistema informa que o
triângulo é “escaleno”.
35. Você precisa de alguma documentação!
• Você precisa de um oráculo!
• A documentação ajuda para quando não tem ninguém da sua equipe
• Todos estão de férias menos você!
37. Todo bug encontrado é culpa
do desenvolvedor
• Algo não está escrito certo ou está difícil de entender.
• Desenvolvedor não entendeu o que estava escrito.
• Nem tinha documentação.
38. Todo bug encontrado é culpa
do desenvolvedor
• Porque o desenvolvedor tem que testar?
• Testar =! Debugar
• Códigos de refatoração -> o testador não vai achar isso!
• Teste unitário e integração
39. Todo bug encontrado é culpa
do desenvolvedor
Depois que o erro é encontrado, podemos declarar que o
procedimento ideal seria:
• Analisar o bug, resolvê-lo, e registrar a atividade como “Erro” na
ferramenta de controle interno para fins de documentação;
• Utilizar métodos de análise de causa para descobrir como o erro
chegou até a produção;
• Certificar-se de que a causa seja resolvida para evitar ocorrências
futuras.
40. Todo bug encontrado é culpa
do desenvolvedor
Depois que o erro é encontrado, podemos declarar que o
procedimento ideal seria:
• Analisar o bug, resolvê-lo, e registrar a atividade como “Erro” na
ferramenta de controle interno para fins de documentação;
41. Todo bug encontrado é culpa
do desenvolvedor
• Precisamos achar de quem é a culpa?
• Não
• Porque só se faz isso então?
42. Os bugs encontrados não é culpa de ngm!
• É necessário corrigir o processo que criou o bug e o processo que não
encontrou ele a tempo.
44. O teste é responsabilidade apenas do
testador
• Porque isso acontece?
• Falta tempo para o desenvolvedor testar
• Falta tempo para o desenvolvedor desenvolver (às vezes)
• Falta experiência
• Sobre preconceito
45. O teste é responsabilidade apenas do
testador
UI
Integração
Unitário
UI
Integração
Unitário
Manuais
Manuais
VS
46. O teste é responsabilidade apenas do
testador
• TDD - Test Driven Development
• Programação em duplas
47. Todo mundo tem que testar!
• Todo mundo testa com diferentes visões.
48. O teste de sistema/funcional é o
mais importante
49. O teste de sistema/funcional é o mais
importante
• Técnica de teste
• Valor limite
• Partição de equivalência
• Exploratório
• Nível do teste
• Módulo único
• Teste de Unidade
• Agrupamento de módulos
• Teste de Integração
• Sistema completo
• Teste de Sistema
50. O teste de sistema/funcional é o mais
importante
• Tem outros?
• Testes funcionais
• Testes não-funcionais
• Teste de usabilidade
• Teste de acessibilidade
• Teste de performance
• Teste de carga
• Teste de stress
• Teste de segurança
• Aceitação
• Regressão
51. O teste de sistema/funcional é o mais
importante
• O que você considera como qualidade?
• O que o seu gerente considera como qualidade?
• O que seu cliente considera como qualidade?
• O que o usuário final considera como qualidade?
52. O teste de sistema/funcional é o mais
importante
• Testes funcionais
• Testes não-funcionais
• Teste de usabilidade
• Teste de acessibilidade
• Teste de performance
• Teste de carga
• Teste de stress
• Teste de segurança
• Aceitação
• Regressão
53. Faça testes que garantam o que você precisa !
• Tudo depende do que você precisa garantir para saber qual teste é
melhor para você.
55. Teste não-funcional não é importante
• Você sabe escrever um requisito não-funcional?
• Você sabe o que é um requisito não-funcional?
56. Teste não-funcional não é importante
• Requisitos não-funcionais são relacionados ao uso da aplicação em
termos de desempenho, usabilidade, confiabilidade, disponibilidade,
segurança e tecnologias envolvidas.
• Muitas vezes, os requisitos não funcionais acabam gerando restrições
aos funcionais.
• “Não é preciso o cliente dizer sobre eles, pois eles são características
mínimas de um software de qualidade.”
57. Teste não-funcional não é importante
• Declarar os requisitos não-funcionais como user-stories
• Como um cliente, quero ser capaz de executar o seu produto em todas as
versões do Windows, do Windows 95 até a versão atual.
• Como diretor de tecnologia, quero que o sistema use nosso banco de dados
de pedidos ao invés de criar um novo banco, para não termos mais um banco
de dados para manter.
• Como usuário, quero que o site esteja disponível 99,999% do tempo em que
tentar acessá-lo, para que eu não fique frustrado e procure outro site.
58. Teste não-funcional não é importante
• Custo de conformidade inicial
• Custo de conformidade contínua
59. Teste não-funcional não é importante
• Equipe de desenvolvimento lembra dos requisitos não-funcionais?
• Gerente
• Dev
• Analista de requisitos
• Chega no final de tudo e alguém fala:
• Vai testar a acessibilidade?
60. Teste não-funcional é importante sim!
• Existem startup usando teste de usabilidade para avaliar protótipos e
ideias.
• Existem testes não-funcionais que são tão importantes quanto os
funcionais.
62. Ninguém tem esse nome tão comprido!
• Qual o problema com o nome?
• O nome é comprido demais
• O nome é curto demais
• Um nome normal não usa números
64. Ninguém tem esse nome tão comprido!
• Antônio Treze de Junho de Mil Novecentos e Dezessete
• Benedito Frôscolo Jovino de Almeida Aimbaré Militão de Souza Baruel
de Itaparica Boré Fomi de Tucunduvá
• Brígida de Samora Mora Belderagas Piruégas de Alfim Cerqueira
Borges Cabral
• Carlos Alberto Santíssimo Sacramento Cantinho da Vila Alencar da
Corte Real Sampaio Carneiro de Souza e Faro
• Napoleão Bonaparte Sem Medo e Sem Mácula
• Simplício Simplório da Simplicidade Simples
65. Não subestimem a criatividade das pessoas!
• Testar com informações reais e possíveis
• Nome: ahskdauhsdkuahskduhakushdkaushdukas
• Sejam criativos
• Façam composições de informações para serem complexas
67. Testes são rápidos/lentos de se fazer.
• As pessoas pensam que testes são rápidos de se fazerem e por isso
deixam para depois. (E não fazem)
• As pessoas pensam que testes são muitos demorados e atrasam o
processo de desenvolvimento. (E não fazem)
68. Testes são rápidos/lentos de se fazer.
• Tudo depende se você tem ou não uma métrica.
• Se você entende das necessidades essenciais de teste.
• Não adianta não fazer testes porque demoraram mais a entrega final
por conta disso.
69. Sem conhecimento não existe qualidade
• Se você registra as condições do teste, você pode obter métricas e
tornar o processo de teste mais inteligente.
• Se você conhece seu produto, entende seu processo de
desenvolvimento e sua equipe, você sabe como testá-lo.
• Ter qualidade no processo significa no final que se você fizer o teste
no começo, no meio ou no fim de uma iteração o resultado não será
trágico.
71. Você não precisa saber programar!
UI
Integração
Unitário
Manuais
72. Você não precisa saber programar!
UI
Integração
Unitário
UI
Integração
Unitário
Manuais
Manuais
VS
73. Você não precisa saber programar!
• Você só sabe fazer teste manual.
• Você só faz testes com a interface.
• Você não tem voz ativa na equipe de desenvolvimento.
74. Você tem que saber programar sim!
• Saber banco de dados
• Saber programar
• Saber mexer com frameworks de testes
76. Testes são só custos
• Por que você quer fazer testes?
• Provar que tudo funciona?
• Provar que não tem erros?
• Provar que você não vai ter surpresas desagradáveis quando entregar aquilo
pro cliente?
• Provar que tem qualidade?
77. Testes são só custos
• Qualidade é o principal.
• Se seu processo de desenvolvimento possui problemas de qualidade
não é o teste que vai salvá-lo.
78. Sigam no twitter
• @thoughtworks_pt
• @eliasnogueira
• @qualister
• @c_caetano
• @gutsrs – canal no youtube também
• http://agiletesters.com.br/