Os 10 mandamentos de um Agile Tester

Uma das palestras vistas no encontro de testadores em Blumenau (que eu comentei AQUI) faagile tester (o testador ágil) e como isso estava funcionando dentro de um projeto ágil. O termo agile tester é utilizado no livro "Agile Testing: A Practical Guide for Testers and Agile Team" para identificar o testador que está alinhado com os princípios e valores ágeis.
lava sobre os 10 mandamentos de um

Em projetos tradicionais, normalmente há uma gerência (Gerência de Qualidade) e uma equipe (Equipe de Garantia de Qualidade) que são responsáveis por especificar e realizar os testes. A Equipe de Garantia de Qualidade busca encontrar erros, sejam erros de não conformidades com normas técnicas ou não atendimento de requisitos do software. Por outro lado, em projetos ágeis, essa burocracia pode atrapalhar bastante o andamento do projeto. Atualmente, técnicas como o TDD indicam que os testes deve ser escritos e executados pelos próprios programadores, quebrando um pouco a prática tradicional. E como fica o testador tradicional???

Agile Testing é mais do que isso, é uma forma de utilizar os valores ágeis para auxiliar o testador a ajudar seu time a entregar um maior valor de negócio para o projeto a cada iteração. Logo, não basta escrever um teste automatizado em um projeto ágil para falar que no projeto se faz Agile Testing e que a pessoa é um Agile Tester, alguns princípios devem ser seguidos para reforçar os valores da agilidade.

No livro são discutidos um conjunto de 10 mandamentos do Agile Tester, que irei apresentar abaixo:

1- Forneça Feedback Contínuo
Como a ideia é utilizar esses conceitos em projetos ágeis, o conceito de feedback contínuo não é nenhuma novidade. Uma das principais funções do testador é apoiar o Product Owner e o Cliente à escrever os requisitos de cada user story, na forma de exemplos e testes.

2- Entregue valor para o cliente
Desenvolvimento ágil é entregar valor em ciclos curtos para o cliente. Nesse caso, o testador deve ficar atento às entregas, se estão exatamente de acordo com o que o cliente priorizou recentemente. Agile Testers sempre estão focados no projeto como um todo. As funcionalidades mais importantes de cada release devem estar prontas para serem entregues, mesmo que com isso, outras funcionalidades devam ficam em segundo plano.

3- Buscar a comunicação olho no olho
​Nenhum time funciona bem sem uma boa comunicação. Como hoje em dia existem times distribuídos, em diferentes continentes, trabalhando no mesmo projeto, o Agile Tester deve buscar uma forma única para facilitar a comunicação com todos da equipe. Uma ótima prática é a daily meeting: uma reunião rápida, no meio do setor, em pé, onde cada pessoa deve responder a 3 perguntas:

  • O que fez ontem depois da daily meeting?
  • O que vai fazer hoje até a próxima daily?
  • O que está te impedindo de continuar e chegar nos objetivos?

Essa reunião não deve durar mais que 15 minutos. Problemas impeditivos devem ser resolvidos após esta reunião. E gente, isso funciona! :D

4- Tenha coragem
​Coragem é um valor importante em projetos ágeis, práticas como testes automatizados e integração contínua permitem ao time praticar esse valor. O time deve ter coragem de realizar mudanças, mas, sem uma suite de testes de regressão automatizados, essa mudança pode ser muito insegura. O Agile Tester deve ter coragem para encontrar os erros de outros e ajudá-los a não cometerem o mesmo erro. Deve ter coragem de pedir ajuda, mesmo quando quem pode ajudá-lo for uma pessoa de difícil acesso.

5- Mantenha a simplicidade
​Agile Testers e seus times não devem apenas produzir o sofware mais simples possível que atenda aos requisitos do cliente, mas também devem encontrar a forma mais simples de medir se o software atende a esses requisitos. Logo, medições são importantes, mas não devem ser uma barreira para a condução do projeto.

