Papéis e Atividades > Conjunto de Papéis do Desenvolvedor > 
Designer de Teste > 
Desenvolver Guia de Teste
Finalidade
|
|
Passos
No início de cada iteração: Quando cada técnica da abordagem de teste é verificada: |
|
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Normalmente, esta atividade é executada várias vezes em cada iteração. | |
| Papel: Designer de Teste | |
| Mentores de Ferramentas: |
|
| Informações Adicionais: |
|
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Reunir diretrizes úteis de todas as fontes existentes e disponíveis. |
Na fase de Iniciação ou no início da fase de Elaboração, dedique algum tempo a localizar guias existentes. O Guia deve se enquadrar em uma das três categorias gerais: orientações (estratégicas ou táticas) para controle e execução do projeto, concordância com padrões e práticas específicas do projeto (ou da organização). Ao procurar guias já existentes, eles deverão estar em uma dessas três categorias.
Guias que documentam decisões estratégicas e táticas sobre determinado projeto. Um bom local para procurar esses guias são os documentos de planejamento dos projetos atuais ou armazenados. Caso tenha acesso aos documentos de avaliação do mesmo projeto, poderá formar uma opinião sobre a utilidade e o êxito dos guias.
Padrões como IEEE Std829-1998 [IEEE] fornecem templates e exemplos para a aderência a documentações com formato específico. No caso de Std829, relaciona-se especificamente ao conjunto de documentação de teste. O RUP contém vários templates de artefato adequados para a aplicação de muitos padrões IEEE de documento. SEI CMM e ISO9001 oferecem um padrão com o qual a maturidade ou a aderência da execução de um processo de software podem ser avaliadas.
Outras categorias de padrão incluem certificações para domínios ou ambientes específicos.
O padrão DO-178B de RTCA descreve Software Considerations in Airborne Systems and Equipment Certification (consulte 
o site de RTCA na Web para obter mais informações).
Algumas organizações também têm seus próprios padrões internos que devem ser seguidos. Categorias comuns incluem convenções de programação e guias de estilo, padrões da interface do usuário e guias de estilo, compatibilidade com convenções arquiteturais de toda a organização, restrições e padrões. Alguns exemplos são a utilização de auditoria centralizada, serviços de controle de segurança ou de transações, restrições impostas a recursos da linguagem e técnicas usadas, ou limites da própria arquitetura (clientes pesados não são permitidos, protocolos HTTP básicos são considerados riscos de segurança etc).
Uma pesquisa que utilize principalmente o mecanismo padrão da Internet apontará um grande número de recursos.
Este tipo de adaptação ou de ajuste de processos é relativamente informal. Os próprios guias assumem a forma de orientações heurísticas ou "livros de receita", que conseguem a adesão do praticante sobre determinado assunto de maneira "espontânea". Para que essas orientações sejam "consumíveis", é importante buscar um equilíbrio entre orientações indicativas e explicações descritivas. Embora seja a categoria de guias mais valiosa, o contexto da situação e a natureza especializada das melhores práticas dificultam sua documentação de forma que possa ser reutilizada.
O RUP contém várias práticas de engenharia de software recomendadas que podem ser acessadas pelo site do RUP na Web. As páginas de artefato Diretrizes e Pontos de Verificação (por exemplo,Pontos de Verificação: Plano de Teste).
Algumas comunidades da Web também oferecem recursos de boas práticas, como a comunidade de padrões de software. Esta é uma listagem de recursos de comunidades da Web que enfatizam os testes:
TestingCraft: Site de Brian Marick, no qual os Testadores de Software Compartilham suas Técnicas.Cem Kaner: Artigos baseados nas observações do Dr. Cem Kaner sobre as técnicas de teste, entre outros assuntos.Satisfice: Vários artigos de James Bach e outros sobre questões relativas a testes.Patterns Of Software Test (PoST): Site de Brian Marick, no qual a aplicação de Padrões
é explorada e discutida em relação ao Teste de Software.| Finalidade: | Determinar adaptações iniciais que atendam ao escopo do projeto/esforço de teste. |
Considere a adaptação inicial necessária para atender ao escopo do projeto e seu respectivo esforço de teste. Algumas adaptações são necessárias de acordo com o tamanho da equipe. Outras se baseiam no processo apropriado e na cultura da organização.
| Finalidade: | Identificar os guias específicos apropriados a determinado contexto. |
Os guias tendem a ser criados como "enciclopédias" abrangentes e, em geral, como um único artefato. Em contrapartida, podem também ser criados como numerosas anotações pequenas sobre questões específicas. Esses dois formatos podem tornar a consulta e o uso dos guias uma tarefa demorada e dispersa.
Considere a criação de um artefato de referência para o projeto, que inclua direcionadores para os guias que você achar aplicáveis ao contexto atual. Você precisará de tempo para atualizar esse procedimento. Evite excesso de duplicações no artefato de referência: tente limitar as entradas a um nome identificador e a um localizador.
| Finalidade: | Identificar como o guia pode ser adaptado para o projeto e obter concordância sobre o que deve ser adaptado. |
Pensar em maneiras como o guia pode ser ampliado e, ao mesmo tempo, reduzido para se adequar melhor às necessidades da equipe.
Depois de apresentar todas as idéias de adaptação, é importante obter um consenso sobre o que deverá ser adaptado.
| Finalidade: | Registrar as decisões concordadas sobre adaptação. |
Depois de escolher o guia apropriado ao contexto atual, documente suas decisões. Provavelmente, você usará dois formatos: um para registrar as decisões tomadas e outro para registrar o próprio Guia de Teste, seus métodos e suas descrições.
O caso de desenvolvimento serve como um formato para o registro das decisões sobre as diretrizes a serem seguidas, como também o plano de desenvolvimento de software, os planos de teste e outros documentos relacionados ao gerenciamento de projeto.
Para obter informações adicionais, consulte a seção "Adaptação" do Guia de Teste.
| Finalidade: | Revisar as diretrizes e corrigir erros de compilação. |
Revise e verifique se o guia foi elaborado com clareza e consistência. Verifique se ele fornece orientações adequadas às equipes que o usarão.
| Finalidade: | Identificar práticas específicas adicionais aplicáveis ao projeto atual. |
Encoraje os membros da equipe a identificarem e observarem as práticas específicas do projeto. A comunidade de padrões de software criou o WikiWikiWeb, um excelente mecanismo para compartilhar experiências práticas. O wiki público mais antigo (o Portland Pattern Repository) foi criado em 1995 e está ativo desde julho de 2001. Você pode visitar o PPR em Wiki:WelcomeVisitors. É recomendável que você crie seu próprio site WikiWikiWeb para capturar e desenvolver práticas específicas do projeto (ou da organização). Para obter informações sobre como começar seu próprio Wiki, consulte WikiWikiWeb.
Mesmo que você não possa ou não utilize o formato WikiWeb, lembre-se de alguns fatores. Primeiro, é importante ter um mecanismo que incentive a identificação e o registro de boas práticas. Esse mecanismo deve permitir que a prática seja identificada. Seu método básico, assim como sua maior vantagem, é a facilidade de registro. Essas informações fundamentais poderão ser ampliadas e apresentadas pela equipe no papel de engenharia de processos. Evite criar excesso de processos e documentações burocráticas, pois desencorajam a contribuição dos membros da equipe.
| Finalidade: | Reutilizar práticas emergentes usadas por outros grupos. |
Geralmente, boas práticas são aquelas que foram usadas diversas vezes anteriormente e que puderam ser ajustadas e aprimoradas.
Você não precisa reinventar a roda a todo momento: tire proveito do sucesso e das falhas de outros projetos e organizações utilizando seus guias.
| Finalidade: | Garantir que o guia seja útil e preciso. |
Quando o guia é usado, surgem novas idéias sobre os aspectos mais importantes e menos relevantes do próprio guia. Em cada ciclo do build ou da iteração, disponha de algum tempo para revisar e continuar o desenvolvimento do guia.
Para incentivar e facilitar esse processo, crie um fórum fácil de ser usado que permita aos membros da equipe registrar rapidamente possíveis melhorias quando elas forem identificadas.
| 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.