Olá! sou seu novo vizinho! nos casamos faz pouco tempo e acabamos de nos mudar pra essa casa e não tinha certeza se você estava me cumprimentando naquele dia pela janela ou se estava fazendo outra coisa. Em todo caso acenei porque não enxergo bem à distância e ainda estou aprendendo os nomes dos vizinhos – Eu disse. 

“Que legal! sou italiana, mas mudei pra esse país fazem muitos anos. Meu marido é inglês e moramos aqui já faz vários anos. Seja bem vindo!”

Que legal! também sou italiano! peró non parlo italiano molto bene. E continuei falando em inglês com ela.

Ana já era bem idosinha, e às vezes não dava pra entender muito o que ela falava em inglês. Mas a simpatia era nítida. Tipicamente de nonas italianas. Diretas mas muito gentis.  

“Você gosta de pasta? qualquer dia desses poderiam vir jantar com a gente e eu posso fazer uma pasta” – disse Ana

Claro! respondi. Adoro pasta (macarrão de qualquer tipo). Mas naturalmente não levei o convite muito a sério, haja vista que havia acabado de me mudar e não é muito costumeiro pessoas te chamarem pra jantar na casa delas, mesmo que sendo vizinhas, acabando de conhecer. 

Desde então, de vez em quando via a Ana pela minha janela cuidando do jardim dos fundos de sua casa. Ou cuidando do seu pé de tomate, feito o pequeno príncipe cuidando da rosa dele. Casas do interior da Inglaterra não tem muitos muros ou cercas. Apesar de ela morar duas casas abaixo da minha, nos víamos com frequência à distância. Raramente via seu marido no quintal. 

Apesar disso, quando encontrava Ana nas redondezas e resolvia cumprimentá-la, ela não parecia me reconhecer. Devido a senioridade dela e eu ter convivido com um avô com Alzheimer anos antes, suspeitei que poderia ser algo do tipo, mas mantive minhas suspeitas pra mim mesmo. 

Não pensava muito sobre o assunto até que um dia, uma outra vizinha me confirmou que de fato Ana tinha algum tipo de o que eles chamam aqui de demência. 

Não sou médico, muito menos habilitado para diagnosticar qualquer coisa ligada à saúde física ou mental de ninguém. Mas a confirmação da doença da Ana, me foi contado por essa vizinha que a conhece há diversos anos fez todo sentido. 

Desde então, quando via Ana pela rua, mantinha os cumprimentos. Às vezes ela me respondia. Outras vezes fazia aquela cara de que não fazia ideia de quem eu era. E era assim, sempre, por quase três anos.

Engraçado observar que por diversas vezes eu sentia o cheiro de algo queimando e fumaça, e saia preocupado pra olhar se não era a casa da Ana pegando fogo. Felizmente nunca foi o caso. Era só a Ana queimando lixo no final das tardezinhas. 

Mais engraçado ainda que eu achava que isso era apenas um costume de pessoas da fazenda ou coisa do interior de onde cresci. Não esperava  uma senhora italiana morando na Inglaterra queimando lixo religiosamente durante a tarde. 

Diversas vezes via a Ana passando na frente do meu jardim da frente quando ela ia ao supermercado. Sempre sozinha. Quase sempre com seu chapeuzinho, vestida de saia e roupas características de nonna italiana. Acompanhada de um carrinho de compras. Postura com a coluna levemente encurvada para frente. Parecendo muito aquelas idosinhas características de desenho animado. 

Hoje recebi a notícia que Ana faleceu ontem a noite. Ana se foi exatamente um mês após seu marido falecer. 

“Você sabia que a Ana faleceu? O marido dela faleceu há exatos um mês e ela ficava esquecendo disso. Então ela me contou inúmeras vezes sobre o fato nesse último mês. Até que ontem, ouvi um barulho, corri pra ver, chamei ambulância e polícia e a Ana se foi”  – O vizinho entre a casa minha e a dela me contou hoje quando eu chegava em casa.

Fiquei pensando em quanto foi triste pra Ana esse um mês de ter que ouvir repetidas vezes que seu marido de muitos anos havia falecido. Repetidas vezes, pois a demência a fazia esquecer do fato. Mais triste ainda comunicar o fato inúmeras vezes aos conhecidos.  

Apesar das duas tristezas de saber que Ana e seu marido se foram. De ver as luzes todas apagadas e a sua casa vazia. Perguntei um pouco mais da vida da Ana pra esse vizinho que a conhecia por muitos anos. 

