Planejamento para Automação de Teste em Ágil

Introdução

Sabemos que a automação de teste em um contexto ágil é obrigatória, independente se esta ação será feita por uma pessoa focada (testador) ou pelos membros do time. O importante é saber como podemos planejar a automação em cada pequena fase que temos.

A seguir veremos como é a big Picture dos Níveis de Detalhe para o Planejamento e, na sequência, como podemos nos planejar para o Nível de Release.

 

Níveis de Detalhe (precisão) para o Planejamento

Há quatro níveis que podemos facilmente identificar quando focamos no planejamento da automação de teste em projetos ágeis:

  • Nível de Release: Visão do todo e planejamento em alto nível sobre automação
  • Nível de Feature: Visão de uma funcionalidade e planejamento específico
  • Nível de Story: Visão macro do que será feito frente a o planejamento
  • Nível de Tarefas: Visão micro e aplicação prática de todo o planejamento

01_niveis_detalhe

Planejamento em Nível de Release

No planejamento de um release o time já tem uma ideia da visão do produto. Como é uma visão nós podemos fazer um planejamento em alto nível. Neste momento devemos também pensar no todo, principalmente no que podemos aplicar de novas práticas, ferramentas, necessidades de ambiente e aplicação de algumas técnicas de teste.

Ao final do release é necessário ter todos estes pontos já desenvolvidos e desempenhados, logo o planejamento em termos de automação no release foca mais em aspectos que possam mudar ou impactar o planejamento como vem sendo feito.

Quando a release inclui um produto com novas tecnologias é necessário separar um tempo para experimentos, aplicações e aprender sobre possíveis problemas de design. Também é necessário levantar todos os riscos necessários

02_nivel_release

Em resumo, no Nível de Release:

  • O Time já tem uma boa visão do todo
  • É o melhor momento de pensar em:
    • Ferramentas
    • Ambiente
    • Práticas/Técnicas de Teste (Performance, Segurança, etc…)
  • Quando há novas tecnologias é necessário:
    • Fazer experimentos
    • Levantar possíveis problemas de design
    • Riscos
Nenhum comentário »

Categorias deste post

Técnico, Testes, Time de desenvolvimento

3 Dicas para a Documentação de Teste em uma Equipe Ágil

  1. Minimize a sua documentação

Não crie documentos só porque é uma prática da empresa se você não sabe realmente onde ele será empregado (como será utilizado, quem irá ler o documento, etc…).

Criar documentação “só por criar” gera um custo muito alto, visto que temos sempre “pouco” tempo para uma entrega. Logo devemos criar somente entregáveis utilizáveis. Se o documento que você está criando não é utilizável interna ou externamente ele pode ser removido.

Se há documentos que você precisa criar por conta de alguma legislação, obviamente, crie! Mas não se esqueça que este deve ser estimado e priorizado (sim, ele vira uma tarefa) e precisa fazer parte da sua Definição de Pronto (DoR).

Exemplo prático referente a teste de software – Evidência de Teste

Muitas instituições financeiras necessitam documentar as evidências de teste. As evidências de teste são prints de telas, de partes estratégicas da aplicação, que são colocadas com uma descrição. É muito comum criarmos evidências de teste quando encontramos bugs para reportar a uma pessoa/equipe quando este não pode ser corrigido imediatamente, mas também é uma prática documentar os cenários de sucesso por conta de legislações vigentes em instituições financeiras (Sox)

doc-de-teste-agil-blog

  1. Mantenha a documentação sempre simples

Criar gráficos, tabelas, diagramas coloridos e qualquer outro apelo visual que só servirá para “deixar o documento mais bonito” e sem informação efetiva, ou com muita informação, só faz você perder tempo. Seja simples e direto no documento. Ninguém gosta de perder tempo (horas) lendo algo que poderia ser absorvido em minutos.

Exemplo prático referente a teste de software – Plano de Teste

Antigamente (não muito tempo atrás) e até hoje muitos testadores mesmo em times ágeis continuam criando documento de Plano de Teste em um padrão/template conhecido da IEEE 829 (referente a documentação de teste). O documento é muito extenso, possui vários tópicos e não é nada direto, ou seja, uma perda de tempo precioso para o time.

Agora pense comigo: o testador (ou o papel deste) não planeja os critérios de aceite com vocês (time)? Já não está saindo o planejamento ai? Precisa de documenta para isso?

Há alguns casos, obviamente, onde iremos fazer um planejamento prévio como por exemplo a aplicação de testes de Performance, Carga e Stress. Mas no dia a dia o documento é bem pouco utilizado e, mesmo que você crie, foque em pontos chave e não o deixe extenso.

Sugiro a leitura da sessão Test Planning do Livro Agile Testing.

  1. Documente somente quando necessário

Focar na criação de diversos documentos que você necessita ao longo do tempo não é uma boa ação (big-requirement-upfront). A documentação de teste deve ser criada por demanda e, se tiver necessidade, por partes. O tamanho da documentação também importa. A documentação tem que ser objetiva, mas não pode habilitar o contexto da comunicação como em uma User Story: o documento de testes deve ser entendido por todos os membros do time e agentes externos (stakeholders) para que todos tenham um exemplo real de como a funcionalidade/requisito/regra deve funcionar.

Exemplo prático referente a teste de software – Critérios de Aceite descrito como Especificação por Exemplos

