Muitos acreditam que testes de performance fundamentam-se apenas na criação e execução de scripts de teste automatizado em ferramentas de simulação de usuários virtuais, como o JMeter, quando, na verdade, isso equivale a algo por volta de 10% de todo o esforço dedicado a atividade de testes de performance. Ao analisar a distribuição de todo o esforço nessa atividade, vemos que os pontos que demandam mais atenção estão voltados a atividades relacionados ao que acontece antes e depois da execução do que se é automatizado. Nesse post, descrevo dicas de o que se deve fazer antes ou depois da execução de um teste de performance.

Antes de executar testes de performance

Compreender como os usuários consomem seu sistema

A compreensão de como a aplicação se comporta se dá através da análise da utilização dela por seus usuários. Em casos como esses, relatórios podem ser extraídos de ferramentas como, por exemplo, o Google Analytics, onde o comportamento dos usuários podem ser identificados com base na utilização da aplicação.

Compreensão da arquitetura de software

A composição da arquitetura influencia diretamente em testes de performance. É através dela que conseguimos entender, por exemplo, como uma requisição enviada pelo usuário é trafegada pela aplicação através de todos os pontos que compõe sua estrutura. Ela também ajuda a definir o que, onde e quanto teremos de carga sendo atribuída a partes do sistema. Por fim, nos ajuda a definir como nossos testes serão construídos e exercitados.

Monitoramento

De nada adianta conseguir exercitar a aplicação se não for possível medir a forma com que ela é utilizada. Nesse contexto, para que seja possível medir, é necessário que se defina o que e como. Por exemplo, ao planejar um teste de performance, geralmente utiliza-se ferramentas conhecidas como Profilers softwares capazes de monitorar a forma com que a arquitetura está sendo consumida, um bom exemplo seriam seus componentes, como o Banco de Dados, Servidor de Aplicação, Servidor Web e itens de hardware como memória, processamento e I/O. Ao monitorar, conseguimos ter claro como eles se comportaram durante a execução dos testes de performance.

Depois de executar de testes de performance

Resultados obtidos pelos usuários virtuais

As ferramentas de teste de performance simulam a execução de cenários de teste por usuários virtuais simultâneos. Cada usuário, ao executar o cenário, envia requisições à aplicação e registra informações da resposta como tempo de resposta, tempo de conexão, tempo de latência, entre outros. Essas informações precisam ser analisadas minuciosamente. Diferentes de testes funcionais comuns, testes de performance não demonstram claramente o que são falhas ou sucessos, uma vez que a definição de sucesso leva em consideração análises estatisticas, medidas de tendência ou mesmo percentuais de aceitabilidade. Os gráficos costumam não ser auto-explicativos, por isso, quem os lê precisa ter destreza para conseguir enxergar além dos números.

Avaliar logs do monitoramento da arquitetura

Os resultados obtidos através da leitura dos resultados dos testes de performance trazem informações relevantes, mas ao mesmo tempo superficiais relacionadas ao comportamento da aplicação e sua arquitetura. Superficiais porque demonstram apenas uma das camadas de análise contida em toda a composição do teste, que é a perspectiva do usuário, ou seja, sua sensação de tempo de espera de o que se requere.

Há uma falha de performance nessa aplicação, pois vejo que o login leva mais que 6 segundos para acontecer.

Para conseguir ir além, é necessário também entender onde está o gargalo e para isso, preciso analisar como a aplicação e sua infraestrutura se comportaram durante os testes. Por exemplo, o login poderia chamar uma API terceira para buscar seu estado, um banco de dados relacional que não estava bem estruturado e escrever os logs em um sistema de arquivos mal dimensionado.

Qual deles foi responsável pelo atraso de 6 segundos?

Em dúvida quanto a pergunta? Uma coisa é certa, a resposta não está dentre os contadores de tempo de resposta, mas sim, nos monitores de cada um dos pontos que você adicionou a sua arquitetura enquanto falávamos de o que vem antes da execução dos testes de performance.

Interpretação e parecer técnico

Outra característica muito particular dos testes de performance é a forma com que os resultados da execução dos testes são apresentados. Comparando-se com testes funcionais, nos quais temos resultados determinísticos, com resultado binário de passou ou não passou. Em testes de performance temos resultados que tem sucesso e que podem ter mais do que um resultado de tempo de resposta, isso porque há variação dos resultados dependendo da forma com que a aplicação ou infraestrutura estão sendo consumidas no momento da execução. Logo, o resultado dos testes também é apresentado de forma distinta, por exemplo, através de análises estatístias e correlações entre variáveis. Em um outro post, comentei sobre um idicador muito utilizado, o Percentil (leia aqui), que é muito útil para explicar a usuários não técnicos, resultados técnicos.

Podemos entender agora a algumas das atividades que existem antes e depois da execução dos testes de performace, ao avaliar o percentual de esforço que elas tomam, poderia dizer que perfazem um total de 50 a 60% de todo o esforço relacionado a execução de um projeto de testes de performance. Isso porque ainda há outras atividades bastante importantes a serem realizadas como o Planejamento dos Testes, da Massa de Dados, da subida das versões de uma aplicação, da definição dos critérios de aceitação, do fechamento da execução e versionamento dos testes, dentre outros.

Esse post nos mostra que para conseguir atingir resultados relevantes ao executar testes de performance é necessário pensar em mais que apenas a ferramenta a ser utilizada para gravar, refatorar e executar os testes que simulam usuários virtuais e nos revela algumas das atividades que se fazem necessárias antes e depois da execução dessa prática.

