Gerenciamento de Teste apresentadas as atividades de testes, escopo,

cobertura dos testes, funcionalidades do software

Uma atividade essencial no desenvolvimento de
todo e qualquer projeto é o planejamento. Um
plano tem o papel semelhante ao de um ‘mapa’.
Sem um mapa, um plano ou qualquer outra fonte
de informação similar, você não conhecerá seus
objetivos, nem aonde quer chegar e jamais terá a
certeza de ter alcançado sua meta. Perceba que
entender o propósito do planejamento é de suma
importância a fim de monitorar a execução de
atividades, sendo também importante conhecer o
papel dos riscos no planejamento, bem como
diferenciar estratégias de planos. Planejamento
engloba três atividades principais:
1- Definir um cronograma de atividades: estabe-
lecer as atividades que devem ser realizadas, as
etapas a serem seguidas e a ordem cronológica
de execução;
2- Fazer alocação de recursos: definir quem reali-
za as atividades e quais ferramentas/recursos a
serem utilizados;
3- Definir marcos de projeto – estabelecer os
marcos, ou milestones, a serem alcançados com
objetivo de se fazer o acompanhamento.
que não serão testadas, premissas, restrições,
requisitos de ambiente, rastreabilidade dos casos
de teste, critérios de validação e os responsáveis
pelas tarefas de teste. Exemplo de itens existen-
tes no Plano de teste:
Premissas:
Deverá ser feita uma carga de dados para execu-
ção dos testes.
Critérios de Validação:
O número de defeitos deve ser igual à zero.
Caso de teste: Descreve uma condição particular
a ser testada, é composto por valores de entrada,
restrições para a sua execução e um resultado ou
comportamento esperado. O processo de criação
de casos de testes pode também ajudar a encon-
trar falhas de requisitos, ou seja, identificar cená-
rios não tratados pelos requisitos do sistema.
Exemplo de casos de testes:

Perceba que o planejamento é acompanhado da

atividade de monitoração ou supervisão que visa
avaliar se o progresso que tem sido alcançado
está em conformidade com o que foi estabelecido
no plano ou, em outras palavras, responder a
questão: quão bem estamos indo no projeto?

Agora, dentro do contexto do desenvolvimento de

software, você necessitará de vários documentos
como, por exemplo, plano de projeto, documento
de requisitos e plano de teste. Neste artigo, o foco
recai sobre o último, isto é, plano de teste. Trata-
se de um documento ou mapa no qual se definem
escopo e objetivos, além de requisitos, estraté-
gias e recursos a serem empregados nas ativida-
des de testes de software. Nesse sentido, o artigo
apresenta os itens que devem fazer parte de um
documento de plano de teste, exemplificando e
discutindo esses itens.

Atividade Plano de teste

O planejamento na fase de testes é muito impor-

tante para garantir o sucesso e a qualidade do
sistema, e para isso existem documentos que são Roteiro de Teste: Descreve os passos necessá-
essenciais nesta fase, são eles: Plano de teste, rios para a execução de um caso de teste ou um
Caso de teste e Roteiro de teste. grupo de casos de testes, Exemplo:
Este post explicará cada um dos documentos,
bem como a utilidade deles para o projeto.

Plano de teste: É a base para o início de qual-

quer teste de software. Neste documento são

1