Uma documentação obrigatória para habilitar o entendimento dos requisitos, guia do desenvolvimento e validação pelo usuário final é o Critério de Aceite. Ela é criada geralmente em conjunto com o time e o cliente.

Este pode ser escrito de diversas formas. A mais recomendada para o entendimento por todo time é através da Especificação por Exemplos.

Através dela podemos, de uma só vez, informar como será o detalhe do requisito em termos de utilização mais o exemplo de dados que utilizaremos.

Uma forma comum é adotar a escrita dos Critérios de Aceite através do Ghekin (Given, When, Then). Abaixo um exemplo:

Dado que eu estou na página inicial da Adaptworks

Quando eu pesquisar pelo treinamento “Agile Testing”

Então o treinamento “Agile Testing” é apresentado

 E o treinamento “Agile Testing Automation” é apresentado

Exemplo prático referente a teste de software – Plano para Testes de Performance

O plano para a execução dos Testes de Performance é um exemplo de uma documentação de teste evolutiva ao longo do projeto. Vamos pegar o exemplo onde precisamos executar testes de performance antes da entrega da Release. A cada iteração iremos planejar quais serão os fluxos criados para o script de teste, coletar a massa de dados necessária, conversar com o pessoal de infraestrutura para ter um ambiente suportado ou mesmo o ambiente de produção, aplicação de monitores em diversas partes da arquitetura, etc…

Isso é muito difícil de fazer em apenas uma iteração, onde dividimos todas as tarefas referente a esta ação em diversas partes.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

1 Comentário »

Categorias deste post

Técnico, Testes, Time de desenvolvimento

O que buscar em uma plataforma ALM Agile ?


Application Lifecycle Management
(ALM) é o processo de gestão de todas as fases do ciclo de desenvolvimento de software a partir de requisitos iniciais até o lançamento de uma release. Plataformas de ALM são end-to-end de soluções integradas para a gestão destes processos de uma empresa, bem como, a perspectiva técnica.
Agile é uma metodologia de desenvolvimento de software interativo que vem crescendo rapidamente entre os desenvolvedores e está moldando o mercado de ALM, com desenvolvedores corporativos cada vez mais preocupados em migrar das metodologias tradicionais de desenvolvimento de software para uma abordagem mais ágil. Ágil e ALM, dois segmentos de mercado distintos, estão agora começando a se consolidar. Como resultado, temos agora o que chamamos de plataformas ALM Agile.

 

Estamos treinados a entender plataformas ALM que dividam em grandes ciclos o desenvolvimento do software, como: planejamento, gestão, construção, teste e elaboração de relatórios.

Precisaremos adquirir conhecimento prévio sobre metodologias e frameworks ágeis, para então realizar a avaliação segura de uma ferramenta que trabalhe em harmonia com as metodologias ágeis aderentes a realidade do time e tamanho de empresa, quando pensamos em escala. Essa avaliação levará em conta alguns dos principais passos envolvidos no ciclo de desenvolvimento e entrega de software em produção:
alm

1)
Integrar valores ágeis, processos e princípios para a plataforma de ALM;
2) Gerenciar o ciclo de vida do aplicativo como um Fluxo de Valor Único;
3) Alinhar o negócio com a TI mantendo foco no “entregável”;
4) Suportar a diversidade de ambientes de desenvolvimento;
5) Ser horizontal no gerenciamento de times e flexível;
6) Proporcionar transparência e rastreabilidade;
7) Suporte End-to-End – visibilidade estratégica.
Sabemos que valorizar indivíduos e interação entre eles mais que processos e ferramentas é ser ágil, então quando avaliar uma ferramenta estiver em pauta, esta avaliação deve ser baseada em critérios claros de consolidação entre os conceitos de ALM e os conceitos ágeis. E essa ferramenta deve proporcionar imagens claras, precisas ou imediata de um estado de produto ou fluxo de valor em desenvolvimento.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Time de desenvolvimento

Quem é o Agile Tester?

A definição

agile-tester-artigo1Segunda Lisa Crispin e Janet Gregory em seu livro Agile Testing: A Pratical Guide for Testers and Agile Team [1] o que define o Agile Tester é:

Definimos o Testador Ágil neste sentido: um profissional que encara as mudanças, colabora bem com pessoas técnicas e de negócio e entende o conceito de usar os testes para documentar os requisitos e guiar o desenvolvimento.

Testadores Ágeis tendem a ter bons conhecimentos técnicos, e sabem como colaborar com outros membros do time para automatizar testes e também são experientes em executar testes exploratórios.

Eles estão dispostos a aprender o que os clientes fazem para que eles possam entender melhor os requisitos.

Eu, propositalmente, dividi em três partes para ficar mais visível tudo o que um Agile Tester é e o que ele pode fazer!

Mas a primeira resposta a pergunta “Quem é o Agile Tester?” é: qualquer pessoa do time!

Porque qualquer pessoa pode pegar uma tarefa de teste para executar. Qualquer pessoa pode pensar como um usuário no momento de um planejamento. Qualquer pessoa pode executar um teste exploratório.

Para alguém do time possuir estes skills, primeiramente, ele precisa ter o MindSet do Teste Ágil.

O MindSet do Teste Ágil

agile-tester-artigo2O time, ao invés de entregar o melhor produto, deve entregar o melhor valor de negócio para o cliente através de um produto, certo?

A grande maioria dos times focam em entregar o melhor produto, mas nem sempre o melhor produto traz o melhor resultado de negócio.

