SBTM e How Google Tests Software - GDGSSA

Notas do Editor

• #2: Bom dia pessoal, meu nome é Lorena Caldas, estamos no 3º de palestras do liguÁgil
• #3: Bom... Vocês já sabem meu nome, eu sou a Lorena, trabalho com TI há 7 anos, 5 deles dedicados à qualidade de software, atualmente sou analista de testes na Capgemini, uma multinacional com filial em Salvador. Escrevo para o site Qualidade de Software através do meu blog, o ciclosw e recentemente, no ano de 2015, fundei o Grupo de Testadores de Salvador com o intuito de discutir melhores formas de aplicar testes de software na Bahia
• #4: Bom.. E o que tenho a intensão de falar para vocês? A relevãncia de uso desse modelo, com base em necessidade, conceitos, comparações entre processos. Vamos lá? Antes de mais nada, vocês já se perguntaram sobre qual é a necessidade em tetar software? Pois eu digo a vocês que é buscar qualidade. Mas apenas isso? Bom... Eu vou atribuir qualidade ao meu produto ou serviço para aumentar a confiabilidade daquilo que e entrego E assim satisfazer ao cliente, fidelizando ele e agregando novos, já que a imagem da empresa será preservada, ela vai ser vista no mercado como boa prestadora de serviços Além disso, eu vou diminuir os custos com o retrabalho, já que minhas entregas serão mais eficazes Diante dessa explicação, eu cito agora 3 pontos que precisam ser esclarecidos para as pessoas que ainda não implementam a visão de qualidade em suas entregas: 1º enquanto a visão de todos os envolvidos no projeto está restrita à construção, a visão do testador também está na desconstrução do documento ou sistema com o objetivo de identificar o máximo de falhas antes que as entregas aconteçam ao cliente 2º qualquer pessoa que saiba ler, escrever, que tenha minima criticidade na leiutra de requisitos de sistemas está apta a testar software. No entanto, esses testes somente serão efetivos no caso de ela conhecer: as necessidades e visão do cliente; os objetivos do projeto; conceitos, técnicas, processo, melhores práticas de testes 3º a atividade de testes manuais sempre vai existir dentro dos projetos de software, isso porque a figura do homologador, que fica da parte do cliente, sempre irá existir. Justamente porque será necessário verificar que aquilo que foi contratado está sendo entregue. A sua visão como desenvolvedor, analista de requisitos, dba, gerente de projetos também deve estar voltada à visão que ele terá no momento das entregas 4º Automação de testes anda de mãos dadas com os testes manuais. Sempre será necessário validar se um código ou um fluxo do produto funciona, antes de realizar a sua correta automatização. Automatização de testes demanda maturidade técnica da equipe, de negócio e do sistema. 5º Por fim, todos os envolvidos no desenvolvimento do projeto devem contribuir para promover a qualidade do produto e isso só acontece se todos estiverem com este objetivo em comum, beleza?
• #5: Daí, tendo aí agora a visão da necessidade de realização dos testes em projetos de software eu apresento a vocês a forma que essas atividades são executadas na maioria das empresas brasileiras, sobretudo no eixo Norte-Nordeste onde as empresas ainda tem a visão fechadas à certificações como forma de vencer licitações e contratos que garantam a continuidade de suas operações Esse é o modelo padrão de testes, vocês podem ver aqui nesta figura um projeto de teste acontecendo em 4 fases. Há diversas atividades acontecendo de maneira linear. As figurinhas em azul estão representadas as tarefas consideradas caminho “não crítico à entrega de resultado ao projeto” enquanto as figurinhas em amarelo são consideradas caminho crítico Eu destaco a atividade modelagem de testes que fica bastante restrita à criação de casos de teste, pela implementação do modelo IEEE. Cada caso de teste contém a descrição de um pequeno fluxo de uso do sistema, um passo-a-passo para auxiliar a execução dos testes Já a atividade de execução dos testes podem acontecer de duas formas: baseada em roteiros, seguindo os casos de teste; ou de maneira exploratória, quando se baseiam em conhecimento de projeto e de carreira daqueles envolvidos nos testes Os testes de roteiro apresentam boa cobertura de requisitos de sistema; enquanto que os testes exploratórios se relacionam bem com o comportamento de sistema Vamos ver um projeto que utiliza este padrão, na prática
• #6: Diversas vezes utilizamos esta ferramenta da HP que integra as atividades de criação, execução e reporte de incidentes para implementar o processo waterfall. Percebam que esse projeto de testes apresenta, aqui na parte esquerda da imagem, várias divisões por pasta, cada uma considerando uma ação de usuário. Cada grupo de testes desses contém vários casos de teste, com cada um deles possuindo de 1 a N passos. Este caso aqui possui muitos passos, com cada passo contendo ação de usuário, resultado de sistema e resultado. Além desses atributos, os casos de teste também devem descrever: título, pré-condições, massa de dados e pós-condições
• #7: Isso tudo se transforma em muita coisa para controlar e ajustar. Pode acontecer de o requisito apresentar uma versão, o caso de teste outro e o sistema mais um, todas desencontradas. Assim como o código-fonte, os casos de teste precisam ser revisados a cada alteração de requisito do cliente
• #8: Assim, esse cara aqui, o engenheiro de software norte-americano James Bach, lá no ano de 2007, tendo participado de vários projetos no contexto descrito decidiu
• #9: Com base nessa vertente do manifesto ágil: Software em funcionamento é mais importante do que ter documentos bem detalhados decidiu experimentar uma nova forma de trabalho.
• #10: 1 - enxugar a atividade de modelagem de testes. Já que ela é uma atividade não crítica ao resultado do projeto, porque dar tanta ênfase a ela?
• #11: 2 - Melhor gastar este tempo exercitando mais caminhos do sistema, com base na experiência de usuário adquirida pelos envolvidos no projeto. Isso contribui para um aumento significativos de erros internos identificados e corrigidos antes das entregas ao cliente
• #12: Nesta nova abordagem, uma sessão apresenta muitos casos de teste e há possibilidade de criar vários novos cenários durante a execução desta sessão As sessões são extraídas diretamente do requisitos, estória de usuário, feature, bugs e tarefas passadas. É uma boa prática alimentar novos ciclos de teste com a experiência de homologação do cliente: incluir formas de uso do sistema, bugs que ele detectou ou melhorias solicitadas. Elas, inclusive, podem ser transformadas em novos requisitos de sofware, como mostra a figura
• #13: Cada sessão pode estar contida em um ou mais charters, a forma de documentar os testes exploratórios na abordagem SBTM. Note que cada card contém a área de cobertura dos testes, anotações sobre os testes, lista de riscos e erros identificados e questionamentos que será considerados na próxima reunião do projeto
• #14: Este aqui é o processo SBTM, que na tradução livre quer dizer: Gerenciamento de Testes Baseados em Sessão. Ou, como chamamos aqui no Brasil: testes exploratórios guiados (à sessão). o ciclo dessa abordagem visa:1º definir os charters. Os charters são documentos bem mais simples que os casos de teste, o que permite ganhar tempo na etapa de modelagem de testes; Cada charter contém, por exemplo diversos cenários que seriam descritos cada um como um caso de testes no modelo padrão.2º Depois os charters são atribuídos e priorizados; 3º E acontece a execução de uma sessão, um período de tempo desprendido para a execução desses testes; Nela devem ser executados o máximo de cenários exploratórios possíveis; 4º Por fim, os testes são analisados e as lições aprendidas são anotadas 5º para a realização de reunião. O legal desse método é que ele propicia a discussão dos resultados com o intuito de alimentar os próximos ciclos de teste, aumentando sempre a eficácia dos testes e conhecimento de todos os envolvidos
• #15: Mas eu, junto com minha equipe, no projeto mais recente em que atuamos, sentimos a necessidade de implementá-lo assim: -Utilizando charters contendo apenas grupos e aspectos a observar. A sessão se dá em cada ciclo de teste, cada qual tendo objetivos distintos. Por vezes executamos testes de regra, outras de itens já identificados. Criamos grupos de teste padrão, que orientam os testes em diversas funcionalidades do sistema, mas a cada de teste incrementamos novos, como resultado das lições aprendidas. Esta última imagem aqui na tela mostra exatamente uma situação dessas. A gestora identificou uma falha utilizando o sistema e nos reportou. Ela disse “Não realizei nenhuma alteração, mas o sistema informou que os dados foram alterados”. Nós corrigimos e decidimos que este cenário deve ser executado em todos os novos ciclos de teste que realizarmos, pois esse é um errro que fez parte do fluxo de uso do sistema
• #16: Nós já experimentamos o uso de mindmaps. São mapas mentais no estilo árvore com cada nó podendo ser destrinchado em diversos cenários
• #17: E através de Kanban tb, respeitando o fluxo de atividades que já possuímos Podemos criar tickets e atribuí-los a uma pessoa
• #18: Cada ticket tem informações como: título ou objetivo, autor, criticidade e tempo estimado
• #19: Além de detalhes a observar e comentários
• #20: Vamos ver agora como este tipo de testes se aplica na cultura do Google
• #21: Explicar os níveis de testes Essas são as duas estruturas de teste que podemos encontrar na maioria dos projetos de software ativos. O primeiro evidencia um projeto que realiza automação de testes, onde a quantidade de testes unitários realizados sobre o código é bem maior do que os testes de sistema. Já a segunda figura demonstra a pirâmide invertida, bastante utilizada em projetos que utilizam os testes manuais como técnica principal de testes. Daí você vê que os testes ficam mais voltados aos fluxos do sistema, ao invés das unidades. É importante dizer que as duas estruturas tem adequação a diferentes formatos de projeto.
• #22: Abordagem pequeno x médio x grande Tipos de Teste ●Ao invés de distinguir os testes por unitário, integração e sistema, no Google usa-se a designação de teste pequeno, médio e grande. ●A idéia é enfatizar escopo ao invés de forma. ●Testes pequenos cobrem pequenas quantidades de código, e assim por diante. ●Os três tipos de teste podem ser executados pelos três tipos de engenheiros, e podem ser automatizados ou manuais.
• #23: Segundo a Google: Engenheiro de Software (SWE) ●É o tradicional papel de desenvolvedor. ●Escrevem código funcional que é disponibilizado aos usuários. ●Criam documentação de design, escolhem estruturas de dados e a arquitetura geral, escrevem e revisam código. ●Escrevem bastante código de testes, incluindo TDD e testes unitários. Engenheiro de Software em Teste (SET) ●Também é um papel de desenvolvedor, porém o foco é em testabilidade e na infraestrutura de testes. ●Revisam designs e atentam para a qualidade de código e riscos. ●Refatoram código para torná-lo mais testável. ●São parceiros dos SWEs na construção do código-base, mas focam em aumento de qualidade e cobertura de testes Engenheiro de Teste (TE) ●É o papel que coloca o teste de usuário em primeiro lugar. ●Organizam o trabalho de SWEs e SETs, interpretam resultados e direcionam a execução de testes. ●Constróem automação de testes de sistema. ●São experts nos produtos, consultores de qualidade e analistas de risco. ●Coordenam contratos de teste, testadores crowd sourced, testes dogfooders, usuários beta etc. Estrutura Organizacional ●A estrutura de trabalho do Google é formada por áreas foco (AF). ●Existe uma AF para aplicações cliente (Chrome, Toolbar etc), Geo (Maps, Earth etc), Adds, Apps, Mobile etc. ●Todos os SWEs reportam para um diretor ou VP de uma AF.
• #24: Abordagem pequeno x médio x grande Tipos de Teste ●Ao invés de distinguir os testes por unitário, integração e sistema, no Google usa-se a designação de teste pequeno, médio e grande. ●A idéia é enfatizar escopo ao invés de forma. ●Testes pequenos cobrem pequenas quantidades de código, e assim por diante. ●Os três tipos de teste podem ser executados pelos três tipos de engenheiros, e podem ser automatizados ou manuais.
• #25: Por fim, eu desejo que vocês reflitam a respeito da cultura de qualidade que a Google prega: “tentar alcançar a excelência, ainda que isso seja difícil”
• #26: Essas são as formas de me encontrar. Espero que tenham gostado. Dúvidas? Tempo total: 24 minutos