Hoje vamos começar sem churumelas!
Testadores de software são os porteiros ou guardiões da qualidade
Em um processo de desenvolvimento cascata, já que os testes são realizados na última etapa do processo, os testadores acabam tendo que assumir o papel de guardiões da qualidade, tendo que categorizar corretamente os bugs mais críticos, fazer testes de última hora, trabalhar alguns finais de semana, testar correções de bugs e seus impactos, dentre outras tarefas.
Mas também tem os times ágeis, que trabalham com Scrum, XP, e outras técnicas de de trabalho ágil, onde ainda existe o papel de tester. Neste contexto, o ideal é garantirmos que enquanto funcionalidades são criadas, testes de regressão ou aceitação são criados e mantidos, garantindo não somente que você não precise perder tempo em fazer uma tarefa repetitiva e massante, quanto um teste de regressão, como também para aproveitar-se a proximidade com o time de desenvolvimento e evoluir no quesito automação (tarefa tão importante no desenvolvimento ágil de software), além de cada vez mais ir ganhar o respeito dos desenvolvedores.
E não dá pra esquecer…Done, é só depois de testado!
Testadores de software não são os porteiros ou guardiões da qualidade
E porque não, pensar que os responsáveis pela qualidade do sistema são todos os envolvidos no desenvolvimento deste? Não deveriam ser os desenvolvedores também responsáveis pela qualidade do sistema, já que são eles quem escrevem (codificam) este sistema? No Scrum, não tem aquele lance de que no time todos são a mesma coisa? Não tem diferença de papéis?
Qualidade é atingida quando todos os envolvidos no processo entendem a importância de seus papéis, e então o fazem com a intenção de garantir o todo, e não só o seu. Softwares são feitos por times, e todos devem ser responsáveis por fazer bem seus trabalhos, como por ajudar seus colegas a fazerem bem seus trabalhos.
Além disso, algumas vezes os testadores (por mais que possuam habilidades com relação as áreas de negócio) não vêem o software, um bug, ou uma melhoria, com a mesma perspectiva do cliente, o qual usa a aplicação e sabe de seus problemas, e as vezes de suas necessidades com relação ao software. Portanto, muitas vezes o próprio cliente será responsável pela qualidade do sistema, principalmente no que diz respeito aos requisitos de software e no entendimento de seu papel em processos ágeis, onde ele deve participar de reuniões de planejamento, ajudar na priorização das histórias e prover feedback sobre o software entregue durante os sprints.
In my humble opinion, it’s responsability to the whole team.
~Walmyr Fº
Pensamento do livro:
“Quality is value to some person”
~Jerry Weinberg
TALKING ABOUT TESTING 