Papéis e Atividades > Conjunto de Papéis do Desenvolvedor > 
Designer de Teste > 
Definir Abordagem do Teste
Atividade:
| ||||||||||||||||||||||||||||||||||||||||||||||||
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Considerar a influência da missão, os motivadores de teste e os itens de teste na abordagem do próximo esforço de teste. |
Usando a missão de avaliação como contexto, examine o Plano de Teste de iteração e estude os motivadores de teste identificados para o próximo esforço de teste. Talvez seja necessário uma maior investigação na fonte de Motivadores - geralmente, o plano de iteração permite localizar informações adicionais.
Considere a abordagem de teste e as técnicas associadas que podem ser necessárias para abordar cada Motivador. Examine também o Plano de Teste de iteração e estude os itens de teste. Cada item de teste-alvo deverá ser considerado em relação a cada Motivador, e a abordagem e as técnicas deverão ser estendidas de acordo. Se você não conseguir localizar muitos detalhes ou se não estiver familiarizado com os itens de teste, talvez seja conveniente discutir os itens-alvo com a equipe de desenvolvimento, normalmente começando pelo arquiteto de software ou pelos chefes da equipe de desenvolvimento.
Concentre-se em identificar o conjunto mínimo de técnicas necessárias para abordar satisfatoriamente a missão de avaliação e os motivadores. Procure por oportunidades em que uma técnica possa ser usada para abordar mais de um aspecto do teste necessário. Observe outras técnicas possíveis que pareçam interessantes para serem exploradas, mas esteja preparado para identificá-las como adicionais, e não essenciais.
| Finalidade: | Considerar a influência da arquitetura de software na abordagem do teste. |
Estude a Arquitetura do Software para compreender seus elementos-chave — mecanismos, principais visões etc. Em geral, o Documento de Arquitetura do Software fornece informações apropriadas, com o nível certo de detalhes, para serem usadas no caso de uma abordagem de teste. Para esclarecer essas informações ou, na falta de um documento, convém discutir a arquitetura com a equipe de desenvolvimento, normalmente conversando diretamente com o arquiteto de software ou com um dos chefes da equipe de desenvolvimento.
Concentre-se na identificação e na discussão dos principais mecanismos e tente adquirir uma boa compreensão desses aspectos do sistema. Cada mecanismo e principal característica da arquitetura provavelmente apresentará desafios ou restrições ao esforço de teste. Por exemplo, uma arquitetura distribuída pode necessitar que a equipe de teste seja organizada em subequipes, com cada equipe concentrada em uma camada de arquitetura. Embora técnicas criativas possam ser usadas com freqüência para superar esses desafios, talvez seja necessário que a equipe de desenvolvimento modifique o software para permitir o teste, conforme discutido em Atividade: Definir Elementos de Testabilidade.
| Finalidade: | Considerar a abrangência da abordagem de teste em termos gerais e detalhados. |
Considerando todos os detalhes agora conhecidos sobre os requisitos para a abordagem de teste, é melhor recuar e considerar a abordagem de teste de uma perspectiva de nível superior. Que aspectos não são tratados pela abordagem de teste mas deveriam? Há algum aspecto que deva ser explorado e que não aparece em nenhuma das informações documentadas?
Baseado em sua experiência, reveja os requisitos para a abordagem do teste nos níveis geral e detalhado apropriados para este estágio do ciclo de vida do projeto. Considere os requisitos adicionais que ajudarão a apresentar uma abordagem mais completa.
| Finalidade: | Reutilizar ou adaptar a partir das técnicas de teste avaliadas existentes, conforme apropriado. |
Com base em sua própria experiência ou em outra experiência à qual você tenha acesso, identifique as técnicas existentes que atenderão aos requisitos da abordagem de teste ou que poderão ser adaptadas para atendê-los.
| Finalidade: | Identificar as técnicas necessárias para fornecer uma abordagem de teste suficiente e abrangente. |
Não convém imaginar uma abordagem de teste como "completa" — há sempre técnicas adicionais que poderão ser experimentadas se houver tempo e recursos ilimitados.
Entretanto, é importante que a abordagem de teste seja bem definida e abrangente o bastante para permitir uma avaliação útil da qualidade percebida que deverá ser feita. Isso requer uma abordagem que avalie aspectos suficientes do risco ou das dimensões de qualidade para que a equipe de projeto avalie a qualidade percebida com um grau de confiança justificado.
| Finalidade: | Descrever as funções de cada técnica, incluindo o objetivo do teste suportado. |
Descrever as funções de cada técnica. Abordar o tipo de teste suportado, o objetivo e o escopo, o método de implementação, as previsões de teste, o método de avaliação e as necessidades de automatização da técnica.
Em vários casos, você reutilizará a técnica de um projeto para o outro. Nessa situação, você poderá simplesmente fazer referência a uma definição comum da técnica ou copiar a definição existente e revisá-la, conforme apropriado.
Várias técnicas suportarão mais de um tipo de teste, portanto, pense um pouco e tente identificar quais testes a técnica precisará suportar. Isso ajudará a identificar o escopo do esforço necessário caso a técnica esteja sendo definida pela primeira vez.
Pense no objetivo fundamental e no valor representado por essa técnica.
Defina como a técnica será implementada. Não basta afirmar simplesmente: "Estamos testando o desempenho do sistema" — você deve pensar seriamente em como isso pode ser alcançado.
Algumas técnicas que você gostaria de usar têm um custo elevado para serem adquiridas. Descrevendo rapidamente como abordará a implementação dessa técnica, você conseguirá obter um sentido geral da logística e dos aspectos práticos que envolvem a aquisição da técnica futuramente.
Determine como você observará e avaliará os resultados de cada teste implementado usando essa técnica. Pense nas diferentes Previsões de Teste disponíveis para utilização — existe uma única previsão ou há diferentes maneiras de determinar o resultado de cada teste?
A automatização pode desempenhar um papel importante em várias técnicas de teste. Em alguns casos, ela será menos sofisticada, simplesmente oferecendo suporte para a condução de testes manuais.
Pense em como o trabalho que envolve a técnica poderia ser implementado, mantido e gerenciado de modo mais eficaz. Pense em todos os aspectos — leve em conta aspectos gerais e detalhados, considerando o maior número de opções possíveis.
Identifique as ferramentas apropriadas a serem usadas com essa técnica de teste. Use o trabalho do passo anterior que identificou as utilizações da automatização.
Lembre-se de considerar uma ampla variedade de categorias de ferramentas; sua lista de sugestões de ferramentas deve incluir mais do que apenas as ferramentas de automatização para execução de testes. Além das ferramentas que automatizam a execução de testes, considere ferramentas que melhorarão a produtividade da equipe de teste, reduzindo tarefas repetitivas e trabalhosas, como o gerenciamento de Dados de Teste, a análise de Resultados de Teste, as ferramentas de elaboração de relatórios de incidentes e Solicitações de Mudança etc.
| Finalidade: | Definir uma sugestão de arquitetura para o sistema de automatização de testes. |
Baseado na experiência adquirida de sistemas semelhantes ou em domínios de problema semelhantes, comece a definir uma sugestão de arquitetura para o sistema de automatização de testes.
Recomenda-se que você reveja as informações no link a seguir para obter ajuda para esta tarefa: Detalhamento do Fluxo de Trabalho: Definir uma Sugestão de Arquitetura.
| Finalidade: | Considerar os requisitos do teste para o gerenciamento de configuração. |
Assim como vários outros artefatos produzidos durante um projeto de desenvolvimento de software, os componentes de teste são sugestões para o gerenciamento de configuração e o controle de versão.
Os requisitos específicos podem variar em termos de complexidade, desde a decisão de utilização de serviços básicos de backup e recuperação permitidos até o suporte total para o desenvolvimento paralelo de Scripts de Teste automatizados em vários locais com diferentes versões de um aplicativo.
Pense nos seus requisitos para o gerenciamento de configuração e comece a esquematizar as prováveis necessidades de logística para a realização desses requisitos.
| Finalidade: | Reduzir o risco e o esforço reutilizando os componentes avaliados existentes. |
Algumas vezes, é melhor criar componentes a partir do zero, e algumas vezes não. Tente obter um equilíbrio razoável entre a filosofia do tipo "faça você mesmo" para todo o processo e o estabelecimento de uma política rígida e burocrática para a criação de um novo artefato.
Algumas vezes, uma abordagem será melhor do que outra, portanto, você deve ser flexível o suficiente para aproveitar os benefícios oferecidos pelas duas abordagens.
| Finalidade: | Registrar as importantes informações sobre a abordagem de teste. |
De acordo com diversos fatores, incluindo tamanho da equipe e cultura da organização, haverá maneiras melhores e piores de registrar as decisões feitas sobre a abordagem de teste.
Normalmente, haverá dois públicos a serem considerados a equipe de gerenciamento desejará rever essas informações para fornecer uma aprovação e estar ciente das implicações logísticas da abordagem, e a equipe de teste desejará usar a abordagem de teste como orientação para o trabalho a ser executado. Tente encontrar um meio apropriado para lidar com essas duas necessidades de modo conveniente: talvez usando um site de projeto da Intranet na Web.
| 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 |