A ordem de criação destes documentos é a se-
guinte:
Todos os documentos de testes devem ser atuali-
zados sempre que um requisito do sistema for
alterado.
Com o uso destes documentos o processo de
testes de software se torna mais produtivo pois o
testador consegue realizar uma sequência de
passos de forma prática sem a necessidade de
consultar todos os documentos da especificação.
Garantir a qualidade do software desenvolvido é
primordial para conseguir o sucesso de qualquer
projeto. Testá-lo adequadamente virou uma obri-
gação. Aqui vou mostrar uma forma sistemática
de como montar um plano de testes eficiente e
consistente baseado em casos de uso.
Uma das primeiras perguntas que devem ser
respondidas para iniciar a montagem de um plano
de testes é o que testar? Parece óbvio e a res-
posta é realmente essa: devemos testar as funci-
onalidades que compõem o escopo do software
que está sendo desenvolvido. Agora você pode
perguntar, onde está descrito esse escopo? Pode
estar na proposta do projeto, na especificação
funcional e, em muitos projetos, nos casos de
uso.
Os casos de uso descrevem requisitos, identifi-
cam o valor que o cliente espera obter da funcio-
nalidade, e representam a forma como o sistema
será utilizado. Permite identificar todos os cami-
nhos que o usuário pode percorrer para conseguir
o que deseja e se podem ocorrer problemas.
Mostram ao cliente o que esperar do software, ao
desenvolvedor o que codificar, e ao testador ou
certificador o que validar para garantir a qualidade
dos entregáveis.
Desse modo, podemos concluir que os casos de
uso ajudam na certificação e validação dos requi-
sitos implementados. Simplificando e sistemati-
zando o processo de teste do software, permitin-
do um ganho de produtividade e ajudando na
garantia de que todo o escopo vai ser abrangido
pelo teste.
Agora que sabemos que os casos de uso podem
nos ajudar a fazer um plano de testes, o que fazer
agora? Abaixo vou listar alguns procedimentos
que você pode seguir:
- Selecione o caso de uso que será testado, iden-
tifique o fluxo principal e os fluxos alternativos e
desenhe um diagrama de atividades. Desse modo
vai conseguir visualizar mais facilmente todos os
cenários que o usuário pode utilizar.
- Agora que já identificou os cenários, você vai
começar a escrever um caso de teste para cada
cenário, detalhando neste caso de teste todos os
passos do cenário. Desse modo o testador vai
poder executar as ações do ator e validar se a
resposta do sistema está de acordo com o que foi
especificado;
- Para iniciar os testes, vai ser necessário a cria-
ção de uma base de dados de certificação, se a
mesma ainda não existir (não é prudente fazer os
testes na base de desenvolvimento e muito me-
nos em produção), e identificar os dados de en-
trada que serão utilizados nos testes;
- É importante tabular o resultado dos testes,
como quantidade de acertos, defeitos e corre-
ções, e armazenar essa informação em algum
meio permanente. Isso vai servir para avaliar a
qualidade de cada desenvolvedor da sua equipe
Critérios de Saída
Utilize a rotina para dar saída de produtos do
almoxarifado que não estão sendo vendidos, ou
seja, que serão usados na propriedade, ou que
serão doados ou para alguma eventual saída de
ajuste.
Esta tela é dividida em duas áreas, sendo elas:
1. Seleção de
2. Grid para consultas, alterações ou exclu-
sões
1. Seleção de dados
O sistema possui diversas opções para filtragem,
como:
• Período: utilize como critério de filtragem o perí-
odo da ordem de saída do produto.
• Tipo de saída: utilize como critério de filtragem o
tipo de saída, as opções são: consumo, venda,
saída de ajuste e doação.
• Produto: utilize como critério de filtragem o pro-
duto cadastrado na ordem de saída.
2
• CC/patrimônio: utilize como critério de filtragem
o centro de custo/patrimônio cadastrado na or-
dem de saída.
• Conta gerencial: utilize como critério de filtragem
a conta gerencial cadastrada na ordem de saída.
Após preenchimento dos critérios de filtragem,
clique em "Filtrar".
2. Grid para inclusão, consultas, alterações ou
exclusões
No grid realize as inclusões, consultas, alterações
ou exclusões de lançamentos realizados anteri-
ormente.
I. Inclusões
II. Consulta
III. Alteração
IV. Exclusão
I. Inclusão
Observe que esta área é constituída de sete
campos, sendo eles:
• Comando "Ação": utilize esta opção para sele-
ção da ordem de saída para exclusão.
• Data: este campo é preenchido automaticamen-
te, porém é possível alteração. Digite neste cam-
po a data da ordem de saída. Este campo é de
preenchimento obrigatório.
• Tipo: neste campo selecione o tipo de ordem de
saída, as opções são: consumo, saída de ajuste
ou doação.
• Produto: este campo é de preenchimento obri-
gatório. Neste campo selecione o produto referen-
te à ordem de saída.
• Unidade: este campo é preenchido automatica-
mente após seleção do produto.
• Quantidade: este campo é de preenchimento
obrigatório. Neste campo insira a quantidade de
produto referente à ordem de saída.
• CC/ patrimônio: este campo é de preenchimento
obrigatório quando o tipo selecionado for referen-
te à consumo ou doação. Neste campo selecione
o centro de custo/patrimônio referente a ordem de
saída do produto.
• Safra: neste campo selecione a safra corres-
pondente à saída do estoque. Este campo não é
de preenchimento obrigatório.
• Conta gerencial: este campo é de preenchimen-
to obrigatório quando o tipo selecionado for refe-
rente à consumo ou doação. Neste campo seleci-
one a conta gerencial referente ao produto de
ordem de saída.
• Atividade: neste campo selecione a atividade
referente à saída do estoque. Este campo não é
de preenchimento obrigatório.
• Observação: utilize este campo para qualquer
anotação pertinente.
• Saldo: este campo é preenchido automatica-
mente após seleção do produto sendo que o sis-
tema busca as informações conforme o cadastro
de entrada e saída do produto.
• Custo médio: este campo é preenchido automa-
ticamente após seleção do produto. O sistema
calcula a média do valor do produto conforme o
valor unitário de cada compra.
Após preenchimento dos campos, clique em
"Gravar".
II. Consulta
• Filtre as ordens de saída utilizando a área "Se-
leção de dados".
• De acordo com os critérios de filtragem utiliza-
dos, as ordens de saída estarão disponíveis no
grid.
• Realize as consultas.
III. Alteração
• Filtre as ordens de saída utilizando a área "Se-
leção de dados".
• Após filtragem, no grid selecione a ordem de
saída e realize as alterações.
• Após a realização das alterações, clique em
"Gravar".
IV. Exclusão
• Filtre as ordens de saída utilizando a área "Se-
leção de dados".
• Após filtragem, no grid selecione a ordem de
saída no comando "Ação" para exclusão.
• Após seleção da ordem de saída que será ex-
cluído, clique em "Excluir".
Conceitos: Estratégia de Teste
Uma estratégia para o teste de um projeto des-
creve a abordagem geral e os objetivos das ativi-
3
dades de teste. Ela inclui os estágios de teste
(unidade, integração e sistema) que devem ser
abordados e os tipos de teste (de função, desem-
penho, carga, stress, etc.) que devem ser execu-
tados.
A estratégia define:
 As ferramentas e técnicas de teste a serem
