DEV Community: Beatriz Feliciano

Agile Testing: como trabalhar com testes em contexto ágil

Beatriz Feliciano — Mon, 16 Aug 2021 20:57:31 +0000

Cada dia mais ouvimos falar sobre a agilidade e vemos que as metodologias ágeis estão sendo aplicadas nas mais diversas áreas além do desenvolvimento de software hoje vemos áreas como RH, Marketing e até no mercado de publicidade entrando na onda ágil. E diante deste contexto diversos profissionais precisaram se adaptar e os testadores não foram uma exceção.

O Agile Testing é uma forma de atuar em contextos ágeis que começou a se difundir pela comunidade de testes por volta de 2002 com publicações de Bret Pettichord, mas só se consolidou em 2009 com a publicação do livro Agile Testing de LisaCrispin e da Janete Gregory.

A evolução do QA

Antes de começar a falar sobre testes ágeis, apresento um que modelo que mostra como o trabalho de um QA tem evoluído ao longo do tempo, esse modelo foi proposto pelo Julio de Lima em uma palestra no Scrum Day 2020 e explica o passado presente e o possível futuro de uma pessoa que atua como QA. O intuito deste conteúdo é proporcionar o entendimento do modelo que se está atuando para saber o que é esperado de você como pessoa QA.

1.0 - Cascata: nesse modelo temos um time de pessoas que atuam nesse modelo em geral são chamadas de testadores ou analista de testes. Nesse contexto de trabalho, as pessoas testadoras são responsáveis por testar o software quando o time de desenvolvimento finaliza a fase de codificação. Neste modelo o testador tem como principais atividades: revisar o plano de testes, criar e executar casos de teste, reportar inconsistências e gerar relatórios com métricas de teste no projeto.

1.5 - Ágil Imaturo: neste modelo de atuação temos já temos um time multifuncional, o que é característica de times ágeis, porém nesse caso o testador acaba atuando como se estivesse em uma metodologia cascata onde de maneira reativa o QA espera que os desenvolvedores concluam a codificação para que eles finalmente atuem com testes.

2.0 - Ágil em maturação: já no modelo ágil em maturação o QA auxilia em todo o desenvolvimento do produto compartilhando boas práticas, fazendo a mentoria do time com relação a testes e claro executando testes específicos e até implementando uma estratégia de testes.

3.0 - Ágil: após mentorar o time com relação ao a testes como é feito no modelo 2.0 é ideal que com o tempo os desenvolvedores ganhem experiência com testes e que eles passem a mentorar o QA a desenvolver, assim todas as pessoas do time acabam ganhando experiência tanto em desenvolvimento quanto em testes. Muitas empresas já buscam profissionais de QA com perfil em desenvolvimento, esse perfil tem sido chamado de Software Engineer in Test.

O mindset do Agile Testing

Como já deve ter sido possível perceber quando estamos em um ambiente ágil atuamos de maneira diferente de quando atuamos em um modelo tradicional. E existem características que devemos considerar ao atuar neste contexto sendo essas elas:

Trabalhe além das competências técnicas: soft-skills são ao habilidades requisitadas em diversas áreas atualmente, mas em especial quando trabalhamos em um contexto ágil seja QA ou não devemos trabalhar algumas competências como:

Resiliência: como o próprio manifesto ágil diz "responder a mudanças, mais que seguir um plano", quando atuamos em um contexto ágil nosso projeto pode sofrer diversas mudanças e elas podem ser relacionadas ao produto ou as tecnologias usadas, mas independente da mudança é preciso saber se adaptar.
Comunicação: o manifesto ágil também cita a importância da colaboração e das interações. Sendo uma pessoa QA, frequentemente interagimos com nossos pares, steakeholders, clientes e etc. E para que essas interações fluam bem é importante saber se comunicar da maneira mais assertiva possível, pois falhas de comunicação podem ter grandes impactos negativos.
Inteligência emocional: trabalhar com tecnologia em geral, exige muito essa competência, pois frequentemente podemos nos encontrar em momentos críticos onde há a necessidade de tomada de decisão, portanto saber administrar suas emoções, mesmo em meio a problemas e encontrar equilíbrio entre área pessoal e profissional é importante.
Resolução de problemas: por fim e não menos importante conseguir entender um problema, para avaliar e propor uma solução adequada. Constantemente, somos expostos a problemas complexos que exigem uma tomada de decisão e saber como fazer as melhores escolhas ou até saber a quem recorrer para nos auxiliar é uma habilidade muito importante atualmente.

