Vídeos – Google Test Automation Conference 2013

Nos dias 23 e 24 de Abril aconteceu mais uma edição do GTAC – Google Test Automation Conference. Dessa vez também acessível via streaming. Os vídeos das 16 horas de palestras também já estão disponíveis no YouTube, os quais compartilho com vocês no decorrer do post. Ainda não tive tempo de assistir a todas as palestras, mas tenho certeza que o nível do conteúdo é excelente, pois já assisti a vários vídeos dos anos anteriores.

As palestras estão divididas em dois vídeos, referentes a cada um dos dias do evento, porém a partir da agenda você pode saltar para a palestra que mais lhe interessar. Já assisti as 4 primeiras palestras do dia 1 e gostei bastante das duas primeiras.

Segue a lista das palestras e os vídeos.

Dia 1:

Duração Palestrante Empresa Tema
00:15:00 Tony Voellm Google Opening
00:45:00 Ari Shamash Google Evolution from Quality Assurance to Test Engineering
00:45:00 James Waldrop Twitter Testing Systems at Scale @Twitter
00:30:00 Break
00:45:00 David Burns and Malini Das Mozilla How Do You Test a Mobile OS?
01:00:00 Lunch
00:45:00 Igor Dorovskikh and Kaustubh Gawande Expedia Mobile Automation in Continuous Delivery Pipeline
00:15:00 David Röthlisberger YouView Automated Set-Top Box Testing with GStreamer and OpenCV
00:15:00 Ken Kania Google Webdriver for Chrome
00:15:00 Vojta Jina Google Karma – Test Runner for JavaScript
00:15:00 Patrik Höglund Google Automated Video Quality Measurements
00:15:00 Minal Mishra Netflix When Bad Things Happen to Good Applications…
00:30:00 Break
00:45:00 Tao Xie North Carolina State University Testing for Educational Gaming and Educational Gaming for Testing
00:45:00 Simon Stewart Facebook How Facebook Tests Facebook on Android
00:15:00

Dia 2:

Duração Palestrante Empresa Tema
00:15:00 Opening
00:45:00 Mark Trostler Google Testable JavaScript – Architecting Your Application for Testability
00:45:00 Thomas Knych, Stefan Ramsauer, Valera Zakharov Google Breaking the Matrix – Android Testing at Scale
00:30:00 Break
00:45:00 Guang Zhu (朱光) and Adam Momtaz Google Android UI Automation
01:00:00 Lunch
00:45:00 Jonathan Lipps Sauce Labs Appium: Automation for Mobile Apps
00:15:00 Eduardo Bravo Google Building Scalable Mobile Test Infrastructure for Google+ Mobile
00:15:00 Valera Zakharov Google Espresso: Fresh Start to Android UI Testing
00:15:00 Michael Klepikov Google Web Performance Testing with WebDriver
00:15:00 Yvette Nameth, Brendan Dhein Google Continuous Maps Data Testing
00:15:00 Celal Ziftci, Vivek Ramavajjala University of California, San Diego Finding Culprits Automatically in Failing Builds – i.e. Who Broke the Build?
00:30:00 Break
00:45:00 Katerina Goseva-Popstojanova West Virginia University Empirical Investigation of Software Product Line Quality
00:30:00 Kostya Serebryany Google AddressSanitizer, ThreadSanitizer and MemorySanitizer — Dynamic Testing Tools for C++.
00:30:00 Claudio Criscione Google Drinking the Ocean – Finding XSS at Google Scale
00:05:00
Anúncios

Aumentando a qualidade do software com apoio do Powerpoint

Como havia prometido no post – Apertem os Cintos, o Analista de Requisitos Sumiu!, descrevo hoje como abordávamos o gerenciamento dos requisitos (estorias) num dos projetos desenvolvidos no C.E.S.A.R. gerenciado com SCRUM. A mesma, já foi inclusive mencionada por Marcelo Nunes no post Mapeando Requisitos em Projetos Scrum.

Espero que de alguma forma, nosso exemplo, possa ser útil a vocês, para que possam tentar aplicá-lo em seus projetos ou que ao menos possa servir de referência para que apliquem suas ideias em seu ambiente de trabalho e com a cooperação dos colegas possam construir soluções para seus problemas. Se você ainda não conhece bem o Scrum, consulte os seguintes links: Scrum em 10 minutosHistórias de Usuário

O que descrevemos nas próximas linhas, como uma abordagem, surgiu naturalmente durante o projeto e foi sendo aprimorado, com o simples intuito de garantir que as estórias selecionadas para a próxima sprint fossem compreendidas de maneira uniforme por toda a equipe, e atingindo esse objetivo outros benefícios eram proporcionados, como: Diminuição do número de defeitos, maior satisfação do cliente, melhor comunicação entre os membros da equipe, entregas realizadas no prazo correto, além de poder servir como guia para novos integrantes da equipe, entre outras vantagens.

