Quem é o QA dentro do Ágil?

Hoje de manhã eu estava lendo um artigo no caroli.org, que me fez lembrar que eu já falei aqui no blog do P.O, do Scrum Master, do System Team, mas que eu esqueci de falar do Q.A..

QA vem do inglês, Quality Analyst, e significa analista de qualidade no bom português. Este é um papel muito importante dentro das equipes que trabalham com produtos digitais ágeis. Apesar de existir um outro acrônimo de QA, que em inglês significa Quality Assurance e em português é "Garantia de Qualidade", o papel do QA aqui está mais voltado ao analista de qualidade de testes que à garantia de qualidade propriamente dita.

Qual o objetivo de um QA?

O QA, assim como o System Team, deve garantir a qualidade do produto. Mas mais do que isso, ele deve garantir que o software que estamos entregando ao cliente é exatamente o que eles querem. Uma análise aprofundada de testes é realizada. A diferença aqui para o System Team, é que o QA está dentro do projeto ágil enquanto o System Team aparece com maior evidência no final das entregas. Para saber mais sobre o System Team, clique AQUI.

O controle de qualidade parece como o trabalho no estilo "camaleão": muda de responsabilidades diárias à medida que a equipe aprende e cresce, e o projeto passa por mudanças.

O que faz um QA?

O QA ai orquestrar todos no time para garantir que essas tarefas sejam realizadas pelas pessoas mais adequadas para realizá-las. O QA é responsável por entender como  se encaixam todas as atividades relacionadas à qualidade da equipe. Lembrem-se, o teste não é mais de feito exclusivamente por um testador.

No ágil todos estão preocupados com a qualidade do produto. O QA é o especialista de conduz o produto do time à qualidade esperada.

Quais são as responsabilidades do QA?

• Análise de teste: Isso inclui análise de risco e design de teste. O QA faz análise de teste quando pensa num teste exploratório, quando está escrevendo casos de teste de regressão, quando está colaborando nos critérios de aceitação da história, quando está implementando ou mantendo testes automatizados, ou quando está decidindo quais testes de regressão não deve fazer porque não vai ter tempo.
• Estratégia de testes: Os QAs geralmente colaboram com os desenvolvedores na estratégia geral de testes da equipe, já que muitos testes, testes funcionais de baixo nível, testes de contrato de serviço, testes de UI são feitos por desenvolvedores. É importante que os esforços de automação de teste entre os QAs e os desenvolvedores se complementem, porque, de outra forma, pode haver lacunas de cobertura que introduzam riscos ou duplicações que retardam a equipe.
• Análise de negócios: os QAs podem ajudar (e muito) os analistas de negócios a definir critérios de sucesso para as histórias.
• Verificação da história – Como os desenvolvedores terminam as histórias ao longo da iteração, alguém precisa testá-las cuidadosamente para garantir que elas atendam aos critérios de aceitação e às necessidades dos usuários. A equipe confia nos QAs, pois possuem habilidades de teste: rigor e conhecimento de técnicas eficientes para encontrar erros.
• Teste manual: Antes de escrever um teste automatizado, precisamos testar as coisas manualmente para ter uma idéia de como elas funcionam e para ter uma idéia melhor do que automatizar. Esta tarefa normalmente é feita de modo aprofundado pelo QA, mas também é executada por um desenvolvedor.
• Automação de teste: Mais uma tarefa compartilhada com o desenvolvimento. Fazer testes de rotinas manualmente deixa uma grande chance de erro. Muitas vezes, é melhor se a maioria das funcionalidades importantes forem testadas automaticamente.
• Testes exploratórios: é aqui que uma QA brilha, pois tenta descobrir casos e combinações que os desenvolvedores não imaginaram ao escrever o código. Aqui o QA incorpora o usuário leigo e o especialista de negócio para encontrar bugs.
• Teste de regressão: Uma regressão é uma alteração indesejada para a funcionalidade existente. Infelizmente, a experiência que tenho como System Team mostra que as equipes ágeis cortam os testes de regressão com maior frequência do que deveriam. Esta atividade é tão importante quanto os testes exploratórios. Apesar de ser uma tarefa dos QAs, devido ao frequente corte de escopo, é aqui que o System Team brilha! ;)
• DevOps: a maioria dos testes acontece em um "Ambiente de Teste", o que muitas vezes significa que o QA é a primeira pessoa que tem uma necessidade real de um produto implantado em funcionamento. Isso às vezes significa que o QA se torna uma pessoa DevOps para a equipe, pois eles começam a solucionar as falhas de implantação por conta própria.
• Comunicação de Riscos e Defeitos: Pessoas em diferentes papéis precisam de informações diferentes sobre riscos e problemas, apresentadas de diferentes maneiras. O QA precisa ser o mais detalhista e preciso possível quando conversar com um desenvolvedor sobre um defeito.
• Liberação de tomada de decisão: O QA geralmente tem a responsabilidade de fazer, ou participar na tomada de decisões, go/no-go ou vai/não-vai, para novas funcionalidades e produtos.