Busca por feedbacks frequentes: a melhoria continua pode ser obtida através de feedbacks que podem acontecer em três áreas distintas, sendo elas:

Pessoal: dar e receber feedback a respeito do seu trabalho e de características pessoais podem ajudar na evolução pessoal.
Time: nesse caso já temos métricas sobre a atuação do time que podemos usar como base para avaliar pontos fortes e a melhorar
Aplicação: aqui os testes marcam forte presença, pois eles podem gerar feedback rápido da saúde da aplicação, porém eles não são as únicas formas de se obter feedback da aplicação, também podemos usar diversas ferramentas de monitoramento e até o bom feedback do usuário.

Protagonismo em fases todas da especificação a entrega: Quando atuamos em um ambiente ágil o QA deixa de ser reativo como em metodologias sequenciais e passa a ser uma pessoa ativa que ao invés de atuar em uma única fase do projeto, participa desde o inicio das do projeto tentando entender melhor o produto ou cliente, pois assim fica mais fácil de saber o que é esperado com para que o produto seja entregue com qualidade.

Abordagem do time todo: em geral uma squad trata-se de um time multifuncional, composto por pessoas com diferentes habilidades. Embora dentro desse time encontramos diferentes perfis de profissionais todos esses profissionais acabam sendo responsáveis por entregar o produto final e essa entrega deve ter qualidade e todos do time devem se responsabilizar por isso, e isso inclui os testes de software que deve ter sua responsabilidade compartilhada com todo o time.

Foco na solução: desenvolvimento de software é uma atividade complexa e para que essas atividades complexas não se tornem um mostro de sete cabeças, o ideal é que antes de partir para a solução entendêssemos o problema, pois assim fica muito mais fácil focar na solução e desenvolver algo que será útil ao nosso usuário. Sendo mais especifico com pessoas de QA, antes de sair desenvolvendo automações entenda seu produto e conheça seu usuário.

Mitigar e prevenir riscos: em metodologias ágeis geralmente temos um curto espaço de tempo entre entre o planejamento e as entregas. Com isso muitas vezes um QA pode desempenhar muito bem levantando riscos junto ao time para poder mitigar ou os prevenir para minimizar os impactos que o produto pode sofrer.

O manifesto do teste

Por volta de 2014, Sam Laing e Karen Greaves inspirados pelo manifesto ágil criaram o manifesto do teste, que é uma forma de resumir de maneira rápida como deve ser a mentalidade quando atuamos com testes ágeis. O manifesto segue os seguintes valores:

Testar todas as etapas versus testar no final
Previnir bugs versus encontrar bugs
Testar o entendimento versus testar a funcionalidade
Construir o melhor sistema versus quebrar o sistema
Time Responsável pela qualidade versus responsabilidade dos testadores

Princípios de teste

Por volta dos anos 2000 Elizabeth Hendrickson, fez uma palestra que acabou servindo de base para a consolidação dos testes ágeis, onde ela descrevia nove princípios de teste de software que formam a base de como os testes devem acontecer em times ágeis.

1. Testes movem o projeto
Atualmente, o termo Shift-Left tem sido muito comentado e ele reflete justamente esse principio, pois esse termo se refere que ao invés dos testes ocorrerem só nos estágios finais, as atividades de testes passam a ocorrer mais cedo, e perduram durante todo o ciclo de vida, por isso do nome shift-left, pois dá a ideia que testando desde o inicio acabamos testando da esquerda para a direita.