A partir do momento em que as estórias haviam sido selecionadas para a nova sprint, os seguintes passos eram iniciados:

  1. Detalhar estórias da sprint 
  2. Discutir o PPT com toda equipe
  3. Implementação da estória
No passo 1, as estórias selecionadas eram descritas através de slides, seguindo a prioridade estabelecida entre as mesmas. Desse modo as mais importantes eram liberadas com maior antecedência para as etapas seguintes. O slides deveriam ser simples e diretos, descrevendo o objetivo central da estória, geralmente continham esboço da interface e informações a respeito do escopo.
Abaixo, exemplificamos o uso dos slides para uma estória fictícia, descrita da seguinte forma: “Como um administrador do blog eu quero saber quais os posts mais acessados para que possa analisar o perfil dos visitantes.”

Já o passo 2, consistia de uma reunião com todo o time, onde o responsável pela elaboração do PPT explicava o funcionamento da estória. Sendo este o momento mais importante da nossa abordagem, o qual permitia um entendimento mais profundo da necessidade do cliente. Durante a reunião todos interagiam procurando esclarecer os detalhes que envolviam a estória, seus possíveis impactos em outras funcionalidades previamente implementadas, além de como a mesma deveria se comportar em determinados cenários.

Ao final da reunião, normalmente algumas mudanças no PPT eram realizadas em razão dos pontos levantados, e a partir desse momento o passo três podia ter continuidade, tendo agora como base também as informações disponíveis no PPT, facilitando o trabalho de desenvolvedores e testadores, através da diminuição da quantidade de retrabalho causado pelo diferente entendimento das estórias.

A abordagem utilizada por nós, atingiu o objetivo do projeto, garantindo que as necessidades do cliente fossem compreendidas pelo time e desse modo proporcionando entregas de maior qualidade. É importante, também, ressaltarmos que o fundamental para o sucesso da abordagem está diretamente ligado a troca de ideias e ao comprometimento com a qualidade, sendo o PPT apenas uma forma rápida e ágil para apoiar essa comunicação.

E o que não podemos nos esquecer, é que a utilização, melhoria e adaptação dos processos deve ser um ato contínuo, onde as características do projeto e das pessoas que fazem o mesmo precisam ser levadas em consideração.

Ficou interessado na abordagem proposta? Caso haja qualquer dúvida ou dificuldade ao tentar aplicá-la em seu ambiente de trabalho, entre em contato conosco.

Os desenvolvedores podem testar seu próprio código?

Por esses dias, estive relendo os posts sobre como são conduzidas as atividades de testes no google, entre outras coisas eles falam sobre os papéis, funções e de que maneira a qualidade de software é conduzida dentro da empresa.

No terceiro post da série, diversas afirmações chamaram a minha atenção e valem a nossa reflexão:

“Who better to do all that testing than the people doing the actual coding? Who better to find the bug than the person who wrote it? Who is more incentivized to avoid writing the bug in the first place?”

A partir dessa afirmação podemos ver que estamos passando por uma grande transição na engenharia de software. Onde há vários anos as empresas dão uma ênfase cada vez maior aos aspectos relacionados à qualidade de software e diversas estratégias surgiram e vêm sendo utilizadas para a organização das equipes e divisão das tarefas.

Porém, o que mais me chama atenção nessa primeira afirmação é como a idéia a que estava acostumado, de que precisamos de pessoas com dois perfis diferentes para testar e desenvolver um software está ficando ultrapassada.

Make it or Break it

Cada vez mais precisamos unir as duas disciplinas que se completam para assim entregar produtos de maior qualidade.

Claro, que para que isso aconteça é necessária uma mudança cultural e comportamental. Abandonarmos os antigos conceitos de que desenvolvedores não conseguem enxergar as falhas em seu próprio código, não gostam e não querem testar e tornar tudo em uma única tarefa.

Diversos benefícios podem emergir dessa tendência, como: detecção de defeitos cada vez mais cedo, maior liberdade para o engenheiro de teste focar em aspectos não funcionais, fluxos de integração e outros pontos que fogem a unidade do desenvolvedor, etc.

  “quality is more an act of prevention than it is detection”

Desse modo, técnicas como o TDD podem ser excelentes caminhos para eliminar essa separação entre testes e desenvolvimento. Ajudando a tornar a qualidade cada vez mais um ato de prevenção do que detecção.

” Testing must be an unavoidable aspect of development and the marriage of development and testing is where quality is achieved”

É óbvio, que existem diferenças entre os diversos tipos de projetos e na realidade de cada uma das empresas, onde cada um possui necessidades diferentes as quais precisam ser avaliadas e planejadas.