Como você pode ver, é uma tonelada de coisas! Tentando fazer tudo é impossível, mas, por sorte, a qualidade é uma atividade de toda a equipe. Embora seja responsabilidade do QA garantir que as coisas aconteçam, não é necessariamente a responsabilidade deles fazer todo o trabalho!

O que um QA deve aprender para iniciar suas atividades?

A desvantagem de tudo isso é que é difícil dizer a alguém exatamente o que eles devem aprender em sua jornada como QA. O que vou propor aqui, é um compilado de vários QAs de várias empresas. Lembrem-se: isso não é uma receita de bolo, mas sim uma sugestão vinda de pessoas que já passaram pelo caminho das pedras.

1. Aprenda sobre o domínio: entender os diferentes tipos de usuários, entender o que é construído e porquê, entender como a coisa que está sendo construída é dividida em pedaços menores (épicos e histórias). Aqui você não precisa debulhar o código fonte, mas sim sentar e conversar para entender bem o produto.
2. Compreenda os princípios básicos do teste: quais são os diferentes tipos de testes, como deve ser um testador, como aplicar testes diferentes às histórias e Critérios de Aceitação.
3. Saiba documentar um defeito: aprendendo quais informações precisam ser incluídas, como funcionam as ferramentas padrão de rastreamento de erros. Existem ferramentas básicas que já falamos aqui no blog: Lightshot para corte e edição rápida de printscreens (http://bitlady.blogspot.com.br/2016/10/lightshot-uma-ferramenta-de-captura-de.html) e LICEcap ou ScreenToGif para criação de .GIFs (http://bitlady.blogspot.com.br/2017/10/licecap-e-screentogif-ferramentas-leves-para-criar-gifs.html).
4. Aprenda mais sobre o sistema operacional: muitos dos scripts, implantação e solução de problemas mais recentes que você precisa fazer dependem da sua capacidade de entender e navegar em torno do seu sistema operacional. Você precisará entender os conceitos básicos de como os principais sistemas operacionais funcionam: Windows, Linux, OS X, Android, iOS – e você precisará estar confortável trabalhando na linha de comando. Cedo ou tarde, você vai precisar. Então quanto antes se acostumar, melhor.
5. Aprenda tudo sobre o browser: (cookies, preferências de localização, browser strings, etc.)
6. Desenvolva habilidades básicas no Excel: Para testar aplicativos, eles precisam ser preenchidos com dados de teste, e o Excel é uma ferramenta extremamente comum para criar, editar e gerenciar dados de teste. Você precisará trabalhar com grandes conjuntos sem fazer alterações um por um, então aprenda as fórmulas para fazer a edição em lote. Muitas empresas usam Excel para gerenciar casos de teste também, então, quanto mais confortável você estiver com ele, mais eficiente voce será nas suas tarefas.
7. Compreenda como funciona Integração Contínua: Compreenda os princípios por trás da Integração Contínua. Saiba como funciona e o que é testado em que fase do pipeline no Git ou do TeamCity. Lembrando que você não precisa fazer, mas compreender como funciona, ajuda bastante.
8. Conheça os logs: Quando você está investigando erros, você terá que descobrir quais logs procurar, como encontrar coisas nesses logs (como abrir, pesquisar, navegar), como encontrar códigos de erro, e quando é apropriado trazer algo que você encontrar para um desenvolvedor.
9. Entenda os fundamentos da Web: seletores HTTP e HTML / DOM / CSS. Pelo menos o básico é importante.
10. Conheça alguns drivers do navegador (por exemplo, WebDriver / Selenium / Watir): Os drivers do navegador são a maneira principal de testar automaticamente as interfaces de usuário baseadas na web. 
11. Saiba os fundamentos de testes móveis: Além de emuladores e implantação de pacotes construídos para vários dispositivos, esta área fornece uma introdução natural à análise de combinações e permutações. Saiba quando repetir absolutamente tudo em cada navegador em cada dispositivo. Aprenda a técnica de teste “parwise”.

Pessoal, ninguém vem pronto para o mercado para trabalhar como QA (nem depois de 4 ou 5 anos de faculdade). Aqui estão dicas do que estudar para você melhorar suas habilidades e conseguir responder sobre a qualidade de um produto numa sprint. Além disso, no ágil todos da equipe são responsáveis pela qualidade do produto.

O que acontece depois de liberar o produto numa sprint?

De duas, uma:

ou cairá para o System Team estabilizar a versão, de modo integrado com os demais produtos, para então liberar o produto ao final de uma release;

ou você dará o OK final para colocar a versão no mercado.

Você concorda? Deixe sua opinião também!

Referências: Caroli. <http://www.caroli.org/o-que-faz-um-qa/>. Acesso em: 05/10/2017>.

Teste de ponto a ponto dos sistemas pelo System Team

O System Team por vezes faz jus à expressão "pau para toda obra". Ja falei bastante sobre o System Team no post anterior AQUI, mas vamos listar aqui algumas de suas atribuições. Depois veremos se não chegamos todos a uma conclusão assim. 😉

• Participamos das releases plannings de todas as equipes onde atuamos, auxiliando no refinamento do backlog para definir a os testes das histórias;
• Criamos novos cenários de testes automatizados;
• Estendemos os cenários de testes para conjuntos maiores de dados;
• Organizamos os casos de testes construídos pelos times individualmente em suítes ordenadas;
• Realizamos teste manual e executamos testes automatizados para novas features e histórias;
• Eealizamos o teste dos requisitos não funcionais do sistema.
• Auxiliamos a identificar problemas e gargalos do produto.

Pensem comigo, nós do System Team temos que conhecer muito sobre os produtos e sistemas que testamos para poder fazer as atividades acima.

O cenário de atuação do System Team

Após os testes efetuados nas equipes de desenvolvimento, entra a equipe de homologação do System Team que realiza o teste de aceitação baseado nos critérios de aceite da feature. Os critérios de aceite já foram previamente definidos pelos analistas de sistemas. Assim é testado e validado se todas as histórias sincronizadas no mesmo código fonte atendem aos critérios de aceite da feature, conforme imagem abaixo. 

Times responsáveis pelos diferentes níveis de teste.

Após a homologação realizada o System Team, através de uma outra equipe de analistas de testes, executa um teste de regressão completo ponto-a-ponto no sistema onde o objetivo é verificar se após a sincronização de todas as features no mesmo branch o sistema continua funcionando como deveria, conforme imagem abaixo.

Teste ponto-a-ponto do System Team.

Nesta etapa o System Team torna-se responsável por documentar e criar casos de testes para áreas do sistema nunca antes mapeadas, gerando assim um grande valor de conhecimento para todos que trabalham com teste na empresa. Na prática, a equipe do System Team torna-se referência na integração dos produtos (fazendo jus à expressão "pau para toda obra"). Outro tipo de teste que o System Team é responsável é o teste de integração com outros sistemas a fim de validar se as novas versões desenvolvidas continuam compatíveis com outros sistemas.

Com a estruturação da equipe para se adaptar ao SAFe onde uma equipe de testes (os QAs) que está junto aos desenvolvedores testa as histórias do usuário, e outra que está junto ao System Team testa as features, a qualidade do teste e a identificação de bugs foi elevada consideravelmente, pois conseguimos detectar defeitos em vários níveis diferentes do processo.

Concordam? Discordam? Comenta aí! 😀 

Referências:

CABRAL, Samuel Pierri. FERNANDES, Anita Maria da Rocha. Teste de Softwares Utilizando um Framework Ágil Escalável. UNIVALI, Florianópolis, SC, Brasil.

Quem é o System Team dentro do Ágil?

Trabalho a pouco mais de 5 meses no System Team. Entrei no time no final da primeira release (iteração) planejada, participei da segunda release inteira e agora estou na terceira release no time do System Team. Já tive altos e baixos, mas vou tentar explicar tudo sobre esse time neste post.

Onde começou o System Team?

No framework ágil SAFe, Times Ágeis não são unidades stand-alone. Pelo contrário, eles são uma parte integral do Trem de Release Ágil (ART/TREM), onde eles coletivamente têm responsabilidade por liberar mais valor. Pense na release como um trem, onde cada vagão é uma equipe. Times operam no contexto do trem, contribuindo para sua visão, colaborando com outros times, e participando em cerimonias chave do TREM. Os times e o trem são inseparáveis; o todo é maior que a soma de suas partes.

Big Picture SAFe - System Team

Afinal, o que é o System Team?

Existe um time específico para a execução dos testes de regressão e integração, criado a partir da implantação do SAFe: o System Team. Esse time tem como função fazer a homologação do sistema após a finalização das features (conjunto de histórias) criadas pelos outros vagões do trem. Ele é composto por analistas de testes mais experientes e com conhecimento aprofundamento do sistema (em teoria). 

Como ocorre a criação desse time durante a transição para o ágil?

Quando o ágil está sendo implementado, é comum começar com a equipe sem ter planejado a estrutura necessária para o trabalho do System Team. Lembre-se de que o System Team trabalha testando os sistemas de forma integrada, como é utilizado pelo cliente e precisa de máquinas boas para os seus testes. Também é comum formar mais de um time de System Team pois as equipes podem ser grandes de acordo com os sistemas e integrações, mas ambos devem testar seus produtos de forma integrada. Os times de System Team auxiliam com a integração de sistema e solução e ajudam a demonstrar a solução evoluindo à medida que ela se desdobra.

Conforme falei neste post aqui, ocorre uma cerimônia chamada de System Demo. Na System Demo é apresentado, de forma integrada, todo o desenvolvimento dos vagões ágeis durante a release. Como o System Team já possui o ambiente de forma integrada, é comum este ambiente ser utilizado para a validação dos produtos para os Product Owners ao final da release. Falo mais sobre System Demo mais abaixo neste mesmo post.

Descrição do Papel System Team

O System Team é um time ágil especial no trem, que possui grande conhecimento nas soluções e por vezes é procurado para fornecer assistência na construção e uso do ambiente de desenvolvimento e testes. Este time executa testes nas soluções de forma integrada e de ponta a ponta. Por este motivo pode fornecer um feedback de forma rápida sobre como está a integração dos sistemas.

Responsabilidades do System Team

... sobre a infraestrutura:

• Pode criar e manter a infraestrutura das soluções integradas, incluindo integração contínua, builds automáticas e automatização de testes;
• Pode criar plataformas e ambientes de demonstração da solução, como podem utilizar o ambiente já existente para tal;
• Pode facilitar os aspectos técnicos de colaboração, tais como prover dados ou serviços, facilidades de hosting, etc. para outras equipes de desenvolvimento do trem.

... sobre integração de sistemas:

• Participa das reuniões de release planning e no refinamento do backlog para definir integração e testes de capacidades e funcionalidades;
• Determina e ajuda a manter decisões e políticas para apropriar modelos de branch;
• Pode participar das dailys de outros times no apoio à atividades diárias.

... sobre testes ponta a ponta e de performance:

• Cria novos cenários de testes automatizados;
• Organiza casos de testes desenhados por times individuais em suítes ordenadas;
• Executa testes manuais e roda testes automatizados para novas funcionalidades e estórias;
• Prioriza testes demorados, refatorados, e roda suítes de testes reduzidas onde aplicável;
• Ajuda os times a criar suítes reduzidas de testes que eles mesmos podem rodar;
• Testa performance da solução contra requisitos não funcionais e ajuda a equipe de Engenharia de Sistema e Solução a identificar falhas e gargalos.

Como o System Team atua nas Demos dos Sistemas e Soluções (System Demo)?

Ao final de cada release os times (vagões do trem) precisam demonstrar a solução desenvolvida no período da release. Normalmente o System Team apoia as outras equipes e ajuda a assegurar que os ambientes de demonstração estão adequados.

Como o System Team atua na liberação dos produtos?

O System Team estabiliza as versões de liberação e possui o conhecimento necessário para testar as integrações dos produtos. O System Team normalmente entendem o que é, o que faz, e quão bem cada entrega atende os requisitos desejados, pois participa das Reviews e, as vezes, das plannings dos demais times ágeis/demais vagões. Nesta perspectiva, o System Team está diretamente envolvido no suporte da liberação, trabalhando com os DevOps e fazendo o que for necessário para ajudar o TREM a preparar, empacotar e liberar a solução. Lembrando que o System Team não faz o trabalho de manutenção de liberar versões que já estão no mercado. O System Team libera versões que ainda não estão no mercado.

Por que dos altos e baixos na equipe do System Team?

Como foi possível compreender após toda a explicação do que o System Team faz e quais são suas responsabilidades, é também possível imaginar o tanto de cobrança que a equipe do System Team tem e qual o seu trabalho. Nós liberamos uma versão nova dos produtos/sistemas a cada fim de release (isto não é uma regra, mas é como funciona onde trabalho hoje). A semana de liberação costuma ser conturbada, pois ainda não finalizamos as estabilizações e cada equipe do trem quer preparar sua apresentação para a posterior aprovação dos Product Owners. Isso quando o ambiente não dá algum problema.

Apesar dos testes serem integrados, temos que testar as funcionalidades novas integradas com as velhas. Aqui temos que deixar claro que NÃO é função do System Team testar as funcionalidades novas desenvolvidas pelos times de desenvolvimento, mas temos que testar impactos e integrações.

Por mais que haja pressão, é comum as equipes de desenvolvimento liberarem seus produtos com testes sem ver seus impactos. Também já vi acontecer de equipes não planejarem seus tempos de testes e testarem seus produtos durante a estabilização do System Team.

Se a equipe do System Team não for forte, acompanhar TUDO, comunicar qualquer deslize e não aceitar algumas liberações, as liberações viram playgrounds e os testes das sprints ficam impossíveis de serem executados!

Referências

System Team Abstract - SAFe. Disponível em: <http://www.scaledagileframework.com/system-team/>. Acesso em: 17 de maio de 2017.