É aqui que o MindSet entra: trocar informações constantes e colaborar com o cliente* a fim de ajuda-lo a expressar de forma adequada os requisitos.

O restante dos pontos é a viabilização disso (tarefas). O MindSet é único: colaboração com o cliente para que ele mesmo entenda o que está pedindo.

Alguns itens que podem ser adicionados ao MindSet são:

  • Criatividade
  • Estar aberto a novas ideias
  • Disposição para assumir qualquer tarefa
  • Foco no cliente
  • Visão constante na Big Picture (no todo)

* a palavra “cliente” pode ser interpretada como o cliente real ou o product owner (dono do produto)

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Agile, Técnico, Testes, Time de desenvolvimento

Personas Ágeis para User Stories

Descrição completa

Por que personas são relevantes em contextos ágeis?

Em projetos ágeis “personas” devem ser vistas como uma ferramenta fantástica nas mãos de um time.
A equipe do Product Owner (composta pelo P.O., especialista em experiência do usuário, analista de negócios…) pode, facilmente, utilizar de “personas” para alinhar suas expectativas com o time funcional (arquitetos, desenvolvedores, testes…) proporcionando uma visão compartilhada e realista do produto em desenvolvimento. E usar personas pré-definidas como atores de user stories farão com que os requisitos descritos tenham mais credibilidade e mais envolvimento, aproximando-os ainda mais da realidade.

Detalhando:

personas-ageis-para-user-storiesPersonas é uma ferramenta de usabilidade que utiliza pessoas fictícias para representar usuários. Utilizamos personas em projetos centrados no usuário (For Them By Us), definindo os objetivos e desejos dos reais usuários, orientando decisões como: a interface, a navegação, os recursos e demais elementos do projeto de design.

Usar personas é recomendado quando não há nenhuma documentação sobre quem é o usuário do seu produto ou se quer especializar a UI (user interface) do produto para o seu público alvo, com base em pesquisas entrevistas, etc. Mas quando estamos em um projeto onde o usuário final não é humano, por exemplo um sistema system-to-system, uma API, etc. onde nenhum que irá interagir com o sistema é humano acho que não faz muito sentido usar personas.

personas-ageis-para-user-stories_2E como explica Martin Fowler, User Stories focam nos objetivos
do usuário e como o sistema alcança esses objetivos. User Stories devem ser curtas, simples e claras. Devemos conseguir escrevê-las em um simples e pequeno cartão

Alguns perguntarão o motivo desta proposta estar em “Design” – lembrando que design é a idealização, criação, desenvolvimento, configuração, concepção, elaboração e especificação de objetos que serão produzidos. O projeto de design necessita de uma análise informacional, a partir de um ponto de vista. Detectar corretamente as “personas-usuárias” e relacioná-las ao objetivo do projeto (user stories) é essencial para um bom planejamento, de modo que as ações sejam tomadas de forma correta – assim, segue esta proposta, pois para quem é designer, quem é o usuário, e quem é o público final, representa o primeiro passo.

Sugestão de dinâmica para aprendizado de Personas

Mecânica do Workshop

1) O grupo de participantes será dividido em 5 times, através de uma dinâmica simples, baseada na diversidade de informações sobre os próprios participantes (onde moram, onde trabalham, cargo exercido, idade, sexo, etc.) fazendo-os mixarem-se em times que prevaleça a diversidade. (time-box 5 minutos)

2) Um sistema web “fictício” em desenvolvimento será mostrado: loja online de feijoadas delivery. E algumas informações sobre cozinheiros, fornecedores de ingredientes e clientes desta loja online de feijoadas delivery serão apresentados: em slides e cartões de papel e entregues aos times.
A facilitadora se nomeará Product Owner principal do produto: loja online de feijoadas delivery. (time-box 5 minutos)

3) Uma introdução sobre personas “driven-design-personas” será apresentada aos times: em slides e cartões de papel e entregues aos times. (time-box 15 minutos)

4) Serão solicitados a criação de mais 2 personas por time, a partir das informações apresentadas previamente. (time-box 10 minutos)

5) Uma introdução sobre user stories, baseadas nos 3Ws e 3Cs será apresentada aos times: em slides e cartões de papel e entregues aos times. (time-box 10 minutos)

6) Serão solicitados a criação de mais 3 user stories por time, a partir das informações apresentadas previamente para as 2 personas criadas pelo próprio time. (time-box 15 minutos)
– Durante o processo de criação, de personas e US pelos times, a facilitadora irá circular pelos participantes esclarecendo dúvidas e pontuando conceitos dados.

7) Os times apresentarão suas personas e user stories para os demais participantes, com pequenas intervenções da facilitadora para garantir time-box e ressaltar conceitos vistos. (time-box 15 minutos)

8) Encerramento e dúvidas. (time-box 5 minutos)

Benefícios

Uma grande vantagem de se utilizar personas é que se pode facilmente interligá-las com user stories, em substituição do “ator”. Isto faz com que suas personas e user stories tenham mais credibilidade e mais envolvimento, aproximando ainda mais da realidade.

E a melhor forma de aprender sobre personas e interliga-las com user stories de um produto, é escrevendo ambas. Hand´s on.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Time de desenvolvimento

A origem do Agile Testing

Origem

Se você já leu algo referente a Agile Testing vai lembrar logo do livro Agile Testing, que foi lançado em 2009, e associar que a origem do termo veio das duas autoras Janet Gregory e Lisa Crispin, certo? Errado!