E você, já executou testes de performance, quais foram seus principais desafios e conquistas?

Sabia que eu envio mensagens gratuitas todos dias para meus seguidores no Telegram? Fiquem atualizados e aprendam mais sobre testes e qualidade de software inscrevendo-se no Canal do Júlio no Telegram:

Canal do Júlio

Links de referência mencionados nesse post:

• Percentis e sua importância nos testes de performance
• Apache JMeter™
• Monitor, Debug and Improve Your Entire Stack
• 5 Google Analytics Features You Should Be Using

Testes de Performance não são tão simples quanto usar o JMeter was originally published in Revista eQAlizando (antiga Revista TSPI) on Medium, where people are continuing the conversation by highlighting and responding to this story.

A quinta edição do garoaQA foi, com certeza, uma das melhores. Juntou um público completamente novo no evento que aconteceu em um dos locais mais inovadores de setor bancário, o inovaBra, do Bradesco. Confira nesse post como foi o meetup!

O inovaBra é um movimento criado para promover a inovação dentro e fora do Bradesco. Uma missão que cumprimos por meio de um ecossistema de programas que abrangem aquisições estratégicas, inovação interna e co-inovação.

Foi com a colaboração da Mayra Marques e da Luciane Ono, hosts, que conseguimos facilitar a quinta edição do garoaQA, um evento onde os participantes são as estrelas. Além delas, tive a ajuda de um grande amigo, parte do meu time na Capco, o Antônio Montanha, que foi mediador dessa edição. Uma vez que o co-founder do meetup, Well, está se preparando pro casório (felicidades, meu amigo!).

O garoa sempre inicia com a seleção de temas pelos próprios participantes. São eles que, ao chegar no evento, propõe quais temas desejam abordar na noite, de forma espontânea, com uso de post-its.

A próxima etapa do evento é o agrupamento de temas. Todos são convidados a olhar os temas propostos e então agrupar por categorias quais são semelhantes.

Após o agrupamento, é hora de votar nos temas. Cada participante tem o direito de votar em um agrupamento. Os mais votados são discutidos em rodas de conversa que possuíram, nessa edição, 6 pessoas e mais um mediador.

Os assuntos mais votados da noite foram, em ordem de maior número de votos: Ágil, Devops e Carreira. Abaixo descrevo um pouco sobre o que eu, como mediador, anotei do que foi discutido nas rodas das quais mediei.

Ágil

• Dailies muito longas
• Pensamento tradicional impactando o ágeis
• Faseamento para implantação de projetos ágeis
• Como engajar todos colaboradores de empresas terceiras
• Gestores virando parte do time
• Estimativas de teste tradicionais no inicio dos projetos individualmente ou poker planning
• Formas diferentes de pontuação diferentes
• Uso de POCs antes das estimativas
• Liderança em times ágeis

Devops

• Versionamento de código
• Jenkins para orquestrar as atividades
• Plugins de ajuda aos processos
• Devops manual, vários problemas relacionados a interação humana
• Pipelines automatizadas
• Diferenças entre versões de branches
• Como pipelines funcionam, quando quebram, quando notificam os usuários, etc.
• Jira como ferramenta para integração
• Microserviços e deploy contínuo
• Docker para evitar o “na minha máquina funciona”

Carreira

• Somos mais que apenas testers
• QAs como análise e garantia de código
• O testador precisa ir além dos testes manuais

Sobre o garoaQA

O garoa é um evento gratuito e aberto a comunidade. Se há um espaço bacana em sua empresa, vocês podem patrocinar um coffee para os participantes e abrir para um público de 25 a 40 pessoas, entre em contato (contato.garoaqa@gmail.com). Estamos procurando empresas que desejam viabilizar a discussão e crescimento da comunidade de testes!

Links importantes

Fotos do garoaQA #5:

Fotos - GaroaQA (São Paulo) | Meetup

Junte-se a nós:

GaroaQA (São Paulo, Brasil)

O garoaQA é um meetup organizado pelo Wellington Avelino e eu. Um evento democrático e gratuito, onde os participantes são os protagonistas. Eles escolhem os assuntos, agrupam, votam e discutem, numa troca de conhecimentos espontânea e baseada em experiências reais. Nossa última edição foi gentilmente hospedada pela DafitiGroup, leia abaixo como foi.

A DafitiGroup é formada por grandes empresas, como a Dafiti, Kanui e Tricae. O escritório da Dafiti fica na Barra Funda e lá foi a sede da quarta edição do garoa. Um lugar gigante, sensacional. Tivemos a presença do Diego Ulrich e do Victor Cruz como sendo nossos hosts mediadores, foi demais!

No garoa, tudo começa com a proposta dos temas, de forma espontânea por cada participante. Depois disso há o agrupamento dos temas e depois a votação.

Depois disso, damos início as rodas de conversa, que ocorrem simultaneamente sobre os assuntos escolhidos. Que dessa vez foram: Testes Integrados, Testes de API e Devops.

Houveram 4 rodas na edição da Dafiti. É interessante, porque fazemos a dinâmica de alternar as rodas, pedindo que os participantes mudem de rodas. A cada nova formação, vemos pessoas com características e posicionamentos diferentes, logo, cada roda traz discussões e abordagens diferentes.

