Facilitar a Gestão de Testes com o Modelo de Experiência do Utilizador
Muitos projectos de desenvolvimento de software não dão a devida
atenção aos testes e, consequentemente, não realizam todos os testes
necessários para a produção de um bom produto. Esta negligência pode
dever-se a um gestor de testes inexperiente e, por vezes, à falta de tempo
para cumprir os prazos do projecto e utilizar uma abordagem completa
em termos de testes.
Com o planeamento adequado defendido pelo RUP (Rational Unified Process),
as equipas de projecto podem assegurar que existirá o tempo necessário para
a realização de testes ao longo do ciclo de desenvolvimento. Relativamente ao
desenvolvimento de software, o RUP propõe uma abordagem iterativa e
orientada para casos de utilização. Este facto exige que as equipas de projecto
identifiquem os requisitos correctos para efectuarem a adição incremental de
funcionalidades e a realização dos testes (com base em casos de teste).
Os casos de utilização fornecem bons passos descritivos para a interacção dos
utilizadores com um sistema. De uma forma geral, os passos dos casos de
utilização podem ser utilizados como procedimentos de teste, pelo que existe a
tendência de transpor os fluxos dos casos de utilização para casos de teste.
Antes de prosseguir, convém deixar claro o que é um caso de teste. Para o RUP, é a definição (normalmente formal) de
um conjunto específico de características de teste, condições de execução e resultados esperados, identificados com o
propósito de avaliar algum aspecto particular de um item objecto de teste.
A identificação dos casos de teste de alto nível marca o ponto de partida do processo de gestão de testes, que deverá
ser simples, fácil de comunicar e fácil de compreender. Estas características são importantes porque serão identificados
mais casos de teste em fases posteriores do desenvolvimento de software, ou quando houver uma melhor compreensão
dos requisitos por parte da equipa.
Existem dois elementos chave que, se forem identificados atempadamente e de forma correcta, irão facilitar os testes.
São eles os casos de teste e os dados de teste. Uma vez identificados estes elementos, o resto do esforço de gestão
dos testes ajustar-se-á de forma adequada.
A Realização de Testes e o Modelo de Experiência do Utilizador
Os projectos que adoptam o modelo UX (User Experience) como parte do seu esforço de desenvolvimento de software,
fazem-no porque permite modelar interfaces com o utilizador – ou seja, a experiência física e psicológica inerente à
utilização da aplicação que está a ser construída. Deste modo, o modelo UX forma a abstracção do protótipo da
aplicação. Ė exactamente esta combinação de modelação e identificação dos requisitos para a definição do protótipo que
constitui o aspecto de maior interesse para os especialistas de teste.
Actualmente, são cada vez mais as equipas de projecto que sabem como se produz um modelo UX antes de construir
um protótipo. Se precisarmos de identificar casos de teste para testes funcionais, podemos começar por olhar para o
modelo UX. Uma vez que este último descreve a forma como um utilizador irá usar o interface para alcançar os seus
objectivos, trata-se de uma base natural para encontrar casos de teste funcionais. De igual modo, pode ser utilizado para
identificar a carga de trabalho para os testes de desempenho. Por esta razão, o modelo UX torna-se um motivador de
teste para as equipas de teste.
O RUP define “motivador de teste” como algo que incentiva a realização de testes, que impele os especialistas de teste
para a acção e para a realização de testes. Os motivadores de teste ajudam a identificar e a tornar visíveis os aspectos
que irão motivar os especialistas de teste para a avaliação dos aspectos apropriados de uma dada versão de software
executável. Como generalização, podemos referir que os motivadores de teste representam normalmente riscos de
qualidade específicos.
Identificação de Casos de Teste
Como é que o processo da modelação UX começa a revelar motivadores de teste? Um projecto típico começa por
modelar um ecrã que o utilizador visualizará utilizando os estereótipos de classe <<screen>> e/ou <<input form>>. Os
ecrãs são encadeados num diagrama de fluxo de ecrã para representar a forma como um utilizador irá usar uma
aplicação de uma forma particular.
A parte textual desta representação é um storyboard de caso de utilização. A descrição da forma como um utilizador
interage com a aplicação é objecto de múltiplos storyboards de casos de utilização. Existirá igualmente um mapa de
navegação que represente todos os caminhos principais que os utilizadores poderão seguir na utilização da aplicação.
Para explicar melhor este processo, vamos recorrer ao exemplo de um Modelo UX para a Compra de Bilhetes de
Cinema, que inclui o mapa de navegação (Figura 1), o storyboard de casos de utilização da compra de bilhete de cinema
(Figura 2) e o fluxo de ecrã (Figura 3). Apresentamos a seguir os passos necessários para produzir as linhas
orientadoras do plano de gestão de testes.
•
Compreender o mapa de navegação.
•
Identificar transacções com sentido.
•
Estimar o esforço de teste.
•
Identificar os dados de teste.
•
Planear a modularidade.
•
Identificar a validação de transacções.
Compreender o mapa de navegação
A Figura 1 mostra um mapa de navegação para vários ecrãs relativos a um storyboard de caso de utilização. Para
completarem uma transacção de compra de um bilhete de cinema, os utilizadores têm que interagir com três ecrãs e dois
formulários de entrada de informação. Estes dois formulários (estereotipados como <<input form>>) recolhem informação
como o nome do utilizador e a palavra de passe. Cada ecrã tem duas áreas. A área do meio mostra aquilo que os
utilizadores podem ver. A área de baixo mostra aquilo que os utilizadores podem fazer.
Figura 1. Mapa de navegação para um storyboard de caso de utilização
Identificar transacções com sentido
O mapa de navegação mostra todas as ligações transversais entre os ecrãs. Assim, quem tiver a seu cargo a concepção
dos testes poderá utilizar essas ligações para modelizar os fluxos da transacção. No caso deste exemplo, o Quadro 1
apresenta a criação dos casos de teste que são planeados para os fluxos de navegação. Os especialistas de teste
precisam de começar pela identificação de todas as transacções com sentido que precisam de ser testadas.
Normalmente, cada transacção com sentido irá apontar para um caso de teste.
Por transacção com sentido, entenda-se uma transacção significativa (do ponto de vista do utilizador) para levar a cabo
alguma tarefa através da aplicação. Desta forma, só uma transacção correcta e completa é uma transacção com sentido,
uma vez que as transacções incorrectas e incompletas não dão resposta cabal aquilo que os utilizadores pretendem. A
partir do mapa de navegação, podemos ver que existem dois caminhos possíveis para chegar a dois pontos finais: o
Display Movie Review e o Select Movie Results. No quadro, estes dois caminhos aparecem como fluxo principal e
subfluxo. Falaremos das transacções incompletas mais adiante.
Quadro 1. Casos de Teste de Alto Nível
N.º
Ecrã
1
Casos
de Teste
Fluxo
Principal
Descrição
Compra
Bilhetes
Cinema
Fluxo Ecrã:
<<screen>>
Frm Principal
Página Filme
2
Subfluxo
Ver Análise
Filmes
Seleccionar
Resultados
Filmes
Frm Principal
Página Filme
Mostrar
Análise Filme
Número Total de Casos de Teste
Tempo de Registo Estimado Por Caso de Teste
Esforço
Conjuntos
de Dados:
<<input
form>> ou
Dados de
Teste
Login Form
Script de
Teste
Dependência
Valor
Esperado
Login
Nenhuma
--
Seleccionar
Filme
Página
Resultados
Frm Principal
--
Página Filmes
Login Form
Login
Nenhuma
Custo
Bilhetes
Correcto
--
Dados Teste:
Nome Filme
Seleccionar
Filme
Mostrar
Análise
Frm Principal
--
Página Filme
Obter
Análise
Filme
Correcta
x
y
x*y*2
Seleccionar
Form Filme
Estimar o esforço de teste
O Quadro 1 também informa sobre o esforço necessário para completar os casos de teste. O esforço está ligado à
tecnologia necessária para alcançar o resultado final. Se for utilizada uma ferramenta de registo e reprodução para
automatizar o esforço, então o tempo mínimo para implementar os casos de teste será duas vezes o processo de registo.
Este aspecto será importante na altura de decidir sobre os recursos e o tempo necessários para os testes.
Por exemplo, se os utilizadores demorarem y minutos para chegar à página Seleccionar Resultados Filmes para
completarem uma transacção de compra, então podemos multiplicar o valor y por dois para obter o tempo total (z) para
registar e reproduzir uma transacção desse tipo. O esforço total necessário será z multiplicado pelo número de casos de
teste. Este valor final poderá ser utilizado no planeamento das iterações.
Identificar os dados de teste
A quinta coluna do Quadro 1 mostra os conjuntos de dados necessários para o preenchimento dos casos de teste. Se
olharmos para o Login Form e para o Seleccionar Form Filme (formulários de login e de selecção de filme), os dados de
teste para o primeiro caso de teste (FluxoPrincipal1) poderão ser deduzidos facilmente. Para identificar os dados de teste
para o segundo caso de teste (SubFluxo1), teremos que examinar as acções que conduzem à apresentação do ecrã
seguinte, que apresenta os filmes disponíveis para selecção.
Quem concebe os testes tem agora uma lista de dados de teste com que trabalhar. Quando existe uma base de dados
da aplicação, muito do trabalho dos especialistas de teste baseia-se na qualificação da utilidade dos registos da base de
dados. Para se conseguir exaustividade e profundidade a nível dos dados de teste, os especialistas de teste precisam de
analisar os detalhes do storyboard dos casos de utilização. Só se pode considerar que está feito um trabalho real depois
dos dados de teste terem sido elaborados para suportar os respectivos casos de teste.
Planear a modularidade
Referimos atrás a necessidade de identificar transacções com sentido. Cada uma dessas transacções pode ser
representada num script de teste. As transacções têm alguma similaridade entre si. Por exemplo, cada transacção tem
que começar com um login e terminar com um logout. Desta forma, os sripts de teste para cada uma das transacções
terão algumas partes que são exactamente iguais. Consequentemente, quando for necessário alterar uma das
transacções, será necessário repetir a mesma alteração nos scripts com transacções idênticas. Estas repetições poderão
ser bastante trabalhosas e consumir bastante tempo quando estão envolvidas muitas duplicações.
A grande vantagem da modularidade reside exactamente na facilidade de manutenção dos scripts de teste. Partindo as
transacções em fluxos de ecrã (como mostra a coluna quatro do Quadro 1), podemos alcançar a modularidade se, por
exemplo, um ecrã corresponder a um script de teste. Desta forma, se o ecrã de login principal (Frm Principal) precisar de
ser alterado, podemos ver na coluna do script de teste (coluna seis do Quadro 1) que são afectados dois casos de teste.
A única coisa a fazer é alterar apenas um script: o script Login.
Para ser construída entre essas transacções, a modularidade requer dependência. Daí a existência da coluna
Dependência no Quadro 1. No entanto, a dependência pode ter um contexto maior. Por exemplo, a dependência pode
mostrar o estado de uma aplicação, da qual depende uma transacção corrente. Ou então, poderá mostrar a execução
concluída de outra transacção. Para concluir o primeiro caso de teste, por exemplo, é necessário que os três scripts
corram completamente e na sequência que se segue: script Login, script Seleccionar Filme e script Página de
Resultados.
Identificar a validação de transacções
A última coluna do Quadro 1 identifica os resultados esperados dos casos de teste. Nem todos os passos estão
validados porque isso constituiria um excesso nos testes. Uma vez que o propósito é permitir que os utilizadores
completem uma transacção, a validação restringe-se ao resultado final da transacção que está a ser testada.
Relativamente ao caso de teste Fluxo Principal, validámos o custo do(s) bilhete(s) devolvido(s) pelo sistema. Ė este o
objectivo dos testes, sendo desnecessária qualquer validação intermédia.
O teste exaustivo de um ecrã – testar todos os botões, caixas de combinação, caixas de listas, os seus estados, os
esquemas de cor da página, os tamanhos de fonte de cada caracter, etc. – é claramente considerado um exagero e
nunca é uma boa ideia à partida. Uma forma de saber se estamos a exagerar nos testes, consiste em olhar para o
objectivo dos casos de teste ou para os requisitos fixados. Normalmente, o melhor é não realizar testes para além da
abrangência desses requisitos. Quando não se segue esta regra, os testes podem tornar-se muito pouco práticos e sem
grande utilidade.
Como resumo, podemos dizer que o mapa de navegação permite que os gestores de testes:
•
Desenvolvam casos de teste de alto nível para toda a aplicação;
•
Identifiquem a quantidade de dados de teste a criar.
Os casos de teste de alto nível têm que ser suficientemente detalhados para identificar as transacções a serem testadas
e os valores esperados dos resultados.
O Catálogo de Ideias de Teste
Vale a pena mencionar nesta altura as “ideias de teste” e o catálogo das ideias de teste (um artefacto do RUP). As
transacções que não foram cobertas até agora são as ideias de teste. Os casos de teste que essas ideias representam
continuam a precisar de ser refinadas e detalhadas. O RUP define uma ideia de teste como sendo uma breve declaração
identificadora de um teste que é potencialmente útil de realizar. Esta declaração representa frequentemente um aspecto
de um dado teste: um input, uma condição de execução, ou um resultado esperado (mas tipicamente apenas um deles).
Uma ideia de teste é diferente de um caso de teste, na medida em que a ideia de teste não contém nenhuma
especificação das tarefas de teste. As ideias de teste só contemplam a essência da ideia que está por detrás do teste.
São de alto nível e constituem bases orientadoras importantes para a realização dos testes. Toda esta informação ajuda
os gestores a estimar os recursos e a agenda que serão necessários para completar os testes.
Na maior parte das organizações, o know-how em termos de testes é uma conjugação das experiências (que podem ser
muito diferentes) dos membros de uma equipa de projecto. Normalmente não existe nenhuma metodologia para a
unificação das lições aprendidas. O catálogo de ideias de teste representa uma solução para este aspecto, na medida
em que fornece um mecanismo para a recolha e reutilização das experiências de teste de várias equipas de projecto e
indivíduos. Para ser verdadeiramente útil, o catálogo de ideias de teste tem que disponibilizar uma representação clara
entre as ideias de teste e a sua implementação (isto é, todos os casos de teste conhecidos).
O Quadro 2 é um exemplo de um catálogo de ideias de teste. A informação relevante do projecto é recolhida nas linhas
Criar (registos de bilhetes de filmes) e Seleccionar (análises de filmes). Também poderão existir ideias de teste similares
de outros projectos na linha Criar (outros).
Quadro 2. Catálogo de Ideias de Teste
Funções
Descrição Projecto
Consideração Para
Testes
Criar
(registos de
bilhetes de
filmes)
Perfil login
reconhecido, capaz
de criar registos de
bilhetes, permite
selecção de lugar ao
mesmo tempo.
Utiliza diferentes
perfis, utiliza uma
combinação
diferente de
lugares, selecção
de horário, etc.
Refere-se
aos
requisitos do
projecto xx
Secção x.x
Login
3
Seleccionar
(análises de
filmes)
Página estática
apresentada
Refere-se
aos
requisitos do
projecto xx
Secção x.x
--
3
Criar
(outros)
--
Selecciona
combinações
variadas de acordo
com o volume dos
dados devolvido,
etc.
--
Conjuntos
Dados
Teste
Projecto
Refere-se à
folha de
cálculo que
contém os
conjuntos de
dados de
teste
--
--
--
--
N.º
Ecrã
1
Detalhes
Requisitos
Projecto
Script Teste
Projecto
Seleccionar
Ecrã
Detalhar os Casos de Teste Utilizando um Storyboard dos Casos de Utilização
Depois das ideias de teste de alto nível estarem definidas, a equipa de projecto pode começar a detalhar os casos de
teste. Para determinar os passos envolvidos nos casos de teste utiliza-se o storyboard dos casos de utilização, uma vez
que se trata dos passos dos casos de utilização com informação sobre a experiência dos utilizadores. A Figura 2 mostra
um storyboard de casos de utilização.
Figura 2. Storyboard de Caso de Utilização
Fluxo Principal
Passos:
1. Um Utilizador Pede Acesso
O caso de utilização tem início quando um utilizador pede acesso ao site Web de filmes para ver
títulos e análises de filmes. O sistema apresenta uma lista de títulos e uma lista de análises de filmes.
São disponibilizados, em média, 100 títulos e análises de filmes. Todos os títulos e análises são
ordenados alfabeticamente. Será construído um perfil para cada indivíduo.
2. O Utilizador Pode Efectuar um dos Seguintes Pedidos:
2.1. O Utilizador Selecciona um Título de um Filme. (Isto acontece em 95% dos casos).
2.1.1. O utilizador selecciona um título de um filme e a data. O sistema responde
mostrando os lugares disponíveis. Os lugares aparecem no ecrã sob a forma de
quadros com código de cores correspondentes à informação sobre o preço.
2.1.2. O utilizador efectua a encomenda de bilhetes. O sistema direcciona o
utilizador para a introdução dos dados do cartão de crédito. Na maior parte das
transacções, o utilizador selecciona um filme e até quatro bilhetes.
2.2. O Utilizador Selecciona uma Análise de um Filme. (Isto acontece em 5% dos casos).
O sistema responde mostrando o nome do autor e a data da análise. O utilizador submete o
pedido de uma análise de um filme. Na maior parte dos casos, o utilizador selecciona
análises de filmes que estão em exibição.
3. O Utilizador Procede ao Log Out
O caso de utilização termina quando o utilizador pede para sair (log out) do site Web.
Fluxo Alternativo 1
No passo 1 (Um Utilizador Pede Acesso), se o site Web estiver em baixo, é apresentada uma mensagem
de erro. Existe o storyboard do caso do utilizador.
Fluxo Alternativo 2
No passo 2.2 (O Utilizador Selecciona uma Análise de um Filme), se não estiver disponível nenhuma
análise, o sistema apresentará uma mensagem “Sem Análise”. Existe o storyboard do caso do utilizador.
O storyboard de casos de utilização precisa de incluir alguns aspectos para ser útil em termos de detalhe dos casos de
teste. Por exemplo, precisa de:
Dizer como os utilizadores irão utilizar o sistema
O storyboard deve fornecer o processo (passo a passo) da experiência do utilizador com a aplicação. Este processo irá
definir eventualmente os procedimentos de teste, pelo que o storyboard de casos de utilização deverá fornecer os
detalhes suficientes. Uma vez que o nosso exemplo de site Web sobre filmes tem dois subfluxos, existem pelo menos
dois casos de teste base para produzir.
Descrever que tipos de objectos podem estar visíveis e qual a sua importância para os utilizadores
Esta informação é importante para os especialistas de testes. Em vez de terem que se basear nos seus conhecimentos e
formação para determinarem pontos de validação, passam a guiar-se pelos pontos chave do storyboard dos casos de
utilização. Os especialistas de teste precisam de criar métodos de validação dos casos de teste – neste caso, trata-se de
validar que o esquema correcto de cor é utilizado para representar o preço.
Incluir múltiplos casos de teste, se apropriado
Os múltiplos subfluxos determinam o número de casos de teste a produzir. Os fluxos alternativos aumentam o número de
casos de teste. Uma desvantagem dos mapas de navegação reside no facto de não mostrarem prontamente os fluxos
alternativos, pelo que podem ser facilmente esquecidos alguns casos de teste. O nosso exemplo tem dois fluxos
alternativos. Normalmente, os especialistas de teste experientes encontram mais fluxos alternativos quando detalham os
casos de teste, ou durante a execução dos testes, uma vez que é nessa altura que descobrem variantes.
Incluir conjuntos de dados de teste para todos os casos de teste identificados
Cada um dos conjuntos de dados de teste identificados anteriormente será um candidato para os diferentes casos de
teste e para posterior elaboração. Por vezes, os conjuntos de dados de teste também precisam de ser refinados. Por
exemplo, se existirem diferentes perfis de utilizador, os dados de teste precisam de reflectir isso para o teste adequado
do motor de perfis. Neste caso, identifica-se o caso de teste base e depois criam-se mais casos de teste para reflectir os
diferentes conjuntos de dados de teste.
No storyboard de caso de utilização (Figura 2), podem existir múltiplos casos de teste para o fluxo principal. Por exemplo,
os especialistas de teste podem decidir testar o fluxo principal utilizando múltiplos perfis ou seleccionar uma combinação
de inputs de ecrã. Ė criado um caso de teste para corresponder a cada conjunto de dados de teste (cada perfil
escolhido). Um método alternativo consiste em executar um caso de teste utilizando um conjunto de dados diferente. No
entanto, neste caso, é crucial assinalar explicitamente o diferente conjunto de dados de teste. Pela nossa parte,
recomendamos a utilização do método anterior, uma vez que existe uma correspondência directa entre um conjunto de
dados e o seu caso de teste.
Fornecer dados para ajudarem na análise da carga de trabalho
Nos testes normais de desempenho, é importante identificar onde é que a aplicação terá um elevado volume de tráfego.
Por vezes, poderá não ser possível emular todo o tráfego, pelo que se costuma utilizar a regra dos 80/20 para colocar de
lado algum do tráfego menos importante. Por outras palavras, 80 por cento ou mais de todo o tráfego deve ser emulado.
A emulação dos restantes 20 por cento ou menos pode ser evitada.
No nosso exemplo, o primeiro subfluxo cria 95 por cento do tráfego. Esta quantidade significativa precisa de ser emulada
nos testes de desempenho. Os restantes cinco por cento são candidatos à exclusão. Se já foi criado um script funcional,
pode ser reutilizado aqui como um substituto. Se não existir informação sobre o volume de tráfego – por se tratar de um
novo sistema, por exemplo – pode-se simular a carga de trabalho utilizando as maiores cargas de trabalho diferentes. Se
possível, devem-se considerar todos os utilizadores da aplicação e alocar as actividades de negócio que realizam com a
aplicação. Estas actividades podem ser utilizadas para delinear a carga de trabalho inicial.
A recolha de todas as experiências dos utilizadores em storyboards de casos de utilização fornece uma área de enfoque
de informação importante para o desenvolvimento dos esforços de teste. Todas estas linhas orientadoras ajudam-nos no
detalhe de casos de teste, como mostra o Quadro 1. A utilização de um quadro/tabela para recolher toda a informação
num local, permite que os especialistas de testes efectuem rapidamente a gestão dos requisitos de teste e determinem a
quantidade de trabalho necessária para os cumprir. Numa fase posterior poderão ser identificados mais casos de teste
pelos especialistas de testes, mas o número total deverá ser gerível à medida que a equipa do projecto vai melhorando a
sua capacidade para identificar casos de teste. Tipicamente, um especialista de testes precisará de completar uma
iteração para valorizar e compreender este processo de teste.
Fluxo de Ecrãs
Há outros elementos no modelo UX. Por exemplo, o fluxo de ecrã apresentado na Figura 3 é um diagrama sequencial e
as mensagens entre os ecrãs são acções que os utilizadores podem realizar. Existe normalmente um fluxo de ecrã por
storyboard de caso de utilização. Convém notar que as acções individuais têm uma sequência de tempo e podem ser
dependentes de acções anteriores. Como tal, as transacções têm que ter em conta as sequências. Este diagrama de
sequência permite que quem concebe os testes possa refinar ainda mais os casos de teste. No entanto, muita da
informação referida atrás está disponível em forma de texto a partir do storyboard de caso de utilização, pelo que não
apresentamos mais informação e descrições de actividades neste artigo sobre os fluxos de ecrãs.
Figura 3. Fluxo de Ecrãs para a Compra de Bilhetes de Cinema
A gestão de testes envolve várias actividades, nomeadamente a criação de uma equipa de testes, o desenvolvimento de
um plano de testes mestre que detalhe os deliverables de teste organizacionais e os métodos a serem utilizados para os
testes, o desenvolvimento de um plano de testes relevante para a equipa do projecto, etc. O modelo UX ajuda as
equipas de projecto a iniciar o esforço de testes. Podem efectuar o planeamento inicial dos recursos e da agenda
utilizando um mapa de navegação, evitando assim o gasto de demasiado tempo com os detalhes. Posteriormente, à
medida que o projecto for avançando e o detalhe dos casos de teste se tornar importante, poderão encontrar a maior
parte dos detalhes que precisam nos storyboards de casos de utilização.
Baseado no artigo “Test Management Made Easy: A User-Experience Model Perspective” de Andy Yap, especialista em
engenharia de software na Rational Software (IBM Software Group).
Tel: (+351) 239 497 230 / 2 • Fax: (+351) 239 497 231
E-mail: [email protected] • Internet: www.engenharia-software.com