Ele me disse que Ana e seu marido tiveram uma vida longa e feliz. Ambos se foram com mais de noventa anos de idade. Tiveram filhos e uma boa vida. 

Sentindo uma sensação de perda e tristeza, respondi pro meu vizinho que é isso que podemos esperar dessa vida. E acredito que é isso que podemos realmente pedir e esperar: uma vida longa e feliz. 

Nosso jantar com a pasta nunca aconteceu. Não mais sentirei o cheiro de fumaça e sairei correndo pra perceber que é você queimando coisas no quintal. Nem ficarei aflito de ver você se apoiando na casinha de ferramentas caindo aos pedaços do seu quintal e achando que ela desmontaria sobre você a qualquer segundo. Nem ainda te verei passando da minha janela pra fazer compras toda admirável. 

Não fomos amigos próximos. Mas ter a Ana como vizinha fez parte da minha vida de uma certa forma. Parte do cenário dessa cidadezinha do interior da Inglaterra que tanto prezo. E fico feliz em saber que sua vida foi longa e feliz. 

Vá em paz Ana. Também o marido da Ana que eu nunca soube o nome. 

The post Ana Italiana de Burgess Hill appeared first on Vinicius Pessoni | Tester Global.

A primeira coisa que as maioria das pessoas pensam quando falamos de teste de software é:

Tem que testar TUDO!

Porém, o que não se considera nesses casos é que softwares são complexos por natureza e têm diversas possibilidades de combinações de entradas e caminhos.

Na maioria dos casos, existe uma infinidade de possibilidades, que tornam o “testar tudo” infactível, ou mesmo impossível!

Por isso, exceto em domínios muito pequenos, nos quais podemos exercitar todas as combinações de entrada, em produtos da vida real, não conseguimos testar tudo.

Mas se não pode testar tudo, o que fazer?

Como não podemos testar tudo, o foco é criar casos de teste efetivos. E isso significa criar testes que cubram a maior parte do software, descubra a maior quantidades de defeitos possíveis e com o menor esforço possível.

É aí que as técnicas de geração de caso de teste são importantíssimas!

As técnicas mais comuns para essa finalidade são a classe de equivalência e análise de valor limite.

Como usar a Análise do valor limite nos testes?

Usamos a técnica análise do valor limite para gerar casos de teste para intervalos numéricos.

Para usar a análise do valor limite nos testes, descobrimos os limites do campo que queremos testar.

Como exemplo, e um intervalo no qual os números válidos são entre 0 e 5, os limites serão 0 e 5.

Zero representa o limite interior.

Cinco representa o limite superior.

A técnica nos diz que devemos testar um valor imediatamente abaixo do que o limite, o valor limite e um valor imediatamente acima do valor limite.

Como exemplo, para um intervalo entre 0 e 5, precisamos testar os valores:

-1, 0, 1 para o valor limite 0

4, 5, 6 para o valor limite 5

Com isso, temos os casos de teste para esse intervalo numérico conforme a técnica análise de valor limite.

The post Análise do Valor Limite appeared first on Vinicius Pessoni | Tester Global.

Você sabe o que um tester de software faz? qual o trabalho de um testador de software? O que é testar programas? Se não sabe vem descobrir!

Apesar de termos diversos nomes como:

• analista de qualidade;
• analista de teste;
• software development engineer in test;
• engenheiro de teste;
• “carinha do teste” kkkk;
• etc…

O trabalho de um testador de software é muito parecido, independente do título recebido.

O nosso principal foco é ajudar a entregar programas (sofwares) de boa qualidade para os clientes. Ou seja, quando o cliente usar os nossos produtos, ele deve conseguir fazer o que precisa, sem problemas e bugs atrapalhando.

E isso significa, não somente fazer teste de forma manual, mas também de forma automatizada e estar presente em todas as etapas de desenvolvimento do software.

No mundo ágil, o nosso trabalho de tester está espalhado em todo o processo de desenvolvimento.

O que fazemos em cada fase do processo de desenvolvimento?

Os testadores de software têm tarefas específicas desde a fase de requisitos, passando pela fase de projeto, desenvolvimento, testes e deployment na produção.

Na fase de requisitos, a gente vai ajudar a revisar os requisitos e levantar cenários diferentes que podem conter problemas. Sempre da perspectiva do usuário. Ajudamos os donos do produto (product owners), e as vezes até conversamos com os próprios usuários junto com os donos do produto e analistas. Auxiliamos na escrita dos cenários, podendo usar BDD por exemplo como forma de descrever os cenários que precisam ser implementados.