empregadas.
 Os critérios de conclusão e êxito do teste a
serem usados. Por exemplo, os critérios podem
permitir que o software evolua para o teste de
aceitação quando 95% dos casos de teste tive-
rem sido executados com êxito. Outro critério
consiste na cobertura de código. Em um sistema
no qual a segurança seja vital, esse critério pode
significar que 100% do código devem ser cober-
tos por testes.
 Algumas considerações especiais afetam
os requisitos de recurso ou têm implicações na
programação, como:
 O teste de interfaces para sistemas exter-
nos.
 Simulação de danos físicos ou de ameaças
à segurança.
Algumas organizações possuem estratégias de
teste corporativas definidas. Nesse caso, procure
aplicar essas estratégias especificamente ao seu
projeto.
Você deve planejar as atividades de teste com
base nas seguintes dimensões:
 Em que iteração você se encontra e quais
são as metas dessa iteração.
 Que estágio de teste (teste unitário, de
integração ou de sistema) você está executando.
Você pode trabalhar todos os estágios de teste
em uma iteração.
Agora, observe como as características das ativi-
dades de teste podem ser alteradas dependendo
de onde você esteja nas "dimensões de teste"
mencionadas acima.
É claro que há várias características a observar
(como recursos necessários e tempo gasto), mas,
nesse ponto, concentre-se no que é importante
para definir a estratégia de teste:
 Tipos de teste (de função, stress, volume,
desempenho, usabilidade, distribuição, etc.).
 Critérios de avaliação usados (cobertura de
teste baseada em código, cobertura de teste ba-
seada em requisitos, número de defeitos, interva-
lo entre falhas, etc.)
 Técnicas de teste usadas (manuais e au-
tomatizadas)
Não há nenhum padrão geral referente à maneira
como os tipos de testes são distribuídos nos ci-
clos de teste.
Dependendo do número de iterações, do tama-
nho da iteração e do tipo de projeto, você enfati-
zará diferentes tipos de testes.
Você perceberá que o foco do estágio de teste do
sistema é garantir que você esteja cobrindo todos
os requisitos testáveis expressos em um conjunto
de casos de teste.
Isso significa que os critérios de conclusão se
concentrarão na cobertura de teste baseada em
requisitos.
Nos estágios de teste unitário e de integração,
você perceberá que a cobertura de teste baseada
em código é um critério de conclusão mais apro-
priado.
A figura a seguir mostra como o uso desses dois
tipos de medidas de cobertura de teste pode ser
alterado à medida que novas iterações do softwa-
re são desenvolvidas.
 O plano de teste deve definir conjuntos de