Em 2002 Bret Pettichord já falava sobre Agile Testing [1] associando ele também com princípios de Context Driven Testing [2]. Na sequência, em 2003 Brian Marick criou o Quadrante de Teste Ágil para distinguir dentro de um processo ágil os testes baseados em negócio e em tecnologia, e os de suporte ao time dos de crítica ao produto.

A Elisabeth Hendrickson em 2008 também já falava sobre Agile Testing na sua palestra Agile Testing, Nine Principles and Six Concrete Practices for Testing on Agile Teams [3].

Lisa Crisprin, em 2002, trabalhou em um time que aplicavam as práticas de XP – Extreme Programming e já começava a criar algumas técnicas de como um testador poderia trabalhar em um time XP. Logo após o primeiro livro formal sobre o assunto foi lançado: Testing Extreme Programmimg [4]. Anos depois ela e a Janet Gregory lançaram o livro Agile Testing que é um compilado das experiências das autoras no processo de transição do Teste Tradicional para o Teste Ágil e como o testador pode ajudar a equipe.
Hoje este livro é a principal referência sobre Agile Testing.

Teste Tradicional x Agile Testing

A imagem abaixo já vai ilustrar uma similaridade e a diferença da adoção de cada abordagem:

origem-agile-testing

origem-agile-testing_2

No projeto por fases podemos ver nitidamente que há uma fase de testes, mas esta depois do desenvolvimento ter sido concluído. A ideia do tamanho das caixas nos passa uma falsa impressão que realmente teremos tempo para testar, mas o que acontece em diversos projetos (até hoje) é a fase de testes ser diminuída e termos uma nova caixa antes da Entrega: o “Teste->Bug->Correção->Reteste” que toma muito mais tempo do que qualquer planejamento inicial de testes.

No Agile os testadores trabalham em cada Interação junto ao time e testam a funcionalidade mesmo quando ela está em desenvolvimento. A funcionalidade/requisito/regra (User Story + Critérios de Aceite) só estarão realmente entregues depois de testado (que são pontos do DoD – Definition o of Done).

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Testes, Time de desenvolvimento

Usabilidade não é “User Experience” (UX) – Mas é Ágil

Usabilidade não é a experiência do usuário, ela ajuda a melhorar, e muito, essa experiência. A maior parte das pessoas ainda confunde UX com Usabilidade. É comum vermos gerentes de projeto, designers, arquitetos, todos substituindo o termo usabilidade unicamente por UX, dizendo equivocadamente “A ´UX´ do site está pronta?”

Apesar de parecer complexo, UX se resume em uma única frase: UX É CONCEITO.
E este conceito está em total harmonia com os conceitos ágeis.

Entendendo:

Temos experiência de usuário em contextos diversos.

Por exemplo, quais sensações e percepções um cliente de fast-food tem ao adquirir e saborear sua refeição? Este cliente é o usuário desse sistema. E quais são as sensações e percepções deste mesmo cliente ao se alimentar em um restaurante gourmet, com refeições à la carte?

Serão experiências diferentes e que não significam melhores ou piores, mas diferentes para o tipo de necessidade do momento.

Os designers direcionam a experiência do usuário. Eles podem gerar fluxos de página, wireframes e, claro, um mapa do site, adicionar testes de usabilidade e revisões. No entanto, UX designers terão uma abordagem diferente, eles levam em conta o proposto pelo design, mas também vão considerar os objetivos emocionais de seu usuário final. Seu foco pode ser mais em torno de modelos de interação, ao invés de estrutura e layout.

A partir do entendimento do que não é UX, entenderemos melhor o conjunto de “usabilidade e UX” no contexto ágil.

ux

Emprestando a hierarquia de necessidades de Maslow, que nos diz que o software deve ser funcional, o software deve ser fácil de usar – ressaltando a importância de Jakob Neilsen – onde o software precisa ser prazeroso, usando os conceitos de Emotional Design de Donald Norman – pioneiro na usabilidade – conceituaremos “UX preocupado com o design e usabilidade” e por fim com o engajamento emocional dos usuários, através da discussão prática sobre:

--

  1. Curva de Aprendizado,
  2. Curva de Satisfação,
  3.  Atendimento de uma necessidade do usuário,
  4. Feedback do usuário.

A seguir temos 10 dicas de como integrar o conceito UX às metodologias ágeis.

  1. Direcionar e incorporar: praticantes de UX devem fazer parte do time do cliente ou Product Owner;
  2. Realizar práticas de pesquisa, modelo, e design antecipado – mas apenas o mínimo necessário;
  3. Divulgar e aplicar o conceito de “Personas”;
  4. Utilizar de um fluxo de desenvolvimento paralelo avançado com acompanhamento do avanço através de feedbacks;
  5. Ganhar tempo de design com histórias complexas de arquitetura;
  6. Cultivar um grupo de usuários para validação contínua;
  7. Aproveitar o tempo do usuário para diversas atividades como inception ágil ou grooming;
  8. Utilizar protótipos de baixa fidelidade;
  9. Tratar os protótipos como especificação;
  10. Tornar-se um facilitador de design.

UX não é usabilidade – mas é ágil: define conceitos, discute a forma de trabalho ágil em uma disciplina – design – vista como arte. E sabemos, arte dificilmente pode ser definida com time-boxes. Com dicas práticas e experiência, no complexo ambiente do software, a apresentação e a discussão em torno do assunto ajuda a clarificar e evoluir a disciplina que tanto cresce neste ambiente. E aqui falamos de adaptabilidade e aprendizado contínuo, agilidade em sua essência.