Na fase de projeto, a gente trabalha junto com os arquitetos e desenvolvedores para projetar o software. Discutimos como é o banco de dados, tipos de padrões de projetos que podemos usar, dificuldades em alguma solução, etc. Então é por isso que testadores também devem ser bons de arquitetura de software, para auxiliar nessas discussões e trazer cenários que podem ser esquecidos durante essa fase.

Na fase de desenvolvimento, trabalhamos diretamente com os desenvolvedores. Podemos sentar junto com eles para programar (pair programming), revisar códigos (pull request review), e também desenvolvemos os testes automáticos de forma paralela. Enquanto os desenvolvedores estão desenvolvendo o código da aplicação, estamos desenvolvendo os códigos dos testes automatizados que vão testar essa aplicação.

Na fase de teste, a gente vai executar os testes que produzimos anteriormente. Nela podemos encontrar defeitos e requisitos que foram implementados de forma incorreta ou incompleta. Isso inclui testes funcionais, de usabilidade, segurança, acessibilidade, carga, estresse. Também podemos fazer testes manuais para complementar os testes automatizados.

Na fase de deployment para produçao, em alguns lugares, podemos ser os responsáveis por colocar as aplicações em produção (ambiente em que os clientes realmente vai usar os programas). Tanto de aplicações web como nas lojas de aplicativos (IOS/ANDROID). Em outros lugares, apenas damos suporte para a equipe responsável por colocar os programas na produção. Mas em todo caso, estamos também envolvidos nessa fase.

Conclusão

No mundo ágil, o nosso trabalho de tester está espalhado em todo o processo de desenvolvimento. Desde a fase de requisitos, passando pela fase de projeto, desenvolvimento, testes e deployment na produção. Muito mais amplo, completo e complexo do que apenas testes manuais e apenas na fase de teste.

E você, como funciona os testes na sua equipe atual? comenta aí que eu quero saber. Um abraço e até a próxima!

The post O que um Testador / Tester de Software Faz? appeared first on Vinicius Pessoni | Tester Global.

O que é 3 amigos?

Três amigos (Three Amigos) é uma técnica de discussão e definição de algo que será feito, podendo ser uma feature, incremento ou correção.

O termo surgiu no meio ágil em 2009 com o principal objetivo de colher pontos de vista de diferentes perspectivas e áreas:

• negócio: geralmente representado pelo analista de negócio ou dono do produto;
• desenvolvimento: representado pelos desenvolvedores, arquitetos;
• e teste: representador pelos engenheiros de teste.

Apesar de chamar 3 amigos, essas discussões podem, e por diversas vezes devem, conter mais que literalmente somente 3 pessoas.

Por quê utilizar essa técnica?

Obter opiniões compartilhadas de diferentes expertises ajuda a definir melhor o que deve ser feito, evitando mau entendidos e falhas de comunicação.

Além disso, utilizar essa técnica contribui nos seguintes aspectos:

• Definição de “qual o problema queremos resolver?”: muito antes de criar código, wireframes ou mesmo testes, é necessário entender bem o que precisa ser feito. Se não entendemos qual o problema queremos resolver com a nova funcionalidade ou correção, corremos um grande risco de entregar algo totalmente fora do real ou pretendido (Alguém aí já passou por isso? ver uma função ser discutida, desenvolvida, testada, e ao final do ciclo não ter nada a ver com o inicialmente pretendido);
• Definição de pronto para ser desenvolvido (Definition of Ready): como sabemos se algo está bem definido o suficiente para começar a ser desenvolvido? o que entendemos por pronto para ser desenvolvido? – já discutimos, detalhamos o que deve ser feito, descrevemos em algum lugar, colocamos as estimativas e está pronto para ser pego por algum desenvolvedor para ser desenvolvido;
• Definição de pronto: como entender que algo está realmente terminado, ou seja, pronto? precisamos chegar a um acordo e detalhar os critérios de aceitação de alguma feature.

Quando utilizar

O mais comum é utilizar nas reuniões de refinamento de backlog (grooming/pbr).

Mas nada impede o uso dessa técnica durante o desenvolvimento – para sanar dúvidas de algo que está sendo desenvolvido, ou também depois que algo foi desenvolvido – para traçar melhores formas de teste. Pode ser utilizada até antes mesmo de uma reunião formal para definição de itens do backlog.