2. Testes não são só uma fase
Os testes não devem ser só uma fase como em metodologias sequenciais. Em contextos ágeis os testes devem ser executados continuamente, pois é necessário adotar uma estratégia de testes que permita testar desde o inicio, e isso foi pode ser feito por exemplo adotando técnicas de para executar bons testes unitários ou testando a aplicação em camadas.

3. Todos testam
Em contextos ágeis, todas as pessoas do time são responsáveis por entregar um produto de qualidade e consequentemente por testar esse produto. Nesse momento, você pode acabar questionando "E o QA faz o que se todos são responsáveis pela qualidade?". Nesse caso o QA passa a ser a pessoa que é guardiã a da qualidade e que compartilha conhecimento de testes com o time e executa testes pontuais ou mais complexos.

4. Ciclos curtos de feedback
Quando aplicamos testes continuamente no nosso projeto e principalmente quando os testes são automatizados, frequentemente devemos executar esses testes e essas execuções são uma forma de prover feedback a rápido a respeito da aplicação e a partir desses feedbacks é possível agir de maneira rápida e assertiva, caso algum problema seja detectado.

5. Mantenha o código limpo
Usar boas práticas de programação, refatorar código sempre que necessário, fazer code review, usar linters, definir um padrão de programação ou até parear com alguma outro desenvolvedor são formas de garantir que o time esteja desenvolvendo um bom código.

6. Documente o necessário
Muitas empresas que iniciam no uso de metodologias ágeis acabam deixando de lado a escrita de documentações acreditando que elas não sejam mais necessárias, porém isso é um grande equivoco, pois a documentação ainda é importante, no entanto devemos documentar apenas o que for mais relevante para o time se localizar nas tarefas a desenvolver, e também o que for importante para o cliente após a entrega da aplicação.
E com relação a testes, use apenas os artefatos que julgar necessário de acordo com o momento que está no projeto alguns exemplos de documentações a ser usadas pode ser:

Chapter de testes exploratórios
Mapas mentais com as funcionalidades em testes
Evidencias de teste em vídeo, gif o fotos
Read me de como executar as automações
Relatórios de execução de automação

7. Testes são exemplos
Sabe quando você não entende algo e acaba pedindo um exemplo? É esse exemplo serve para que você entenda a expectativa da outra pessoa com relação a algo. Quando pensamos em testes estamos fazendo justamente isso, avaliando se o produto que estamos desenvolvendo está atendendo a expectativa do nosso cliente e uma das formas de conseguir esse alinhamento é através do uso de técnicas como: BDD, ATDD, ou SBE que são formas de entender a necessidade do cliente já fazendo o alinhamento com o que deve ser desenvolvido e testado.

8. Testes fazem parte do DoD
Na definição de pronto devemos listar, todos os testes que deverão ser contemplados nos stories a serem desenvolvidos. Esses testes devem ser definidos pelo time e podem ser definidos no momento que o time faz a sua estratégia de testes.
Algo que pode ocorrer é a necessidades de testes específicos, por exemplo um teste de acessibilidade em alguma área da aplicação, nesses casos o ideal é que esses cenários sejam descritos no critério de aceite.

9. Desenvolvimento orientado a testes
Este nono principio pode facilmente nos lembrar do TDD, onde o desenvolvimento começa a partir dos testes e não o contrário como ainda ocorre bastante. No entanto o desenvolvimento orientado a testes vai muito além disso, pois quando definimos os requisitos já pensando nos testes como sugere o principio sete acabamos sendo mais assertivos no que estamos construindo e realizando uma entrega de maior qualidade.

Referencias:

http://www.althority.com/agile_testing_overview/
https://medium.com/revista-tspi/descubra-o-que-%C3%A9-shift-left-testing-b67116b79a0c

O que é DevOps?