Durante as rodas de conversa os mediadores de cada roda anotam os conhecimentos adquiridos durante as conversas e no fim faz uma consolidação do conhecimento. Abaixo estão as notas das rodas em que eu fui mediador.

Roda 1: Testes de APIs

• Quais ferramentas os participantes usam: ReadyAPI e SoapUI e Postman
• BDD como definição do cenário de testes
• Healthy check com Runscope
• Testes de Performance com Rational Performance Tester
• Clusterização para execução de testes de performance de forma distribuída com JMeter
• Técnicas de Teste que usam para projetar testes de API: Mindmaps e Tabelas de Decisão
• Analistas de Negócio definem o contrato? Em alguns times, sim.

Notas:

• https://medium.com/assertqualityassurance/como-construir-e-testar-uma-api-em-java-utilizando-o-postman-baae69d8b8aa
• https://medium.com/assertqualityassurance/automatizando-sua-api-com-postman-64a72185e1e6

Roda 2: Testes de Integração

• Muitas integrações em fluxos, com diversos riscos, como: dados de terceiro, comunicação
• Longos prazos pra execução de testes integrados
• Dificuldades de tracking da comunicação entre serviços
• Integração entre App e APIs
• Monitoramento: via Log, Charles Proxy e Kibana
• Ambientes de teste não isolados tornam a manutenção dos dados uma situação crítica, uma vez que qualquer um pode alterar os dados
• Mocks dinâmicos podem solucionar os problemas com sistemas muito dinâmicos, adicionando endpoints sob demanda com respostas pre-planejadas
• Em Mocks, apenas contratos não são suficientes, precisamos tomar cuidado com os dados esperados em cada resposta
• Em terra de testes integrados, quem sabe fazer a massa é rei!

Notas:

• Testes integrados revelam problemas de comunicação!

Roda 3: Devops

• Escolha de ferramentas é muitas vezes um problema
• Processos podem impedir a evolução
• Gargalos por falhas de planejamento
• QAs que participam juntos com os demais para determinar a forma de arquitetura da aplicação e pipeline
• Devops para ambientes de QA e seus riscos: custo, complexidade, etc.
• Lentidão dos testes durante o CI ou CD

Obrigado a todos que participaram, são vocês que fazem o garoa ser um evento que vale a pena!

O garoaQA é um meetup que tem o objetivo de incentivar o compartilhamento de experiências reais através de rodas de conversa. Todos os temas são escolhidos, agrupados e votados pelos próprios participantes. O lugar onde o meetup acontece é cedido por empresas que incentivam esse tipo de evento. Como diz o título, essa edição do garoa foi gentilmente sediada pelo iCarros, um lugar sensacional!

O garoa se inicia com os participantes sugerindo quais temas eles gostariam de discutir na noite. Isso é feito com a escrita dos temas em post its.

Todos os temas sugeridos são colados em uma parede para que todos os participantes possam ter acesso e também opinar sobre os temas escolhidos. É um momento bem bacana, onde a galera começa a ver quais temas foram escolhidos pelos demais participantes.

O número de temas escolhidos sempre é bem grande, por isso, depois da sugestão de temas a galera precisa agrupa-los, pois assim podemos escolher de forma mais simples quais serão aqueles grupos a serem discutidos no dia.

Os grupos mais votados nessa edição foram Devops, Data Science e Ferramentas de Teste. Temas bem interessantes, que geraram discussões muito legais. O garoa incentiva o compartilhamento de experiências reais ao invés daquelas retiradas de literaturas, além do pensamento crítico sobre os temas e tentativas de identificar como a área de QA atuaria em cada um dos temas.

Tivemos em torno de 25 participantes nessa edição. Eles foram divididos em 4 rodas de conversa. Cada um dos três temas mais votados foram discutidos simultaneamente em cada roda de discussão. Basicamente, 20 minutos de discussão e outros 10 minutos de consolidação do conhecimento.

Cada roda teve um mediador, dois deles eram hosts do próprio iCarros, o James e o Paulo. Além deles, o Wellington Avelino e eu. Como mediadores, nossa missão foi de provocar, de incentivar e de ajudar no desenrolar das discussões. As estrelas, na verdade, foram os próprios participantes, que compartilharam suas experiências com as rodas.

Claro, os momentos mais legais, certamente são os das rodas de conversa. Mas rolou também um momento de networking, uma parada pra água e pra bater papo com a galera.

No final, tivemos um sorteio de camisetas da StackOverflow patrocinado pelo Frederico Moreira.

Se você ainda não faz parte do Meetup do garoaQA, clique aqui e torne-se parte, assim você ficará a parte de todas as atualizações e novas edições. O garoa é um meetup aberto a comunidade. Tem um espaço na sua empresa que poderia abrigar de 20 a 40 pessoas e quer levar o garoa para ai? Mande um e-mail (contato.garoaqa@gmail.com) pra gente e vamos conversar, seria bem legal!

Em nome do garoa, agradeço a todos os participantes que estiveram lá na noite prévia a um feriadão prolongado e também a toda a galera do iCarros que abriram o espaço e que participaram como mediadores, foi demais!

Veja todas as fotos aqui ;)

Até a próxima!

Há uns meses atrás tive a oportunidade de conhecer um modelo de evento bastante diferente do que eu havia visto até então. Ao invés de ter palestrantes falando sobre alguns temas, havia participantes, discutindo e falando sobre como aplicaram ou viram a aplicação prática, de temas comuns relacionados a tecnologia. Foi o Matheus Marsiglio, organizador do FrontUX, quem me descreveu como organizar um evento nesse modelo e deu 30 milhões de dicas sobre. Desde então, quis muito ter a oportunidade de fazer algo assim na área de qualidade de software.