___________________________________________________________________________________________________________________

Gostou? Fique ligado no nosso blog que logo logo tem mais!

Não esqueça de deixar seu comentário 😉

Facebook  |  Twitter  |  Linkedin | Youtube

Nenhum comentário »

Categorias deste post

Técnico, Time de desenvolvimento

QUnit para Javascript com Filosofia Aplicada: – ”O conhecimento é sempre uma tradução, seguida de uma reconstrução”. – Parte I

Em os Sete Saberes, Edgar Morin nos conta que “conhecimento” e “conhecimento pertinente” são dois aspectos para os quais devemos nos atentar, devido à complexidade educacional do mundo atual. Mundo esse que intitulamos de era digital ou era do conhecimento.

Considero o princípio da complexidade, premissa, para qualquer estudo de softwares ou das disciplinas interligadas. As ‘boas práticas’, já fundamentadas e experimentadas em estudos anteriores, me servem de guia para meus estudos, porém entendo que práticas podem, naturalmente, emergir, em contextos complexos. E o modelo educacional, discutido, por Morin  atende perfeitamente como modelo de aprendizagem e desenvolvimento de competências ao ambiente dinâmico imposto tecnológica e financeiramente aos profissionais de áreas digitais e afins.

Em Sete Saberes lemos que “conhecimento nunca é um reflexo ou espelho da realidade. O conhecimento é sempre uma tradução, seguida de uma reconstrução”.

Como desenvolvedora, há alguns meses uma curiosidade investigativa sobre testes de unidade em frontends e a tentativa de provar suas vantagens e desvantagens, tem me feito dedicar alguns momentos ao estudo ao framework Qunit aplicado para JavaScript.

E gradualmente uma cadeia de valor sobre o assunto vem acontecendo. Gosto do modelo cadeia de valor do conhecimento, sintetizado, na figura a seguir. Este gráfico reflete como venho adquirindo competência sobre o assunto: testes de unidade em QUnit.

cadeiadevalor

