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.
