Muito se fala sobre qualidade, controle de qualidade, testes etc. Quando ouvimos estes termos muitos associam esta responsabilidade a um profissional de qualidade, aquela pessoa que testa sua aplicação e fala que tá tudo errado! Brincadeira viu, pessoa de QA!?
O profissional de QA é realmente uma peça fundamental para garantir a qualidade do software e trazer uma visão diferenciada sobre o produto para o time de desenvolvimento afinal ele (teoricamete) não está enviesado como o time de desenvolvimento pode estar.
Mas será que você já parou pra pensar em como a cultura em torno disso foi criada na sua organização? Não adianta nada ter um excelente profissional de QA a disposição e não ter um manifesto bem definido ou mesmo sem dar abertura para que este profissional possa atuar e realmente trazer sua expertise pra dentro do software que estamos construindo (ou mantendo).
Neste sentido me proponho a trazer alguns pontos bacanas à serem discutidos quando estiver pensando em implementar a cultura e QA em sua organização.
Reportar bug não é falar mal da pessoa desenvolvedora! ¶
Uma das funções mais comuns de um profissional de QA é o bug report e é aqui que muita treta começa!
Dependendo de como começou o movimento de bug report por parte do time de qualidade e como isso é feito, o time de desenvolvimento pode entender o report como uma ofensa, algo impositivo ou pessoal. Por isso é muito importante pensar em como será feito o bug report e a linguagem a ser usada. Então aqui vai umas dicas rápidas!
Tudo começa com um bom bug report ¶
Parece tarefa fácil relatar um bug, certo? Chama o amiguinho e fala "bicho, não tá funfando aquele treco ali que você fez!" e bora voltar para o trampo normalmente, é claro...
Escrever um bug report afeta não só o entendimento do bug por parte do desenvolvimento quanto a motivação para desenvolver uma tratativa. Receber um report que não está claro, não há passos para reprodução e ainda por cima apontando culpados desmotiva qualquer um a realizar qualquer bug fix. Ao relatar um bug procure ser impessoal, destacar o ponto falho bem como o cenário esperado e não ser opinativo (ex: eu acho que deveria ser assim), procure sempre se basear em fatos e não opiniões na hora do report.
Então Quality Assurance se resume a bugs? ¶
Essa associação é muito comum, uma vez que é pela mão do profissional de QA que passa a maioria dos bugs e é este profissional que tem, em sua fase de descoberta, a responsabilidade de procurar e reportar bugs.
Pode não parecer óbvio para todos mas o profissinal de QA também está muito mais atrelado ao desenvolvimento e ao produto do que você imagina.
Com o passar do tempo é natural que o profissional de QA entenda melhor que ninguém os fluxos da aplicação e a importância destes para o negócio, também é muito comum -principalmente QA focado em automação, por saber um pouco mais de código mesmo- que este profissional se preocupe em como algo é desenvolvido ou como será corrigido e este com certeza é o melhor dos mundos!
É importante criar a mentalidade de que QA não é apenas encontrar e reportar bugs. Em determinados momentos este profissional passará a entender o que é melhor ou não entrar agora na esteira de desenvolvimento, participará da criação de novas features etc, basicamente este profissional terá todo o potencial para se tornar o guardião das galáxias! Digo... O guardião do produto em questão.
Este ponto com certeza é o que qualquer empresa gostaria de atingir e pra conseguí-lo o primeiro passo é este que estou tentando apresentar a vocês: cultura.
Qualidade e desenvolvimento trabalham juntos ¶
Sem o desenvolvimento não existe QA e sem QA o desenvolvimento está muitas vezes enviesado em seu contexto atual estando suscetível a bugs ou até mesmo a esquecer uma regra ou outra. A ideia é quebrar a barreira que as vezes um profissional forma do outro e entender que ambos trabalham juntos! Seja estando no mesmo time ou em times separados é importante criar um ambiente em que as partes possam cooperar, trabalhar em conjunto.
Aqui mais uma vez a comunicação se faz primordial! Vejo muita empresa ainda deixando ambos muito distantes um do outro, o processo para assegurar a qualidade deve ser dinâmico e iterativo, assim como o desenvolvimento, então porque não ambos falarem a mesma língua e participarem dos mesmos rituais? Se por acaso sua organização faz uso de alguma metodologia ágil, inclua QA e desenvolvimento nas mesmas cerimônias e procure deixar ambos sempre alinhados tenho certeza que o impacto disso será muito positivo.
Escreva um manifesto ¶
Ninguém gosta de imposições e no desenvolvimento de software não podia ser diferente. Quando for pensar em como estruturar a área de qualidade, junte-se com os principais envolvidos e escreva um manifesto.
Usando manifesto ágil como referência: ninguém chegou num determinado momento e impôs agilidade goela abaixo! O manifesto foi criado por pessoas e com o passar do tempo foi ganhando experiência/maturidade.
Procure fazer o mesmo na sua organização e entenda a dor de cada um e se realmente é a área de QA que vai resolver essa dor, não implemente por implementar e deixe o profissional isolado, tomando pancada sozinho...
Um manifesto não é algo escrito em pedra, escreva-o agora e o revisite de tempos em tempos, talvez marque reuniões exporádicas com os envolvidos (inclusive com o profissional de QA que passou a fazer parte da organização pós-manifesto) e atualize conforme a cultura for evoluindo e lições vão sendo aprendidas.
E se algo deste texto pôde contribuir para o manifesto de qualidade da sua organização me dê um ping no Twitter e deixe-me saber!