Três amigos (Three Amigos) é uma técnica de discussão e definição de algo que será feito, podendo ser uma feature, incremento ou correção.
O termo surgiu no meio ágil em 2009 com o principal objetivo de colher pontos de vista de diferentes perspectivas e áreas:
negócio: geralmente representado pelo analista de negócio ou dono do produto;
desenvolvimento: representado pelos desenvolvedores, arquitetos;
e teste: representador pelos engenheiros de teste.
Apesar de chamar 3 amigos, essas discussões podem, e por diversas vezes devem, conter mais que literalmente somente 3 pessoas.
Por quê utilizar essa técnica?
Obter opiniões compartilhadas de diferentes expertises ajuda a definir melhor o que deve ser feito, evitando mau entendidos e falhas de comunicação.
Além disso, utilizar essa técnica contribui nos seguintes aspectos:
Definição de “qual o problema queremos resolver?”: muito antes de criar código, wireframes ou mesmo testes, é necessário entender bem o que precisa ser feito. Se não entendemos qual o problema queremos resolver com a nova funcionalidade ou correção, corremos um grande risco de entregar algo totalmente fora do real ou pretendido (Alguém aí já passou por isso? ver uma função ser discutida, desenvolvida, testada, e ao final do ciclo não ter nada a ver com o inicialmente pretendido);
Definição de pronto para ser desenvolvido (Definition of Ready): como sabemos se algo está bem definido o suficiente para começar a ser desenvolvido? o que entendemos por pronto para ser desenvolvido? – já discutimos, detalhamos o que deve ser feito, descrevemos em algum lugar, colocamos as estimativas e está pronto para ser pego por algum desenvolvedor para ser desenvolvido;
O mais comum é utilizar nas reuniões de refinamento de backlog (grooming/pbr).
Mas nada impede o uso dessa técnica durante o desenvolvimento – para sanar dúvidas de algo que está sendo desenvolvido, ou também depois que algo foi desenvolvido – para traçar melhores formas de teste. Pode ser utilizada até antes mesmo de uma reunião formal para definição de itens do backlog.
O intuito é ter sempre pessoas advindas de diferentes áreas discutindo e chegando a um consenso sobre o que deve ser feito.
Como isso influencia na qualidade do produto
A participação de testers desde as fases mais iniciais do ciclo de desenvolvimento é sempre benéfico pois eles serão capazes de levantar questões sobre testabilidade e sobre a qualidade do que deve ser produzido.
Além disso, as discussões que levam em consideração diferentes pontos de vista são mais ricas para originar cenários de uso.
Mais contribuições significam uma maior cobertura de possíveis cenários, possibilidades e restrições.
Com base nessa informação, os testers podem então aprender mais sobre o que cada área espera do software e traçar casos de teste mais eficazes, contribuindo para uma melhor qualidade do produto.
Mas isso quer dizer que sua boca não funciona corretamente? ou que suas mãos deixaram de lhe ser úteis? ou que seus pés esqueceram como é caminhar e devem ser substituídos?
Certamente não!
Morder a língua ou a bochecha de vez em quando não quer dizer que sua boca esqueceu como é mastigar e por isso não lhe serve mais. Nem que precisa de uma boca 2.0.
Deixar cair algo de vez em quando não significa que nossas mãos deixaram de nos ser úteis e por isso abandonamos seu uso.
Tropeçar de vez em quando não prova que seus pés esqueceram como é caminhar e perderam a serventia
Essas “pequenas falhas” simplesmente revelam a nossa natureza humana: somos falhos por definição.
Mas ainda assim, pisamos na lua, descobrimos a cura para diversas doenças, voamos, fazemos transplantes de órgãos tão importantes quanto um coração. Dentre outras realizações que seriam enxergadas como mágica ou impossíveis há não muitos séculos atrás.
E conseguimos tudo isso sendo seres imperfeitos. Realizamos várias maravilhas.
Nesse sentido, como na vida em geral, precisamos rever a definição debom o bastante no contexto de produzir software. A perfeição não é um estado em um determinado momento, estático. Pelo contrário, a perfeição é um processo de aprimoramento e correção constante.
Grandes empresas já entenderam o que é bom o bastante. Aquelas que mudaram a forma como comunicamos, nos relacionamos e até vivemos como Google, LinkedIn, Apple, Microsoft, Nokia.
E é também graças a esse reconhecimento da falibilidade que chegaram onde chegaram. Softwares imperfeitos foram colocados em produção, para todo mundo usar. O ciclo de correção foi encurtado apoiado pelos métodos ágeis, automação, CICD, DevOps.
E assim, iniciando com produtos bom o bastante, diversas empresas conquistaram grandes mercados e uma gama sem fim de realizações.
Como desenvolvedores de software de qualidade precisamos nos lembrar disso frequentemente, para não corrermos os risco de focarmos em padrões inalcançaveis e atrasar o lançamento do produto a tal ponto de não ser relevante.
Se você é um profissional de TI certamente já ouviu falar em abordagens ágeis quando se trata de como uma equipe que desenvolve software deve funcionar.
É bem provável que a empresa que você trabalhe aplique ou tente aplicar métodos ágeis em alguma profundidade.
Em maior ou menor instância, do jeito certo ou nem tanto, é bem provavel que sua empresa não funcione num processo cascata ou nos moldes clássicos. Ou pelo menos não deveria, a menos que seja realmente adequado para a realidade dos produtos que produzem.
Mas o que é ser ágil?
Resumidamente e simplificadamente, ser ágil consiste em respeitar um conjunto de 4 valores e 12 princípios descritos nomanifesto ágil em 2001visando construir um produto de melhor qualidade. Apesar dessa filosofia ter surgido com o desenvolvimento de software, hoje pode ser aplicado para desenvolver outros produtos também.
Existem diversas formas de aplicar os valores e princípios ágeis, e utilizar o SCRUM (que é um método ágil de funcionamento de equipes) é uma dessas formas. Mas existem outros métodos de trabalho para que uma equipe seja entendida como ágil como: XP, kanBan, lean, Crystal etc.
E se quem desenvolve software está usando SCRUM (como é o caso da maioria das empresas que desenvolvem software),
onde é que o gerente de teste está?
O gerente de teste, no SCRUM, não está em lugar nenhum. Isso acontece porque nesse método, não existe a figura dos gerentes, tão pouco do gerente de testes. No entanto, é possível verificar sua existência em muitas empresas que ainda estejam migrando para um funcionamento totalmente ágil.
Se não tem gerente de testes, quem gerencia os testes?
Numa equipe ágil (entenda-se scrum, pois é o método que a maioria das empresas aplica ou tenta aplicar), a função de gerenciamento é de toda a equipe.
A proposta é ter equipes auto gerenciáveis. Não há uma figura responsável por gerenciar algo dentro de uma equipe scrum. Pelo não com os títulos clássicos “gerentes”.
Lembre-se que o papel de gerenciar também não é do scrum master (que possui a função de manter a equipe funcionando da melhor forma possível, mas não de gerenciar o que cada um faz com um gerente tradicional).
Como qualquer parte de um projeto de teste (ou de software, em geral) para que se obtenha sucesso na automação dos testes é necessário planejamento.
Nesse sentido, é necessário decidir qual o melhor momento para incluí-la, juntamente com outros fatores como quais ferramentas serão utilizadas para tal, quais níveis (fases) de teste ela cobrirá, com quais técnicas (caixa preta, caixa branca, mutação, exploratóŕio) e quem os conduzirá.
Automatizar o teste de software significa muito mais que utilizar de ferramentas específicas de automação. E é claro que as ferramentas irão auxiliar a:
controlar bem a execução dos testes;
gerar e inserir dados;
comparar os resultados obtidos com os esperados;
gerar relatórios baseados em métricas definidas;
realizar os testes automaticamente em cada deployment (ou “deploy”).
Os motivos para essa automação são vários, dentre eles destacam-se alguns:
atender a pressão de mercado por entregas mais rápidas;
necessidade de maiores taxas de cobertura;
software como fator estratégico para sucesso das empresas;
recursos escassos, variantes;
“pequenas modificações” geram grandes taxas de reteste.
A automação pode ser inserida em praticamente todas as fases do processo de teste, desde unidade, passando por integração, sistema e até regressão. Em cada nível de teste existem diferentes responsáveis por essa automação.
Quando automatizar?
Que legal! se a automação pode ser inserida em qualquer fase do projeto, então vamos automatizar todos os testes e resolver os nossos problemas de cronograma e orçamento! Não é bem assim.
Ao contrário do senso comum, nem sempre a automação é a resposta para apertos no orçamento ou tempo. Primeiro, é natural que para se utilizar de automação, a equipe tenha um certo grau de conforto tanto com as ferramentas tanto com o produto sob teste, e isso leva tempo. Também, para desenvolver e configurar automações tempo é gasto, e quase sempre não é uma tarefa rápida. Segundo, se o orçamento é apertado, e a equipe não possui expertise em automação, dificilmente bons resultados serão obtidos.
Caso a equipe possua os conhecimentos necessários, para em pouco tempo incluir automação nos testes (o que quase sempre acarreta em gastar pouco a mais do orçamento) é possível ganhar em qualidade do produto ao incluir automação. Do contrário, pouco provável.
Em vias gerais, para automatizar é necessário verificar se com automação haverá ganhos para o projeto. Se haverá economia de tempo e esforço dos analistas de teste (o que influencia na entrega como um todo); se a qualidade do produto será melhorada com isso (com a automação é possível se testar mais casos, aumentando a cobertura); se os testes serão reutilizados; etc. Se não houverem ganhos reais a serem obtidos com a automatização, dificilmente você conseguirá explicar para os diretores/gerentes/clientes porque o orçamento e tempo foram gastos com isso.
Pontos a se observar para a automatização dos testes
Para incluir automação de testes em algum projeto sugiro que se observem alguns pontos:
1. A equipe tem um certo grau de conhecimento sobre as ferramentas, técnicas, linguagens que serão utilizadas?
Caso seja o primeiro projeto em que a equipe utilizará automação, tempo a mais para essa automatização será necessário, uma vez que será a partir desse projeto que a equipe começará a ter noções de tempo, dificuldades, etc. Além do tempo a mais de aprendizado, que cada membro da equipe terá.
2. O cronograma e o orçamento do projeto são extremamente apertados?
Caso o cronograma e o orçamento do projeto sejam muito apertados, só vale a pena automatizar caso o primeiro item dessa lista de observações seja respeitado. Se a equipe ainda não possui expertise, provavelmente não é uma boa ideia começar a automatizar em um projeto restrições nos recursos. Pelo menos não como um todo. Mas é possível começar por pequenas partes, que são possíveis de serem feitas mesmo nessa “correria”.
3. O produto possui requisitos com certo grau de estabilidade?
O cliente quase nunca sabe o que quer com certeza, ou pode ter vontades voláteis Vivemos em um mundo de constantes mudanças. Assim, dificilmente os requisitos estarão fechados. No entanto, em um determinado momento do projeto, eles começam a ser relativamente estáveis. E é a partir daí que se pode desenvolver automações para os testes. Gastar recursos para desenvolver automações para funções que certamente serão mudadas é desperdício de esforço e tempo.
4. Tarefas repetitivas.
Sempre existe aquele fluxo que a gente tem que passar zilhões de vezes para garantir que está tudo certo (softwares que lidam com financeiro ou sessões críticas tem muito isso). Como esses fluxos tendem a ser mais estáveis, são grandes candidatos a automação e podem se beneficiar muito (em termos de profundidade e cobertura) da automação. Além de ampliar a qualidade, diminui o cansaço do testador em realizar diversas vezes a mesma coisa.
Automação e teste de carga
Além dos pontos comentados anteriormente, alguns tipos de teste seriam praticamente impossíveis de serem executados se não houvessem a automação, técnicas e ferramentas específicas para os tornar possíveis. O teste de carga é um desses tipos de teste.
O objetivo do teste de carga é verificar a quantidade de usuários/requisições/solicitações um produto consegue atender simultaneamente (ou seja, qual a carga esse produto consegue suportar). Assim é possível se ter uma noção de como a aplicação se comportará quando houver vários usuários utilizando-a ao mesmo tempo, e como isso, tomar decisões quanto a alocação de recursos para tal.
Como se trata de um teste no qual é necessário a simulação do acesso de várias pessoas, nada mais natural que a necessidade de uma ferramenta para tal simulação. Sendo assim, a escolha de uma ferramenta é um fator essencial para o teste de carga.
A escolha da ferramenta depende de qual fase de teste o teste será aplicado. Muito provável que esse teste será aplicado na fase de sistema, quando o produto já estiver com a funcionalidade pronta para ser apresentada ao usuário.
Esse tipo de teste é extremamente importante para grandes aplicações que recebem imensos volumes de acesso em determinados períodos, por exemplo: sites onde são divulgados resultados de concursos; sites de notícias; sistema da receita federal; sistemas de vendas de ingressos para shows.
Concluindo
A automação de testes pode sim contribuir para o desenvolvimento de produtos com maior qualidade, por meio da ampliação da profundidade e cobertura dos testes e diminuição do esforço gasto. Porém, para que seja utilizada, alguns pontos devem ser observados.
Sugestões de Ferramentas Gratis para Automação
Se você é um profissional de teste, certamente já ouviu falar do Selenium para automação de teste em navegadores. Particularmente eu o acho bem versátil e poderoso, principalmente quando utilizado com alguma linguagem de programação (gosto muito de java =}). Ele possui duas versões:
IDE: é um plugin que se instala no navegador. Possui o funcionamento mais simples, e é o mais indicado se você está começando agora comSelenium. Funciona como “capture/replay”, ou seja, gravando e executando ações que se quer;
WebDriver: um pacote java (JAR) com as funções mais elaboradas. Utilizando essa versão você terá maior versatilidade e poder de teste. Pelo fato de se poder utilizar uma linguagem de programação para criar os testes, é possível fazer bastante coisa com essa versão. Para agilizar, você pode gravar partes do fluxo com o IDE e exportar para a linguagem que deseja utilizar.
Além do Selenium, existe o Jmeter que pode ser utilizado para testes funcionais também, mas que proporciona um maior poder de teste para testes de carga/estresse.
Outras ferramentas super importantes para automação são Capybara, Rspec.
Se você é um profissional de TI certamente já ouviu falar em abordagens ágeis quando se trata de como uma equipe que desenvolve software deve funcionar. 