Conheci o Wellington Avelino num Meetup, e desde então não paramos de se falar. Ele comentou que não haviam mais meetups rolando constantemente em São Paulo, e propus a ele fazermos um evento estilo FrontUX, com card sorting e rodas de conversa. E ele topou. Falei então com a Mari e o Emerson, do Moip. Eles curtiram a idéia e abriram um espaço sensacional do Moip para realizarmos o evento, além disso, toparam em ser moderadores. O Well e eu montamos uma estrutura modelo que, inclusive, pode ser utilizada por qualquer pessoa que deseja montar um evento semelhante.

Os participantes se inscreveram a partir de um formulário que o Well criou, tivemos 40 inscritos. 30 confirmaram a participação e 19 compareceram no evento. Cada um dos 19 participantes, ao chegar no evento, escreviam temas que gostariam de discutir e colavam em uma das paredes da sala.

A segunda parte do evento foi composta do agrupamento dos mais de 30 temas que foram elencados pelos participantes. Foi um momento bem divertido, onde os próprios participantes relacionavam quais temas eram semelhantes. Essas duas etapas baseiam-se numa técnica de UX chamada Card Sorting.

Houveram, mais ou menos, 10 temas. Havíamos planejado trabalhar 4 temas. Por isso, fizemos uma votação para decidir quais seriam os temas a serem discutidos. Cada participante podia votar uma única vez, em um grupo de temas. Os temas mais votados foram Integração Contínua, Tradicional versus Agile testing, Carreira e Evidências de Teste.

Uma vez que tivemos os agrupamentos de temas escolhidos, começamos a fazer as Rodas de Conversa. Uma metodologia de aprendizado coletivo que visa dar a oportunidade de conversa entre os participantes. Cada roda tinha um moderador, no caso, Well, Mari, Emerson e eu. Nós fazíamos perguntas que eram discutidas entre os participantes de cada roda e ajudávamos eles, facilitando as discussões. Tentando ao máximo não influir, nem incliná-los aos nossos conhecimentos, mas sim, deixá-los brilhar, compartilhando seus conhecimentos e reconstruindo conhecimentos antigos.

As rodas foram muito produtivas, a galera colaborou muito dando exemplos sobre como os temas refletiam no seu dia a dia profissional. Como cada tema foi tratado nas empresas em que trabalham ou mesmo esclarecendo dúvidas ou discutindo se os temas realmente fazem sentido. Todos sentiram-se muito participativos, pois puderam colaborar e ao mesmo tempo aprender com os outros participantes. Como moderadores, pudemos auxiliar nas discussões ou fazer perguntas chave, levando-os a olhar de outras perspectivas sobre o tema discutido.

Após duas rodas de conversa, teve um coffee break patrocinado pelo Moip, onde a galera pôde se aproximar mais. Foi demais, pois vimos muita gente que não se conhecia fazendo conexões e falando sobre qualidade de software.

Conseguimos fazer rodas de conversa para abordar 3 dos 4 temas, e o retorno foi muito bom. Faremos um post em breve com as anotações que cada moderador fez das rodas de conversa que facilitaram. Assim, poderemos compartilhar com vocês sobre o que discutimos e qual foram os principais tópicos que notamos.

Ao fim, uma foto com a galera toda que participou dessa edição do GaroaQA.

Novamente, em nome do Well e meu, agradeço a Mari, Emerson e Moip, por abrir as portas para a primeira edição do GaroaQA. Também, agradecemos aos participantes, que fizeram uma noite inesquecível, com seus insights e experiência. Foi sensacional! Se sua empresa quer sediar um GaroaQA, com a condição de ser um evento aberto à comunidade, entre em contato conosco para conversarmos e agendar um evento juntos.

Nos vemos no próximo GaroaQA, até lá!

Veja todas as fotos:
http://bit.ly/GaroaQAFotos

Faça parte:
https://www.meetup.com/pt-BR/garoaqa/

Testadores que influenciaram o início de minha carreira

2008 foi o ano em que iniciei minha carreira como testador. Nessa época o conhecimento de testes ainda estava concentrado em certificações de teste, cursos, automação de testes e no livro base de conhecimento em testes de software. Ao começar estudos sobre certificações internacionais, conheci Rex Black e Glenford Myers, dois profissionais que ficaram famosos por explicar de formas diferentes o custo do bug. Rex Black continua escrevendo artigos e é um dos representantes do ISTQB no mundo.

Naquele tempo, no Brasil, havia duas pessoas muito relevantes no tocante a cursos, Cristiano Caetano e José Correia, diretores das empresas Qualister e Iterasys, respectivamente. Cristiano com treinamentos e José com cursos. Ambos palestravam e escreviam bastante, mostrando mais sobre testes de software. Na época escolhi a Qualister e tive uma relação de amor e admiração, o que me fez sonhar em trabalhar lá, sonho que realizei posteriormente. Cristiano foi o maior influenciador e o mentor da minha carreira, aprendi com ele que aprender e compartilhar conteúdo é a melhor forma de aprender e atingir seus objetivos.

