Testadores ágeis devem corrigir os bugs que encontram?
Você já pensou sobre isto? Não seria interessante os testadores corrigirem bugs, por exemplo, quando não tem o que testar? Ou mesmo quando a correção é algo tão trivial?
Testadores ágeis devem corrigir os bugs que encontram
Primeiramente, quando se fala em desenvolvimento de software ágil não devemos pensar na separação dos papéis de desenvolvedores e testadores, mas sim em um time inter-disciplinar o qual é comprometido com a entrega de software que agrega valor ao cliente/usuário final. Portanto, obviamente o time deve se preocupar com a correção de bugs quando eles aparecem, e ainda mais com a prevenção da ocorrência dos mesmos.
Em casos em que exista um cargo específico de testador, e o mesmo sabe exatamente o que causa certo problema no sistema, porquê não aproveitar para corrigí-lo, em vez de cadastrar um bug, esperar ser priorizado, para um dia então ser corrigido?
Além disso, no mundo ágil a prática de TDD (test-driven development) é percebida como algo saudável e provê rápido feedback quando uma funcionalidade deixa de funcionar, e com este feedback rápido, fica mais fácil de identificar que alteração quebrou a aplicação, para então ir atrás da causa raiz para a correção, ou ao menos uma sugestão de correção.
Testadores ágeis não devem corrigir os bugs que encontram
Um ponto interessante neste sentido é que se todo bug que for encontrado pelo “tester” for corrigido por ele mesmo, o desenvolvedor pode acabar se acostumando com isto, e então deixando bugs passar, pois sabe que serão corrigidos logo em frente pelo tester. Ou mesmo, nem notar que está cometendo erros básicos e passando código sem qualidade a diante. Ou seja, a comunicação não estaria fluindo como deve ser no desenvolvimento ágil de software.
Outra questão importate é que a correção de um bug as vezes pode causar outro. Com isto, não basta somente corrigir um bug específico, mas sim saber onde se está mexendo, conhecer a arquitetura da aplicação com a qual se está trabalhando, para que não hajam efeitos colaterais da correção de simples bugs.
_________________________________________________________
No fim, tudo depende do contexto, da vontade do tester de fazer parte do desenvolvimento do software final, ou mesmo, de o tester se preocupar com a automação dos testes, a refatoração dos mesmos, e a correção destes quando quebrarem por uma alteração na aplicação que exige sua mudança, ou mesmo quando um teste passou a falhar após seu refactor.
TALKING ABOUT TESTING 
Ótimo post!
Adicionando: não adianta o testador, se tiver esta capacidade, apenas corrigir do defeito… é necessário criar um teste para que este defeito não ocorra novamente ou atualizar /refatorar os testes unitários atuais analisando qual foi o gap nestes testes que deixaram esse erro ocorrer 🙂
Na verdade, só para lembrar, os testadores ágeis não ficam “sem nada para testar”, porque, se adequadamente inseridos dentro do processo de desenvolvimento, sempre haverá “serviço” para eles, em cada etapa da sprint.
Concordo, mas as vezes a demanda é menor por parte dos testes.
Eu sou da idéia de que a pessoa q corrige bugs tem que ser a pessoa que melhor sabe fazer isso – no caso, o Dev. O tester sabe fazer um cenário que reproduza mais fácil ou um teste automatizado especial pra aquele bug. Cada um ajudando da melhor forma q pode 🙂
No caso de projetos maiores, a discussão de “quem é o culpado” é mais longa, mas minha thumb-rule continua valendo…
+1
Concordo contigo em quase tudo. Mas se tem um time ágil de verdade, não deve se preocupar com os devs deixando passar defeitos 😉 Entregar valor vem antes de quem é o responsável por isso ou por aquilo. Ao corrigir um defeito (usualmente trabalhando em par ou submetendo um pull request pra review), você aprende com o dev mais sobre a sua app e o dev aprende mais sobre o seu mindset. No final os dois melhoram e o problem é resolvido mais rápido.
Ótimo post 😉
Pegando o gancho do Camilo …
E se o time fosse feito de #DevTesters? Perfil acima de tudo! Pessoas qualificadas e dentro de um ambiente de aprendizado contínuo? Pareamento, coaching, boas práticas em geral … Acredito que o “problema” de quem deve corrigir o bug já esteja resolvido, não? Responsabilidade é na verdade a peça chave na minha visão!
Muito boa discussão, parabéns!