Papéis e Atividades > Conjunto de Papéis do Gerente > 
Gerente de Testes > 
Combinar Missão
Atividade:
| ||||||||||||||||||||||||||||||||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Normalmente, esta atividade é executada várias vezes em cada iteração. | |
| Papel: Gerente de Testes | |
| Mentores de Ferramentas: | |
| Informações Adicionais:
|
|
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Obter uma compreensão inicial do escopo e objetivo do plano de iteração. |
Examine o plano de iteração e identifique o escopo e os objetivos do plano.
É útil complementar esse exame iniciando discussões informais com a equipe principal do projeto, como o gerente de projeto, o arquiteto de software e o representante do cliente. Essas reuniões geralmente enfatizam as preocupações de forma mais explícita do que o documentado no plano. As reuniões de início de iteração também fornecem informações úteis.
| Finalidade: | Compreender as expectativas dos envolvidos em relação ao escopo do esforço de avaliação. |
A missão é o carro-chefe que conduz o esforço de teste durante um período específico. Os recursos de teste são geralmente limitados e, portanto, o desafio será balancear determinadas restrições de recurso de teste com as necessidades de validação de qualidade do esforço de desenvolvimento de software.
Busque uma compreensão inicial, em um nível estratégico, das expectativas da equipe de desenvolvimento de software. Você deve estar principalmente preocupado com as expectativas do gerente de projeto, do arquiteto de software e dos analistas de sistema líderes.
| Finalidade: | Obter colaboração e feedback dos envolvidos no que diz respeito aos objetivos e ao escopo do esforço de teste. |
Não é uma prática extremamente útil considerar os objetivos e o escopo separados do restante da equipe de projeto. O RUP defende a propriedade de qualidade de produto da equipe e, sendo assim, você deve incluir envolvidos relevantes da equipe de projeto ao decidir qual teste é importante. Você deve considerar como envolvidos importantes os membros da equipe que desempenham os seguintes papéis: Gerente de Projeto, Arquiteto, Analista de Sistema e Integrador.
Em alguns casos, o formato da apresentação adequado será o formal, com os envolvidos reunindo-se como uma junta consultiva e fazendo uma boa preparação antes. Em outros casos, almoços "de negócios" ou entrevistas individuais com cada envolvido podem ser apropriados. Existem pontos positivos e negativos em cada abordagem: escolha o formato que melhor se adeqüe às suas necessidades no contexto do ambiente de projeto atual.
| Finalidade: | Identificar claramente a essência do enfoque de teste da iteração atual. |
As declarações de missão são úteis ao enfocar uma equipe, especialmente em situações em que a equipe se depara com várias opções possíveis. As equipes de teste que não têm uma missão de avaliação geralmente consideram que a missão deles é simplesmente "executar testes": isso orienta muito pouco quando escolhas difíceis devem ser feitas para decidir o melhor enfoque de teste dentro das restrições de tempo ou recurso. Uma declaração de missão destila a essência do objetivo de trabalho atual e fornece um "mantra" para manter a equipe centrada nas tarefas certas.
Formule uma declaração de missão que possa ser usada pela equipe de teste. Não a torne muito complexa nem incorpore muitas idéias conflitantes: as melhores declarações de missão são simples, curtas e fáceis e, na maioria dos casos em que é preciso escolher uma das opções possíveis, a missão deixará bem claro o que a equipe deve escolher.
Aqui estão algumas idéias de declarações de missão que você poderia adotar em uma determinada iteração:
Observando essa lista, você deve ter imaginado que várias missões são mutuamente exclusivas. Por exemplo, se minha missão é "localizar problemas importantes com rapidez", provavelmente não serei capaz de "verificar uma especificação": para executar com sucesso uma missão, geralmente outras missões possíveis serão negadas e uma abordagem de teste de suporte diferente será necessária.
As equipes de teste que tentam atender a várias missões de avaliação geralmente têm dificuldades ao se depararem com conflitos contínuos em seu trabalho. Observe também que recomendamos a escolha e reconsideração de sua missão de avaliação a cada iteração: é natural que a missão seja alterada no decorrer do tempo, de acordo com o contexto do esforço de trabalho atual.
| Finalidade: | Chamar atenção para a importância do esforço de teste. |
Determinados produtos de trabalho são produtos liberados importantes para um ou mais envolvidos: outros produtos de trabalho são artefatos necessários do esforço de teste e, embora sejam importantes para a equipe de teste, pouco interessam aos mesmos envolvidos.
Reflita um pouco sobre o conjunto mínimo de produtos liberados úteis no esforço de teste. Não liste todos os produtos de trabalho, mas somente aqueles que oferecem benefícios diretos e tangíveis a um envolvido e aqueles através dos quais o sucesso do esforço de teste será avaliado. Talvez seja necessário adaptar essa lista inicial para acomodar as necessidades dos envolvidos, mas você precisará desempenhar um papel pró-ativo, estimulando os produtos liberados a se manterem úteis e gerenciáveis.
| Finalidade: | Negociar com todos os envolvidos para obter um acordo mútuo sobre a maioria das missões apropriadas da iteração. |
Mais uma vez, reflita sobre o formato apropriado para apresentar a missão e conseguir as aprovações necessárias. Escolha o formato que melhor se adeqüe às suas necessidades no contexto do ambiente de projeto atual.
| Finalidade: | Verificar se a atividade foi concluída corretamente e se os artefatos resultantes são aceitáveis. |
Agora que você concluiu o trabalho, convém verificar se ele foi proveitoso e garantir que você não apenas consumiu uma grande quantidade de papel. Avalie se a qualidade de seu trabalho é apropriada e se ele está completo o suficiente para ser útil aos membros da equipe que o utilizarão depois como entrada em seu próprio trabalho. Sempre que possível, use as listas de verificação fornecidas no RUP para verificar se a qualidade e a abrangência estão satisfatórias.
Faça com que as pessoas que executam as atividades subordinadas e que dependem de seu trabalho como input participem revisando o seu trabalho provisório. Faça isso enquanto ainda dispõe de tempo para executar algum tipo de ação em relação às questões levantadas por elas. Avalie também seu trabalho, comparando-o com os principais artefatos informados para verificar se eles foram representados de forma precisa e satisfatória. Talvez seja útil solicitar ao autor do artefato informado para rever seu trabalho baseado nisso.
Lembre-se de que o RUP é um processo iterativo e de que, em muitos casos, os artefatos evoluem com o tempo. Portanto, normalmente não é necessário — e, em geral, é improdutivo — formar um artefato completo que será usado apenas parcialmente ou que nem será usado no trabalho imediatamente subseqüente. Isso porque há uma grande probabilidade de a situação que envolve o artefato ser alterada — e as suposições feitas no momento de criação do artefato acabarem sendo incorretas — antes de o artefato ser usado, resultando em desperdício de esforço e em um dispendioso retrabalho. Evite também a armadilha de ficar perdendo tempo com inúmeros ciclos de apresentação em detrimento do valor do conteúdo. Em ambientes de projeto em que apresentações têm grande importância e são considerados produtos liberados, utilize um recurso administrativo para tarefas de apresentação.
|
Rational Unified Process |
