Como havia prometido, volto hoje ao tema abordado na semana passada. Tentarei destacar os principais pontos abordados no vídeo recomendado na parte 1. E antes de tudo, obrigado a todos pela participação no blog, na DFTestes e no Linkedin. A colaboração de vocês é fundamental para o enriquecimento da discussão.
A primeira grande contribuição do vídeo trata-se da abordagem inicial a evolução das metodologias de desenvolvimento e consequentemente as diferentes formas de atuação dos testadores. O palestrante, Alberto Savoia, a divide em dois grandes momentos: Old Testmentality e New Testmentality. Partindo da dependência completa dos documentos de requisitos, aos ciclos mais curtos das metodologias ágeis associados a uma maior integração entre desenvolvedores e testadores.
Durante a chamada Old Testmentality, as aplicações só eram entregues quando estivessem completamente “prontas”. Enquanto, que na New Testmentality, as entregas passaram a ser frequentes, exigindo uma participação constante do cliente na construção do “produto correto”.
Em seguida, Savoia começa a destacar os pontos que o levam a pensar que o teste tradicional está morto. Começando pelo o que ele chama de Post-Agile, a qual tem como diferencial o fato de apresentar uma postura mais casual e descuidada em relação aos testes ágeis tradicionais.
Segundo Savoia, a questão central cada vez mais é a construção do “produto correto” e não o simples desenvolvimento correto do produto ou das funcionalidades, ou seja, o objetivo é entregar um produto, que em primeiro lugar, atenda às necessidades dos usuários. Não basta ser apenas perfeito funcionalmente.
O palestrante nos lembra que de fato existem diversas aplicações fabulosas construídas utilizando os conceitos tradicionais, mas que a estrutura existente nos dias atuais, como a computação nas nuvens, permitem diminuir o foco da qualidade de software e transferi-lo para garantir que estamos construindo o produto CORRETO.
Um grande exemplo citado é o twitter, que tornou famosa sua baleia com a enormidade de vezes que deixava os usuários na mão, mas mesmo assim eles continuavam voltando, pois o produto era o desejado.
Nesse novo cenário, que se desenha, segundo Savoia, precisamos nos voltar para outro tipo de bug, o chamado idea bug, que podemos traduzir como bugs de conceito ou de idéia do produto.
Um produto errado é muito pior do que um produto com o comportamento errado.
A chave é testar a idéia, ou seja, garantir que estamos desenvolvendo o produto certo.
A sugestão de Savoia é começarmos utilizando protótipos iniciais (pretotype), os quais ele diferencia dos protótipos tradicionais, por serem desenvolvidos e aplicados em curtos espaços de tempo. É fundamental testar cedo e falhar rápido, segundo o mesmo Bons testes falham rápido, diminuindo o tempo e o capital investido. (BdB – Os bons testes falham)
Sinais do Testpocalypse:
– Diminuição no numero de contratações – Comoditização dos testadores – Saída dos antigos líderes e ausência de novos – Mais e mais empresas partindo para o Post-AgileAcompanhado essa corrente de mudanças existem enormes oportunidades. Savoia enfatiza a crescente necessidade do surgimento de novos líderes na área de testes, com uma mentalidade diferente, e que possam conduzir essa etapa de transição. Onde, como o mesmo aponta, ainda conviveremos por um longo tempo com as diversas formas de teste. (BdB – Imagine um mundo sem Bugs no Software)
Por fim, um dos slides afirma “Test is dead. Don’t take it literally, but take it seriously.”, traduzindo, “Teste está morto. Não leve isso literalmente, mas leve a sério.”. Logo, a palestra é uma alerta e não uma simples afirmação arrogante, que se julga acima de todos nós. Uma apresentação, que vale a pena ser vista com atenção, e que nos deve levar a refletir sobre os caminhos, que estamos seguindo, as oportunidades de aprendizado e de mudança que podemos levar a nossa área. Sejamos o agente dessas mudanças.
Bytes don't Bite! 
Jovem! Concordo com Thiago de que este foi, provavelmente, seu melhor post até o momento. Fico muito feliz em saber que a comunidade de testes já está se adaptando aos conceitos ágeis de que o importante é de fato ter o produto correto e não o comportamento esperado. O mais engraçado é que começo a me dar conta de que o que fazíamos aí no CESAR é exatamente o que se prega hoje e na época não tínhamos muita clareza disso.
Obrigado Marcelo… De fato, nossa equipe tinha um foco grande no produto.
Já disse no twitter minha opniao a respeito desse post (Como Marcelo já citou), e gostaria de reafirmar aqui.
O ponto chave pra mim é
“Um produto errado é muito pior do que um produto com o comportamento errado.”
Claro que essa frase nao serve para diminuir o foco na qualidade do produto, mas sim para mostrar que o foco tambem tem que ser dado na definicao do quê será desenvolvido!
Parabens carrera!
Perfeito Burgos…
Show ze 🙂 Seria legal se as pessoas”ocupadas” tivessem um tempinho pra ler esse teu post e ver o video 😀 Excelente síntese 🙂
Obrigado Sarah….
🙂
Só relembrando uma opinião que eu tenho, não é apenas old testmentality, é old devmentality também, neste tipo de mercado todo mundo tem que pensar diferente, é uma “reforma” geral, onde vale mais a qualidade da ideia do que a qualidade do produto, o que faz muito sentido, pois não adianta fazer algo bem feito se esse algo não for usado por ninguém, será um investimento enorme em pra nada, e isso é um modo de pensar que vale pra vida toda e em todo lugar, não só em informática.
Mas voltando ao assunto testes, se existe new testmentality, então opa, existe teste, lembrando que testar não é só aquele momento em que tem alguém clicando/teclando, testes é bem mais amplo, começa lá no começo do projeto, antes mesmo da codificação e talvez nunca termine, principalmente se alguma coisa é chamada de “beta”, logo o teste ainda não terminou.
“Sinais do Testpocalypse:
– Diminuição no numero de contratações”
__Sim e não, a quantidade de pessoas permanece a mesma, o que muda é a quantidade de pessoas na função “testa ai!”.
“- Comoditização dos testadores”
__De todo mundo, é natural do ser humano se acomodar a alguma coisa, e continuar programando em cobol até morrer, por exemplo.
“- Saída dos antigos líderes e ausência de novos”
__Com a troca de gerações (não apenas falando de idade, mas geração de pensamento), vai mesmo acontecer isso, assim como hoje em dia não é fácil achar pessoas boas em cobol, a tendência é sempre essa em TI, as pessoas focadas em coisas “antigas” vão se tornando raras com o passar do tempo, e as novas pessoas que vão entrando na área vão partindo para novas tecnologias, em detrimento das antigas.
“- Mais e mais empresas partindo para o Post-Agile”
__”Maria vai com as outras”, “se dá certo no Google vamos fazer”, “opa, o exercito americano usa, vamos usar também”, “se o exercito britânico usa, vamos usar também”, como aconteceu no waterfall, muitos vão usar e dar certo, outros vão usar sem saber o que estão fazendo e vão se dar mal, o sucesso de qualquer “way of thinking” é dominar suas forças e as fraquezas, qualquer exercito que vai para o campo de batalha sem conhecer seus pontos fracos está sujeito a ser surpreendido pelos seus oponentes.
Infelizmente não tem receita para o sucesso, na verdade tem, mas ninguém consegue colocar em palavras de modo que a interpretação e reação da outra pessoa seja a esperada, waterfall, agile, post-agile, anti-agile, espiral, etc, cada um é melhor em alguma abordagem, assim como existe o martelo para pregar e muitos estragam chaves de fenda ou alicates usando como martelo, essa comparação tem tudo a ver com esse tema, se o alvo é um prego, usarei o martelo, se o alvo é um parafuso, usarei uma chave, se o alvo é uma rede social ou um website deste nicho de mercado, caberia bem um post-agile, se o alvo é um sistema desktop de automação comercial para o mercado da esquina, o dono do mercado ficaria muito bravo se o sistemas desse problema e a fila do caixa ficasse imensa, cheia de gente xingando, neste caso caberia um XP até, desde que tenham “construído certo o produto”, pois o “produto certo” o dono do mercado já sabia bem o que ele queria.
Resumindo: O quanto testar depende do quanto se quer investir em testes. Quanto se quer investir depende dos riscos envolvidos na falha. Um risco do tipo do twitter que só pode apenas apertas F5 ou tentar depois de 10min não se compara ao risco de um aparelho médico matar uma pessoa ou um sistema aeronáutico derruba um avião.
Excelente contribuição Felipe.
A respeito de mais empresas aderirem a essa nova tendência acredito que existam sim algumas empresas simplesmente querendo entrar na nova “onda”, porém acho que o palestrante quis dizer que cada vez mais existem projetos, que possuem características que permitem voltar toda a atenção para a construção do PRODUTO CORRETO.
Concordo José, eu não quis dizer o contrário disso não, é que sempre penso nos dois extremos, o bom e o péssimo, e no péssimo vejo muitas empresas que vão se dizer seguir essa “onda” e não vão seguir nem a sombra disso, vão fazer tudo errado, descarregar muitos problemas, criados por eles mesmos, em cima dos desenvolvedores e da equipe entre muitas outras coisas, que as vezes temo, entrar em uma nova empresa, ai na hora do “vamos trabalhar agora” eu perceber que aceitei sem saber uma proposta para o caos (leia-se também “inferno”), vejo pelo scrum, fazem a mesma coisa com ele, que é tão bom, e por ai vai, vendo as tendências brasileiras podem surgir novos “nomes” pra “roles” que vão criar, sem a real necessidade, podem desmerecer a nossa função, pessoas boas podem perder emprego pode falta de “insight” dos gestores e por ai vai… mas, olhando por outro lado as empresas que vão “jogar fora” bons profissionais por serem cegos, na verdade nunca mereceram terem eles em sua equipe, e esses bons profissionais vão entrar na concorrente e fazerem a diferença, é assim que eu penso. []s
Entendi… E de fato voce tem razão no que diz….
Trabalho e invisto em minha formação em testes a 2 anos e essa palestra (discussão) que acompanhei tanto aqui quanto no DFTestes ao invés de me deixarem preocupado me deixaram bastante entusiasmado pois percebo um campo extremamente vasto de possibilidades seguindo a ideia da “Pretotype” não vou dar mais detalhes do que eu imagino mas está ai uma fonte bastante interessante da evolução em nossa área.
Perfeito, Juraci.
Também vejo a palestra como um bom sinal de que existem novos caminhos a serem explorados, e quem sabe esses serão meios de nos levar a construir produtos ainda melhores e mais atraentes para o consumidor final.
Belo post! Parabéns.
Meu ponto de vista é visto por muitos como arrogante e isso me entristece muito, porque não é arrogante, mas sim realista.
Concordo com o pensamento do Felipe sobre uma coisa que funciona em um ambiente poder não funcionar em outro, e que não é porque uma empresa de sucesso usa que devemos usar o mesmo que ela sem pensar se isso é realmente útil pra nós, mas acho fundamental entender porque essas empresas usam e o que elas tem de vantagem com o uso dessa ferramenta/processo. Sinceramente, prefiro ser maria e ir com o Google e os bons do que ser maria e ir com a maioria acomodada.
O problema aqui no Brasil é que estamos constantemente importando novidades da década passada, como esta acontecendo agora com o TDD e o record and play-back e fechando os olhos para o que está acontecendo ou o que pode acontecer. Quando falamos de teste de software vemos que ainda achamos os processos de décadas atrás importantes, e isso pode ser visto nos nossos discursos, palestras e certificações. Itens como TMM, estimativas de teste, bug tracking, CMMi e V Model ainda são referência para nós e na maioria das vezes não trazem produtividade, apenas burocracia. Quando falamos sobre automação de testes em listas as pessoas simplesmente se sentem ofendidas e isso me assusta muito. Temos que entender que todo problema é uma oportunidade em potencial.
Na minha opinião esse é o principal motivo de não encontrar bons QAs no Brasil e também da diferença na remuneração do profissional de teste de software (que aqui é muito maior), mas isso não vai mudar do dia pra noite e ignorar esses fatos tirando uma certificação também não vai melhorar nada. O único jeito de mudar isso é sendo a mudança que você quer ver na comunidade (Gandhi). Admitir incompetência dói muito, mas infelizmente temos que fazê-lo se quisermos melhorar. Digo isso com propriedade pois admiti minha incompetência em muitas coisas recentemente e vejo o quanto estou melhorando como um QA. Estudar nos fins de semana não é uma atividade das mais prazeirosas, assim como ler calhamaços de artigos e livros. Mas tudo isso faz parte do amadurecimento profissional que é mutio necessário. Nossos developers sabem o que mudou da minor version do Rails na ultima atualização, nós não sabemos nem se a ultima versão do FireFox já tem um webdriver compatível.
A old testamentality está muito enraizada e uma simples crítica a ela causa um estardalhaço gigantesco como pode ser visto na thread do DFTestes. Eu espero que um dia, nós, os profissionais que estamos criticando por décadas, aceitemos críticas a nossa forma de trabalho de forma tão profissional e humilde quando nossos developers tem aceitado durante todo esse tempo.
Acredito que posts como esse, aliados a posts técnicos ajudam a mudar e muito os problemas da nossa comunidade. Novamente parabéns Carréra. Favoritei esse 😉
Reforço seu brilhante comentário: “Uma apresentação, que vale a pena ser vista com atenção, e que nos deve levar a refletir sobre os caminhos, que estamos seguindo, as oportunidades de aprendizado e de mudança que podemos levar a nossa área. Sejamos o agente dessas mudanças.”
Camilo
Realmente precisamos admitir nossos erros, nossa incompetência em diversos aspectos e AGIR. Ainda temos que ralar muito para de fato contribuir com o crescimento da nossa área.
Perfeitas essas duas colocações que você fez:
“Mas tudo isso faz parte do amadurecimento profissional que é mutio necessário. Nossos developers sabem o que mudou da minor version do Rails na ultima atualização, nós não sabemos nem se a ultima versão do FireFox já tem um webdriver compatível.”
“Eu espero que um dia, nós, os profissionais que estamos criticando por décadas, aceitemos críticas a nossa forma de trabalho de forma tão profissional e humilde quando nossos developers tem aceitado durante todo esse tempo.”
Abraço e obrigado pelos elogios e pela contribuição
“Sinceramente, prefiro ser maria e ir com o Google e os bons do que ser maria e ir com a maioria acomodada.”
Vou guardar e usar muito essa frase ainda 🙂 é um bom jeito de se minimizar os riscos de algo dar errado.
É bom ter pessoas como você na comunidade, que soltam o verbo mesmo, sou a favor disso, tem gente que fica dormindo e se alguém não gritar ou tacar pedra ou cutucar alguma ferida essa pessoa não “acorda pra vida”, e é bem por ai mesmo que você disse, ser humilde e aceitar os erros é o que diferencia uma pessoa que vai melhorar da que não vai. e ponto final.
Os devs que não pensem que vai ser fácil também não, afinal é mais um acumulo de função para eles, lógico que em partes apenas, mas devs que pensam que a qualidade não é responsabilidade principal deles não terão lugar nesse mercado, onde maturidade e comprometimento é requisito, trabalho de equipe e humildade muito mais. Qualidade não se faz na execução dos testes, mas no ciclo de vida todo.
“Na minha opinião esse é o principal motivo de não encontrar bons QAs no Brasil”
Sei que não foi ao pé da letra o recado e que você na verdade deve sim conhecer bons QAs no Brasil, mas é só pra ser chato mesmo que estou te lembrando disso 😉
“Quando falamos de teste de software vemos que ainda achamos os processos de décadas atrás importantes”
Não só em testes, a tecnologia já começou tarde no Brasil, a popularização do computador e da internet são coisas recentes pra nós, muitas pessoas há 1 ou 2 anos atrás tinha que ir em lan house pra usar o Orkut, essa explosão de informação (leia-se oportunidades) esta causando um conflito de “gerações” entre o que é referência internacional sólida, porém antiga, a nossa realidade na empresa (não vou dizer no Brasil porque cada empresa no Brasil vive sua própria fase, existe desde o “inferno” ao “céu” no mercado à fora) e as tendências de futuras vindas de toda parte do mundo. Por isso que eu não gosto de livros, eles são muito estáticos para conseguirem acompanhar tudo isso acontecendo tão repentinamente.
(resumindo: não discordei de nada, só acrescentei um pouco da minha visão)
Olá Felipe 🙂
Tocou em alguns pontos legais.
Na verdade, acho que quando tentamos acompanhar empresas como o Google estamos criando riscos e não evitando-os, isso porque muitas das coisas que fazemos serão mudadas drasticamente e isso se também se chama inovação. Mas sim, também prefiro correr riscos do que simplesmente assumir uma performance ruim ou um produto sem qualidade. 🙂
Claro que temos bons QAs no Brasil, mas a maioria ainda está engatinhando, mesmo alguns com anos quatro ou mais anos de experiência (o que não significa nada, mas infelizmente é a nossa medida de senioridade . . .). Isso se deve ao motivo do mercado subjugar o profissional de qualidade como inferior. Entre os motivos para isso estão a falta de visibilidade da importância desse profissional e de sua capacitação. Isso não vai mudar se os QAs não evoluírem. Não falo de automação em si, mas principalmente de atitude. O problema com as nossas referências de hoje, é que a maioria nos ensina a ter uma atitude extremamente tradicionalista, do tipo “Todo bug deve ser cadastrado”, “Casos de teste de acordo com a norma IEE829”, “500 páginas de documentação para testes de performance” e etc. Esse tipo de comportamento extremamente defensivo não nos leva a lugar algum, apenas a ser “o tester chato com quem eu não quero almoçar”. Vamos pensar em mais iteração com tecnologias e principalmente pessoas do que em templates e processos. Vamos pensar mais em documentação evolutiva e colaborativa do que em templates e ferramentas de tracking.
Já comentei sobre alguns dos pontos old school do teste de software, mas acho legal lembrar que existem muito mais desenvolvedores atualizados do que QAs. Sempre cito um conto que o Correia colocou no TestExpert sobre o paradigma do elevador, e como foi a reação do pessoal na época. O post descrevia uma pessoa totalmente atualizada com smartphone, livros, tablets etc, e outro totalmente desligado num mesmo elevador, e perguntava quem era o dev e quem era o QA. Todo mundo sabe o que é mais comum nesse cenário, mas como o tapa doeu muito, muitas pessoas hipócritas ficaram revoltadas em listas de discussão. É claro que todo mundo sabe que poderia ser o contrário e em vários casos é. Vemos o exemplo das pessoas aqui discutindo essa thread, são pessoas mais interessadas do que muitos devs que eu conheço. Eu acho que esse tipo de citação, como os puxões de orelha que você citou, são muito importantes de vez enquanto.
No mais, não quero parecer um disseminador da discórdia, mas quero que as pessoas reflitam sobre as principais reclamações dos QAs no Brasil, e entendam que NINGUÉM é mais culpado do que a comunidade de QA.
Abraços.
Camilo
“Na verdade, acho que quando tentamos acompanhar empresas como o Google estamos criando riscos e não evitando-os”
Concordo com isso, não disse evitar, disse minimizar, toda mudança cria um risco, não mudar também é um risco, mas se vai mudar seguindo essas empresas com cases de sucesso é um risco menor do que seguir empresas sem esse notável sucesso, foi isso que quis dizer.
“Vamos pensar em mais iteração com tecnologias e principalmente pessoas do que em templates e processos. Vamos pensar mais em documentação evolutiva e colaborativa do que em templates e ferramentas de tracking.”
Apoiado. Assinei o Agile manifesto concordando e apoiando essa causa.
“NINGUÉM é mais culpado do que a comunidade de QA”
Só discordo disso, na verdade não sei em que contexto ou qual foi a sua definição para “comunidade de QA” nessa afirmação, mas no meu modo de ver a culpa não é da comunidade e sim do pessoal que trabalha como QA mas não participa da comunidade, logo anda contra a comunidade em muitos aspectos, principalmente renovação. Chamo de comunidade o ambiente onde as pessoas trocam informações, aprendem, criticam e evoluem.
Boas respostas, []s e sucesso!
Excelentes colocações do Felipe e do Camilo, concordo plenamente.
Excelente post Carrera, parabéns.