Determinar Qual Software Será Implementado
Finalidade:
|
Compreender os principais produtos liberados da equipe de desenvolvimento na próxima programação.
|
Usando o Plano de Iteração e outras fontes disponíveis, identifique os itens de software individuais que a equipe de
desenvolvimento planeja produzir para a próxima Iteração. Se o esforço de desenvolvimento estiver distribuído entre as
equipes situadas em vários locais, pode ser que você precise discutir os planos de desenvolvimento diretamente com cada
equipe. Verifique se algum desenvolvimento é subcontratado e use todos os canais disponíveis para reunir detalhes do
esforço de desenvolvimento dos subcontratantes.
Da mesma forma que em um novo software, observe também se ocorreram mudanças na infra-estrutura e nos componentes
compartilhados. Essas mudanças podem afetar outros elementos de software dependentes ou associados produzidos nos
ciclos de desenvolvimento anteriores, tornando necessário testar o efeito dessas mudanças nesses elementos. Por razões
semelhantes, identifique qualquer mudança e adição a componentes de outro fabricante que pretendem ser utilizados pelo
esforço de desenvolvimento. Isso inclui componentes compartilhados, bibliotecas de código base ou comum, widgets de
GUI, utilitários de persistência etc. Revise a arquitetura de software para determinar o mecanismo que está sendo
utilizado e que pode ser afetado pelas mudanças nos componentes de terceiros.
|
Identificar Sugestões de Elementos de Sistema a Serem Testadas
Finalidade:
|
Identificar os itens de destino a serem usados pelo esforço de teste.
|
Para cada motivador de teste identificado, examine a lista de itens de software a ser fornecida como parte desse ciclo
de desenvolvimento. Faça uma lista inicial que exclua qualquer item que não possa ser justificado como útil do ponto de
vista dos motivadores de teste. Lembre-se de incluir software disponíveis para comércio bem como softwares a serem
desenvolvidos diretamente pela equipe de desenvolvimento de projetos.
Considere também o impacto dos diversos ambientes de destino de implementação nos elementos a serem testados. Sua lista
de sugestões de elementos de sistema deverá ser expandida para incluir o software que está sendo desenvolvido e as
sugestões de elementos do ambiente de destino. Esses elementos incluirão dispositivos de hardware, software de driver
de dispositivo, sistemas operacionais, software de rede e comunicação, componentes de software base de terceiros (por
exemplo, software cliente eMail, Navegadores da Internet etc.) . Também podem incluir várias configurações e definições
relacionadas às possíveis combinações de todos esses elementos.
Se tiver identificado ambientes de destino de implementação importantes, registre essas informações criando ou
atualizando uma ou mais Configurações de Ambiente de Teste descritas; essa descrição deve fornecer um nome, um resumo e
enumerar os principais requisitos ou características da configuração. Evite perder muito tempo nesses esboços; a lista
de requisitos e recursos será detalhada subseqüentemente em Tarefa: Definir Configurações do Ambiente de Teste.
|
Refinar as Sugestões de Lista de Itens de Destino
Finalidade:
|
Eliminar destinos desnecessários e incluir elementos ausentes no plano de trabalho do esforço de
teste.
|
Usando a missão e o escopo de avaliação do esforço de teste, em conformidade com os investidores na avaliação, examine
a lista de itens de destino e identifique aqueles que não satisfazem à missão de avaliação e que, obviamente, estão
fora do escopo do esforço de teste.
Como uma verificação contrária, examine criticamente os itens novamente e questione se a missão de avaliação e o escopo
do esforço de teste realmente serão satisfeitos pela lista refinada de itens de destino. Pode ser necessário adicionar
outros elementos à lista de itens de destino para garantir o escopo apropriado e a capacidade de atingir a missão de
avaliação.
|
Definir a Lista de Itens de Destino
Finalidade:
|
Comunicar as decisões tomadas sobre os itens de teste de destino para o próximo trabalho.
|
Agora que decidiu sobre os itens de teste de destino, você precisará comunicar suas escolhas à equipe de teste e aos
outros investidores no esforço de teste. Discutivelmente, o método mais comum consiste em documentar as decisões sobre
os itens de destino no Plano de Iteração de Teste.
Uma alternativa é simplesmente registrar essas informações em algum tipo de tabela ou planilha e utilizá-las para
orientar a atribuição do trabalho e das responsabilidades. Durante a implementação e execução de testes, os testadores
individuais utilizarão essas informações para tomar decisões táticas sobre os testes específicos a serem implementados,
e sobre os resultados de teste que devem ser capturados em relação a esses itens de destino.
|
Avaliar e Verificar os Resultados
Finalidade:
|
Verificar se a tarefa foi concluída apropriadamente e se os produtos de trabalho resultantes são
aceitáveis.
|
Agora que o trabalho foi concluído, convém certificar-se de que o trabalho foi vantajoso e que não foi apenas um grande
consumo de papel. Você deve avaliar se o trabalho é de qualidade adequada, e se ele é completo o suficiente para ser
útil aos membros da equipe que o utilizarão em seguida como entrada para o trabalho deles. Onde for possível, utilize
as listas de verificação fornecidas no RUP para verificar se a qualidade e a integridade estão suficientemente boas.
Faça com que as pessoas que desempenham tarefas posteriores, que dependem do seu trabalho como entrada, participem da
revisão do seu trabalho provisório. Faça isso enquanto você tiver tempo disponível para tomar alguma ação para resolver
os problemas delas. Você também deve avaliar seu trabalho em relação aos principais produtos de trabalho de entrada
para certificar-se de que foram representados de maneira precisa e suficiente. Pode ser útil fazer com que o autor do
produto de trabalho de entrada revise seu trabalho nessa base.
Não se esqueça de que o RUP é um processo de entrega interativo e que, em muitos casos, os produtos de trabalho evoluem
com o tempo. Dessa formal, nem sempre é necessário (e às vezes é contraproducente) formar completamente um produto de
trabalho que será utilizado apenas parcialmente ou que nem será utilizado no trabalho imediato subseqüente. Isso
acontece porque há uma grande probabilidade de que a situação em torno do produto de trabalho sofra alterações e de que
os pressupostos feitos quando o produto de trabalho foi criado se provem incorretos, antes que o produto de trabalho
seja utilizado, resultando em esforço perdido e retrabalho dispendioso. Evite também a armadilha de gastar muitos
ciclos na apresentação em detrimento do valor do conteúdo. Nos ambientes de projeto em que a apresentação tem
importância e valor econômico como um produto liberado do projeto, convém utilizar um recurso administrativo para
executar as tarefas de apresentação.
|
|