critérios de conclusão para os testes unitário, de
integração e de sistema.
 Pode haver diferentes conjuntos de crité-
rios de conclusão definidos para iterações indivi-
duais.
No projeto, você deve automatizar os testes o
máximo possível, especialmente aqueles que são
repetidos várias vezes (testes de regressão).
Mas lembre-se que tempo e recursos são neces-
sários para criar e manter testes automatizados.
Sempre haverá algum teste manual em cada
projeto.
4
A figura a seguir ilustra quando e em que estágios
de teste você provavelmente executará testes
manuais.
Gerência de Configuração
Desenvolvendo Software de Forma Eficiente e
Disciplinada
Os sistemas de software estão em constante
evolução. A manutenção do software, isto é, mo-
dificações em artefatos existentes, chega a con-
sumir 75% do custo total do seu ciclo de vida.
Aproximadamente, 20% de todo o esforço de
manutenção é usado para consertar erros de
implementação e os outros 80% são utilizados na
adaptação do software em função de modifica-
ções em requisitos funcionais, regras de negócios
e na reengenharia da aplicação.
A Gerência de Configuração de Software surgiu
da necessidade de controlar estas modificações,
por meio de métodos e ferramentas, com o intuito
de maximizar a produtividade e minimizar os er-
ros cometidos durante a evolução.
É uma disciplina que controla e notifica as inúme-
ras correções, extensões e adaptações aplicadas
durante o ciclo de vida do software de forma a
assegurar um processo de desenvolvimento e
evolução sistemático e rastreável, sendo indis-
pensável quando equipes manipulam, muitas
vezes em conjunto, artefatos comuns.
Apesar de existir um forte apelo para o uso da
Gerência de Configuração de Software durante a
etapa de manutenção, a sua aplicação não se
restringe somente a essa etapa do ciclo de vida
do software.
O uso dos sistemas de Gerência de Configuração
é fundamental para prover controle sobre os arte-
fatos produzidos e modificados por diferentes
recursos desde o planejamento e levantamento
de requisitos até a construção e entrega do pro-
duto.
O motivo da sua importância está geralmente
associado aos problemas identificados quando a
Gerência de Configuração não é utilizada no de-
senvolvimento de software. Abaixo, vamos anali-
sar alguns destes problemas.
Imagine que uma organização desconhece o que
seja Gerência de Configuração e que em um de-
terminado projeto um desenvolvedor esteja modi-
ficando os artefatos C1, C2 e C3 em um diretório
compartilhado na rede.
Simultaneamente, um segundo desenvolvedor
modifica os artefatos C4, C5 e também o artefato
C3, como exemplifica a Figura 1.
Figura 1. Espaço de Trabalho compartilhado por
vários desenvolvedores
Neste cenário, o segundo desenvolvedor não
notifica o primeiro desenvolvedor sobre o impacto
que a modificação do artefato C3 pode causar no
código. Consequentemente, o primeiro desenvol-
vedor, que está usando o mesmo espaço de tra-
balho, não conseguirá identificar, de forma rápida,
o motivo que levou sua implementação a falhar.
Este problema acontece pela falta de notificação
e pelo compartilhamento de artefatos de software
por diversos desenvolvedores.
Imagine que agora foi acordado entre os desen-
volvedores que o ideal seria centralizar os artefa-
tos em um repositório e que cada desenvolvedor
implementaria suas modificações em um espaço
de trabalho privado.
Após cada modificação, o artefato seria devolvido
ao repositório. Considerando este cenário, fre-
quentemente ocorreriam sobreposições ou per-
das de modificações implementadas nos artefatos
comuns nas organizações sem a prática da Ge-
rência de Configuração.
Um desenvolvedor poderia implementar sua mo-
dificação em uma versão desatualizada do artefa-
to e sobrepor a versão mais atual disponibilizada
por outro. Este problema ocorre devido à atuali-
zação simultânea, quando dois desenvolvedores
compartilham o mesmo repositório e não existe
controle ou restrição quanto ao acesso a este
repositório (ver Figura 2).
5