O intuito é ter sempre pessoas advindas de diferentes áreas discutindo e chegando a um consenso sobre o que deve ser feito.

Como isso influencia na qualidade do produto

A participação de testers desde as fases mais iniciais do ciclo de desenvolvimento é sempre benéfico pois eles serão capazes de levantar questões sobre testabilidade e sobre a qualidade do que deve ser produzido.

Além disso, as discussões que levam em consideração diferentes pontos de vista são mais ricas para originar cenários de uso.

Mais contribuições significam uma maior cobertura de possíveis cenários, possibilidades e restrições.

Com base nessa informação, os testers podem então aprender mais sobre o que cada área espera do software e traçar casos de teste mais eficazes, contribuindo para uma melhor qualidade do produto.

Referências

• https://www.visual-paradigm.com/scrum/agile-three-amigos-development-strategy/
• http://rgalen.com/agile-training-news/2014/4/13/3-amigos-in-agile-teams
• https://docs.cucumber.io/bdd/who-does-what/
• https://www.agilealliance.org/glossary/three-amigos

The post O que é 3 amigos no ágil e como isso influencia no software de qualidade appeared first on Vinicius Pessoni | Tester Global.

Os analistas de requisitos reúnem os requisitos, descrevendo-os em algum formato e passam para os desenvolvedores.

Os desenvolvedores desenvolvem o produto e enviam para os testers testarem.

Os testers realizam os testes, encontram um defeito e a guerra se inicia:

-DEV: isso não é um defeito, VOCÊ que não entendeu isso direito.

__TESTER: claro que é! olha aqui a descrição que o analista passou. VOCÊ esqueceu esse pequeno detalhe.

Dev “buffa” de raiva, diz AHRAM, e vai corrigir o defeito. O tester, sai com a alegria e orgulho de um “trabalho bem feito“. Com ar de herói, e que se não fosse ELE, o código estaria explodindo em produção.

UFA, pensa o tester, salvei a equipe de teste receber uma métrica ruim.

A tensão entre dev e testers aumenta a cada release e defeito encontrado. Nesse ambiente não há muito espaço para amizade, em uma guerra não tão fria que segue instalada. Testers trabalham isoladamente dos desenvolvedores, cada um em seu silo. O sentimento entre devs e testers é sempre o de inimigos mortais.

Esse cenário lhe soa familiar?

Em equipes que se dizem ágeis esse cenário não deveria mais existir.

Em equipes ágeis NÃO EXISTEM HERÓIS.

Melhores Amigos

Em equipes verdadeiramente ágeis as responsabilidades são compartilhadas pelos membros da equipe. Não existe aquela velha divisão em que cabe a célebre frase “isso não é meu trabalho”.

As linhas de divisão de trabalho estão cada vez mais tênues. Testers não só desenvolvem e realizam testes, mas participam ativamente desde a concepção das features. Revisam código em pull requests, chamam a atenção para possíveis problemas. Testers e devs sentam-se juntos para programar algo, ou resolver algum problema que um ou outro sozinho não conseguiria resolver.

Não há espaço para o jogo de culpas em que um foca no erro do outro, muito menos para quem acredita que consegue fazer tudo sozinho. Não há espaço para o sentimento de inimigos mortais, pois são melhores amigos. Falei um pouco sobre a importância do espírito de equipe nesse texto aqui.

Em ambientes verdadeiramente ágeis, realizar entregas frequentes e de qualidade é responsabilidade de toda a equipe. E para tanto, faz toda a diferença estarem genuinamente juntos, colaborando diariamente.

Como as outras características de software, a qualidade não é somente trabalho dos testers e muito menos de qualquer indivíduo isoladamente.

Testers, developers, donos do produto discutem os requisitos juntos. Existe até um nome para essa técnica, conhecida como 3 amigos. Os cenários são descritos de forma clara e testável, falei sobre o formato de descrevê-los usando BDD nesse texto aqui.

Assim, focando em como podemos entregar software de qualidade frequentemente, devemos nos fazer duas perguntas:

1. Qual o problema estou resolvendo?

2. Quais os problemas eu deveria estar resolvendo e como isso impacta no resultado da minha equipe como um todo?

Certamente que partindo dessas duas premissas, sem focar em culpados por detalhes específicos, encontraremos formas de contribuir em nossas equipes. E isso significa, controbuit muito além da área específica em que fomos contratados para atuar.

The post Inimigos Mortais X Melhores Amigos appeared first on Vinicius Pessoni | Tester Global.