6- Pratique a melhoria contínua
​O Agile Tester sempre deve estar em busca de novas ferramentas, técnicas, habilidades ou práticas que auxiliem em seu trabalho de garantir que os desejos do cliente serão atendidos da forma mais simples possível.

7- Responda à mudanças
​Apesar de esse ser um dos valores mais importantes para times ágeis, é um dos mais difíceis conceitos para Agile Testers. Pois com a estabilidade, o testador pode dizer que, após ele testar algo, aquilo está pronto. Entretanto, a adaptação a mudança é necessária, logo, a utilização de ferramentas automatizadas para testes pode auxiliar um Agile Tester a responder a mudanças com maior rapidez e segurança.

8- Seja auto-organizado
​O Agile Tester é parte do time auto-organizado do projeto. Logo, ele deve buscar apoio de todos do time para atingir seus objetivos.

9- Foque nas pessoas
​Projetos de sucesso são aqueles onde boas pessoas conseguem fazer seu melhor trabalho. Como o testador encontra erros, ele deve fazê-lo sempre respeitando a todos da equipe, nunca focando na pessoa que cometeu algum erro, mas sim no erro que foi cometido, para evitar algum mal estar entre os membros da equipe e ajudar a todos a não cometerem os mesmos erros.

10- Aproveite
​Trabalhe em um time onde se sinta confortável, ninguém consegue realizar um bom trabalho em um ambiente ruim.


Finalizando, pode-se perceber que o Agile Tester deve estar alinhado com os princípios e valores ágeis, todos os 10 mandamentos são baseados neles. E você, se considera um Agile Tester? Já pratica esses "mandamentos"?
Até mais,  :D

Referências:
MyScrumHalf. Disponível em: <http://blog.myscrumhalf.com/2014/02/agile-tester/>

Os ChatBots estão vindo com tudo!

Em setembro vi os primeiros posts sobre ChatBots em blogs de arquitetura de software. Vi que o número de posts relacionados ao tema foi aumentando. Para minha surpresa, tomei conhecimento de que tinha uma iniciativa sobre este tema na empresa onde trabalho e logo no mês seguinte fizeram um post sobre ChatBots no blog da empresa.

O que são os ChatBots?
São plataformas virtuais de comunicação que querem suprir as necessidades de comunicação e demanda de serviços. Mas diferente dos chats normais onde você conversa com uma pessoa, no ChatBots você conversa com um "robô".

E isso tem futuro?
Parece que sim, e muito! Os ChatBots estão se tornando tendência muito forte e prometem mudar a forma como as empresas em geral se comunicam e vendem seus produtos.

Um exemplo bacana...
Hoje é possível, com um ChatBots, que milhares de usuários conversem ao mesmo tempo com o Presidente Obama através da página oficial da Casa Branca no Facebook. Claro que não é o presidente quem está lá respondendo, mas sim um robô automatizado que consegue entender o tópico no qual o usuário está interessado e fornecer conteúdo relevante como se fosse a voz do próprio Obama.

Pausa, fizeram um robô do Obama?
Não, é um software. Não tem um robô físico na frente de um computador respondendo as mensagens.

Por que se fala tando sobre ChatBots agora?
Com o desenvolvimento da tecnologia e as melhorias no reconhecimento da linguagem e do processamento de informação, a interação com os serviços digitais está cada vez mais intuitiva, acessível e inteligente graças, sobretudo, à ajuda das interfaces conversacionais. Apesar de que a funcionalidade de maior valor dos ChatBots é a capacidade de fazer transações comerciais, esses robôs podem fazer muito mais!