Beatriz Feliciano — Tue, 27 Jul 2021 12:45:16 +0000

DevOps é um termo que tem se tornou muito popular nos últimos anos e refere-se a contração de duas palavras que identificam duas equipes:

Desenvolvimento: time responsável por identificar requisitos, analisá-los e codificá-los.
Operações: time responsável pela implantação, monitoramento e solução de incidentes em produção.

Uma das primeiras referências a respeito de devOps surgiram por volta de 2009 em uma conferêcia da O'Reilly, a partir de então muitas outras referências foram surgindo até chegar nos dias de hoje, porém atualmente devOps é visto como um papel dentro de TI em muitas empresas, no entanto essa visão está deturpada.

DevOps é uma cultura fortemente focada em colaboração entre equipes de desenvolvimento e operações. O conceito de devOps visa unir essas áreas, pois juntos os times conseguem entregar valor de forma mais rápida e com maior qualidade ao cliente. Essa cultura é fundamentada em quatro princípios.

Colaboração: no devOps não temos mais a segregação de times, divididos em silos, agora todos trabalham junto com o propósito de entregar algo cada vez melhor para os usuários.
Afinidade: construir relação entre os times onde ao invés de segregar por papel, unimos os diferentes papeis em para uma atuação conjunta.
Ferramentas: usar a ferramentas para impulsionar o devOps, a partir de ferramentas podemos proporcionar uma entrega mais valiosa ao usuário em um curto espaço cada vez mais curto de tempo.
Escala: sempre buscar crescer de acordo com as necessidades da organização, projeto ou empresa. Ao usar algo novo é comum começar pequeno e com o tempo ir expandindo conforme necessário.

O que é JSON?

Beatriz Feliciano — Mon, 26 Jul 2021 17:27:20 +0000

JSON (JavaScript Object Notation), é um tipo de formatação de texto compacta que permite que aplicações troquem informações entre si de maneira simples e rápida. O JSON é usado pra estruturar dados e através dessas estrutura podemos fazer com que nossas aplicações se comuniquem.

Apesar do nome conter uma referência a linguagem de programação Javascript, o JSON pode ser usado com qualquer outra linguagem de programação e permite que aplicações desenvolvidas em diferentes linguagens se comunique entre si.

Um arquivo com o formato JSON deve ter seus dados estruturados por meio de uma coleção de pares com nome e valor. Seus valores devem ser:

Chave: seria o nome do conteúdo que queremos identificar. Sendo assim, deve ser uma string delimitada por aspas,
Valor: é o conteúdo que corresponde a uma chave podendo ser representado pelos seguintes tipos de dados: string, array, object, number, boolean ou null.

Exemplo:
{
"estado": "São Paulo",
"UF": "SP",
"Municipios": 645
}

O que é TDD?

Beatriz Feliciano — Tue, 20 Jul 2021 10:23:11 +0000

TDD significa Desenvolvimento Orientado por Testes (Test Driven Development), e trata-se de uma prática de desenvolvimento de software onde a codificação das funcionalidades começa a partir da escrita de testes unitários. Essa técnica foi criada por Kent Beck e é um dos pilares do XP (Extreme Programming).

O TDD consistem em um ciclo apelidado de Red, Green, Refactor. Que funciona da seguinte maneira:

Escrevemos um teste para uma funcionalidade a qual queremos implementar. Ao executar esse teste ele deve falhar, pois ainda não temos a implementação e assim passamos pelo step red.
Após o nosso teste falhar implementamos a funcionalidade e executamos o nosso teste novamente, porém dessa vez o teste passa com sucesso, com isso passamos pelo step green do TDD.
Com os testes funcionando chegamos ao step refactor. Como o próprio nome já diz, nesse momento devemos refatorar nosso código procurando pontos a melhorar e aplicando boas práticas de programação.