Em um outro post eu falei sobre quais linguagens de programação aprender em 2019. Mas além de indicar linguagens de programação para aprender, sempre recebo a pergunta:

Como eu faço para aprender programação?

Existem vários cursos maravilhosos em diversas plataformas como Udemy, Pluralsight, Code academy. Alguns custam bem pouco (em torno de 30 reais) outros custam na casa das centenas de reais.

Mas e se eu não tenho dinheiro no momento? como fazer?

E foi por isso que resolvi listar algumas formas de aprender programação DE GRAÇA.

YouTube

Foi-se o tempo em que o youtube só possuía entretenimento. Basta dar uma pesquisada pra encontrar material de tudo e qualquer coisa e em Português! Existem diversos cursos muito bem produzidos e sólidos, como:

• Java
• Javascript, EcmaScript
• Ruby

Sites com tutoriais interativos

Eu particularmente gosto muito de vídeos para aprender sobre diversos assuntos. Porém, há quem prefira ler os conteúdos, como se estivesse em um livro.

Em todo caso, como em outras áreas, no caso de programação, não adianta só assistir os conteúdos, é preciso praticar! E existem alguns tutoriais que fazem o passo a passo para que haja a leitura e a prática em cada passo. Eis alguns:

• JavaScript e outras tecnologias web na Khan Academy. A missão da Khan Cademy é prover educação gratuita e de qualidade em uma infinidade de assuntos. O legal é que agora eles possuem esse conteúdo em Português. O site disponibiliza o material com um passo a passo. Em cada passo do curso podemos executar os comandos no próprio navegador, sem precisar instalar nada no computador.
• Kotlin. Kotlin está popularizando bastante, não só para desenvolvimento mobile mas para microserviços também (caso em que uso atualmente). No site da própria linguagem existe uma ferramenta interativa para aprender, passo a passo da mesma forma que o Khan Academy. Eu mesmo utilizei essa ferramenta quando estava aprendendo a linguagem. Vale a pena conferir. OBS> esse é em inglês.
• Aprender Java na Code Academy. Há alguns anos atrás todos os cursos da Code Academy eram gratuitos. Eu mesmo aprendi Ruby inicialmente com eles ainda quando era gratuito. O site é mto bem construído e você pode executar os comandos no próprio navegador, assim como os outros dois acima. Hoje vários cursos são pagos, mas esse de introdução ao Java ainda é grátis. OBS> esse é em inglês.

Plataformas EAD

• Orientação a objetos com Java. Curso grátis em vídeo do ITA.

Conclusão

Se você tem vontade de aprender programação, nem sempre precisa desembolsar rios de tinheiro pois atualmente existem diversas ferramentas e fontes para aprender a programar gratuitamente. Encontre a que você mais gosta e inicie hoje mesmo!

Conhece alguma outra ferramenta/site/tutorial de boa qualidade mas que eu não citei acima? me envie uma mensagem que eu a avalio e adiciono nessa lista.

The post Como aprender a programar DE GRAÇA appeared first on Vinicius Pessoni | Tester Global.

A equipe scrum possuía 8 integrantes:

• 1 dona do produto;
• 1 scrum master;
• 2 testers (eu era um deles);
• 4 desenvolvedores.

Todos com bastante experiência em suas áreas, bem versados em métodos ágeis e muito bons no que faziam.

A empresa é uma multinacional, com mais de 100 anos de existência, que fatura bilhōes por ano e com bases em diversos países.

Mesmo com tanta experiência reunida em uma mesma equipe e com todo o aparato por parte da empresa, enfrentávamos diversos problemas como:

• diversas vezes atrasamos as nossas entregas, mesmo sendo uma carga de trabalho que nós mesmos concordamos em fazer em uma determinada sprint;
• quase nunca estávamos em acordo quanto as estimativas das histórias;
• parear para trabalhar com outro colega era sempre difícil, parecia que as coisas não fluíam quando estávamos juntos;
• era difícil perguntar mesmo coisas simples uns aos outros; a sensação de estar incomodando o colega quando perguntava alguma coisa era sempre frequente;
• a comunicação do estado atual de cada tarefa era complicada: mesmo sentando juntos, conversando todo os dias, respeitando as cerimonias do scrum, por vezes quando alguém dizia que seria capaz de entregar tal tarefa amanhã, isso não se tornava realidade.

Até então, eu nunca tinha trabalhado em uma equipe assim.