Quais outras aplicações dos ChatBots?
Com um pouco de imaginação, é possível muita coisa. Olhá só algumas ideias onde os ChatBots já estão sendo implementados:
Helps: Sabe aquela documentação de ajuda de um software? Você pode solicitar diretamente pelo chat do help algum conteúdo que você busca e o Bot vai te entregar o conteúdo relevante;
Aplicativos de automação de casas: por meio de um ChatBot, você pode solicitar que ligue o ar-condicionado do seu quarto as 17 hs;
Pedidos de comida: Você pode solicitar comida pelo ChatBot, e ele vai fazer o pedido e anotar seu endereço pra depois um entregador real te entregar a comida no conforto da sua casa;
Comprar produtos e serviços: Já pensou entrar no site de uma empresa e , por meio do chat, solicitar a compra de uma Televisão pra entregar na sua casa? 
Reservar um restaurante/cinema/outro lugar: Solicitar uma reserva pelo chat sem ter que fazer todo um cadastro. Ô coisa boa! :D
Movimentações bancárias: Essa parte eu achei mais delicada, mas a promessa é conseguir fazer consulta à extrato, movimentações e pagamentos. Nesse tópico fiquei com um pé mega atrás, mas é uma possibilidade.

Já existem empresas de grande porte usando os ChatBots?
Sim, alguns exemplos de empresas que possuem algumas iniciativas com ChatBots são PizzaHut, GE  e a Amazon.

Quem fornece a inteligência artificial dos ChatBots?
Já temos algumas empresas nesse campo, mas acredito que a mais famosa é o Watson da IBM. Dá uma olhadinha no site do G1 que a chance de você encontrar algum banner sobre o IBM Watson relacionado à inteligência cognitiva é grande.

Como eles funcionam?
Por meio de inteligência artificial, um motor do ChatBot treina um vocabulário. É possível ter quatro conceitos: intenções, entidade, diálogos e contextos.

Na intenção, você cadastra expressões que possuem o mesmo significado e são utilizadas para definir o que o usuário quer. Exemplo: é criado uma intenção chamada #ligar e adicionar mais sentenças parecidas, como:
#ligar
eu gostaria de ligar
eu quero ligar
ligar por favor
voce pode ligar

As entidades são termos que possuem sinônimos ou que podem ser escritos como abreviações. Exemplo:
@objetos
ac - acs - ar-condicionado
luz - lustre - lampada - luzes
som - aparelho de som - rádio

Os diálogos são os caminhos lógicos que o robô utiliza para determinar uma resposta com base nas intenções e entidades fornecidas pelo usuário. 
Exemplo 01: se um usuário simplesmente digital "ligar", o ChatBot não vai saber o que ele precisa ligar, e responderá com alguma sentença, como "Entendo que você quer que eu ligue alguma coisa, porém, preciso saber especificamente o quê você quer que eu ligue.".
Exemplo 02: se um usuário simplesmente digital "ligar ac", o ChatBot pode responder "Entendido, ar-condicionado ligado".

Os contextos vão armazenar as intenções, entidades e diálogos de um mesmo contexto.
Imagem da autora

Como esses ChatBots são testados?
O testador precisa incorporar o usuário! Os caminhos que levam o robô a responder corretamente são parecidos com um modelo de negócio, pois seguem um fluxo. Minha sugestão para testes com os ChatBots é validar a transição de estados de uma conversa com outra. Outra sugestão, é fazer teste de usabilidade com uma pessoa que nunca teve a interação com o ChatBot. Solicitar que ela faça algo e ver como o ChatBot e a pessoa se comportam. 

Lembre-se que o intuito do ChatBot é ter uma conversa humanizada que entregue valor para o usuário . Eles chegam ao mercado para ser cada vez mais colaborativo para os seres humanos, não para substituí-lo.

Você já teve alguma experiência com algum ChatBot? Conta pra gente como foi! :D

Referências
Chatbots: uma tendência cada vez mais forte na tecnologia. Disponível em: <http://www.senior.com.br/noticias/chatbots-uma-tendencia-cada-vez-mais-forte-na-tecnologia/>.
Desenhando interfaces conversacionais: o desafio do UX. Disponível em: <http://arquiteturadeinformacao.com/user-experience/desenhando-interfaces-conversacionais-o-desafio-de-ux/>.
O papel de UX nas interfaces conversacionais. Disponível em: <http://arquiteturadeinformacao.com/user-experience/o-papel-de-ux-nas-interfaces-conversacionais/>.