Eu morava no interior de São Paulo, não havia testes formais por lá. Por isso, precisava de apoio para conseguir implementar essa atividade na empresa na qual eu trabalhava. Foi ai que entrou a Marcela Coutinho, minha antiga diretora. Ela acreditou em mim e no meu projeto e junto com uma grande amiga, Fabiana Correia, montamos a primeira equipe de testes da região.

Elias Nogueira era a maior referência em automação de testes e também era um dos maiores compartilhadores de conteúdo voltado a essa atividade, ainda continua compartilhando conhecimento, mas agora, abrangendo conhecimentos conceituais e técnicos. Realizei o sonho que tinha de conhecer ele quando trabalhamos juntos na Qualister. Um período onde aprendi muito sobre automação e como ser mais técnico. Uma outra pessoa bastante importante nesta época era o Eduardo Souza (Dudú), que organizava o evento TestDay. Compartilhava conteúdo e palestrava falando sobre automação de testes. Outra pessoa que também compartilhava conteúdo desse segmento era o Camilo Ribeiro, que escreveu muitos artigos falando sobre automação de testes e sobre testes de performance com JMeter. Conheci também nessa época o Leonardo Molinari, pois também escrevia, e continua escrevendo, literatura referente a tecnologia e testes de software.

Outra vertente forte nessa época era a ALATS, uma associação que oferecia certificação em testes de software para a america latina. Alguns dos responsáveis por ela escreveram um livro chamado “Base de Conhecimento em Testes de Software” que serviu como conhecimento em testes para muitas empresas que iniciaram naquela época, dentre os autores, o que continua ativo na comunidade de testes é o Aderson Bastos. Eles costumavam promover um evento chamado BRATESTE. Foi em uma edição desse evento que conheci Lee Copeland, Janet Gregory e Martin Pol. Todos muito envolvidos com teste de software e que continuam escrevendo sobre. Lee falando sobre mindset do testador, Janet como uma das principais disceminadoras dos testes dentro do contexto ágil e Martin propondo modelos de teste tradicional como um modelo de maturidade, o TMap.

Duas pessoas começaram a influenciar o contexto dos testes tradicionais e a ensinar técnicas e mindsets completamente diferentes dos que eram conhecidos como absolutos, esses eram James Bach e Michael Bolton. Eles pregam o teste orientado ao contexto, técnicas ágeis e liberdade de criatividade ao testador.

Influenciadores da nova geração

Alguns testadores ganharam relevância depois de 2010, eles ajudaram e continuam ajudando a disceminar novas crenças e mindset sobre como a área de testes é interpretada. São pessoas que produzem bons materiais e despertam discussões muito produtivas.

Samanta Cicilia é muito ativa na comunidade de testes, já vi palestras, artigos e também eventos que ela organizou. Ela também se mostra bastante ativa na questão da inclusão de mulheres na tecnologia, com várias iniciativas ligadas a esse tema. Junto ao Leonardo Galani, organiza o Agile Testers Conference, um evento voltado a disseminação de conhecimento em testes de software. Galani é uma pessoa bastante pragmática e que tem uma visão bastante contemporânea sobre o testador e seu papel em uma equipe de desenvolvimento. Tem argumentos fortes e seus textos e palestras são muito bons.

Outra pessoa que costumava produzir bons materiais e palestras é o Stefan Teixeira. Considero ele um dos testadores mais técnicos que conheço. Ele atuou em muitos projetos legais e ajuda a disceminar conhecimento que ajuda testador ser mais técnico. Quem faz um trabalho semelhante é o Walmyr Filho, que tem escrito muitos posts, e inclusive um livro, sobre automação de testes com frameworks modernos. Além de assumir um papel de Software Engineer com foco em Testes, o que é algo em que acredito muito. Outra pessoa que também vale a pena seguir é o Fredão Moreira, que organiza o Minas Testing Conference, palestra e também escreveu conteúdos voltados a testes de APIs e Microserviços. Por fim, também menciono um amigo que começou a pouco escrever sobre engenharia de software, mas que me influenciou muito nos últimos 6 meses, o Danilo Albuquerque. Ele é Software Engineer, mas desenvolve suas aplicações fundamentando-se em testes automatizados. Isso é inspirador e inovador, por isso, tenho procurado seguir mais desenvolvedores que possuem esse mesmo mindset e recomendo que vocês também o façam.

Agradecimentos

Os objetivos de cada um desses profissionais que foram mencionados certamente é muito variado, mas foi baseado em muitos textos e conhecimentos disseminados por eles o que me ajudou a construir o meu mindset atual. Por isso, deixo aqui meu agradecimento pelo tempo que dedicaram à comunidade de testes e o que conseguiram formar até agora.

O que eu diria a você, leitor, é que compartilhe também seus conhecimentos, para ajudar a formar novos conceitos e práticas em testes de software.

Sucesso, keep writing!

Testadores que influenciaram minha carreira em testes de software was originally published in assert(QA) on Medium, where people are continuing the conversation by highlighting and responding to this story.

Há oito anos atrás, diversas organizações aplicavam (e ainda aplicam), tri ou semestralmente exames a testadores que estavam interessados em demonstrar seus conhecimentos ao mercado para tornarem-se mais atrativos às empresas. O contexto contemporâneo sofreu diversas mudanças, em contrapartida, a maior parte da base de conhecimento em testes proposta por muitas dessas organizações não acompanhou tal mudança. Dado esse contexto, discutiremos se ainda faz sentido preparar-se para certificações em teste de software.