Na minha trajetória profissional, havia tido a sorte de sempre trabalhar em equipes que, por maiores as dificuldades enfrentadas, o espírito de equipe imperava, e sempre conseguíamos dar um jeito e realizar entregar consistentes.

Mesmo no tempo em que trabalhei em órgão público no Brasil, enfrentei alguns desafios mas ainda assim conseguimos superá-los.

Mas esse não parecia ser o caso dessa equipe.

E alguns meses após essa equipe ser desfeita, e os membros dela redistribuídos em outras equipes, constatei que realmente o problema era realmente essa equipe.

MAS, o que faltava nela?

Em resumo, consigo dizer que faltava espírito de equipe.

Parece algo vago e que charlatōes com títulos vagos usariam para definir um problema de natureza abstrata sem significar muito.

Apesar de parecer um mistério, existem teorias que tentam explicar. Algumas em formas de propriedades emergentes de sistemas complexos. Outras, definem como espírito de equipe.

Seja como quiser chamar, o fato é que, de alguma forma, pessoas boas, bons profissionais isoladamente, as vezes podem não funcionar bem juntos.

Essa foi a pior equipe em que estive. E conversando com alguns outros membros dela, após estarmos alocados em diferentes equipes, ouvi a mesma constatação.

A equipe era ruim não pelas pessoas em si, mas por elas juntas simplesmente não funcionar. Apesar dos diversos esforços do scrum master e outros gestores de melhorá-la, a melhor decisão, foi no fim desfazê-la.

E assim, aprendi na pele, que ser um bom team player e ter bons team players ao seu lado fazem toda a diferença.

Uma boa equipe

Uma boa equipe, significa muito mais do que ter excelentes profissionais com enormes experiências juntos. Eles devem interagir bem entre si, e serem capazes de constituir uma master mind, como diria Napoleon Hill, que é muito maior, melhor e poderosa do que qualquer indivíduo.

Devem ser capazes de prover feedback e também recebê-lo com prazer. Criticar um colega é muito mais fácil do que receber críticas. Mas ambos os casos devem ser verdade e feitos com o objetivo de melhorar.

Se todos possuem a mesma visão quanto ao seu papel de dar suporte e apoio aos demais membros de uma equipe e fazer muito mais que seu trabalho diário, as coisas fluem de uma forma incrível.

E você, já esteve em uma equipe ruim? o que fez para melhorá-la?

The post A pior equipe em que estive appeared first on Vinicius Pessoni | Tester Global.

Quantas vezes você já:

• mordeu a língua?
• deixou cair algo que ia pegar?
• bateu o dedo mindinho do pé em algum móvel?

Mas isso quer dizer que sua boca não funciona corretamente? ou que suas mãos deixaram de lhe ser úteis? ou que seus pés esqueceram como é caminhar e devem ser substituídos?

Certamente não!

Morder a língua ou a bochecha de vez em quando não quer dizer que sua boca esqueceu como é mastigar e por isso não lhe serve mais. Nem que precisa de uma boca 2.0.

Deixar cair algo de vez em quando não significa que nossas mãos deixaram de nos ser úteis e por isso abandonamos seu uso.

Tropeçar de vez em quando não prova que seus pés esqueceram como é caminhar e perderam a serventia

Essas “pequenas falhas” simplesmente revelam a nossa natureza humana: somos falhos por definição.

Mas ainda assim, pisamos na lua, descobrimos a cura para diversas doenças, voamos, fazemos transplantes de órgãos tão importantes quanto um coração. Dentre outras realizações que seriam enxergadas como mágica ou impossíveis há não muitos séculos atrás.

E conseguimos tudo isso sendo seres imperfeitos. Realizamos várias maravilhas.

Nesse sentido, como na vida em geral, precisamos rever a definição de bom o bastante no contexto de produzir software. A perfeição não é um estado em um determinado momento, estático. Pelo contrário, a perfeição é um processo de aprimoramento e correção constante.

Grandes empresas já entenderam o que é bom o bastante. Aquelas que mudaram a forma como comunicamos, nos relacionamos e até vivemos como Google, LinkedIn, Apple, Microsoft, Nokia.

E é também graças a esse reconhecimento da falibilidade que chegaram onde chegaram. Softwares imperfeitos foram colocados em produção, para todo mundo usar. O ciclo de correção foi encurtado apoiado pelos métodos ágeis, automação, CICD, DevOps.

Falei um pouco sobre a evolução dos testes em meio a isso tudo nesse texto aqui.