Figura 1 . Cadeia de valor do conhecimento (Fonte: ROWLEY (2007)

E consigo visualizar o ciclo desta cadeia de valor, fundamentada mais uma vez por Edgar Morin e sua teoria. Em uma sequência lógica: dados obtidos do framework de testes, propriamente dito, no site do qunitjs.com e escritos em código Javascript, somados a informações de tutoriais, vídeo-aulas e ideias de testes transformam-se através da prática em conhecimento. No decorrer do tempo esse conhecimento, aplicado e validado, poderá ser reconhecido como uma nova competência adquirida. Aqui identificamos a tradução seguida de uma reconstrução.

Voltando a Grécia antiga, lembramos a visão racionalista de Platão, que afirma que o conhecimento é “uma crença verdadeira justificada”.

E Morin quando nos diz que podemos e devemos aprender por disciplinas, aprendizado por partes, reafirma Platão pois nos diz que temos a capacidade de contextualização do conhecimento, “e é essa capacidade que deve ser estimulada e desenvolvida pelo ensino, a de ligar as partes ao todo e o todo às partes. Pascal dizia, já no século XVII: “Não se pode conhecer as partes sem conhecer o todo, nem conhecer o todo sem conhecer as partes””. E esse conhecimento contextualizado é o segundo aspecto tratado por Morin como “conhecimento pertinente”.

Na prática diária conseguimos criar programas complexos quando o dividimos em unidades menores, compreensíveis, e depois juntamos essas unidades sem que o contexto perca seu objetivo inicial. O teste de unidades – que tanto falamos e executamos – é o teste dessas partes menores. Mas se você ainda não escreveu testes de unidades para o seu código, talvez rever seus conceitos lhe ajude na construção de conhecimento. Esses testes lhe ajudam a pensar sobre seu código de uma forma organizada, minimizam o risco e o esforço ao mudar o código e incentivam o design modular – que tem seus próprios benefícios.

Vamos iniciar uma nova ‘cadeia de valor de conhecimento’, coletando e gerando dados de testes de unidade, com QUnit, para um código simples em JavaScript.

O que é o Qunit?

QUnit é um poderoso framework de testes de unidade JavaScript e muito fácil de usar. Pode ser utilizado em projetos jQuery, jQuery UI e jQuery Mobile, e é capaz de testar qualquer código JavaScript genérico, incluindo a si mesmo!

QUnit pode ser utilizada para testar código JavaScript puro ou mesmo o comportamento do DOM. Por  exemplo, os plugins do JQuery são testados com QUnit, e não somente os códigos de lógica e classes.

Como qualquer ferramenta de teste, o QUnit é perfeito para teste de regressão, afinal, uma vez que um bug é encontrado, você pode criar um teste para validar a existência dele, e após corrigi-lo, verificar a correção, rodando novamente o teste toda vez que você trabalhar no código.

Você não precisa instalar nada de especial para rodar o QUnit, é necessário apenas referenciar o script do Qunit e rodar seus testes no Browser.  O download do script é encontrado no site qunitjs.com, ou pode ser usando diretamente do repositório Git.

Vamos ao primeiro exemplo!

Usaremos uma página HTML simples para testar o nosso “Oi mundo”. Essa página HTML será nossa centralizadora da suíte de testes que estamos iniciando.

Para usar QUnit você só precisa incluir dois arquivos na sua página HTML. QUnit consiste do qunit.js e qunit.css e, também, iremos do quadro “tests runner”, que desenharemos e utilizararemos estilos para a página de suíte de teste exibir os resultados dos testes.

Esta HTML será nossa QUnit “test runner”.

HTML01

Figura 2. HTML pata Qunit Test Runner

Deixaremos o script de teste, que chamamos de testsoimundo.js fora da página HTML.

Manter seu código de teste e suporte à arquivos fisicamente e logicamente separado do código que você está realmente tentando escrever, ou testando unitariamente é importante, e a esses códigos de teste de unidade chamaremos de Suíte de Testes, ou ST. Crie uma pasta separada para abrigar todo o seu código de teste e bibliotecas de suporte, sua ST. Nesta pasta teremos: a Biblioteca QUnit, quaisquer outras bibliotecas específicas para a ST, sua página HTML “test runner” e os arquivos JavaScript que contêm o código de teste. Mas, obviamente, que bibliotecas que são usadas pelo ST e já se encontram em qualquer outro repositório não precisam ser copiadas, podem ser referenciados nas suas localizações originais. Como fizemos com a biblioteca Qunit em nossa HTML “test runner”.

HTML02

Figura 3. Código de teste

Quando a pagina HTML é executada em qualquer browser os testes são executados dinamicamente e exibidos na própria página, por isso a nomenclatura HTML “test runner”.

 

testrunner

Figura 4. Test Runner – visualização

 

O cabeçalho do pacote de teste exibe o título da página e uma barra verde quando todos os testes passaram (ou uma barra vermelha quando pelo menos um teste que falhou), abaixo do cabeçalho vemos algumas caixas de seleção para filtrar os resultados dos testes e uma barra azul com a versão, que foi solicitada pelo navigator.userAgent (útil para screenshots dos resultados dos testes em diferentes navegadores ) .

Das caixas de seleção: “Hide passed tests” é útil quando muitos testes foram executados e apenas alguns falharam. Selecionando esse filtro todos os testes bem sucedidos serão ocultados tornando mais fácil a concentração nos testes que falharam.

Selecionando “Check for Globals ” o QUnit fará uma lista de todas as propriedades no objeto janela, antes e depois de cada teste , para que diferenças sejam verificadas. Isso ajuda a certificar-se de que seu código de teste e código em teste não exportam, acidentalmente, todas as propriedades globais.

Selecionando “No try-catch ” o QUnit irá executar o teste fora de um bloco try-catch . Quando o teste lança uma exceção , o testrunner vai morrer, incapaz de continuar a execução, mas você terá uma exceção “nativa”, o que pode ajudar tremendamente a depuração em navegadores antigos.

Abaixo do cabeçalho é um resumo que mostra o tempo total de execução de todos os testes, bem como o número total de verificações de sucessos e falhas.

O conteúdo real da página são os resultados do teste. Cada entrada na lista numerada começa com o nome do teste seguindo-se, entre parêntesis, o número de falhas, sucessos, o total de verificações. O link “ReRun” é para que qualquer teste possa ser executado individualmente.

Mas até aqui foi fácil!

Até este momento, revisando nossa cadeia de valor, informações básicas foram transmitidas. E o conhecimento ainda é raso para adquirir competência nesse assunto aprofundemos um tanto mais!

Edgar Morin nos dá, como terceiro aspecto, a Identidade Humana. Sim, nós somos geradores e consumidores de conhecimento que flui do ser humano para o ser humano em sua maior intensidade.

“Eu acredito possível a convergência entre todas as ciências e a identidade humana. Um certo número de agrupamentos disciplinares vai favorecer esta convergência. É necessário reconhecer que na segunda metade do século XX, houve uma revolução científica, reagrupando as disciplinas em ciências pluridisciplinares.” (Edgar Morin em Os 7 Saberes).

Porque, nos dias de hoje, testar código na sua origem não é diferencial e sim uma questão de higiene básica de TI?

Evoluímos em nosso conhecimento sobre produtos digitais e amadurecemos na disciplina gerenciamento de produtos, construímos e mantemos software em funcionamento por anos a fio. Falamos muito em manutenção de código legado. Sendo assim, construir código com teste nos garante eficiência em sua manutenibilidade, seja esta planejada ou não. Ter código com cobertura de testes proporciona segurança e rapidez em alterações emergentes de adequação ao mercado. Testes deixa um produto digital mais competitivo.

Em um próximo post nossa preocupação será testar o frontend de aplicações. Testaremos as interações que outro ser humano terá com o software.

Até breve!

Nenhum comentário »

Categorias deste post

Agile, Técnico, Time de desenvolvimento

Introdução do Quadrante de Teste Ágil

Uma pergunta muito comum, quase sempre vinda de um profissional de testes, dento da linha ágil é: como vou testar no Scrum?
Essa pergunta geralmente é feita por falta de conhecimento em agilidade, e a resposta é que não existe fórmulas, padrões ou receitas de bolo de testar utilizando Scrum , XP, Kaban ou qualquer prática ágil para desenvolver um software.

Muitos tem sede de ter um processo, uma fórmula para trabalhar com testes em agilidade, mas isso é mais fácil do que imaginamos…
Mas antes vamos conceituar um pouco o porque disso.

 

Conceituação no modelo tradicional

No modelo que podemos chamar de tradicional temos duas abordagens distintas com algumas dimensões, além de separação clara de papéis e atividades. Enquanto parte dos profissionais de análise de negócio, arquitetura e gestão trabalhavam no desenvolvimento dos requisitos, o testador criava uma série de documentos para verificar se os requisitos estavam de acordo com o que foi pedido, mas muita coisa era perdida e o foco era (ou ainda é em algumas empresas) em pesadas documentações e checklists.
O Modelo V de Testes foi um guia por muito tempo neste ponto, trazendo quatro níveis e chamando estas etapas de Verificação: requisitos, análise, arquitetura e codificação (este compartilhado com o próximo grupo de nível).
Neste ponto os testadores também criavam os casos de teste, quando o time já estava na fase “codificação”

Quando chegava a fase em que um grupo de funcionalidades já estava apta a ser testada entramos na fase de validação, que consiste nos níveis: unidade, integração, teste a aceitação. Neste ponto começam os testes como conhecemos no modelo tradicional.

O Modelo V de testes foi utilizado por muitos como um guia para entender estes níveis e o que poderíamos fazer em cada um, e esta é a forma correta de utilizá-lo, mas remetendo sempre a termos testes no final do processo.

E como isso funciona dentro do Ágil?

 

O Quadrante de Teste Ágil

Já sabemos pelo post anterior o que é Agile Testing. Agora iremos aprender qual o guia que temos quando utilizamos práticas ágeis no projeto e queremos aplicar alguma abordagem ou técnica de teste.

O Quadrante de Teste Ágil foi criado por Brian Marick que introduziu uma série de termos para diferentes categorias de teste para alcançar diferentes propósitos através de um diagrama.

Quadrante Teste Agil

Este diagrama, dividido em quatro quadrantes reflete diferentes razões de teste. Nele já uma matriz dividindo testes que suportam o time e criticam o produto, que é dividido em foco no negócio ou foco em tecnologia.

Vale lembra desde agora que o quadrante é um guia, e não um processo!

Testes que suportam o time

Podemos dizer que os testes que suportam o time são os que ajudam os desenvolvedores, não somente testers, enquanto o produto é desenvolvido. Estes testes são mais voltados a qualidade e entendimento dos requisitos e arquitetura do que em testes como conhecemos de forma funcional.

Quadrante 1

Representa, basicamente, a principal prática de desenvolvimento ágil:  TDD – Test Driven Development.
Dentro deste quadrante temos duas práticas: teste de unidade, que valida uma pequena parte da aplicação como objetos e/ou métodos, e testes de componente que valida partes maiores da aplicação como um grupo de classes que provê o mesmo serviço. São usualmente desenvolvidos com ferramentas xUnit e medem a qualidade interna do produto.
Ao utilizar a técnica de TDD o programador pode desenvolver uma funcionalidade sem se preocupar em posteriormente alterar qualquer parte da aplicação, ajudando assim a tomar melhor decisões de arquitetura e design.
Não são destinados ao cliente, pois o cliente não irá entender os aspectos internos do desenvolvimento e não devem ser negociáveis com o cliente, pois a qualidade do código deve sempre existir e não ser negligenciada. Os testes desenvolvidos usualmente executados dentro de uma abordagem de Integração Contínua para prover um rápido feedback da qualidade do código.

Quadrante 2

Este quadrante também suporta o time de desenvolvimento, continua guiando o desenvolvimento, mas de uma maneira mais alto-nível focando mais em testes que o cliente entenda, onde este define a qualidade externa de que ele precisa.
Aqui o cliente define exemplos que serão usados para um entendimento maior do funcionamento da aplicação, e são escritos de forma com que o cliente ou papéis ligados a negócio entendam. Todo o teste executado aqui tem um foco no funcionamento do produto e alguns deles podem até mesmo ter uma pequena duplicação com alguns testes criados no Quadrante 1.
Testes testes focados no negócio também podem ser automatizados e, usualmente, a técnica de BDD – Behavior Driven Development é utilizada na escrita e execução automatizada destes exemplos.

Neste quadrante também podemos utilizar de pessoas com conhecimentos em UX para que, através de mockups e wireframes, o cliente possa validar a interface gráfica antes que o time comece a desenvolver esta camada.

Testes que criticam o produto

O termo “criticam” aqui não é apenas de forma destrutiva, mas também relacionados a melhoria. O foco é saber como iremos aprender a melhorar o produto, escrevendo, se necessário, mais critérios e exemplos.

Quadrante 3

As vezes mesmo criando diversos mecanismos para assegurar que estamos atendendo a necessidade do cliente através de critérios e/ou exemplos, pode acontecer de não atendermos realmente aquele desejo, ou mesmo o teste unitário e o teste através do BDD podem não ter um real valor.
Neste quadrante iremos realmente criticar o produto e executa-lo como um usuário real usando nosso conhecimento e intuição na utilização da aplicação. O cliente pode executar este tipo de tarefa, usualmente chamada de UAT – User Acceptance Testing, dando um feedback mais preciso, aceitando a funcionalidade, analisando possíveis novas funcionalidades. Esta ação pode ser também um dos critérios de DoD – Definition of Done de uma funcionalidade.
O ponto central deste quadrante, além do UAT, são os testes exploratórios. Utilizando esta técnica qualquer membro do time é capaz de, simultaneamente, aprender sobre a aplicação e executar mais testes, usando o feedback do último teste para a execução dos próximos e também é capaz de extrair novos critérios, sempre observando o comportamento da aplicação.

Quadrante 4

Os testes neste quadrante são os mais técnicos e criticam o produto em termos de performance, carga e segurança.
Nos dias de hoje negligenciar aspectos como performance podem tirar a vantagem competitiva de um cliente. Geralmente já conhecemos aspectos relacionados a performance e segurança quando refinamos algumas User Stories.
As técnicas aplicadas a performance, carga e segurança vão desde os níveis mais baixos (como um profiling de código) como a utilização de ferramentas que simulam diversos usuários simultaneamente.

Bom, agora você já sabe, conceitualmente, um pouco deste guia para iniciarmos atividades de teste de software dentro de uma equipe ágil. Vale ressaltar que todas as técnicas de teste e abordagens podem ser utilizadas, pois o quadrante é um guia e não um padrão 😉

2 Comentários »

Categorias deste post

Agile, Qualidade, Técnico, Time de desenvolvimento

O que é Agile Testing?

Primeiramente para entender Agile Testing temos que dar uma olhada no Manifesto Ágil
Em um grande resumo o manifesto coloca que temos entregas de valor em um curto espaço de tempo.

Muitas práticas são utilizadas por um time ágil referente a teste. Programadores utilizam TDD (Test Driven Development) para desenvolver código com uma maior qualidade. Com ele os programadores escrevem testes para um pequeno pedaço de uma funcionalidade no ciclo do TDD (falha na primeira vez, é refatorado até possuir o comportamento esperado. Sempre que é alterado ou melhorado passa por este processo).
Esta prática não é somente usada exclusivamente por equipes ágeis, mas como uma forma inteligente de pensar no design de software e agir de forma a prevenir os defeitos futuros.

Mas TDD não é teste. É uma maneira que temos de pensar no design do software e garantir que este, se alterado, continuará a funcionar. Se alguma inconsistência for encontrada frente a alguma modificação, facilmente com um conjunto de testes que asseguram o comportamento do software, podemos detectar e alterar/refatorar o ponto de inconsistência.

Alguns acham que TDD é aplicar Agile Testing, mas ele é muito mais que isso….

Times

Dentro de uma equipe ágil possuímos, basicamente, dois times:

Time do Cliente: todos que estão do lado do negócio no projeto (product owner, business experts, business analyts). Este time escreve histórias e funcionalidades que o time de desenvolvimento entrega.

Time de Desenvolvimento: todos que entregam código são parte integrante deste time, onde o papel de cada um por ser misto ou variado. Eles transformam todas as histórias do time do cliente em software.

Estes dois times trabalham próximos uma grande parte do tempo e se transformam em um único time com um objetivo em comum: entregar valor para a organização.

 

E o testador?

Falando do conceito de time para o Time do Cliente, os testadores são membros parciais do negócio, ajudando-os a descobrir requisitos e exemplos e também ajudando o time a expressar requisitos como testes.
Testadores também são parte do Time de Desenvolvimento advogando por qualidade à favor do cliente e ajudando o time a entregar o máximo de valor ao negócio.

Muitos times não possuem membros se intitulando testadores. Entretanto o time precisa de alguém que ajude o Time do Cliente a escrever histórias e características, a escrever testes para elas, garantir que elas estão atendendo as necessidades e, automatizar os testes de regressão (para termos um feedback rápido e contínuo sobre a qualidade/saúde do software).

O que é então Agile Testing?

Agile Testing é um conjunto de práticas, seguindo o Manifesto Ágil, que incorpora todas as técnicas de teste comumente utilizadas por profissionais de teste, tendo um grande foco em automação. A principal função é de criticar o produto, ou seja, constantemente garantir que o que está sendo especificado e desenvolvido realmente atende as necessidades do cliente e irá entregar valor ao negócio.

 

O que é um Testador Ágil?

Um Testador Ágil é aquele profissional que abraça as mudanças, colabora com pessoas técnicas e de negócio e entende o conceito de usar testes para documentar requisitos e guiar o desenvolvimento.
Ele tende a ter bons conhecimentos técnicos para colaborar com o time de desenvolvimento a automatizar os testes e também para explorar o sistema a procura de comportamentos, testes e problemas.

Ser um testador ágil está ligado muito mais a atitude e comportamento do que conhecimento técnico. Ele olha para o produto como um todo, com uma visão de usuário e/ou cliente, que é o fator mais importante. Assim ele consegue tanto interrogar o Time do Cliente quanto a requisitos e funcionalidades como guiar o desenvolvimento, através de testes, exemplos e ferramentas, para que o Time de Desenvolvimento tenha também a visão do valor que cada um destes itens tem para o produto final.

 

Sobre o autor:

Embora vários títulos já exercidos no mercado (Arquiteto de Teste, Engenheiro de Teste, Analista de Teste) Elias Nogueira é essencialmente um testador: alguém com uma grande curiosidade de como o software comporta através de diversas situações/contextos.

É consultor e instrutor em qualidade de software, blogueiro e palestrante já tendo trabalhado nas mais diferentes segmentos como bancos, telecos, governo, varejo, qualidade de dado e geoprocessamento. Elias também é instrutor associado na Adaptworks no curso de Agile Testing.
Acredita que a qualidade do software é dever de todos e, quando há um papel especifico para isso, que este deve saber sobre os dois mundos do desenvolvimento de software: técnico e negócio.

http://about.me/eliasnogueira
@eliasnogueira
http://sembugs.blogspot.com

4 Comentários »

Categorias deste post

Agile, Qualidade, Técnico, Time de desenvolvimento