O registro mais antigo que tenho da atividade de testes de software de maneira formal no Brasil é rodeado de certificações e pesquisadores escrevendo livros e artigos com o objetivo de estabelecer como a área de testes poderia ser implantada em empresas de softwares. Além disso, havia uma grande preocupação em quais seriam os papéis a serem ocupados por pessoas testadoras dentro das equipes de desenvolvimento. Lembro-me também que havia uma grande preocupação em dividir e segregar o papel da pessoa que testa frente à pessoa desenvolve. As bases de conhecimento da época (2009) pregavam, dentre outras, essas características. Isso se encaixava muito bem ao que vivíamos naquele contexto, por isso havia uma grande preocupação em adaptar-se a esse modelo de processo e mindset de testes. A comprovação desse conhecimento no nível corporativo, por sua vez, dava-se através da obtenção das certificações.

A obtenção de certificações em testes de software demonstra que você conhece a forma com que um grupo de pesquisadores entende a atividade formal de testar aplicações e sistemas.

A adoção de metodologias ágeis pelas empresas trouxe consigo uma grande mudança no processo, mindset e técnicas de teste. Já não havia mais tempo hábil para especificação formal de testes (criação de artefatos como casos, procedimentos e cenários de teste, por exemplo), no lugar dela passou-se a ser valorizado o teste exploratório, onde a especificação, aprendizado e execução, acontecem simultâneamente durante a validação do software. O testador e o desenvolvedor já não estavam separados, mas sim, trabalhando juntos e compartilhando as atividades que desempenhavam. Ou seja, testadores podem desenvolver e desenvolvedores podem testar. Outra grande mudança foi que os papéis de testador, analista, especialista e líder passaram a ser desempenhados por uma só pessoa, denominada testador (ou analista de QA), capaz de planejar, projetar, especificar, executar e automatizar seus testes. A questão é que mesmo as certificações mais populares continuam pregando um modelo não adaptado a esta realidade em sua base de conhecimento fundamental.

A popularidade que as certificações possuem no contexto de desenvolvimento de software fazem com que muitas empresas continuem requerendo, como pré-requisito para suas contratações, que os testadores possuam as certificações, inclusive quando não seguem o modelo proposto em seu ciclo de vida de desenvolvimento e testes. Por isso, muitos testadores e curiosos continuam buscando certificar-se, motivados pela atratividade ao mercado de trabalho.

Usamos metodologias ágeis, mas procuro testadores que possuam certificações que demonstram conhecimento em processos de testes tradicionais que não se estabelecem no nosso contexto apenas porque a certificação é internacionalmente reconhecida!

O estudo proposto nas bases de conhecimento fundamentais de testes propostas para certificações em teste de software não possuem, em sua maioria, compatibilidade com os processos de teste de software utilizados por equipes de desenvolvimento que fazem uso de metodologias ágeis, por exemplo. Em contrapartida, as técnicas de teste (como as caixas preta e branca) propostas por elas e o formato de gestão de defeitos continua sendo extremamente úteis ao testador, uma vez que estas atividades são desempenhadas com vigor por esses profissionais.

Portanto, a decisão em preparar-se ou não para certificações se dá, na verdade, pelo objetivo que o testador procura nelas. Se busca encontrar em certificações conteúdo adaptado completamente ao contexto atual da atividade de testes, como vimos, essa certamente não será uma boa decisão. Se procura obter conhecimento sobre como o modelo tradicional funciona no contexto de testes, suas técnicas e mindset dos pesquisadores da época, faz sentido estudá-las. Preparar-se para certificações é algo que está relacionado diretamente ao que o mercado requere. Se é um diferencial, certamente obtê-las será algo que poderá ajudar na melhoria do currículo do testador e na sua relevância perante o mercado de trabalho.

[ :) ] Obrigado especial ao Leandro Muto pela revisão deste post!

Em todos estes anos na área de testes de software, entre cursos, palestras, consultorias e mentorings, conheci muitas pessoas muito inteligentes, com vasto conhecimento, cheias de idéias e soluções inovadoras para problemas bastante comuns. Minha pergunta a estas pessoas sempre foi:

– Por quê não escreve sobre isso!?

A resposta, na maioria das vezes, estava relacionada a tentativas de escrita mal sucedidas por não saber por onde começar. Chegamos aqui ao objetivo deste post, mostrar uma forma de estruturar suas idéias e transcrevê-las em seu primeiro post.

Gostaria de convidá-lo a, de fato, escrever um post enquanto faz a leitura deste texto, publicá-lo aqui no Medium e compartilhar o link como resposta a este post.

Bem, o primeiro passo para escrita do seu post deve ser a identificação de um tema do qual você deseja abordar. Esse tema pode se resumir a uma palavra ou uma frase, por exemplo “Cucumber” ou “Escrever testes automatizados em seu idioma”.

O próximo passo é pensar em 3 características interessantes sobre o assunto que você deseja abordar e escrevê-los em forma de frases, por exemplo “Com Cucumber posso descrever o comportamento do software em seu idioma em forma de estórias”, “Ele gera métodos em Ruby a partir de cada passo descrito nas estórias” e “Posso usar o Selenium WebDriver dentro dos métodos Ruby gerado pelo Cucumber para interagir com um browser simulando ações humanas”.

Bom, agora iremos criar uma introdução para seu post, que, basicamente, é resumir o assunto que irá abordar juntamete com as três características que você definiu, veja:

