is there any start stop boundary qa s role scrum
Qual é o papel do controle de qualidade no Scrum: Atividades do Scrum para os testadores
Este artigo não é apenas um tutorial sobre alguns processos, métodos ou instruções sobre como trabalhar como QA. Em vez disso, este é um artigo no qual desejo compartilhar minha própria experiência de trabalho como um QA Sênior em SCRUM.
Meu CTO anterior sempre dizia que ‘Com a liberdade vem a responsabilidade’. Se você tem liberdade para fazer o seu trabalho do seu jeito, então é você e somente você quem é responsável por seu trabalho, tarefas ou atividades.
Scrum é isso !! Deixe-me dar uma ideia básica sobre o Scrum à medida que avançamos.
O que você aprenderá:
Visão geral do Scrum
Scrum é um subconjunto do metodologia ágil e é uma estrutura de processo leve que é amplamente usada.
O Scrum nos ajuda a manter os clientes satisfeitos, dando-lhes o produto em pequenos módulos, mas também mantém o cliente ciente de que seus requisitos que mudam frequentemente podem atrasar as atividades. Os lançamentos são curtos e o trabalho é feito de acordo com a capacidade da equipe envolvida, portanto, as chances de falhas ou clientes insatisfeitos são reduzidas em grande medida.
Por outro lado, os requisitos (neste caso as Estórias de Usuário) são finalizados antes do início do Sprint para evitar retrabalho e, assim, resultar em Sprint atrasado ou com falha (sempre há exceções).
Mas o maior desafio para um QA é que o período de lançamento é curto, um Sprint é principalmente um ciclo de 15 dias. Portanto, entregar um produto 'livre de bugs' em no máximo 4-5 dias (levando o tempo de desenvolvimento) requer muitos esforços e pensamento inteligente.
Eu sou o controle de qualidade da minha equipe:
Sim, sou o controle de qualidade da minha equipe e sou um jogador importante dela. Por que?? Porque os clientes, BAs, Scrum Master e todos os outros estão confusos sobre a qualidade, a aparência e o desempenho do aplicativo ou produto.
No Scrum, como a duração do sprint é curta, o controle de qualidade deve ser executado de maneira inteligente e, portanto, a necessidade do controle de qualidade de estar envolvido desde o início 'Planejamento' torna-se muito importante. Há momentos em que um QA pode desempenhar o papel de proprietário do produto proxy quando o pedido de compra não está disponível, ajudando assim o BA na criação de cenários / casos de teste de critérios de aceitação.
Os desenvolvedores também abordam o controle de qualidade nos momentos em que enfrentam problemas com a funcionalidade ou regras de negócios. No Scrum, o foco é apenas em ter um lançamento de Sprint tranquilo e bem-sucedido e não se trata de ‘Meu trabalho’ ou ‘Seu trabalho’ para ajudar quando sua equipe se aproxima de você para obter ajuda.
No vínculo da equipe Scrum, as relações saudáveis entre os membros da equipe desempenham um papel muito importante e sendo um QA, você deve ter muito cuidado ao comunicar sua opinião sobre as histórias de usuário que está testando. Sua comunicação deve ser sobre a história ou funcionalidade do usuário e não sobre a pessoa que trabalhou nela.
No Scrum, o QA não é julgado ou apreciado pelo número de bugs que descobre, mas também pela forma como está interagindo com o time, ajudando o time e motivando o time mesmo em momentos difíceis.
Além de testar as tarefas do sprint, escrever planos de teste / casos de teste / documentos de lançamento também tenta envolver mais porque a duração do lançamento do Sprint é curta e o objetivo é o mesmo para todos “Para entregar um produto funcional livre de bugs com sucesso, ajudando uns aos outros”.
Um QA está envolvido em quase todas as atividades realizadas em um Sprint e, tecnicamente, não há limite para o início ou parada das atividades de QA. Ao contrário do modelo tradicional em cascata, em que o controle de qualidade se limita apenas a testar a versão, aqui o controle de qualidade tem muito mais responsabilidades. Então, eu sugeriria tentar e fazer mais das seguintes atividades.
Atividades a serem seguidas
Abaixo estão algumas atividades que eu sugiro que você siga como um QA no Scrum.
como classificar uma matriz de inteiros em java
# 1) Dwell Deeper:
Com isso, quero dizer que, quando as histórias de usuário e seus critérios de aceitação estiverem prontos, estude-os completamente e pense mais profundamente sobre as dependências, os resultados ocultos e se há uma maneira melhor de fazer isso.
Comunique-se e colabore com o BA e a equipe de desenvolvimento sobre isso, porque pode acontecer que eles também não tenham pensado nisso. Compartilhe suas ideias e descobertas com a equipe.
Se você achar que há obstáculos ocultos ou impactos negativos, apresentá-los ao Scrum Master e ao pessoal de desenvolvimento lhes dará tempo para pensar e agir de acordo. Esta atividade no Scrum se torna muito crítica quando o projeto é de grande escala e quando há módulos espalhados pelas equipes.
Agora, ao estudar sobre as dependências, um impacto é muito importante para um controle de qualidade e até mesmo torna a equipe de desenvolvimento ciente do mesmo. Para fazer isso, discuta com os QAs das outras equipes e receba informações deles.
# 2) Envolva-se nas estimativas:
A prática usual é envolver um QA nas estimativas, mas muitas vezes devido ao pequeno sprint, o QA pode não ser solicitado a fazer uma estimativa para testar as tarefas, deixando-os com 3/4/5 dias para o trabalho de teste.
Nunca aceite isso. Levante a voz se for necessário, mas certifique-se de fornecer sua estimativa de teste, que deve incluir o tempo necessário para cada trabalho.
Pode incluir tempo para pesquisa, tempo para configurações, tempo para coleta de dados históricos etc., mas seja estrito e específico sobre o tempo necessário para a realização das atividades de teste e tenha esses valores de tempo adicionados à história do usuário junto com o tempo das tarefas de desenvolvimento .
Isso é muito importante porque se você tentar fazer o seu trabalho no tempo previsto e não conseguir concluí-lo, somente você será responsável pela falha. Quando o tempo de QA for adicionado, o Scrum Master, o PO estará ciente das atividades de QA envolvidas e da quantidade de tempo necessária.
# 3) Emparelhamento Dev QA:
Idealmente, no Scrum, as Estórias de Usuário Sprint são entregues para teste após o desenvolvimento ser concluído e uma vez que o teste de desenvolvimento tenha sido feito, mas o problema aqui é que no momento em que é entregue ao QA para teste, dificilmente 4-5 dias para a demonstração ou revisão permanecem.
Agora, se como um QA você descobrir até 4 bloqueadores ou falhas funcionais, você terá que trabalhar tarde da noite ou no fim de semana para cumprir sua data de lançamento, já que haverá testes funcionais, regressões etc., a serem feitos. Este parece ser o modelo tradicional em cascata, que não é a melhor maneira de fazer, no Scrum a maneira mais inteligente é “Previna defeitos ao invés de encontrar defeitos”.
Portanto, a solução é fazer o emparelhamento dev QA e realizar uma rodada básica de testes na configuração do dev assim que os desenvolvedores estiverem prontos com as histórias, antes mesmo de um lançamento formal para teste.
Os seguintes critérios podem ser levados em consideração para fazer um BVT na configuração de desenvolvimento para as histórias de usuário:
- Critérios de aceitação para cada história de usuário: BVT das histórias de usuário de acordo com os critérios de aceitação.
- Falta de confiança nos desenvolvedores: Às vezes, os desenvolvedores não estão confiantes sobre algumas implementações e, portanto, eles discutem tais implementações e fazem um BVT para aqueles na mesma configuração de desenvolvimento.
- Testes de Dependências / Impacto: BVT das dependências ou impacto sobre / dos outros módulos das novas implementações.
- Teste de Unidade: Faça um BVT com o desenvolvedor dos testes de unidade que eles criaram, se necessário, ajude-o adicionando ou atualizando os testes de unidade.
Isso ajudará a reduzir o vaivém de bugs, economizando o tempo de todos, pois antes do lançamento para controle de qualidade, a maioria dos bugs funcionais ou de falhas já foram corrigidos. Lembre-se de registrar esses defeitos em suas ferramentas antes da revisão do sprint e movê-los até o estado 'fechado'.
# 4) Controle de qualidade no quadro branco:
Sempre incentivei pessoalmente minha equipe a incluir tarefas de controle de qualidade no quadro do White Scrum, incluindo os bugs também. Isso ajuda o Scrum Master a descobrir o status de QA de uma história de usuário simplesmente olhando para o quadro.
O não. de bugs na lista de tarefas pendentes, os bugs na lista Em andamento, as atividades de controle de qualidade nas listas A fazer, Em andamento e Concluído falam por si. Acho muito doloroso quando alguém pergunta sobre o status do teste de histórias individuais para uma Sprint, porque preciso gastar um tempo extra para tirar meu status das ferramentas de compilação e mostrá-las ou redigir um e-mail.
Eu simplesmente prefiro apontar a pessoa para o Scrum Board e deixá-la fazer isso por si mesma. Prefira uma cor brilhante brilhante para as cunhas QA Sticky.
# 5) Documentação:
Esta é uma das desvantagens ou contras do Scrum que, devido ao tamanho pequeno do Sprint, não há muito tempo para documentação e nunca vi um Escritor Técnico em uma equipe Scrum. O Scrum Master / BA não pode e nem sempre atualiza os documentos sobre as informações do produto.
O problema surge se novos membros ingressam ou, no pior dos casos, se as regras de negócios, as funcionalidades mudam e como mantê-las sob controle, porque pesquisar informações em histórias de usuários 'Concluídas' será como procurar uma agulha em um palheiro.
A solução é criar uma tarefa separada em um sprint sempre que possível (principalmente em tempos de folga ou quando a carga de trabalho é muito menor) para a documentação, de modo que você possa revisar os documentos e atualizar ou fazer com que o Scrum Master ou o BA os atualize.
Um QA é a pessoa certa para ajudar na atualização dos documentos, pois você é quem testa, verifica as histórias de usuário e conhece a funcionalidade interna e externa. Faça você mesmo se não houver BA e se seu Scrum Master estiver ocupado para atualizar.
# 6) Sprint Review / Sprint Demo:
Na maioria das vezes, acontece que o QA é aquele que é escolhido para dar a demonstração ao PO e às partes interessadas. mas se não convencer seu Scrum Master a fazer isso. Um QA é a pessoa certa para fazer a demonstração, pois ele / ela testou a história do usuário por dentro e por fora.
Um QA pode fazer uma demonstração do ponto de vista do negócio porque conhece as funcionalidades, os fluxos e as regras de negócio. Prepare-se bem para a demonstração e tente responder a todas as perguntas que o PO e as partes interessadas têm. Isso ajudará você a se tornar o ponto de contato para eles na ausência do Scrum Master e do BA.
# 7) Aja como um BA:
Esta não é uma tarefa normal e nem mesmo esperada de um QA, mas tente entrar nesta função quando houver uma chance, porque um QA é a melhor pessoa para ser um BA. Por exemplo, tente pensar e visualizar se os fluxos, funcionalidades ou regras de negócio podem ser modificados de forma a beneficiar o cliente.
Pense e pesquise as tendências atuais na IU, veja e sinta o aplicativo e como ele pode ser beatificado, tornado mais amigável, etc. Se a equipe estiver presa em algum problema, envolva-se e tente dar uma resposta simples e inteligente solução. Isso dará um impulso à sua função e será um fator que contribuirá para o crescimento da sua carreira.
As chances surgem durante ligações com o PO, quando alguns problemas são discutidos ou em revisão / demonstração onde você pode dar sugestões.
Conclusão
Scrum é uma metodologia muito diferente do método normal em Cachoeira, e o Scrum Master é um facilitador. Portanto, não espere que ele / ela defina suas atividades para você.
No Scrum, não há limite de início e fim para a função de QA. O controle de qualidade precisa e deve estar envolvido em todas as atividades desde o início até o fim, desde o pré-planejamento até a revisão / demonstração do sprint e deve participar de todas as atividades.
Isso ajudará a entender o produto ou aplicativo, pois (como eu disse antes) não há documentação adequada disponível ao trabalhar no Scrum. Espera-se que você seja responsável, motivado e proativo. Portanto, não espere que alguém venha e lhe diga o que ou como você deve fazer.
Você deve tomar iniciativas por conta própria, ajudar a equipe de todas as maneiras possíveis, manter um relacionamento saudável, acompanhar as coisas em andamento na equipe e, o mais importante, ser claro sobre suas tarefas em um determinado sprint.
Aqui, não há Gerentes que irão monitorar você ou manter um controle de suas atividades. Esteja sempre pronto para ajudar sua equipe e você terá as melhores oportunidades.
Sinta-se à vontade para expressar suas idéias / sugestões sobre este artigo informativo na seção de comentários abaixo.
Leitura recomendada
- Função dos analistas de negócios no SCRUM e por que um controle de qualidade é melhor para essa função?
- Agile Scrum Online Quiz: Teste Seu Conhecimento de Agile Scrum
- Instalando seu aplicativo no dispositivo e comece a testar no Eclipse
- Kanban vs Scrum vs Agile: Uma comparação detalhada para encontrar diferenças
- Como entregar recursos de software de alto valor em um curto período de tempo usando o processo Agile Scrum
- Manifesto Agile: Compreendendo os Valores e Princípios do Agile
- Triagem de defeitos no Scrum: como é organizado em uma configuração do Scrum
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)