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.
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.
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 debom 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.
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.
Já se perguntou porque devemos testar os softwares que criamos? Afinal, qual o objetivo do teste de software?
Geralmente quando fazia essa pergunta para minhas turmas de alunos ou amigos de computação, a primeira coisa que respondem é:
“a gente testa para ver se funciona”
Essa resposta não está errada, mas também não está inteiramente certa. Ela está incompleta e esconde a natureza real do teste.
Dizemos que o teste possui a natureza destrutiva.
Diferentemente do desenvolvimento, que possui a natureza construtiva, dizemos que o teste de software possui a natureza destrutiva.
Parece meio dramático isso, mas o motivo primordial do teste de software não é demonstrar que algo funciona, mas demonstrar que esse algo possui problemas!
Isso quer dizer que o mindset do desenvolvimento e teste são inerentemente diferentes. Claro que ambos devem estar focados na qualidade final e primando um produto que funcione da melhor forma possível e agregue o maior valor possível para os clientes.
Mas no momento do teste, o foco é diferente de quando estamos desenvolvendo. No teste, executamos os programas justamente procurando aqueles casos que podem ter sido esquecidos na hora de fazer os requisitos ou de programar o produto. Procuramos por combinações que causarão comportamentos fora do comum, esperado, normal e seguro do produto.
Assim, o objetivo do teste de software é fazer o programa falhar, revelando defeitos que causam isso.
O objetivo secundário é mostrar que o software funciona de acordo com o esperado
Além de procurar por defeitos, o teste também serve para verificar se o que foi acordado foi de fato desenvolvido corretamente. Verificamos se os requisitos foram implementados de acordo com o que foi pedido.
Essa demonstração de funcionar conforme o esperado para alguns casos é chamado por vezes de exercício do “happy path” (caminho feliz). Caminho feliz porque estamos apenas mostrando que aquele produto funciona bem para aquelas entradas que colocamos.
Importante notar que apesar de ser possível demonstrar que o produto funciona para determinadas entradas, não temos condições de demonstrar que o produto funciona bem para absolutamente todos os conjuntos de entradas e combinações possíveis (salvo para domínios bem pequenos) dada a natureza infinita das possibilidades que essas entradas assumem.
E é exatamente por isso que existem as técnicas de teste, para nos ajudarem a criar casos de teste que sejam relevantes e que demonstrem o maior número de defeitos possível quando executado, mesmo sem exercitar todas as possíveis combinações de entradas de um software.
Além disso, erros no software podem causar tragédias e custar vidas
Veja alguns exemplos em que catástrofes foram causadas por erros de software:
Desde os meus tempos de professor universitário, essa era uma das perguntas mais recorrentes. Especialmente nas turmas de algoritmos. A imagem acima é de 2018, do github, listando as top 10 linguagens usadas nos repositórios. Além disso, o StackOverflow tem uma pesquisa super bacana e bem detalhada sobre o assunto aqui.
Confesso que por muitas vezes quando alguém me perguntava “qual linguagem aprender”, meu amor por Java falava mais alto, e de pronto respondia “Java, claro!”
Porém, mais que preferência pessoal por uma linguagem, robustez, atualização e segurança da linguagem, precisamos pensar no momento e na finalidade do seu aprendizado.
Nesse sentido, trago aqui 3 perguntinhas simples para te ajudar a escolher qual linguagem de programação aprender ainda esse ano:
1. É a sua primeira linguagem de programação? está aprendendo a programar agora?
Se esse for seu caso, recomendo começar por uma linguagem fortemente tipada, como JAVA. Ela pode parecer complicada e cheia de palavras de início, mas uma vez que você entenda sua lógica, será fácil de aprender outras linguagens. Alem disso, te ajudará a entender tipos e estruturas de dados, e como e onde cada um deles deve ser usado.
2. Qual seu objetivo profissional? quer ser desenvolvedor web? backend? frontend? full stack? tester? cientista de dados? ainda não sabe?
Linguagens são apenas ferramentas, e como qualquer ferramenta, cada uma é melhor em um determinado momento. Você não vai tentar pregar um prego usando uma chave de fenda ou uma faca de cozinha, mas usando um martelo. Com as linguagens de programação a ideia é a mesma. Identifique seu objetivo, que as linguagens para cumpri-lo virão juntas.
3. Empregabilidade é o foco? Quero arrumar um emprego pra ontem usando essa linguagem.
Faça uma busca dos empregos que você quer e veja quais os requisitos (linguagem que utilizam, frameworks, processos, certificaçōes que pedem). Isso vai te ajudar a decidir pela que melhor se encaixa nos planos de carreira.
E minha recomendação geral?
Após 11 anos de computação, muito aprendizado e experiência, nacional e internacional, de forma geral: recomendo Java!
Se com essas 3 perguntinhas acima, sua decisão for outra, não tem problema. Eis os motivos da minha recomendação:
A empregabilidade é ótima, tanto no Brasil tanto quanto aqui na Europa;
É uma linguagem robusta, segura, de propósito geral;
Fortemente tipada;
Orientada a objetos;
Sustentada por um grande nome (Oracle atualmente);
Muito, mas muito conteúdo na internet grátis e também livros publicados;
É uma linguagem aberta (não precisamos pagar pra usá-la, nem precisamos de sistemas caríssimos para executá-la).
Linguagens de programação que estou trabalhando no momento
Java – desenvolver os microservices e testes automatizados;
Kotlin – desenvolver os microservices e testes automatizados;
Javascript – desenvolver frontends e testes automatizados para eles.
Se você é de computação, a não ser que estivesse congelado ou vivendo em uma caverna isolado do mundo nos últimos 18 anos pelo menos (o manifesto ágil é de 2001), já ouviu falar de métodos ágeis.
Muito se fala em ser ágil e como as equipes devem se adaptar as adversidades do dia a dia. O cliente muda de ideia diversas vezes, o cronograma e orçamentos são apertados e ainda tem os defeitos para divertir nossa vida.
Porém, com isso, vejo ainda muita confusão sobre o que é ser ágil.
Nesse contexto, gostaria de dizer o que NÃO é ser ágil, para eliminar alguns absurdos que ouvimos por aí e auxiliar no melhor entendimento.
Ser ágil NÃO É
deixar de documentar: seja o software em si, a arquitetura, os testes. Não precisamos ter manuais do tamanho dos senhor dos anéis, com 500 páginas para explicar como iniciar um pagamento em nosso sistema. O sistema deve ser intuitivo e levar ao usuário o que ele precisa da forma mais forma possível. Mas isso não signigica que não precisamos fazer qualquer tipo de documentação. Documentação é necessária, e ao nível que a equipe concordará que será útil. Seja em testes que documentam como o software funciona, documentação automática baseada no código, ou mesmo diagramas, desde que sejam úteis para a equipe.
deixar de ter um processo: desenvolver software sem processo, mesmo que ágil, significa apenas que sua empresa será uma bagunça mais rápida. Ser ágil não significa a ausência de processos e métodos de trabalho. Pelo contrário. É justamente primando por essa agilidade, que todos devem saber exatamente como trabalhar e em que fase cada tarefa está claramente para agir de acordo com a necessidade do momento.
deixar de ter fazer testes, principalmente os end-to-end: “Ahh aqui a gente é ágil, então o programador mesmo já codifica e testa. A gente não precisa de quality assurance nem tester não, isso é perda de tempo”. A qualidade, como um todo, deve ser pensada desde o início do produto. Devemos pensar em teste desde a concepção do que queremos fazer no software. Vamos discutir sobre a nova funcionalidade? chama os testers, QAs, QEs, pra conversa e discussão. A pirâmide de teste deve ser levada em consideração.
ter uma arquitetura má definida: “Vamos começar a desenvolver logo, mostrar pro cliente e ouvir o feedback”. Lindo essa idéia de design sprint. E concordo que funciona muito bem para alguns contextos. Mas serve para tudo? Se o software é complexo e crítico, inevitavelmente precisamos gastar um tempo definindo a arquitetura dele e discutindo os detalhes e limitações. Dificilmente teremos tudo definido no início (coisa de método cascata), mas pelo menos precisamos ter alguma consistência ao começar a construir o software.
evitar reuniões a todo custo: sim, sabemos que em muitas empresas gastamos muito tempo com reuniões infinitas que saem de lugar nenhum para nenhum lugar. Mas isso não significa que todas elas são inúteis ou irrelevantes. Uma das dicas do agile é colocar um tempo limite para elas. Sempre ter uma agenda e mediador também ajuda muito.
colocar qualquer coisa em produção: a ideia dos métodos ágeis é colocar um produto em produção o mais rápido possível, para que com isso, consigamos reunir as experiências e feedbacks dos usuários e evoluir o produto. No entanto, essa corrida para colocar o código em produção não significa despachar algo ruim, mal feito, cheio de defeitos básicos e que não cumpra o que os usuários querem. Idealmente, começamos com funções simples, mas que façam um mínimo de fluxo que agregue valor para os clientes. A partir do uso e respostas, evoluímos o produto para a maturidade.
ficar mudando os requisitos durante a sprint: usar métodos ágeis significa “abraçar mudanças” e se adaptar a elas quando aparecem. Mas nem por isso significa que iremos cumprir todo e qualquer requisito que aparece durante uma sprint. Se estamos usando scrum, devemos blindar a equipe durante as sprints para que consigamos entregar o que foi acordado no planejamento da sprint. Caso precisemos mudar o escopo ou cancelar o que está sendo feito, devemos entrar em acordo com a equipe (pois todos concordaram quanto ao que seria feito anteriormente).
No planejamento da sprint, uma das maiores dificuldades que enfrentei (e enfrento) é como estimar o trabalho que faremos em cada unidade de trabalho.
Ter conhecimento do projeto de antemão, familiaridade com a lingaugem e tecnologias usadas, e até mesmo a interação entre os membros da equipe influenciam na estimativa de uma determinada feature.
Mas, o que é uma feature?
Para o Scrum, uma feature é um item do backlog. Algo que deve ser feito e que foi identificado em algum momento, e foi registrado para posterior priorização.
Para o XP, uma featura é uma story (Apesar de que dificilmente encontraremos um lugar que aplica scrum ou XP puramente. Então o pessoal da sua empresa pode chamar o pedaço de trabalho de srotory tranquilamente).
Simplificanto, uma featuredeve ser:
um pedaço de trabalho que contribui com valor de negócio: pode ser algo novo, correção de algum defeito ou modificação de uma funcionalidade, desde que possua valor para o negócio (o usuário vai fazer algo com isso, possui valor para ele);
estimável: conseguimos dizer de alguma forma o quão difícil/demorado/complexo ela é;
testável: possuir formas de ser testada.
Tipos de Estimativa
Existem várias formas de estimar o trabalho que faremos no contexto ágil, mas as mais comuns são:
T-shirt sizing (método do tamanho das camisetas): dividimos as features entre P (pequenas), M (médias) e G (grandes). É uma forma mais simplista e menos granular de ser estimar os tamanhos do que deve ser feito.
Story points: consiste em dar pontos para as histórias, de acordo com sua complexidade. Considero essa forma uma das mais legais – por poder ter mais granularidade, e mais opções de tamanhos. Mas também é uma das que mais geram discussões – porque precisamos “ignorar” a noção de tempo e focarmos na complexidade ao darmos os números para cada história. Assim, uma história que contenha 1 story point é menos complexa do que uma que seja dada 5 story points.
Observe que em cada uma dessas formas, não é uma pessoa sozinha quem classifica as histórias, mas a equipe é quem chega num consenso sobre isso.
Em geral, isso é feito ou no refinamento do backlog ou no planejamento da sprint em uma reunião que tenha os donos do produto, testers, developers, etc.