Massa de dados com data fixa: como evitar a quebra dos testes automatizados?

Um dos maiores medos dos testadores/automatizadores é quando um cenário de testes vem com data fixa. Se este teste é executado daqui a um tempo novamente, este cenário irá quebrar pelo simples fato de possuir uma data fixa nas pré-confições do cenário. Por exemplo, tenho testes que utilizam informações de um período de férias do mês anterior, no próximo mês o mês anterior já não será o mesmo, isso provavelmente fará o teste falhar. 

Que alternativa temos para as datas fixas?
Uma alternativa fácil, que também é sujeita a falhas, é "fixar" a data da máquina onde os testes estão executando. Eu acho esta uma prática muito errada, pois a máquina pode alterar o horário para o horário correto no meio da execução dos cenários automatizados. Aí perdemos a execução (Isso já me aconteceu devido à política de máquinas definida no AD aqui na empresa :'( ).
Outra alternativa é ter um mecanismo de "popular" a base através de um script antes de iniciar o teste. Isto permitiria que os dados inseridos fossem dinâmicos. Este script gera uma manutenção alta, pois alterações na base podem fazer com que o script pare de funcionar ou faça algo não esperado.

Existem ferramentas de mercado para inserir massas de dados que serão utilizadas nos testes?
Existe sim meus caros testadores! Uma boa opção é o DBUnit. Ele lê de um arquivo XML os registros e altera na base.

Como funciona quando uma validação precisa ser previsível?
Bom, a previsibilidade dos script pode ser garantida de forma lógica. Por exemplo, Existem cenários de testes para um processo de inserção de nota fiscal, onde o número da nota deve ser igual ao número anterior + 1. Para evitar que ocorram erros futuros quando se adicionar notas indiscriminadamente, adota-se uma validação lógica a qual seja especificada que o número da nota inserida deve ser igual ao número da nota anterior + 1. Dessa forma, ao se adicionar novas notas necessárias para outros cenários futuros não quebrará o teste.
Isso ocorre também no caso de datas exemplificado no início deste post. Repare que a especificação é estática e bem definida para o propósito de ser validado, porém por também ser lógica a implementação dela é que será dinâmica de acordo com a data em que o teste será executado.

Você já se deparou com uma situação assim? Comente como foi a solução!
Até mais! :D

Quando considerar um projeto pronto na metodologia ágil? Definição de Pronto - DoD (Definition of Done)

Olá meu povo testador!

Conforme mencionado neste post, uma das palestras que participei num encontro de qualidade promovido pela empresa falou a respeito da definição de pronto. Vou desmistificar um pouco sobre a Definição de Pronto dentro da metodologia ágil.

O que é Definição de pronto?
Equipes ágeis maduras desenvolvem projetos seguindo alto padrão de qualidade. Tal rigor é imposto por meio da DoD – Definition of Done, ou Definição de Pronto. A DoD é uma discussão entre Time de Desenvolvimento (o que inclui o testador/QA) e Product Owner de que toda a entrega atenderá os padrões de qualidade estabelecidos por eles mesmos.

Para que serve o DoD?
É uma forma de se buscar a excelência. A discussão aprofunda a compreensão da equipe dos itens do backlog e os requisitos do produto de cada estória da sprint.

Quando uma estória está pronta?
Vida de Programador - nº1438
Toda mudança é difícil, quando você sai do modelo de desenvolvimento tradicional e vai para o ágil a história não é diferente. Posso dizer que eu vivi o quadrinho do Vida de Programador acima. É difícil de um programador de longa data aceitar que o "pronto" não é mais um status por etapa de desenvolvimento e sim "pronto" de tudo. Ainda percebo que é difícil o programador aceitar que ele precisa se preocupar com tudo também.

É importante frisar que, no ágil, a definição de pronto é decidido pela equipe e ocorre por estória. Então temos que o "pronto" pode ser diferente para cada estória dentro da sprint. ;)