Esse ciclo pode se repetir quantas vezes o desenvolvedor julgar necessário e a cada nova implementação é interessante que todos os testes que já estão em funcionamento sejam executados, pois assim é possível validar que todos os testes continuam funcionando e que a nova implementação não impactou nas funcionalidades já desenvolvidas.

Os principais benefícios do TDD são:

Maior cobertura de testes unitários
Testes são executados com maior frequência
O código se torna mais limpo

O que é SRE?

Beatriz Feliciano — Mon, 19 Jul 2021 12:13:03 +0000

SRE é a abreviação de Site Reliability Engineering, este termo surgiu inicialmente em 2003 e foi criado por Ben Treynor Sloos, VP de engenharia do Google. O termo nasceu quando Ben precisou gerenciar uma equipe de engenheiros de software que eram responsáveis por um ambiente de produção.

SRE como o próprio nome já diz SRE está relacionado com a garantia da confiabilidade dos ambiente de produção. É um tipo de trabalho operacional onde, ao invés de sermos reativos e só atuarmos quando algum problema acontecer, agimos antes garantindo a que o ambiente de produção está funcionando corretamente e minimizando as chances de falha em produção.

Para garantir a confiabilidade em ambiente de produção é comum a adoção de práticas como: monitoramento de aplicações, uso de boas práticas de implantação, gerenciamento de capacidade de serviços, avaliação de latência, uso de ferramentas que permitam avaliar escalabidade de aplicações, entre outras práticas que podem variar de acordo com o contexto de onde estamos atuando.

O que é DOR e DOD?

Beatriz Feliciano — Wed, 17 Feb 2021 11:27:34 +0000

Quando atuamos em projetos ágeis muitas vezes podemos acabar percebendo alguns desalinhamentos dentro do time de desenvolvimento ou até mesmo entre time de desenvolvimento e Produc Owner. Esses conflitos geralmente podem acontecer por dois fatores, sendo eles:

O time pode estar recebendo requisitos com baixa granularidade ou com nenhum detalhamento. Além disso pode ocorrer de histórias maiores que a capacidade do time de entrega entrem para a sprint.
Cada integrante do time entrega a sua feature ou a atividade que está responsável de uma forma diferente, ou seja, um integrante pode entender que apenas desenvolver já é o suficiente enquanto outro pode entender que o entregável é um software desenvolvido e com testes unitários.

Diante desses dois possíveis conflitos que podem acontecer durante o desenvolvimento de um produto podemos resolver com o DOR e DOD, também conhecidos como Definition of Ready e Definition of Done .Ambos servem como um acordo entre o time que deve ser visível e comum a todos os membros do time. Inclusive, se um novo integrante entrar para a equipe, ele deve ser informado a respeito dos critérios de DOR e DOD.

DOR - Definition of Ready: é um acordo que ocorre entre o time de desenvolvimento e o Product Owner onde ambos acordam o que é necessário para que uma estória entrar na sprint de modo que a equipe de desenvolvimento consiga desenvolve-la sem grandes problemas e que ela caiba na capacidade do time no período da sprint.

Exemplos de Definition of Ready:

A estória deverá ter critérios de aceite detalhados
A estória deve estar escrita seguindo o princípio INVEST
Deve ter um wireframe de baixa fidelidade disponível e validado pelo cliente final

DOD - Definition of Done: também é um acordo feito com o time e Product Owner onde as expectativas alinhadas referem-se ao incremento do produto que será entregue ao final da sprint. Neste momento o Product Owner sugere o como ele espera que o entregável seja apresentado a ele ao fim do sprint.

Exemplos de Definition of Done:

Os testes unitários devem ser feitos atingindo uma cobertura de 70% no mínimo
A aplicação deve ser disponibilizada em ambiente de homologação
Realizar Code Review

De modo geral, tanto o DOR quanto o DOD são acordos feitos para melhorar o fluxo de trabalho dando transparência sobre o que é necessário para iniciar uma estória e o que é necessário para finalizar um estória dentro de uma sprint.