Está cada vez mais claro o caminho para produzirmos softwares de maior qualidade, testes e desenvolvimento como uma só tarefa, apresentando um grau de automação cada vez maior. Para seguirmos esse caminho várias mudanças são necessárias tanto nas pessoas, como nos processos e ferramentas.

E vocês o que acham? É esse o caminho a ser seguido?

Como testar quando o software não tem botões?

Mencionei anteriormente da importância, para uma pessoa que trabalha com testes de software, de se ter conhecimentos sobre como desenvolver e ter uma visão do ambiente em que o software opera. Tais conhecimentos podem ser considerados facultativos para diversos profissionais de teste, mas em certos casos se tornam obrigatórios.

O que acontece, por exemplo, quando não existe uma UI para testar? Este cenário acontece quando o software desenvolvido trata-se de uma API (Application Programming Interface). O teste de API requer o desenvolvimento de uma aplicação que simule o uso real das chamadas.

Uma vez que se trata de testes de API, Josh Poley menciona que muitas técnicas diferentes serão sugeridas, dependendo do testador. Entretanto, o mesmo apresenta uma situação que funcionou bem para os testes do Sistema Operacional do Xbox.

Participei de dois projetos em que aplicações eram desenvolvidas para que o produto principal pudesse ser testado. No primeiro, o produto desenvolvido continha implementações de JSRs para um emulador de J2ME. Nos testes, então, eram criadas aplicações J2ME, que tinham a proposta de avaliar as classes definidas em cada especificação.

No outro projeto, foi criada uma API para comunicação com determinadas impressoras. Nesta aplicação, uma das funcionalidades era o envio de uma linguagem intermediária para API, que gerava um comando (PCL / PJL / HP-GL) correspondente e mandava para impressão. Para tal funcionalidade, era necessário o conhecimento das entradas e saídas esperadas (tanto da linguagem intermediária como do comando enviado para impressora). Os testes foram desenvolvidos em C++, simulando uma aplicação real que utilizaria a API.

Mas antes de começar a desenvolver os testes, é necessário dedicar um tempo para o planejamento do que será testado. Dependendo da complexidade da aplicação, um documento de testes pode auxiliar nessa atividade.

Já na criação dos testes, deve-se pensar como o ambiente pode ser preparado para identificar certas situações, como por exemplo, o uso de um arquivo corrompido ou a ausência de conexão de rede. A atividade de forçar falhas, em uma aplicação, pode ser considerada bem interessante. Uma vez que se detêm conhecimento para criar testes que forcem defeitos, o entusiasmo é enorme. Mas atenção, a prioridade deve ser dada ao fluxo principal, primeiro crie testes para as situações em que se espera que o software funcione.

Alguns cenários são mais complexos de serem testados. Casos como atualização de estruturas de dados, modificação de certos recursos e chamadas da API que não possuem retorno, necessitam de alguma forma de verificação. Uma função que não tem retorno, por exemplo, deve mudar de alguma forma o estado da aplicação. Em um teste a uma chamada que remove algum valor de uma lista e não tem valor de retorno, pode ser necessário usar de chamadas para percorrer a lista e verificar os valores, tendo assim certeza de que o valor solicitado foi removido.

James Whittaker e Alan Jorgensen relataram que, em teste de API, alguns problemas interessantes para os testadores são: garantir que a aplicação varia os parâmetros das chamadas de modo a expor possíveis falhas; gerar combinações interessantes de parâmetros; configurar o ambiente externo e os dados internos que afetam a API; variar a seqüência de chamadas da API para exercitar de várias formas as funcionalidades.

No blog de testes da Google, em um dos posts é mencionado que testes de chamadas isoladas da API não conseguem simular o cenário real. Para uma calculadora, testar as chamadas isoladamente pode ser efetivo. Mas para aplicações em que a ordem das chamadas pode interferir no resultado, devem ser testadas tanto as chamadas isoladas como combinações entre elas.

A organização dos testes é importante para facilitar a manutenção. Códigos bem escritos podem auxiliar no entendimento da equipe sobre o que está sendo testado. Então, caso possível, o uso de um guia com padrões de codificação é bem vindo. Dessa forma, a equipe irá se acostumar a escrever de forma que todos entendam. Quando o cenário de teste é complexo, a documentação no código ajuda a entender do que se trata.

A qualidade do código de teste pode influenciar diretamente na qualidade do produto testado. Erros nos testes podem omitir falhas importantes nos produtos.

Mas quem vigia os vigilantes? Quem testa o código de teste? Como garantir que os testes estão corretos? Quando se escreve códigos de teste, a atenção deve ser dobrada. Com isso é importante a cultura de revisão de código, programação em pares ou alguma outra forma que auxilie na diminuição de erros. Criar log da execução pode ajudar na identificação de problemas.