Figura 2. Repositório centralizado compartilhado
por vários desenvolvedores
Sob a perspectiva de desenvolvimento, a Gerên-
cia de Configuração de Software abrange três
sistemas principais: controle de modificações,
controle de versões e controle de gerenciamento
de construção.
O sistema de controle de versões permite que os
artefatos sob Gerência de Configuração evoluam
de forma distribuída, concorrente e disciplinada,
evitando perdas ou sobreposições durante o de-
senvolvimento e a manutenção do artefato. Po-
demos citar como exemplos de ferramentas de
mercado: CVS, Subversion, IBM Rational Clear-
Case e Microsoft Visual Source Safe.
O sistema de controle de modificações armazena
todas as informações geradas durante o anda-
mento das solicitações de modificação e relata
essas informações aos participantes interessados
e autorizados. Podemos citar como exemplos de
ferramentas de mercado: Bugzilla, Jira, Trac e
IBM Rational Clear Quest.
O sistema de gerenciamento de construção au-
tomatiza o processo de transformação dos diver-
sos artefatos do software que compõem um proje-
to em um sistema executável propriamente dito.
Este processo é nomeado construção do software
que, por exemplo, testa e empacota a aplicação
java como um arquivo jar.
Este processo ocorre de forma aderente às nor-
mas, procedimentos, políticas e padrões definidos
para o projeto. Podemos citar como exemplos de
ferramentas de mercado: Maven e Apache Ant.
As vantagens da utilização da Gerência de Confi-
guração de Software são inúmeras. Dentre elas,
podemos listar:
(1) ganho de produtividade e eficiência;
(2) diminuição do retrabalho e dos erros;
(3) aumento da disciplina no processo de desen-
volvimento;
(4) aumento da memória organizacional;
(5) acesso às informações qualitativas e quantita-
tivas referentes ao processo de desenvolvimento,
como por exemplo, medida de esforço para efe-
tuar uma alteração e frequência de modificações
por componente;
(6) possibilidade de estabelecer uma trilha de
auditoria indicando por que, quando e por quem
um artefato foi alterado;
(7) auxílio à gerência de projetos e
(8) garantia de ambiente estável no qual o produ-
to deve ser desenvolvido.
Neste artigo, veremos alguns conceitos da área
de Gerência de Configuração de Software e como
esta área se relaciona com o processo de desen-
volvimento de software. Também serão apresen-
tadas algumas estratégias de organização do
trabalho.
Gerenciamento de Incidente
O Gerenciamento de Incidente
Para que o gerenciamento de serviços de TI seja
eficiente e eficaz, o ITIL propõe um processo para
o gerenciamento de incidente, onde a maior parte
das ações desse processo são realizadas pe-
lo SERVICE DESK.
Nesse processo, a central de serviços registra os
incidentes informados pelos usuários, e tenta
resolve-los, consultando uma base de erros co-
nhecidos (BEC), onde consta a solução de alguns
incidentes.
O Gerenciamento de Incidentes tem como foco
principal restabeler o serviço o mais rápido possí-
vel minimizando o impacto negativo no negócio,
uma solução de contorno ou reparo rápido fazen-
do com que o cliente volte a trabalhar de modo
alternativo.
Garantir que os melhores níveis de disponibilida-
de e de qualidade dos serviços, sejam mantidos
conforme os acordos de nível de serviço é tam-
bém uma tarefa da gerência de incidentes.
6
É importante que o Gerenciamento de Incidentes
conheça e seja informado de quaisquer mudan-
ças.
Algumas Definições:
· Incidentes: Qualquer evento que não seja parte
da operação padrão de um serviço e que causa,
ou pode causar, uma interrupção ou redução na
qualidade daquele serviço;
· Requisição de Serviços: É tratada como uma
categoria de incidente que não provoca interrup-
ção ou falha na infraestrutura de TI. Exemplo:
Solicitação de informação e/ou documentação;
· Posição no fluxo de trabalho: O status do
incidente, reflete sua situação atual no ciclo de
vida;
· Carga de Trabalho: Tempo ou esforço gasto
em qualquer parte da resolução do incidente.
· Prioridade: De modo geral é medido pelo im-
pacto sobre o negócio e na urgência também
pode ser definido as ANS’s (acordo de nível de
serviço);
· Impacto: Grau em que a provisão de serviço é
interrompido;
· Urgência: Prioridade em que o incidente deve
ser resolvido;
· Esforço Esperado: Quantidade de esforço para
restaurar o serviço;
· Escalada: Mecanismo que oferece a resolução
adequada de um incidente;
· Funcional: O chamado é escalonado para um
segundo nível;
· Hierárquico: Utilizado quando existir a possibi-
lidade de que o chamado não seja atendido no
prazo;
· Detecção de Incidentes e Registros: Registrar
informações básicas do incidente;
· Classificação e Suporte Inicial: Classificar,
comparar, priorizar, fornercer suporte inicial (reso-
lução rápida);
· Investigação e Diagnóstico: Avaliação do inci-
dente e solução de contorno;
· Resolução e Recuperação: Resolver o inciden-
te ou elaborar uma requisição de Mudança (RM)
e tomar ações corretivas;
· Fechamento do Incidente: Verificar junto ao
cliente se o chamado foi atendido e resolvido e
comunicar o fechamento;
· Prioridade, Monitoração, Acompanhamento e
Comunicação.
Benefícios:
 Redução do Impacto: Com a maior rapi-