E assim, iniciando com produtos bom o bastante, diversas empresas conquistaram grandes mercados e uma gama sem fim de realizações.

Como desenvolvedores de software de qualidade precisamos nos lembrar disso frequentemente, para não corrermos os risco de focarmos em padrões inalcançaveis e atrasar o lançamento do produto a tal ponto de não ser relevante.

The post Quantas vezes você já mordeu a língua? appeared first on Vinicius Pessoni | Tester Global.

A primeira vez que ouvi isso foi um choque.

Pensei comigo: como assim? é praticamente dizer que meu trabalho não deveria existir. Quase ofendido, chateado, magoado, tipo criança quando xinga a mãe.

Mas respirei fundo, fiz cara de ser humano altamente maduro e evoluído e segui em frente. Porém, essa ideia não me saiu da mente tão rápido ou facilmente.

Sempre vejo esses questionamentos como oportunidades de crescimento. Defendo sempre que testers devem saber tudo de tudo. Quanto mais soubermos melhor seremos no que fazemos. Pontos de vista contrários são ótimos para nos confrontar quanto ao que sabemos e evoluir.

E essa “pulga atrás da orelha” me levou a grandes discussões sobre o assunto com alguns excelentes engenheiros de software tanto daqui quanto dos USA. Não foram discussões no sentido programa do ratinho ou programa da tarde mal sentido. Pelo contrário, o objetivo foi racionalizar sobre o que foi dito, pedindo esclarecimento e tentando ver pelo ponto de vista do outro.

Existe sim quem defenda que o teste está morrendo (ou morto, para os mais catastróficos).

Gostaria de dizer que após muito refletir, concordo em partes.

Concordo que o teste totalmente manual, da forma como era feita totalmente isolada e somente após a construção do software não seja mais adequada no mundo agile.

Além de automatizar para agilizar, precisamos estar integrados e remando para o mesmo objetivo, juntos, e com informação propagada igualmente nas equipes desde o inicinho da produção de alguma funcionalidade.

Em um mundo ideal testers realmente não deveriam existir. Em um mundo ideal não existem bugs. Os desenvolvedores realizam todos os testes unitários e de integração perfeitamente, respeitando as restrições das frameworks. As complexidades de integração entre componentes do software não geram novos defeitos. Não há falhas de comunicação nem especificação entre as diversas partes da equipe, localmente ou espalhadas pelo globo. Mas além disso, e principalmente:

O MUNDO IDEAL NÃO EXISTE

Se você já escreveu uma redação ou qualquer outro texto na vida, sabe bem que mesmo que o façamos com toda a atenção, revisemos diversas vezes sempre escapa algum erro.

Basta que uma outra pessoa leia nosso texto uma única vez que essa pessoa encontre esses erros e pontos de melhoria que não enxergaremos nas diversas revisões.

Simplesmente porque temos o viés de quem produz uma obra, de defender o que produzimos e isso torna difícil um olhar imparcial sobre nossa própria produção.

Quando testamos nós mesmos as linhas de código que produzimos, mesmo que de forma inconsciente, tendemos a fazer testes de confirmação ao invés de testes destrutivos como um tester faria.

É uma diferença de mindset mesmo. O mindset do teste é destrutivo enquanto o mindset do desenvolvimento é construtivo. Dois objetivos inerentemente diferentes, apesar de complementares que buscam produzir software de qualidade.

Fazer software é muito parecido com escrever texto. Só isso, tudo isso, muito mais que isso. É tentar traduzir da cabeça das pessoas as suas necessidades para o mundo da programação. Do abstrato das necessidades para o abstrado do código solucionando os problemas reais.

E essa atividade está sujeita a erros. Muitos erros. Vários erros!

“Partes que foram feitas independentes e testadas e que funcionam sozinhas deveriam funcionar bem juntas”

Essa afirmação parece ser verdade mas infelizmente para o mundo do software não é. Para quem conhece engenharia de sistemas isso não é de se assustar. Mas para quem nunca ouviu falar disso, procure saber sobre propriedades emergentes dos sistemas.

A complexidade que temos que lidar ao produzir grandes produtos de software escaláveis, distribuídos, confiáveis e tolerantes à falhas é enorme. E em cada etapa – requisitos, projeto, desenvolvimento, integração, teste – mais e mais erros são inseridos no processo de produção.

Frente a isso, a conclusão é:

o teste de software não morreu, e sinceramente não o vejo morrendo tão cedo. O teste evoluiu, da mesma forma como os processos, ferramentas e linguagens também evoluíram.

