O papel do analista de teste em um time de scrum

Há um pouco mais de um ano fui convidada a participar do projeto piloto de Scrum na Globo.com. De lá pra cá aprendi muito sobre como trabalhar em um time com profissionais de todas as especialidades e como adaptar minhas atividades como especialista em QA. Já passei por um longo caminho e sei que ainda tenho muito a percorrer mas, neste post, vou tentar passar pra vocês um pouco da minha experiência e como defino o papel do QA no time de Scrum.

Bom, posso começar falando que mudei bastante minha forma de trabalhar. Na equipe de QA, tínhamos processos, planilhas, relatórios e todos foram abortados. No início resisti um pouco a abdicar dos artefatos de teste, mas percebi que realmente era necessário abortá-los. Posso dizer que o primeiro e principal papel do tester no time é definir processo de trabalho com o time.

- Relatórios: Não foi mais preciso gerar relatórios já que a proximidade do time é boa, sentamos todos próximos o bastante para uma boa comunicação. Tudo o que é preciso dizer é dito na hora, ou no daily ou nos reviews/retrospectives.

- Planilhas: Casos de teste e planilhas de bugs não existem mais. Com a proximidade do tester com os desenvolvedores, não tem motivo algum pra se registrar um bug no Jira. Ganha-se tempo e o entendimento é bem melhor. Os casos de teste são registrados no wiki junto com os respectivos bugs apenas para não perdermos o controle (bem mais prático).

- Processos: Cada time de scrum tem sua forma de trabalhar. Alguns automatizam testes. Alguns fazem TDD. Alguns fazem teste unitário. Não existe mais processo a ser seguido, já que cada time possui sua forma de trabalhar. Após definir o processo de qualidade com o time, o papel do analista de teste é mostrar por A + B, a importância de um TDD, de testes unitários, de um teste automatizado.

Passando dessa primeira fase de adaptação, o papel do testador é “evangelizar” o time. Ele testa, testa e testa e …. com o passar do tempo consegue provar ao time que NÃO existe sistema ZERO bug, mas que basta um esforço em equipe para se chegar bem próximo a excelência em qualidade.

O papel do tester é ser insistente. Não é fácil convencer desenvolvedor a testar (e testar bem). Só o tempo e a persistência é que vão fazer você chegar lá. Você vai encontrar bugs, o time vai gastar tempo para corrigir, e de tanto isso ocorrer, o time vai apostar na idéia de automatizar os testes.

Outro papel do analista de teste é passar seu conhecimento sobre técnicas de teste, conceitos de QA em geral, para que todo o time consiga ter qualidade nos testes, não só o especialista. O tester é muitas das vezes um tira-dúvidas do time. Ele deve mostrar o caminho para se alcançar a qualidade. Pode-se fazer apresentações, reuniões, pair-testing etc.

Além de todas as atividades que mencionei aqui, não posso deixar de falar também sobre estudar sempre novas técnicas de teste, tanto teste manual quanto teste automatizado, adaptando-se sempre ao mercado e trazendo novidades que possam aprimorar a qualidade ao time.

Resumindo:

1) Definir processo de trabalho com o time;

2) Evangelizar o time a nível de qualidade como um todo;

3) Jamais desistir. O caminho é longo até o QA entrar no sangue de todos do time;

4) Transmitir o conhecimento de QA ao time;

5) Buscar novidades no mercado em relação a testes manuais e automatizados;

Enfim, esses são os cinco mais importantes papéis do analista de testes em um time de Scrum, segundo meu ranking. Scrum é a tendência do mercado. É necessário se adaptar. O resultado vale a pena. Pode confiar.

Até a próxima….

3 respostas para O papel do analista de teste em um time de scrum

  1. Recentemente eu levantei a mesma questão junto a comunidade que participo no LinkedIn, particulamente eu não recomendo limarem de vez documentação e relatórios, já que os números são insumo para tomada de decisão e averiguação da evolução do time. Mas como você falou “Martinha” o mais importante é achar o melhor processo para o seu time. Não existe uma regra , apenas boas práticas. Devo postar algo em relação a isso em breve. Sem dúvida uma ótima discussão para o momento.

  2. marthahuback disse:

    No meu time mantemos o wiki sempre atualizado. Lá eu sei a quantidade de bugs que encontro, tenho casos de teste e métricas.

    Em metodologia agile é importante a interação entre pessoas. Documentar é importante, porém apenas o que for realmente necessário.

    Antigamente tínhamos status diário, relatório de fim de projeto, plano de testes de 30 páginas e muito mais. Em agile nada disso é necessário. Apenas dificultaria o andamento do trabalho.

  3. JamW disse:

    fala Martinha, eu dei minha contribuição em relação a este assunto, dá uma olhada lá.
    flW :-)

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Sair / Alterar )

Imagem do Twitter

You are commenting using your Twitter account. Sair / Alterar )

Foto do Facebook

You are commenting using your Facebook account. Sair / Alterar )

Connecting to %s

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.