Cucumber é um framework BDD usado para descrever estórias em seu idioma, estas estórias tornam-se métodos Ruby que, por sua vez, permitem a utilização de frameworks como o Selenium WebDriver para automatizar testes.

Vamos analisar minha introdução:

Tema { Cucumber é um framework BDD } Primeira característica { usado para descrever estórias em seu idioma } Segunda característica { estas estórias tornam-se métodos Ruby } Terceira característica { que, por sua vez, permitem a utilização de frameworks como o Selenium WebDriver para automatizar testes. }

Ótimo, o próximo passo é dar mais informações sobre cada uma destas três características que você levantou, fazendo com que cada uma torne-se um parágrafo, vejamos a um exemplo com a primeira frase “Com Cucumber posso descrever o comportamento do software em seu idioma em forma de estórias”:

Com Cucumber posso descrever o comportamento do software em qualquer idioma em forma de estórias. Estas estórias utilizam uma DSL (Domain Specific Language) chamada Gherkin e que utiliza palavras chave utilizadas no início de cada linha da estória, são elas: Dado que, Quando, Então, E e Mas. Por exemplo: Dado que eu esteja logado quando informar o usuário “juliodelimas” e a senha “123” e clicar no botão “Entrar” então verei a mensagem “Seja bem vindo!”

Faça o mesmo com as outras duas frases de modo que, ao fim, tenhamos a introdução em um parágrafo e mais três parágrafos descrevendo as três características que você está abordando no seu post.

Para finalizar, resuma em um parágrafo o que você abordou em cada parágrafo do conteúdo do seu post, veja um exemplo:

Concluímos que é possível descrever os comportamentos de uma determinada aplicação escrevendo em qualquer idioma e que com conhecimento de programação Ruby e uma pitada de Selenium WebDriver podemos criar testes automatizados em uma estrutura extremamente organizada com relatório que podem ser compreendidos por usuários técnicos e de negócio!

Excelente, agora você já tem seu primeiro post!

Como próximos passo, recomendo que publique seu post aqui no Medium, compartilhe o link com seus amigos em suas redes sociais, fique atento a responder dúvidas que poderão surgir, compartilhe o link para seu post como resposta a este texto e, é claro, keep writing!

;)

Teste de performance é um tipo de teste de software que basea-se na definição de um número fixo de usuários, que executam um passo a passo em uma aplicação e que avalia certos resultados como tempo de resposta, peso da resposta, latência, entre outros. Ferramentas de testes de performance permitem a gravação dos cenários e definição do que chamamos de usuários virtuais, que basicamente são Threads que reproduzem a mesma ação que usuários reais de forma paralela.

Os resultados gerados pela ferramenta geralmente são textuais, apresentando os resultados obtidos por cada um dos usuário virtuais que foram utilizados nos testes. Mas a dúvida que a maioria das pessoas tem é: como analisar os resultados de forma prática? Bem, uma forma é através do Percentil, e é sobre ele que falamos neste post.

Percentil é uma medida da estatística descritiva que tem o objetivo de dividir uma amostra de valores, ordenados de forma crescente, em cem partes. Frequentemente é usado para medir o grau de aceitação de algo.

Para exemplificar de maneira prática, imagine que criamos um teste de performance com 10 usuários virtuais, com o objetivo de fazerem login em uma aplicação e cronometrar quanto tempo levou desde o envio do formulário de dados de acesso até o carregamento da página secreta.

Definimos um requisito não funcional que diz que 90% dos usuários devem ter tempos de resposta de até 4 segundos ao se logarem no sistema.

Após a execução dos testes tivemos os seguintes tempos de resposta (em segundos): 1, 4, 4, 2, 1, 7,8, 1, 2, 3. Como vimos antes, para aplicar o percentil é necessário primeiro ordenar esta amostra de maneira crescente, então: 1, 1, 1, 2, 2, 3, 4, 4, 7, 8.

Neste caso, o percentil que desejamos observar é o 90º, que em nossa amostra é o 9º valor, ou seja, 7. Logo, sabemos que 90% de nossos usuários tiveram tempos de até 7 segundos o que, infelizmente, não atende ao tempo que desejamos, que é 4 segundos.

Perceba que se fossemos utilizar outra métrica, como por exemplo a Média, poderíamos nos enganar, pois a média seria 3.3 e estaria dentro do tempo desejado mesmo que um dos usuários teve tempo de 7 e 9 segundos, ou seja 3 a 5 minutos a mais do que era o esperado.

Usar o 90º percentil é algo comum em testes relacionados a performance de uma aplicação, inclusive é conhecido como Linha dos 90%. E está disponível em ferramentas de mercado, como o JMeter, por exemplo.

Existem outros percentis que também são bastante utilizados e possuem nomes específicos como por exemplo, o primeiro, segundo e terceiro Quartil que são, respectivamente, o 25º, 50º, 75º percentil. Dentre os quartis, temos a Mediana, que é o segundo quartil.

Concluímos então que o uso do Percentil em testes de performance é algo que pode ajudar na analise dos resultados quando os requisitos não funcionais referem-se a um nível de aceitação baseada em uma porcentagem da amostra em que se fundamenta um teste.

Referências

• Percentil - Wikipédia, a enciclopédia livre
• Quartil - Wikipédia, a enciclopédia livre
• Apache JMeter - Apache JMeter™

CTFL refere-se a Certified Tester Foundation Level e é o primeiro nível dentre 3 propostos pelo ISTQB (Foundation, Advanced e Expert), uma instituição internacional em testes de software que promove a certificação.