dez na solução do incidente, o serviço fica menos
indisponível, reduzindo o impacto para o negócio.
 Registro: Possibilita o registro de todos os
incidentes ocorridos, favorecendo a análise dos
KPIs (Key Performance Indicator).
 BDGC mais completo: A cada incidente
todos os itens de configurações são analisados e,
se necessário, completados.
 Aumento do tempo para o segundo ní-
vel: Mais tempo para a equipe de suporte traba-
lhar, pois não será interrompida com requisições
de usuários.
Relacionamento com outros processos
O gerenciamento de incidentes se relaciona com
os processos de configurações, problemas e mu-
danças da seguinte forma:
 Configurações: Os incidentes ocorrem em
algum item de configuração, que pertence aoB-
DGC (Base de dados de gerenciamento de confi-
gurações), que é administrado pelo gerenciamen-
to de configurações.
 Problemas: Quando a causa raiz do inci-
dente é desconhecida, ele é encaminhado para o
gerenciamento de problema que analisará, e for-
necerá os erros conhecidos e soluções de con-
torno para o gerenciamento de incidentes.
 Mudanças: O gerenciamento de incidente
deve estar avisando de todas as mudanças pla-
nejadas. Caso ocorra algum incidente relacionado
a mudanças realizada, deve ser avisado para que
7
o gerenciamento de mudanças torne as providên-
cias necessárias.
Dificuldades:
Algumas dificuldades podem ser encontradas na
implantação:
 Falta de comprometimento da equipe e do
gestor para resolução dos incidentes no tempo
necessário.
 Dificuldade para alinhar a área de TI com a
área de negócio, pois, normalmente, a área de TI
não entende as necessidades do negócio.
 Falta de acordo de níveis de serviços, im-
possibilitando que a equipe resolva os incidentes
conforme necessidade do negócio.
 Resistência a mudanças, impossibilitando
se adequar a nova forma de trabalho.
Processo de Gerenciamento de Incidente
O fluxo abaixo representa as atividades no pro-
cesso de gerenciamento de incidentes.
ANOTAÇÕES
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________
________________________________________