Exemplos de definição de pronto:
- Critérios de aceite da estória atendidos.
      Responsável: Time de Desenvolvimento e Product Owner;
- Testes da estória executados conforme planejamento. Todas as subtasks de testes devem estar finalizadas.
      Responsável: QA (Quality Assurance);
- Todos os defeitos não críticos que não podem ser corrigidos dentro dos limites da sprint adicionados ao backlog do produto e priorizados para a próxima sprint.
      Responsável: todo o time;
- Integração de todas as funcionalidades.
      Responsável: todo o time;
- Todos os requisitos funcionais testados, incluindo os testes positivos e negativos, com o número de testes com base no tamanho, complexidade e riscos.
      Responsável: QA;
- Todos os riscos de qualidade cobertos de acordo com a medida acordada de testes.
      Responsável: QA;
- Documentação escrita, avaliada e aprovada.
      Responsável: Product Owner.

Espero que tenham gostado deste post. Qualquer dúvida, perguntem! :D

Referências
Definition of Done. Disponível em: <http://www.mindmaster.com.br/definition-of-done/>.
Apostila da certificação CTFL-AT (já falei sobre ela AQUI): Foundation Level Extension Syllabus Agile Tester. Disponível em: <http://www.bstqb.org.br/uploads/docs/syllabus_ctfl_at_2014br.pdf>.

Evento gratuito de Testes - QA Ninja Conference 2016

Olá meu povo testador!

Hoje começa um evento gratuito de testes de software, chamado QA Ninja Conference 2016. Esse evento terá transmissão ao vivo e gratuita, basta fazer sua inscrição AQUI. Ele ocorre durante essa semana, de 24/10/2016 a 28/10/2016 a partir das 19 hs.

Qual o melhor caminho para testar minha aplicação? 
Como evitar que mudanças causem transtornos e efeitos colaterais no meu software? 
Como técnicas automação de testes podem tornar meu trabalho mais produtivo?
Pensando nisso foi criado um evento, totalmente on-line e gratuito, que vai te ajudar a encontrar respostas para essas perguntas, focado em Qualidade de Software.

http://www.qaninjaconference.com/

Público Alvo: QAs e DEVs com interesse em conhecer e aprender mais sobre Qualidade e Testes de Software.
Seu software testado: Conheça as melhores práticas e ferramentas para realizar variados tipos de testes nos seus projetos.
Testes ágeis: Entendendo tipos de testes sob a perspectiva do desenvolvedor e do usuário final.

Link do evento: http://www.qaninjaconference.com/ Os videos do evento ficarão gravados no Youtube e estão disponíveis nesse link também.

Aproveite! Também comente se você viu o evento e o que achou. :D

Encontro de testadores 2016 - Blumenau/SC

Ontem, eu participei de um evento anual que proporcionou um encontro com todos os profissionais de testes de software da empresa onde trabalho, aqui em Blumenau/SC. Mais ou menos 70 profissionais de testes se reuniram. O foco deste ano foi falar sobre o ágil. Eu já havia comentado, num post aqui no blog, que estamos migrando os projetos do formato cascata para o ágil. 

Este encontro ainda vai render vários posts sobre ágil aqui no blog (meu Trello de ideias está cheio :D ). Então vou dar um gostinho do que vi ontem:

Ágil - O que é? Como funciona? Um pouco da experiência de quem já viveu essa transição e fazer acontecer.
Os 10 mandamentos do QA - A teoria e exemplos reais. Post aqui.
Definição de Pronto, DoD - Quando uma entrega está pronta? Post aqui.
User eXperience - O que é e como um testador ajuda um designer a melhorar a experiência de uso de um software?
Fora o OneMinuteTalk, Fishbowl e o Game interativo que tivemos usando o smartphone.

Aguardem! :D