E continua extremamente relevante em um mundo altamente competitivo com clientes cada vez mais experientes e exigentes por experiências de usuário maravilhosamente desenvolvidas.

E qual sua opinião sobre o assunto?

Referências

• https://www.softwaretestingnews.co.uk/manual-testing-is-alive-with-new-approaches/
• https://www.linkedin.com/pulse/software-testing-dead-really-philip-lew/

The post No mundo ideal não existem Testers appeared first on Vinicius Pessoni | Tester Global.

Sim, eu sei que é uma afirmação um tanto dura. E também sei que pode parecer obvia para alguns.

No entanto, durante minha carreira, eu a ouvi diversas vezes. As vezes direcionada a mim, as vezes direcionado a outros.

Embora nem sempre com essas palavras, em momentos ela vinha disfarçada e abrandada como diferenças salariais para um mesmo cargo e experiência parecida. Mas era sempre e exatamente com o mesmo sentido, se soubesse ler nas entrelinhas.

Confesso que as primeiras vezes isso me enfureceu pois sou do tipo que gosto de aprender tudo de tudo. Conhecimento para mim é diversão, e uma das coisas mais importantes da vida. Acredito sempre que não existe tal coisa como se ter conhecimento demais.

Levou um tempo para que a entendesse e por fim concordasse com essa afirmação.

Deixe-me ilustrar: suponha que aconteça um acidente de carro e uma pessoa seja ferida durante o acidente.

Passando perto do local há dois médicos:

1. Doctor T: teórico, ampla educação em medicina, com conhecimento profundo em como realizar procedimentos, mas com pouca experiência prática em como de fato realizá-los;
2. Doctor P: conhecimento teórico o suficiente, educação o suficiente, com conhecimento o suficiente em como realizar procedimentos, mas com muita experiência prática em como de fato realizá-los.

Eu sei, eu sei, é uma situação exagerada e um tanto quanto extrema. E também entendo que performar bem em determinada situação depende de inúmeros fatores palpáveis e não palpáveis como: cansaço, estresse, equipe em que se esta inserido, processo utilizado, etc etc etc.

Trazendo agora para o mundo do software. Você fez graduação em uma ótima faculdade, fez mestrado, tem inúmeras certificaçōes. Isso demonstra que você é um ótimo teórico e bom estudioso. Perfeito acadêmico.

Mas isso significa que você será o melhor na sua empresa? na sua equipe? não necessariamente.

Entenda que não estou defendendo de forma alguma não fazer uma graduação ou passar pela educação formal. Fui professor universitário, e ensinar é um amor que eu tenho pra vida. Vejo valor, e muito em se ter educação formal, por diversos motivos que não cabem aqui agora. Mas só o aprendizado pelo aprendizado, sem a ação com ele irá te recompensar em meios comerciais? dificilmente.

Existem casos por exemplo, em que pessoas sem educação formal (graduação/mestrado) mas com garra, dedicação e humildade, desempenham de longe muito melhor do que alguém extremamente academicamente educado mas com arrogância demais para assumir que não sabe algo, aprender e se desenvolver mais. Já vi isso pessoalmente, e continuo vendo, mesmo na empresa global em que estou atuando no momento.

O simples fato de saber muito sobre algo não lhe garante as melhores posiçōes no mercado. Saber por saber, sem saber fazer não é muito valorizado. Não é assim que o mercado recompensa indivíduos.

Parece muito contra intuitivo não? mas acontece, e muito. Não adianta se esconder atrás de seus títulos quando se deparar com algo que tem dificuldade em fazer. Aquele defeito catastrófico em produção não irá se resolver sozinho se você jogar seus títulos neles. E ainda, lembre-se que açōes falam muito mais alto que palavras. Não importa muito o que ou o quanto você diga algo, com o tempo, a inexperiência da parte prática fica evidente para quem já passou por esse processo.

Ganha-se muito mais assumindo que não sabe, “descendo do pedestal” e aprendendo com outros do que sustentar sempre a pose de detentor de todo conhecimento. Assim, alinha-se o conhecimento teórico com o prático. Essa é uma forma de definir inteligência, sabedoria e expertise.

A dura verdade é que somos recompensados para fazer algo com o que sabemos e agregar valor no ambiente em que estamos.

Simples assim.

The post Você não é pago pelo que sabe, mas pelo que faz com o que sabe appeared first on Vinicius Pessoni | Tester Global.