Cada país possui um board que representa o ISTQB. No Brasil temos o BSTQB e é através do site deles que você se inscreve para a prova e tem acesso ao Syllabus (documentação oficial de estudos) e também ao Glossário de Termos de Teste.

A prova é composta de 40 questões de multipla escolha seguindo estilo Simples (ex. a. Gato, b. Cachorro, c. Avestruz, d. Macaco), Romana Simples (ex. a. I e II estão corretas, b. III e IV estão coretas…) e Romana Complexa (ex. a. W1, X3, Y2, Z4, b. W2, X3, Y1, c…) e o tempo de prova é de 60 minutos. Se você estudar bastante este tempo não será problema, garanto.

Bem, para alguns certificar-se é um sonho realizado e motivo de orgulho, por se tratar de um requisito de entrada em algumas empresas; já para outros, certificar-se é jogar dinheiro fora.

O fato é que este post não vem defender nenhum dos lados da moeda. O objetivo é mostrar o que se pode fazer para aqueles que acham relevante, se prepararem e conseguirem ir bem na prova.

Vamos às dicas:

1. Não importa quantos anos você tem na área de testes e nem o quão sênior você é, armazene isso em uma caixa a parte enquanto estiver estudando. Isso porque a linha de raciocínio dos pesquisadores que escreveram a certificação poderá ser um tanto diferente da visão que você adquiriu sobre testes de software;
2. Leia o Syllabus e o Glossário de Testes uma ou duas vezes tentando referenciar o conhecimento contido nele com o que você vive em sua empresa. Por exemplo, no Syllabus fala "A análise e a modelagem de teste são atividades onde os objetivos gerais do teste são transformados em condições e modelos de teste tangíveis", neste caso, um bom exercício é trocar o que até então você chamava de "ler a documentação e criar os casos de teste" por "análise e modelagem". Isso lhe fará assimilar melhor os conceitos;
3. Não precisa decorar o código de ética, ele não cai na prova;
4. Decore e faça mnemonicos de todas as listas que aparecerem no Syllabus, por exemplo, meu mnemonico para níveis de teste era a "CISA", que representa Componente, Integração, Sistema e Aceite. Existem muitas listas e esta dica lhe ajuda e memoriza-las;
5. Faça o simulado contido no site do BSTQB e analise as respostas dadas por eles a cada questão, muitos dos meus alunos dizem que ao menos 30% da prova refere-se à questões similares (ou iguais) às que caem na prova;
6. Não use simulados e nem leia livros que não fundamentem-se no mesmo conhecimento pregado pela certificação, isso apenas atrapalhará você. Por exemplo, o livro BCTS (Base de Conhecimento em Teste de Software) é um excelente livro, mas é destinado a outra certificação, e os conceitos pregados lá não são os mesmos pregados na CTFL. Logo, enquando no BCTS diz que as atividades de teste são Procedimentos iniciais, Planejamento, Preparação, Especificação, Execução e Entrega, na CTFL as atividades são Planejamento e Controle, Analise e Modelagem, Implementação e execução, etc. Já viu né, iria se confundir por completo;
7. Aprenda na prática como usar as técnicas de teste caixa branca e caixa preta descritas no capítulo 4, tem alguns slides do Fabrício Ferrari que são excelentes http://pt.slideshare.net/FabricioFFC/tcnicas-de-modelagem-de-teste-parte-1 e http://pt.slideshare.net/FabricioFFC/tcnicas-de-modelagem-de-teste-parte-2-1129143;
8. Entenda os artefatos de teste descritos na norma IEEE 829 1998 (veja este estudo da Daniele e da Valesca), na prova caem questões como "Qual dentre os abaixo não é um campo contido no Plano de Teste segundo IEEE 829 1998?" e ai meu amigo, é a hora de saber se decorou o template dos artefatos;
9. Dentre os assuntos que sempre caem na prova estão: Diferença entre defeito e falha; 7 princípios do testes de software; Quais são as atividades, níveis, tipos e técnicas de teste; Papéis e tipos técnicas estáticas; Quais são as técnicas caixa preta e caixa branca, para que servem e quando usar; Papéis do líder e do testador (inclusive na CTFL basicamente temos apenas estes papéis); O que é risco; Ferramentas usadas por desenvolvedores e testadores; Quais campos estão em cada artefato (documento) de teste do padrão IEEE 829–98; Quais são as características de qualidade da ISO 9126–1; Qual significado de cada termo do glossário do BSTQB;
10. Quanto a recursos adicionais ao seu estudo, recomendo o livro "Sample Exam Questions" que você pode encontrar em versão digital na Amazon, os simulados oficiais do ISQTB com "Answers and Justifications" (respostas e justificativas) e os simulados do QualidadeBR, que fundamentam-se no material do CTFL.

Os resultados da prova demoram a sair, então uma forma de amenizar a expectativa de "passei ou não passei" é marcar as questões da prova como "tenho certeza que acertei", "não sei se acertei" e "essa eu chutei". Sendo sincero consigo mesmo conseguirá ter uma prévia se conseguiu ou não alcançar seus 65% e passar na prova.

Se você fez a certificação e se lembra de questões que cairam na sua prova, compartilhe aqui. Assim os amigos que usam este post para estudar poderão ver o que geralmente cai na prova.

Espero que essas dicas possam ajudar em seus estudos e que você consiga atingir seu objetivo de passar na certificação.

Boa sorte!