Evento gratuito de Testes - QA Ninja Conference 2ª edição

Olá Pessoal

Quero compartilhar com vocês um evento de testes que vai acontecer entre os dias 24 a 28 de abril. É a 2ª edição do QA Ninja Conference, a primeira edição eu participei assistindo em outubro de 2016 e foi uma troca de experiências muito bacana. O evento é gratuito e totalmente online. Os assuntos abordados são bem interessantes, acho que vale a pena conferir. 😁

Seguem algumas das palestras que achei interessante (e pretendo ver):

• 24/04: Fala sério, mulheres na TI?
• 25/04: Testes em 2027: Para onde QA está indo?
• 25/04: Como trabalhar com QA em times de desenvolvimento ágil
• 25/04: Práticas do Agile Testing
• 27/04: Você já fez dev box testing hoje?
• 27/04: A importância de testes estáticos na entrega final do produto

Aproveitem, pois é gratuito e online. Ano passado teve várias conversas, entre uma palestra e outra, com pessoas que trabalham com testes fora do nosso Brasil. Muito bacana pra ver as tendências de fora.

Espero que gostem e até mais, 😃

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/>

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

Minha opinião sobre a prova de certificação da CTFL-AT

Olá Pessoal,

Mês passado fui aprovada na prova de certificação CTFL-AT (Certified Tester Foundation Level - Agile Tester), do BSTQB/ISTQB. Hoje eu vou lhes contar aqui um pouco sobre a certificação e preparação para a prova da CTFL-AT.

O que é a CTFL-AT?

É uma certificação com validade internacional em testes de software, feita para testadores que trabalham com ágil. Ela ainda é nova: foi criada em 2014. Então, se você trabalha/quer trabalhar com testes de software em locais que trabalham com alguma metodologia ágil, esta é uma ótima opção.

Tem pré-requisitos?

Tem sim. Para fazer esta certificação você precisa primeiro ser certificado CTFL.

Qual era a minha motivação para fazer a prova?

A empresa onde trabalho começou a implantar ágil este ano. Muitos projetos ainda estão em fase inicial de implantação dentro dos projetos (incluindo o que eu trabalho), enquanto alguns poucos já estão com o ágil bem maduro na equipe. Eu queria aprender sobre o ágil. Já tinha lido muito sobre a teoria e como o ágil funciona, mas nada era focado sobre como o ágil é usado para testes de software. Quando eu e meus amigos estávamos estudando pra CTFL, vimos que tinha uma certificação que eu não sabíamos que existia: a CTFL-AT. Decidimos que se passássemos na CTFL, iríamos emendar a certificação do módulo ágil. E foi o que aconteceu. :D

Como eu me preparei para a prova? 

Comecei a me preparar logo depois da inscrição, assim que recebi o resultado de aprovação na prova da CTFL, cerca de 2 meses antes da prova da CTFL-AT. Novamente usei o Trello para me ajudar a organizar os estudos com um checklist. A minha "receitinha" de estudos foi praticamente igual a que usei pra CTFL: 

• Ler a apostila pela 1ª vez, marcando partes importantes;
• Ler a apostila pela 2ª vez, somente partes marcadas;
• Fazer simulados diversos encontrados na internet;
• Fazer simulado oficial, disponibilizado em inglês no site da ISTQB (link AQUI, lembrando que o  Sample Exam é o simulado e o Answer Sheet dá a alternativa correta e a explicação) (não tem simulado oficial no site brasileiro da BSTQB até a presente data);
• Ler a apostila pela 3ª vez, identificando os erros cometidos após o simulado oficial em inglês;

Últimas duas semanas antes da prova: 

• Foco no simulado oficial em inglês;
• Releitura das partes marcadas na apostila.

Como foi a prova?

O estilo da prova é bem parecido com a da CTFL. Foram 40 questões, feitas em 1 hora. Foi assustador num primeiro momento, pois parecia que eu tinha lido a apostila errada (meu amigo também achou isso). Mas eu tinha estudado tanto que não perdi minha confiança.

O tamanho de algumas questões também assustava um pouco, o simulado em inglês do site ajudou a ter uma noção de como seria a prova, e se confirmou na dificuldade. A prova é objetiva. Algumas questões precisam de interpretação de texto. Haviam situações em que todas as respostas estavam certas, mas que você precisava indicar a mais apropriada para determinada situação. Conversando com meu amigo, novamente chegamos à conclusão de que a prova era diferente entre nós.

Vale a pena fazer a prova e tirar a certificação CTFL?

Vale! O material é ótimo e fala bastante sobre como testes se encaixam numa equipe ágil. Esclareceu muitas dúvidas que eu tinha. Além disso, esta é a certificação mais barata da BSTQB: R$ 200,00. Após ter feito a prova (nem sabia do resultado ainda), pude ajudar mais com a implantação do ágil na equipe que trabalha comigo. Só por isso já vi que tinha valido a pena.

Conclusão!

Para você que quer aprender mais sobre testes ágeis, faça a certificação! A prova é difícil, mas você aprende muito.

