Primeiramente deve-se falar que o Scrum não reconhece diferença entre desenvolvedores, o QA é considerado como um desenvolvedor.
Há que se respeitar a disciplina de testes, ela é tão profunda quanto desenvolvimento de sistemas, mas o ideal é que cada desenvolvedor aprimore suas qualidades de testador, aprender sobre testes de integração e funcionais é um dever.
Se a equipe tiver um dev especializado em testes(leia-se QA), então esse deve funcionar como um conselheiro dos testes, deve ajudar no desenvolvimento do plano de testes, ele deve ratificar os testes feitos por cada dev, além de fazer os seus próprios, mas encontrar um erro nessa fase deve ser uma exceção, passível de ser discutida na retrospectiva da sprint.
QA não é babá de programador.
Nosso DEV entendido de testes pode ficar responsável por montar a pipeline de testes automatizados também.
O Scrum é um framework para desenvolvimento de produtos, não só software, um desenvolvedor pode ser um pintor de parede, todos os seus devs programam em Java, ou em Oracle? Não, então o QA é um dev e pronto.
Um dev testar o trabalho do outro, antes de passar para o nosso dev especialista em testes(QA), costuma dar bons resultados.
Os testes devem fazer parte da definition of done e da definition of workflow, evitando-se sobrecarregar o QA e deixar tudo para a última hora.
Um bom Scrum Master deve saber sobre WIP, e definição de workflow, para ajudar o time em suas definições.
A empresa pagar um curso de testes na Udemy é uma boa estratégia.
A certificação DEV da Scrum.org aborda muito a área de testes.
O Scrum é um framework adaptável a realidade e as práticas da empresa(isso não deve ser confundido com Scrum relaxado).
Quanto mais o P.O entende do produto, e é capaz de transformar isto em boas histórias, menos precisa-se dos stakeholders para testes de UAT, mas não há nada que impeça que os stakeholders possam dar uma forcinha com os testes, isso é especialmente útil quando a equipe trabalha com sistemas legados e complexos.
É muito importante que nosso dev entendido de testes participe ativamente do refinamento do backlog.
Muito embora a review não deva ser vista como um portal de envio de valor para a produção, espera-se que a maioria do que foi combinado seja demonstrado ao fim da sprint, não vale deixar tudo para o QA conferir na quinta-feira véspera da review, quando muitas vezes é tarde para se arrumar alguma coisa.
Defeito não é débito técnico, é defeito mesmo, se algo está defeituoso, não bate com a definition of done, e não deve ser demonstrado na review.
Apesar da entrega contínua diminuir a pressão da entrega na review, não se deve fazê-lo por falhas no processo.-Marcello Dias