Pelo fato de os testes serem parecidos, a prática do copy & paste vai parecer tentadora. Mas evitar esta prática pode evitar vários problemas. Recomendo uma apresentação de Borba, para ter a visão dele sobre código duplicado. E, se em algum momento achar que o código de teste pode melhorar, melhore!

Nos projetos que trabalhei, a padronização dos testes foi um ponto importante, para transferência de conhecimento aos que precisavam entender o que estava sendo testado. Para o emulador de J2ME, foi criado um framework no qual as aplicações de teste deveriam ser desenvolvidas. Em ambos os projetos, certos testes precisavam de uma confirmação visual, mas ainda assim foi possível avaliar tais cenários, só demandava uma confirmação do testador. Nos testes foram contempladas variações de parâmetros e combinações de chamadas. Também foram utilizadas algumas técnicas de teste como pairwise, classe de equivalência, valores limite, etc. Os testes eram documentados e tanto o documento como o código passavam por um processo de inspeção. Sempre que possível, os testes eram projetados para necessitarem da menor intervenção humana, realizando o maior número de testes ao apertar um único botão.

Incentivando uma briga

Por muitas vezes refleti se as pessoas, que trabalham com testes de software, devem ter habilidades de desenvolvimento. Não nego que possuir conhecimento do negócio é necessário para o profissional da área de testes. Mas, entender sobre a estrutura do que é testado, que antes de tudo é um software, também é importante.

James Whittaker, que já trabalhou com testes na Microsoft e atualmente trabalha na Google, escreveu um livro que demonstra algumas técnicas para se “quebrar” um software. As falhas exibidas são bem interessantes, e possíveis de serem atingidas em abordagem caixa-preta.

Como testador, pude experimentar algumas técnicas mencionadas no livro. Vou relatar sobre a aplicação de uma dessas técnicas em um projeto que trabalhei. No software desenvolvido, um usuário poderia criar menus que seriam acessados através de um servidor. Quando acessado um determinado item do menu, uma ação seria acionada. Uma das ações disponíveis era verificar o usuário que estava acessando o item e direcionar para outra ação.

Na imagem acima, quando um usuário A acessa o ITEM 2 do MENU, a ação 2 é chamada. Uma vez que a AÇÃO 2 identifica que é o usuário A, a AÇÃO 3 é acionada. Olhando para este exemplo, tendo em vista que uma ação de decisão envolve processamento, já é possível reproduzir a falha. A idéia é forçar um processo a ser executado várias vezes. Imagine uma ação parecida com a AÇÃO 2 no lugar da AÇÃO 3, apontando para AÇÃO 2 quando o usuário for A.

Agora, imagine o usuário A acessando o MENU pelo servidor. Ele tenta acessar uma vez o ITEM 2, vai para a AÇÃO 2, que o direciona para AÇÃO 3. A AÇÃO 3 o manda de volta para AÇÃO 2, que o manda mais uma vez para AÇÃO 3. Vai para AÇÃO 2… Deu pra entender que nunca vai parar? Bastaram algumas requisições feitas com o usuário A para ser necessário reiniciar o servidor, pois o serviço havia ficado indisponível.

No livro “How to Break Software”, James Whittaker demonstra falhas que podem ser provocadas tanto pela interface com o usuário como através de outro software. Ele ainda fala que muitos têm dificuldade em entender o ambiente em que o software funciona. Na experiência que tive com testes de software até o momento, me deparei com vários testadores que somente interagiam com a porção de botões, ou outros componentes visuais, que lhe eram oferecidos através de especificações. Tais testadores desconsideravam sistema de arquivos, componentes externos, sistema operacional, rede, relacionamento com outras funcionalidades, etc.

Com esse post, pretendo incentivar uma briga.

Testadores, aprendam onde os desenvolvedores deixam os bugs. Acreditem, boa parte das falhas de um software estão no código! Estudem formas diferentes de se encontrar os problemas. Entenda o sistema operacional, analise o código fonte do software, entenda de redes, estude as falhas dos frameworks utilizados, avaliem a segurança do produto (não usem a desculpa de que segurança é um requisito não-funcional), estudem tudo o que for válido para certificar a qualidade do software.

Desenvolvedores, vocês vão deixar? Vejam o que esses testadores poderão fazer com o código produzido por vocês! Se aproximem do pensamento dos testadores, vejam como eles agem. Desenvolvam o senso crítico. Dêem seu máximo para que falhas comuns não aconteçam. Estudem onde os bugs aparecem para poder evitá-los!

No final, essa disputa saudável, entre evitar e encontrar os bugs, é uma forma de se obter um software de qualidade e uma equipe em evolução contínua.