Até mais! :D

Problemas que uma equipe de testes pode enfrentar no início da implantação da metodologia ágil - Scrum

No Scrum, todos da equipe são responsáveis por uma Sprint. Será? O que acontece quando a equipe de testes é chutada para fora da equipe? O que acontece se a equipe de desenvolvimento achar que testes não é necessário dentro da Sprint "deles", considerando-os como uma "Sprint paralela" ao desenvolvimento? Eu vivi isso e vou te contar neste post.

Toda mudança possui vários altos e baixos, e passamos por basicamente 4 estágios:

- 1º você rejeita

- 2º você tenta um boicote à mudança

- 3º você aceita

- 4º você coopera com a mudança

Quando começou a implantação da metodologia ágil, no meu local de trabalho, não foi diferente. Mas eu, como parte da equipe de teste, via algumas interpretações corretas e outras absurdas da metodologia. Contextualizando a ordem dos fatos:

• A empresa sentiu necessidades de mudança, pois viu que outras empresas levam metade do tempo para fazer grandes entregas (possivelmente com um grande incentivo do novo diretor de desenvolvimento);
• Começou um projeto piloto para implantação da metodologia;
• Adquiriram ferramentas específicas para auxiliar no gerenciamento de Sprints;
• Liberaram um documento com a política de funcionamento do processo ágil na empresa (mais parecia um cópia e cola de um site cheio de erros de português e loops no processo);
• Começou uma onda de mudanças, onde algumas equipes foram avisadas que a partir de X data poderiam migrar seus projetos para a ferramenta e trabalhar com o processo em ágil.

Se vocês ficarem bem atentos, verão várias inconsistências:

• A empresa acreditou que as pessoas chaves do projeto sabiam como funciona a metodologia ágil e um simples documento seria o bastante para aplicar ágil nos projetos;
• Migrar projetos do modo cascata pro ágil? Sem coordenação ou acompanhamento de um gerente de projetos?
• Fizeram do trabalho de faculdade de alguém um documentos de processo de funcionamento ágil? É isso mesmo?

Enfim, o problema estava claro pra toda a equipe de testes que teve de se adaptar. A adaptação não é um problema! A equipe de testes geralmente é bastante flexível, pois estamos acostumados com mudanças no processo de trabalho e mudanças de projetos de trabalho. O problema é que nem todos os analistas de testes/testadores dos produtos sabiam como se impor e alguns projetos viraram um caos.

No modo tradicional de desenvolvimento, o cascata, as equipes eram acostumadas a iniciar testes só depois que a implementação está pronta. Na metodologia ágil isso deixa de existir. A equipe de testes está testando partes antes de estarem concluídas, está dando ideias de situações que os programadores devem prever durante a implementação, pois a equipe de testes conhece o negócio e antecipa a ação que o cliente usará.

Eu vi uma equipe criar Sprints sem atividade de testes. Os testadores estavam num tipo de "sprint paralela" e atrasada do projeto. Você não leu errado, o sentimento era de total descaso com testes! Assim que a equipe de desenvolvimento acabava toda a implementação envolvida de uma Story, a mesma era encerrada. A Sprint acabava e uma nova Sprint era planejada! E testes? Os testadores precisavam buscar no "limbo do projeto" as Storys encerradas para então fazer um teste integrado. Não recebiam nenhum alerta de encerramento da Story e um controle paralelo era necessário. O desenvolvimento levando os créditos de que a Sprint foi um sucesso, encerrada no tempo planejado. SEM TESTES é só um detalhe? Ao meu ver, a Sprint só é um sucesso quando a equipe de testes dá seu aval de "Testes OK".

Isso parece um belo boicote à mudança. Jeff Sutherland, do livro "Scrum - a arte de fazer o dobro de trabalho em metade do tempo", disse que todos na equipe deveriam ser responsáveis pelas Sprints. Eu via que isso não estava acontecendo naquela equipe. O desenvolvimento não sentia que testes deveriam fazer parte da equipe. Para piorar, a pessoa que deveria apoiar e coordenar os trabalhos em testes ouviu todo esse problema e ficou por isso mesmo.

Recebi um retorno da não conformidade que abri, dizendo que era uma situação grave e deveria ser combatida. Quando a bagunça da equipe em questão acabar eu apresento a solução aqui no blog. Vale lembrar que esta é a única equipe que vi deixar testes de lado enquanto usavam metodologia ágil (não, eles não tem testes unitários para garantir coisa alguma). Mais alguém está achando que a metodologia usada por essa equipe mais parece GO HORSE?

Resumo da história: O pessoal de testes precisa se impor. Precisam mostrar que testes é importante sim dentro da Sprint e brigar por isso. O modo tradicional de testes, de testar somente quando a entrega já está pronta, não funciona na metodologia ágil. Testes unitários não garantem integração de produtos. Os testes de integração DEVEM entrar na Sprint! Cadê a responsabilidade da equipe toda em fazer uma entrega rápida e sem impactos para clientes?