Experiência de 5 anos com Teste de Software
•Transferir como PPTX, PDF•
0 gostou•118 visualizações
Muitas pessoas ligadas ao desenvolvimento ágil vem tratando o teste de forma simplista, reducionista e mecanicista.Eles acham que todos teste precisam ser automatizados para ganhar tempo. Mas isso não faz sentido, porque o teste é uma atividade cognitiva complexa que requer um conjunto de habilidades e experiência se realmente queremos que as pessoal o façam bem. Vamos falar aqui sobre muitos equívocos que pessoas que não possuem uma imersão na área tem nos rotulado.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Destaque
Semelhante a Experiência de 5 anos com Teste de Software
Semelhante a Experiência de 5 anos com Teste de Software (20)
Experiência de 5 anos com Teste de Software
- 1. Apresentação: - Experiência de 5 anos com Teste de Software - BSTQB - Foundation Level - Sistemas da Informação - FEAN marionick18 48 9692-1488 www.testeinteligente.commarioramos18@gmail.com marioramos18 Mário Ramos
- 2. Falácias e outras Ilusões sobre Teste Ágil
- 4. Cargo Declaração da Missão A - Realizar consultoria no desenvolvimento de soluções em sistemas de informação, estratégias para intranet/internet, fábrica de software e out sourcing. Ter boa comunicação, saber trabalhar sob pressão, ser organizado, detalhista e facilidade de aprendizado. B - Atuar com seleção / desenvolvimento de ferramentas, proposição, implementação e monitoramento de métricas, definição de processos para garantia da qualidade das entregas. C - Ter boa compreensão de grande volume de regras de negócios. Desejáveis conhecimentos em Scrum, Kanban, SQL. Informações técnicas: •Linguagem: .Net C#, Framework 4.0 - Web Forms, JS e AngularJS •Ferramentas utilizadas: Visual Studio 2015, Microsoft QualityTools, xUnit •Banco de dados: SQL Server 2008 com Transact SQL (envolvendo Stored Procedures e Triggers). Conhecimentos e experiências em desenvolvimento na linguagem .Net C#. 1. Tester 2 . QA 3 . Desenvolvedor
- 5. Testador Essencialista A busca disciplinada por menos Ágil todo mundo faz tudo?
- 6. PAPEL em um time ÁGIL Excelência e Maestria
- 7. “TIME ÁGIL e o Mindset problema... … precisamos preservar a Distância crítica” “... é aquela em que as pessoas com competências diversificadas, interesses, temperamentos e experiência trabalham juntos.”
- 8. Relaxe… um papel é uma heurística, não uma prisão. - Se eu sou um desenvolvedor, eu posso fazer teste? - Sim, claro! - Se eu sou um Testador, eu posso melhorar a qualidade fazendo TDD? - Estou certo que sim! - Se eu sou um goleiro, eu posso tentar fazer um gol? - Não há nenhuma regra que lhe impeça. - Se eu sou um zelador, eu posso oferecer sugestões a um CEO? - Por que não?
- 9. Relaxe… um papel é uma heurística, não uma prisão. - Se eu sou um desenvolvedor, eu posso fazer teste? - Claro, como desenvolvedor você já faz teste. E você vai ter que aprimorar suas habilidades e lidar com certas deficiências e preconceitos, se você quiser fazer um grande teste. - Se eu sou um testador, eu posso melhorar a qualidade fazendo TDD? - Estou certo que sim! E se você fizer isso vai ter adotado, pelo menos, temporariamente, a função de desenvolvedor. É difícil vestir dois chapéis ao mesmo tempo. - Se eu sou um goleiro, eu posso tentar fazer um gol? - Não há nenhuma regra contra isso. Mas se você ir para frente a meta do seu time ficará aberto. E a pessoa que abrange o gol no seu lugar não poderá usar as mãos. - Se eu sou um zelador, eu posso oferecer sugestões a um CEO? - Por que não? Mas seu papel não é necessariamente ouvir ou cumprir com as sugestões.
- 10. Missão “Ser um testador é um trabalho digno e importante, que exige uma mentalidade especializada e um conjunto especializado de habilidades.”
- 11. O que é um Testador? O que eu sou? - Eu sou um cientista de pesquisa. - Eu sou um explorador. - Eu sou um cientista social. - Eu sou um crítico...
- 12. Garantia Qualidade “Garantia da Qualidade é assumir a responsabilidade sem autoridade.”
- 13. “Por que o TESTE NÃO PODE ser codificado” “TIME ÁGIL e o foco em AUTOMAÇÃO...“
- 14. “Não há nenhum suporte na literatura científica ou engenharia que sustente a ideia que o TESTE pode ser codificado…..!
- 15. “Conhecimento Tácito e o conhecimento Explícito! “Podemos saber mais do que podemos dizer”. - Michael Polanyi (1966)
- 16. … INTERPRETAÇÃO não pode ser codificado. … EXPERIÊNCIA não pode ser codificado. … INVENÇÃO não pode ser codificado. CONHECIMENTO TÁCITO não pode ser codificado “Teste não é um artefato, teste é uma performance” James Bach
- 17. “Automação de teste deve ser visto como uma extensão da mente humana, não um substituto”
- 18. … muito pouco disso pode ser codificado!”
- 19. Aprender a programar? Comunicação Persuasão e Venda Pensamento Crítico Pensamento Lateral Escrita Pensamento Sistêmico Comportamento Humano Pensamento Criativo Psicologia
- 20. “... o que eles estão automatizando? " “O meu negócio é Teste de Software... “
- 21. - Tanto no Teste Tradicional como no Ágil as pessoas confundem Verificação de Saída (que é completamente automatizável) com Teste (que não é). O TESTE é mais que uma VERIFICAÇÃO Assim como a programação, o teste é um processo de pensamento vivo, verificando vida dentro dele.
- 22. … é algo que fazemos com a motivação de confirmar crenças existentes. VERIFICAÇÃO … fornece um resultado binário de verdadeiro ou falso. … é tudo sobre responder a pergunta “Será que está afirmação passa ou não”? … quando uma Verificação passa, não sabemos se existe um problema ali, só sabemos que ela continua a funcionar no âmbito das nossas expectativas.
- 23. … possui dependência de um artefato como uma especificação (Critérios de Aceite). VERIFICAÇÃO … geralmente possui um resultado previsível e facilmente observável. … é um processo que pode, em princípio, ser realizada por uma ferramenta. … o processo de fazer avaliações através da aplicação de regras de decisão algorítmicos para observações específicas de um produto.
- 24. … tem um resultado em aberto. TESTE … é a cerca de perguntar e responder a pergunta “Existe um problema aqui? E se… “? … não precisa de um artefato como especificação. … envolve conhecimento tácito. … é sobre obter informações através de experimentação, aprendizagem e inferência….
- 25. “Teste engloba a Verificação, ao passo que a Verificação não pode abranger o Teste.”
- 26. “Embora o TESTE envolva alguma Verificação, um programa que só é VERIFICADO é susceptível de ser MAL TESTADO”. “Mesmo se todas as verificações forem executadas, não há teoria, nem métrica, nem ferramenta que pode nos dizer quantos defeitos importantes permanecem.” “Se você está sendo solicitado a fazer somente VERIFICAÇÃO, você possivelmente não está sendo muito útil, porque o seres HUMANOS não se comportam de forma algoritimica.”
- 27. RATIFICAÇÕES… VERIFICAÇÃO Estas definições não são de juízos morais. Não estou dizendo que a verificação é uma coisa intrinsecamente má a fazer. Pelo contrário, a verificação pode ser muito importante. Estou afirmando que para a verificação ser considerado boa, deve acontecer no contexto de um processo de teste competente. Verificação é uma tática de teste.
- 28. CONCLUSÃO Os Agilistas (DevOps, Agile…) tem forçado cada vez mais o uso de Ferramentas, elas estão por toda a parte, ferramentas que na maioria se concentram na verificação. Isto não é em si uma coisa ruim. Mas estou preocupado pela ausência de discussão séria sobre testes, meu objetivo é enfatizar o julgamento complexo envolvido em testar as coisas.
- 29. LIVROS CHABRIS, Christopher; SIMONS, Daniel. The Invisible Gorilla: And Other Ways Our Intuitions Deceive . Harmony (2011) SIMON, Herbert. Sciences of the Artificial. Mit Press (1996) KHANEMAN, Daniel. Thinking, Fast and Slow. Farrar(2011) WEINBERG, Gerald. An Introduction to General Systems Thinking. Weinberg(2011) COLLINS, Harry. Tacit and Explicit Knowledge. University Of Chicago(2010) MCKEOWN, Greg. Essentialism: The Disciplined Pursuit of Less. Rh Korea (2014)
Notas do Editor
- A palavra Teste está na boca de todos que trabalham com desenvolvimento de software, talvez como nunca antes na história. Curiosamente essa palavra é usada para justificar decisões importantes sobre desenvolvimento de software para aqueles que o falam. Assim, por conta do Teste, justificamos a qualidade do produto entregue ao cliente, o tempo de desenvolvimento do produto, a qualidade do código, o que torna o produto aceitável e até mesmo rejeitado pelo cliente. Muito da nossa vida com desenvolvimento de software é pautada em alguma ideia sobre teste de software. Hora, sendo assim tão onipresente, seria de se esperar, que todos soubéssemos com clareza do que se trata. Mas quando somos colocados contra a parede, afinal se você diz, que por causa do teste fez isso ou aquilo, então o que é? do que se trata? ai começam as dificuldades. Afinal de contas, da mesma maneira que usamos tanto a palavra, ignoramos quase que absolutamente o seu sentido. A nível da palestra é obviamente introdutório, pegar você pela mão , passar por ideias a partir de um senso comum presumido e é claro vindo comigo você pouco a pouco vai se distanciar do estágio inicial de ingenuidade de que se encontra. O convite está feito, tomara que você curta a palestra, e ai, pouco a pouco venha a entender porque é tão difícil ver o teste com uma única definição.
- N sou o Testador fodao, n sou o guru, n sou o dono da verdade, sou um cara que através da minha experiência com testes de software, acho posso passar conhecimento pra vc, que pode facilitar a sua vida profissional. A palavra Teste está na boca de todos que trabalham com desenvolvimento de software, talvez como nunca antes na história. Curiosamente essa palavra é usada para justificar decisões importantes sobre desenvolvimento de software para aqueles que o falam. Assim, por conta do Teste, justificamos a qualidade do produto entregue ao cliente, o tempo de desenvolvimento do produto, a qualidade do código, o que torna o produto aceitável e até mesmo rejeitado pelo cliente. Muito da nossa vida com desenvolvimento de software é pautada em alguma ideia sobre teste de software. Hora, sendo assim tão onipresente, seria de se esperar, que todos soubéssemos com clareza do que se trata. Mas quando somos colocados contra a parede, afinal se você diz, que por causa do teste fez isso ou aquilo, então o que é? do que se trata? ai começam as dificuldades. Afinal de contas, da mesma maneira que usamos tanto a palavra, ignoramos quase que absolutamente o seu sentido. A nível da palestra é obviamente introdutório, pegar você pela mão , passar por ideias a partir de um senso comum presumido e é claro vindo comigo você pouco a pouco vai se distanciar do estágio inicial de ingenuidade de que se encontra. O convite está feito, tomara que você curta a palestra, e ai, pouco a pouco venha a entender porque é tão difícil ver o teste com uma única definição.
- A profissão de teste é como o Império Romano no século XVI. É fragmentado, cheio de sobreposição de culturas, e está sendo atacada de diferentes maneiras de diferentes lados por diferentes motivos. Os Agilistas que em colaboração como o valor central de tudo, criticam o próprio conceito de ter um papel de teste como sendo um gargalo ou de de alguma forma inerentemente divisionista, e eles pensam que divisão é a pior coisa do mundo. Eu acho que entregar um produto com erros para o cliente, isso sim ser a pior coisa do mundo. Agile típico dedicado, é esperado que todos possam ajudar com os testes, na prática, isso significa que todos permanecem cronicamente testadores amadores, destreinados e desmotivados. Teste de software é uma tarefa cognitiva social complexa, que requer habilidade, conhecimento tácito, e muitos tipos de experiência, se queremos que as pessoas realmente o façam bem. No entanto, teste é complicado de explicar , precisamente porque muito do que os Testadores qualificados fazem, envolve conhecimento tácito e não explícito, que são aprendidos pela prática e pela imersão em uma cultura, não a partir de documentos ou outros artefatos. Vou falar mais sobre isso depois. Em um campo onde ainda se tem tantas dúvidas como Teste de Software, todos acabam virando autoridade. Pessoas principalmente ligadas ao desenvolvimento Ágil) que em sua maioria desenvolvedores do que propriamente testadores, tratam o teste de forma simplista, rasa e superficial, os resumindo em automação. Como consequência disso, as empresas podem pensar que o teste desacelera os projetos, de modo que todo teste precisa ser “Automatizado” para fornecer mais tempo. Eles podem ter ouvido que em algumas empresas famosas “não se tem testadores” porque os “desenvolvedores fazem o teste”. Que “testadores” não podem fazer parte de um time Ágil, ao menos que saibam programar. Em algumas empresas o teste como um papel definido está indo embora e em outras, testadores estão assumindo novas responsabilidades. Isso tudo está enfraquecendo os testadores de carreira séria, e tirando o foco do que realmente é vital entre tantas coisas triviais. Como testadores de carreira séria, precisamos nos posicionar sobre alguns equívocos que pessoas ligadas ao desenvolvimento de software com conhecimento raso, superficial, minimalista, reducionista estão rotulando nossa profissão.
- Vamos começar com um jogo. Você vai ler declarações de cargo de três empresas de desenvolvimento de software. Tente ligar cada cargo à sua declaração Como você se saiu? Se não teve absolutamente nenhuma ideia de como resolver o exercício, você não foi o único. As declarações de missão bastante genéricas tornam a tarefa quase impossível. Essas afirmações vagas e exageradas não servem para o que deveriam servir: inspirar nos testadores uma clara noção de propósito ou missão. Precisamos eliminar o que não é essencial para assegurar que dediquemos nossa energia às atividades mais significativas para nós. O primeiro item não essencial que devemos aprender a eliminar é, simplesmente, qualquer atividade que não esteja alinhada com o que pretendemos alcançar ou trabalhar. Parece óbvio, mas para conseguir isso é preciso ter muita clareza de propósito. Sem clareza da sua missão,testadores usam uma estratégia em cima do muro: tentam atingir objetivos demais e fazer coisas demais. Em consequência, as equipes se espalham num milhão de direções e fazem pouco progresso em todas elas. Desperdiçam tempo com o que não é essencial e negligenciam o que realmente importa.
- Procuro ser o que eu chamo de Testador Essencialista. O caminho do testador essencialista é buscar de forma incansável por menos porém melhor. Existem muito mais atividades e oportunidades no mundo de desenvolvimento de software do que tempo e recursos para se investir nelas. E, embora muitas possam até ser muito boas, o fato é que a maioria é trivial para testadores. O caminho do testador essencialista exige aprender a fazer uma distinção: filtrar todas essas opções e selecionar apenas as verdadeiramente essenciais. O testador essencialista não trata de fazer mais; trata de fazer as coisas certas. Também não é fazer menos só por fazer menos. É investir tempo e energia da forma mais sábia possível para dar sua contribuição máxima fazendo apenas o essencial. Pode-se ver a diferença entre o caminho do testador essencialista e o caminho do não essencialista no esquema a seguir. Em ambas as imagens, o esforço é o mesmo. Na imagem da esquerda, a energia é dividida em muitas atividades. O resultado é a experiência pouco satisfatória de avançar um milímetro num milhão de direções. Na imagem da direita, a energia é dedicada a uma atividade. O resultado é que, ao investir em menos coisas, temos a experiência satisfatória de alcançar um avanço significativo no que mais importa. O caminho do essencialista rejeita a ideia de que se pode fazer tudo
- As pessoas às vezes dizem "em um projeto Agile, todo mundo faz tudo" ou "não existem papéis em um projeto Agile". O efeito, "todo mundo fazendo tudo" parece ser contrário a uma outra ideia importante para o desenvolvimento Agile: perícia e habilidade. Se tornar um programador especialista leva anos de estudo focado, experiência, determinação e imersão em um modo de vida. No entanto, competência e adequação não são suficientes quando se aspira a alcançar a excelência e maestria. Em um certo ponto da mossa vida precisamos decidir onde focar a nossa energia. Assim: papéis representam uma heurística para focar o meu desenvolvimento de competências e para a distribuição de competências em torno da equipe.
- O Mindset Problema construir um produto exige uma certa mentalidade; testá-lo profundamente exige outro. Quando estou programando, eu venho a ter a mentalidade do construtor . Como tal, eu estou perto da"distância crítica" para o meu trabalho. É relativamente fácil para mim para realizar testes superficial e detectar erros de codificação, ou erros ortográficos e gramaticais, embora depois que eu estive olhando para o trabalho por um tempo, eu posso começar a perde-lôs também. É um pouco mais difícil para mim perceber problemas estruturais mais profundos ou temáticos, porque eu já investi tempo e energia na construção da da minha tarefa, convergindo para algo que eu acredito que eu quero. Para ver problemas mais profundos, eu preciso de uma maior distância crítica, e isso está disponível na mentalidade dos Testadores. Não é uma questão trivial para alternar entre mentalidades, especialmente no que diz respeito ao seu próprio trabalho. Mudar mentalidades não é impossível, mas mudar de construção em um bom trabalho crítico e analítico é trabalhoso e demorado, e mexe com o fluxo. A distância aqui se refere a diferença de uma perspectiva e outra. Uma equipe bem sucedida é aquela em que as pessoas com competências diversificadas, interesses, temperamentos e experiências trabalham juntos para produzir algo que eles não poderiam ter produzido individualmente. Papéis são heurísticas poderosas para ajudar a organizar e estruturar as relações entre as pessoas. Mesmo que eu esteja disposto a fazer qualquer coisa, eu posso servir melhor o projeto no papel de teste, assim como outros servem o projeto melhor no papel desenvolvedor.
- O meu compromisso e responsabilidade em fornecer serviços de teste, me obriga a ser muito cauteloso sobre fazer coisas fora do meu papel. Se eu estou sendo solicitado a realizar um papel diferente, o teste pode ser negligenciado ou comprometido, devo descobrir as prioridades com o meu cliente.
- Então, qual é a missão de um Testador de carreira séria e focado. No papel de um testador, minha missão é apoiar a equipe de negócios e desenvolvimento, encontrando e descrevendo coisas que eu acredito serem problemas importantes e que possam ameaçar o valor do produto. Um testador qualificado deve ser capaz fazer isso em qualquer fase que tenha algo a testar, com qualquer tipo de produto, quer se trate de um programa compilado, um componente, uma função, o código fonte, uma especificação, um documento de requisitos, um modelo, um diagrama ... Qualquer um desses produtos pode ter problemas observáveis, descritíveis associados. Para ser eficaz, devo ser capaz de fornecer uma descrição credível de porque eu acredito que esses problemas realmente importam. O objetivo é dar às pessoas a informação que os ajude a decidir se o produto que eles têm é o produto que eles querem. Qualquer um que é um consumidor dessa informação é um cliente do serviço que eu ofereço. Como testador, eu sou nem o desenvolvedor nem o proprietário do produto. Eu não tenho autoridade sobre o produto, o projeto, ou o negócio. Não faz parte do papel de teste para corrigir o problema (que está nas mãos dos desenvolvedores); não é responsabilidade de um testador decidir que o problema deve ser fixado, nem quando, nem como (que cabe aos desenvolvedores e gerentes); nem é o papel de um testador tomar decisões sobre o escopo do produto. Eu nem sequer tenho autoridade para declarar definitivamente que algo é um problema. Para alguns problemas, designers e desenvolvedores fazem essa determinação. A autoridade superior repousa dentro de uma pessoa responsável pelas decisões sobre o desenvolvimento e lançamento do produto, como um gerente de projeto ou gerente de produto. (Alguns testadores ficam desconfortáveis com a realidade dessas limitações. Para mim, isso seria como um repórter investigativo estar chateado porque ele não pode acabar com a má-fé, processar políticos corruptos, e reestruturar a administração local. Repórteres investigativos investigam a revelam problemas e questões . isso é um trabalho digno e importante e requer um conjunto especializado de habilidades. Quando um repórter investigativo anseia para mudar as coisas para que sejam do jeito dele, ele se torna um político. os políticos precisam de outros conjuntos de habilidades, mentalidade e prioridades que são diferentes daquelas realizadas por repórteres. Os políticos têm certos tipos de autoridade que os repórteres investigativos não têm. os políticos podem e talvez levem em conta as informações que os repórteres investigativos proporcionam, Mas sendo um político significa que você tem direito a ignorar essa informação. Da mesma forma, ser um testador é um trabalho digno e importante, que exige uma mentalidade especializada e um conjunto especializado de habilidades.Construir um produto de qualidade é uma meta que todos compartilham, mas as prioridades dos desenvolvedores e gerentes pode ser diferente da sua. Se você quer ser o único a tomar decisões sobre o produto, então se torne um designer, um programador, ou um gerente de projeto.)
- Resumo: Muitas pessoas dizem que um Testador é aquele cara que quebra o sistema, mas se pensarmos bem, nós não quebramos nada. Se encontramos um problema, é porque ele já estava quebrado. E isso foi descoberto quando eu entendi onde ele poderia estar quebrado. O que eu posso dizer que eu quebro é: eu quebro sonhos; Eu quebro a ilusão de que o software está fazendo o que as pessoas querem. E quando alguém não entender o que um testador faz, estas são algumas das metáforas sobre a qual eu posso começar uma conversa. Eu sou um cientista de pesquisa. O meu campo de estudo é um produto que está em desenvolvimento. Eu pesquiso o produto e tudo em torno dele para descobrir coisas que ninguém mais tem notado até agora. Um foco importante da minha pesquisa é potenciais problemas que ameaçam o valor do produto. Como cientista, eu estou tentando falsificar a teoria de que tudo está bem com o produto. Então eu estudo as tecnologias em que o produto é construído. Eu analiso cada recurso no produto, à procura de problemas na forma de como foi concebido. Eu experimento com cada parte do produto, tentando refutar a teoria de que ele irá se comportar razoavelmente, não importa o que as pessoas fazem com nele. Eu sou um explorador: Eu começo com uma ideia difusa do produto, e um grande caderno vazio. Eu trato o produto como um conjunto de territórios a serem investigados, um país ou cidade ou paisagem para aprender sobre. Eu mover através do espaço, às vezes seguindo uma rota segura, e às vezes desviando do caminho habitual, e às vezes ir aos extremos. Eu poderia seguir alguns dos mesmos caminhos de outra vez, mas quando eu realmente quero aprender sobre o território, eu me desligo das estradas marcadas, ramificação e retrocesso, se perder algumas vezes, mas sempre tentando ver a paisagem de novos ângulos. Eu sou um cientista social. Eu sou um sociólogo e antropólogo, estudando como as pessoas vivem e trabalham; como eles se organizam e interagem; como as coisas acontecem na sua cultura; e como o produto irá ajudá-los a fazer as coisas.Um produto se encaixa na sociedade, para cumprir um propósito social de algum tipo, e os seres humanos devem reparar as diferenças entre o que as máquinas e o que os seres humanos podem fazer. Assim, o teste requer um juízo social complexo é muito mais do que uma questão de garantir que as rodas giram para direita. Eu sou um crítico. Como meus críticos de cinema favorito, eu estudo o trabalho e como ele pode apelar ou não para o público a qual ele se destina. Eu estudo os aspectos técnicos do produto como crítico de cinema olha para iluminação, enquadramento, pelo som; na edição; na construção de histórias; e assim por diante. Eu estudo a cultura e a história de software como um crítico de estudos e das sociedades em geral, para avaliar quão bem o produto (história) se encaixa em relação à sua cultura e sua época e do gênero na qual o trabalho se encaixa. Eu poderia gostar do trabalho ou não, mas como crítico, as minhas preferências pessoais não são tão importantes como a análise do trabalho em prol de uma audiência.
- Eu penso que algumas advertências merecem aqui a nossa atenção, quando você lê algum site de desenvolvimento de software ou conversa com alguém, toda vez que aparece a palavra teste, essa palavra parece indicar um conjunto de regras algorítimicas. Eu diria que o ponto mais agudo dessa percepção é justamente a expressão teste automatizado. No final das contas isso faz acreditar que o teste corresponderia a uma espécia de tabela, uma tabela onde você teria todas as possibilidades de teste em duas colunas de entrada e saída., aceitável ou não aceitável. Se o Teste fosse essa tabela, está palestra de teste seria a palestra para ensinar como devemos testar, e um bom testador é um testador que decorou a tabela. Então esse testador já teria a resposta certa sobre como fazer teste sobre o mundo de desenvolvimento de software. Olha você deve supor que esta palestra não é isso, pq a palestra n é isso? a palestra n é isso pq o TESTE n é isso. E o teste não é isso pq? Por que o teste não pode ser codificado. Quando você vai realizar um teste, você olha, pondera, tenta algo. Você vê o que acontece e refleti sobre isso. Você tem uma pergunta, em seguida, concebe uma observação que pode responder à pergunta. Então testadores qualificados executam centenas de teste que podem parecer discretos em uma sessão. Poucos deles precisam ser repetidos. O valor de um teste não pode ser conhecido até que tenha sido executado. Estes momentos são incorporados em nosso conceito de evolução do risco e de status do produto. Mas para uma pessoa de fora, que não está a par do funcionamento da mente de um testador, é útil sugerir e falar sobre codificação de teste, porque é uma tarefa incorporada dentro do teste, que pode ser substancialmente acelerado ou apoiado com a automação Destilar ideias de teste de modelos mentais tácitos e explícitos para criar casos de teste, vamos chamar isso de "codificação ". Codificação significa a expressão de ideias, de forma explícita , sob alguma forma de código (como palavras escritas (casos de teste) ou software (scripts)). Cultura Ágil insiste que a codificação (TDD) é prática desejável e por outro lado é até irresponsável da nossa parte não codificar teste. Mas isso não faz muito sentido. Por que o teste não pode ser codificado.
- Apesar de anos de pesquisa, os autores estão cientes de nenhum estudo já mostrará que o teste deve ser codificado, ou mesmo que possa ser escrito. Na verdade, o oposto é mais o caso. 1 - Veja o livro “Ciências do Artificial”, que rendeu Prêmio Nobel Herbert Simon para um profundo tratamento deste tema. Simon mostra que a racionalidade perfeita não está disponível para nós em qualquer situação, e sim nas mais simples, e explora a natureza dos processos de concepção como "racionalidade limitada" exigindo soluções heurísticas. 2 - Ou talvez o livro “ Introdução Geral ao Pensamento Sistêmico”, por Gerald Weinberg, que mostra que observar e descrever sistemas complexos nos obriga a simplificá-los, e que não existe algoritmo algum para saber como fazer isso sem perder algo que pode ser importante. 3 - Ou também o livro “O Gorila Invisível” de Christopher Chabris e Daniel Simons, mostra que um artefato que um artefato como um script ou caso de teste tem potencial para nos causar uma “Cegueira Inatencional” que nada mais é do que a capacidade de não notar algo inesperado quando sua atenção está totalmente focada em outra coisa. Ou seja, podemos deixar de ver alguma coisa óbvia de ante dos nossos olhos se n estamos procurando por ela. Trata-se de um efeito colateral de algo que geralmente fazemos muito bem, que é concentrar nossa atenção e filtrar todas as distrações relevantes. O ponto negativo é que as vezes filtramos coisas que queríamos ou precisávamos. 4- Khaneman também faz um tratamento sobre a cegueira inatencional. Este libro teve um profundo efeito sobre a forma de como me aproximei do meu trabalho com Teste de Software, como Khaneman popularizou o conceito de ter dois modos de pensar: rápido e devagar.Ele tb me da uma compreensão de como falho meu cérebro realmente é quando se trata de enquadrar os riscos, a compreensão estatísticas e uma infinidade de preconceitos em mais ou menos cada situação que eu me encontro.concentrando-se em vieses cognitivos específicos 5 - Em 2011, o sociólogo Harry Collins começou a mudar tudo para nós, as suas ideias sobre a forma como a ciência funciona se encaixa perfeitamente em como vemos o campo de teste de software. Aprendemos a falar sobre a diferença entre o conhecimento tácito e explícito, o que nos permite reconhecer o que pode e não pode ser codificado em um script ou outros artefatos.Harry Collins, nos ajuda a entender melhor como os cientistas pensam, se comportam, socializam e realizam seus experimentos. Depois de ler esse livro, você nunca vai olhar para o seu ambiente de teste da mesma forma novamente! Se você mesmo olhar através de qualquer um destes trabalhos, você vai ver uma rejeição mecanicista, reducionista e formas de algoritmos de conceber e controlar sistemas complexos, incluindo os sistemas sociais.
- Conhecimento explícito: Conhecimento que é codificada e transmitido para outras pessoas através de diálogo, de demonstração, ou mídia, tais como livros, desenhos e documentos. Conhecimento tácito: Profundamente experiência pessoal, aptidões, percepções, conhecimentos empíricos, que na verdade não pode ser expresso - que reside em indivíduos e equipes. Aqui está um diagrama que mostra visualmente a diferença na quantidade de conhecimento que temos em cada tipo, veja que o conhecimento explícita sendo bastante pequeno, a maior parte do nosso conhecimento é tácito. De acordo com Buckman da Buckman Labs ,, 90% do conhecimento em qualquer organização está inserida e sintetizadas nas cabeças das pessoas. Desencadeando este conhecimento que é de natureza tácita-apresenta um grande desafio. ( Wah , 1999b;)
- Se o teste funcionou a partir do momento em que um testador relata com sucesso um problema importante, eu acho que isso é resultado de muitas sobreposições, apoio de pensamentos, julgamentos e experiências. Você não pode codificar interpretação, invenção, inovação e resolução de problemas que acontece no trabalho de programação.
- Cada um deve criar um modelo mental sobre o produto. Uma maneira mais familiarizada de dizer que temos de aprender tudo sobre ele, e o resultado dessa aprendizagem é uma estrutura mental do qual nós podemos projetar testes. Este modelo em si não pode ser codificados em qualquer forma explícita (é neurônios baby). Mas podemos, se quisermos, produzir algum forma de projeção explícita de nosso modelo mental. Por isso , enquanto que alguns dos nossos aprendizados podem ser codificados, a maior parte dele não pode por pelo menos duas razões: 1 - Nós não temos nenhum algoritmo ou mecanismo para fazer uma "cópia do nosso cérebro" que reflita com precisão o estado de nosso conhecimento sobre qualquer coisa. Isso significa que nunca se pode descartar a possibilidade de que haja um fato que sabemos sobre, e ainda não colocamos em nosso modelo. 2 - Mesmo se não houvesse um tal mecanismo , a velocidade com que aprendemos é esmagadora. Nós seres humanos temos a capacidade de fazer as coisas, identificar coisas, perceber as coisas e analisar coisas que os computadores não podem. Isso é verdade mesmo para testadores "não qualificados". Os testadores precisam assumir o controle de seus modelos mentais e elaborar perguntas poderosas para sondar a tecnologia a frente deles. Este é um processo de auto-programação. Neste modo de funcionamento, a automação de teste é visto como uma extensão da mente humana, não um substituto. Um bom exemplo onde usamos uma ferramenta como extensão de mente humana pode ser a curisoity. Já que no momento n se rra viável enviar seres humanos para fazer uma exploração em Marte, criamos uma ferramentar para fazer essa exploração por nós. Mas sempre sob os olhares de um ser humano competente.
- A âmbito de um teste é elástico. Pode envolver a exploração especulativa de um produto, ou algo tão simples como verificar o resultado de uma função ao chamá-la.Testes tem vários níveis, os quais contribuem para o êxito da empresa em teste, e acredite, muito pouco disso pode ser codificado. É tempo de nos lembrar o que sempre foi verdade, que as ferramentas não são o ponto central do teste. Em outras profissões como cientista e pesquisadores eles não usam palavras como pesquisas automatizadas ou estudos automatizados, e nem por isso deixamos de reconhecer o valor das ferramentas para essas áreas.
- Bom, se vimos até agora que muito pouco do teste pode ser codificado, então porque muitas das pessoas que se dizem especialista em Teste de Software, vivem dizendo que vc precisa aprender a programar? O que eu falei até agora são dados científicos de pessoas altamente conceituadas na comunidade científica, não há questionamento com relação ao que eles dizem. Não sou contra de testadores aprenderem a programar, se isso é algo que eles estão interessados e querem aprender.Por outro lado, pode não ser a melhor habilidade ou valor que você pode trazer para uma equipe, especialmente se você já tem 5-6 codificadores excepcionais em sua equipe. Existem outras habilidades que são de valor para a equipe e para a empresa do que conhecimento técnico. Muitas pessoas dizem que vc deve aprender a programar, mas quantas dizem para vc melhorar sua comunicação e torna-lá mais eficaz? Saber se comunicar bem é extremamente útil para um testador expressar um problema de forma credível e confiável, e acho que isso não é novidade para ninguém, mas ela geralmente é deixada de lado comparado a aprender a programar. Todos nós temos que saber vender nossas idéias e convencer os outros de que as nossas idéias são as idéias certas e que traram benefícios ao time. Quantas vezes você precisou vender o teste que você está executando? Ou convencer alguém de que um defeito realmente não precisa ser corrigido? Ter essas habilidades é crucial para testadores serem capazes de transportar suas atividades de testes diários. Bom tem várias coisas que considero serem mais importantes que aprender a programar, n vou entrar em muitos detalhes sobre cada uma delas porque o tempo aqui é curto. Mas prometo detalha-las melhor no meu site depois testeinteligente.com Em muitas organizações existe um monte de ego, desânimo, nenhuma habilidade parece ser boa o suficiente etc. Em vez de dizer: “Testadores precisam codificar”, podemos dizer “Testadores precisam testar” e “desenvolvedores precisam codificar” e isso é uma combinação que deixa nossos clientes felizes.Podemos ter no time testadores de software exploratórios que se concentram em aprender a testar melhor, enquanto tb temos desenvolvedores apaixonados que têm uma vasta experiência com programação. Podemos aprender várias coisas juntos que é benefício mútuo com os nossos clientes e para nós. Mais uma vez voltando para o testador Essencialista, precisamos aprender a dizer não, se não definirmos a nossa missão ou prioridades dentro de um time como pessoas altamente qualificadas em teste, outras pessoas acabaram fazendo isso por nós. E acredite, você n irá gostar do rumo das coisas.
- Já ouvi muitas pessoas dizendo que também estão em meu negócio. Às vezes, quando essas pessoas falam sobre como automatizar testes, percebo que eles provavelmente não estão no mesmo negócio que eu. Eles não podem estar, porque o que eu acho que eu estou fazendo é muito difícil de automatizar de forma significativa. Então eu me pergunto ...
- Essa distinção começou a ser feita por Michael Bolton e James Bach a partir de 2009. É possível distinguir entre os aspectos do processo de teste que as máquinas podem fazer contra aqueles que só os humanos qualificados pode fazer. Um problema comum em nossa indústria é que a verificação é confundido com o teste. Um dos meus propósitos aqui é reduzir essa confusão. A verificação é descritível; um teste pode não ser (Isso porque, ao contrário de uma verificação, um teste envolve o conhecimento tácito).
- Essa distinção começou a ser feita por Michael Bolton e James Bach a partir de 2009. É possível distinguir entre os aspectos do processo de teste que as máquinas podem fazer contra aqueles que só os humanos qualificados pode fazer
- As verificações podem ser muito úteis, mas eles são meros ecos e sugestões de pensamento do processo de teste. Eles não refletem a riqueza da busca de defeitos.
- Ferramentas não deveriam ser notáveis em teste, bons testadores usá-las quando necessário dentro de um determinado contexto. Em vez de perguntar para alguém se está pessoa faz teste automatizado. Perguntar se ele está usando alguma ferramenta para apoiar seus teste. Qualquer coisa que nos ajude no teste pode ser encarado como uma ferramenta. Como por exemplo um caderno, uma folha em branco, um planilha de excel. Todos esses itens são ótimas ferramentas que podem apoiar os teste.
- Estamos precisando lidar cada vez mais com sistemas mais complexos, isso pressiona os testadores a fazer testes cada vez mais rápidos e por isso é muito tentador pensar em ferramentas. Já vi muitos projetos e empresas, incluindo um monte de projetos ágeis, rotineiramente vejo que falar de verificação tem abafado conversa sobre testes, exceto o que as pessoas chamam de teste, onde ninguém percebe como enviesada seu foco se tornou. Testadores se tornam cada vez mais entusiasmados como quase-programadores. Quem vai estudar sobre testes, então? O que os testadores em projetos ágeis normalmente falam nas respectivas conferências ou na Web? Ferramentas. Ferramentas. Só estou reividicando que as ferramentas voltem ao seu lugar de direito, que abaixo do teste e não acima dele.
- Essa distinção começou a ser feita por Michael Bolton e James Bach a partir de 2009. É possível distinguir entre os aspectos do processo de teste que as máquinas podem fazer contra aqueles que só os humanos qualificados pode fazer
- Estamos precisando lidar cada vez mais com sistemas mais complexos, isso pressiona os testers a fazer testes cada vez mais rápidos e por isso é muito tentador pensar em ferramentas. Nós visitar muitos projetos e empresas, incluindo um monte de projetos ágeis, e nós rotineiramente achar que falar de verificação tem abafado conversa de testes, exceto que as pessoas chamam de teste para que ninguém nem percebe como enviesada seu foco se tornou. Testadores se tornam cada vez selecionada para o seu entusiasmo como quase-programadores. Que estuda os testes, então? O que os testadores em projetos ágeis normalmente falam nas respectivas conferências ou na Web? Ferramentas. Ferramentas. E ferramentas na maioria das quais se concentram na verificação, bem como a elaboração de requisitos verificáveis. Esta não é em si uma coisa ruim. Estamos preocupados pela ausência de discussão séria de testes. investigação crítica do produto que somente sreres humanos qualificados podem fazer.