Atividade: Obter Confirmação de Testabilidade

Examinar as necessidades de testabilidade

Estude a arquitetura de automatização de testes e as especificações da interface de teste para obter um bom entendimento das necessidades de implementação e avaliação do teste. Especificamente, é necessário que você entenda as restrições impostas por essas necessidades ao processo de engenharia de software ou à arquitetura e ao design de software.

Avaliar o impacto e priorizar

Estude as necessidades de testabilidade e execute a análise básica em termos do impacto no esforço de teste provocado pela necessidade não ter sido atendida. Considere também algumas análises básicas do esforço possível exigido pela equipe de desenvolvimento para investigar e fornecer uma solução para a necessidade. Identifique, para cada necessidade, soluções alternativas possíveis que teriam um impacto menor nas equipes de desenvolvimento.

Usando essas informações, formule uma lista priorizada que coloque em primeiro lugar as necessidades que causarão maior impacto no esforço de teste caso não sejam atendidas e que não possuem solução alternativa. Faça isso não desperdiçar valiosos recursos de desenvolvimento em necessidades de testabilidade menos essenciais, reservando essa oportunidade para as necessidades realmente importantes.

Definir benefícios de testabilidade

Ao solicitar que a equipe de desenvolvimento desenvolva um software com provisão específica para o esforço de teste, você estará acrescentando requisitos e restrições adicionais ao esforço de desenvolvimento; isso resume-se basicamente em mais trabalho, além de risco e complexidade adicionais para a equipe de desenvolvimento. Algumas equipes de desenvolvimento considerarão o design de testabilidade como fora do escopo de sua responsabilidade. Em outros casos, as necessidades de testabilidade deverão competir pelos recursos de desenvolvimento com as necessidade e os requisitos do cliente que normalmente recebem mais prioridade. Dessa forma, você precisará "vender" os benefícios das necessidades de testabilidade para o gerente de projeto, para o arquiteto de software e para outros envolvidos na equipe de desenvolvimento.

Formule uma análise dos benefícios de cada necessidade de testabilidade para a qual você deseja obter uma confirmação. Procure artigos de pesquisa e estudos que suportem a importância de sua necessidade de testabilidade e utilize estatísticas sobre o retorno de investimento quando ela estiverem disponíveis. Pense nos benefícios em termos de importância para a equipe de desenvolvimento; que informações úteis de avaliação você poderá fornecer a eles que não poderiam ser fornecidas se essa necessidade não fosse atendida? Como isso facilitaria ou tornaria mais eficaz que você fornecesse um feedback à equipe de desenvolvimento oportuno, preciso, detalhado ou útil durante cada ciclo de build? Essa necessidade fornecerá uma característica útil à equipe de desenvolvimento que poderá ser usada em seu próprio esforço de teste ou em diagnósticos futuros de falhas do software? No caso de disputa com as necessidades do cliente, pense em maneiras de demonstrar que uma solução antecipada para a necessidade de testabilidade trará oportunidades adicionais para que os requisitos do cliente sejam suportados em ciclos de build subseqüentes.

Identificar e conhecer os campeões de testabilidade

Considerando que você estará impondo um possível trabalho ou risco adicional à equipe de desenvolvimento, identifique e conheça os envolvidos influentes com capacidade para aprovar ou ordenar o suporte da testabilidade. Faça isso o mais rápido possível, antes de promover ativamente as necessidades de testabilidade que deseja que sejam suportadas.

Os três envolvidos mais importantes são o arquiteto de software, o gerente de projeto e o representante do cliente. Passe algum tempo com o arquiteto de software e mostre a importância de se criar uma arquitetura de software que suporte a testabilidade. Passe algum tempo com o gerente de projeto e mostre os benefícios da testabilidade em termos de produtividade da equipe de teste e um rápido tempo de resposta às informações de avaliação. Mostre ao cliente a importância de liberar um produto de qualidade.

Promover as necessidades e os benefícios de testabilidade

É importante promover as necessidades da testabilidade na direção certa. Cada combinação de gerente de projeto, equipe de desenvolvimento e envolvidos do lado do cliente possui uma dinâmica social e cultura diferentes; é importante que você esteja ciente disso quando promover as necessidades de testabilidade. Como heurística geral, não monte uma "campanha" de testabilidade formal no caso de uma equipe relativamente relaxada e informal nem use uma abordagem informal em um projeto de alta cerimônia.

Em alguns casos, uma sessão de "brainstorming" de colaboração é um formato de apresentação útil, onde a necessidade é apresentada como um desafio à equipe de desenvolvimento, que é estimulada a identificar soluções criativas para atender às necessidades de testabilidade. Isso estimula sua propriedade da solução e gera uma sensação de parceria no esforço.

O tempo também é importante neste passo. Como regra geral, tente identificar e promover as questões de testabilidade mais importantes o quanto antes, em geral, durante a Elaboração, e, quando for possível, na Fase de Iniciação. Quando questões de testabilidade são levantadas nos estágios iniciais do projeto, a equipe normalmente é menor e mais receptiva a mudanças. Também é mais fácil incluir essas necessidades no design em desenvolvimento já que geralmente um retrabalho mínimo é necessário.

Uma boa chance de identificar as necessidades de testabilidade e apresentá-las de uma forma positiva e menos "oficial" é quando a equipe de teste oferece seus serviços na avaliação das atividades de prova de conceito e na avaliação da seleção de componentes de outros fabricantes para utilização no esforço de desenvolvimento. Especificamente, o envolvimento das equipes de testes durante a seleção de componentes de banco de dados, seleção de componentes ou controle de UI, seleção de componentes de middleware etc. significa que as questões de testabilidade podem ser usadas como um aspecto dos critérios de seleção de componentes. Por exemplo, em muitos casos, as equipes de desenvolvimento terão uma preocupação mínima sobre qual biblioteca de widgets de UI utilizar; se uma biblioteca for mais testável que outra, a equipe de desenvolvimento ficará feliz em selecionar a biblioteca de widgets mais testável.

Se já tiver tido problemas para identificar ou conhecer os campeões de testabilidade, você talvez precisará considerar uma abordagem que apresente as mudanças de uma forma mais incremental, tornando-as possivelmente menos arriscadas e distribuindo-as em blocos menores de esforço, ou talvez precisará escalar as necessidades de testabilidade mais importantes como questões críticas do projeto que impedem que o esforço de teste seja bem-sucedido até que elas sejam resolvidas. No segundo caso, recomenda-se que você considere cuidadosamente todas as suas opções antes de decidir adotar essa medida.

Obter uma confirmação para suportar e manter a testabilidade

É importante assegurar que as necessidades de testabilidade sejam consideradas da mesma maneira que qualquer outro requisito ou restrição imposta ao esforço de desenvolvimento. Você precisa receber uma confirmação de que as características de testabilidade disponibilizadas hoje não serão abandonadas amanhã.

Em alguns casos, tentar obter essa confirmação poderá resultar na recusa da equipe de desenvolvimento em desenvolver ou suportar as necessidades de testabilidade. Embora isso possa ser desestimulante, é melhor estar ciente dessa situação e lidar com a realidade o quanto antes do que perder um tempo enorme e desperdiçar esforço desenvolvendo uma implementação de teste que não será mais suportada pela equipe de desenvolvimento.

Defender a resolução das questões de testabilidade

Embora a equipe de desenvolvimento possa concordar em fornecer o suporte necessário para as necessidades de testabilidade do esforço de teste, é importante que você tenha um interesse ativo no design, na implementação e na conclusão desse trabalho. Não abandone simplesmente o trabalho só porque a equipe de desenvolvimento concordou em lidar com as necessidades de testabilidade ou começou a trabalhar em uma solução; você precisa garantir que uma solução apropriada será desenvolvida no momento oportuno.

Coloque a si mesmo e os outros membros da equipe de teste à disposição para responder às perguntas das equipes de desenvolvimento e se ofereça para avaliar os protótipos assim que eles forem construídos. Ofereça um feedback construtivo e demonstre entusiasmo pelo esforço da equipe de desenvolvimento em ajudá-lo a atender às suas necessidades. Ofereça os principais membros de sua equipe para promoverem ou participarem de workshops de design para as necessidades de testabilidade mais complexas, mas tome cuidado para que sua equipe não acabe se tornando autoritária e controlando o espaço de solução do processo de design para os desenvolvedores.

Quando surgirem problemas e você sentir que eles não estão recebendo a devida atenção ou sendo resolvidos com a rapidez necessária, compartilhe suas preocupações com o arquiteto de software e o gerente de projeto. Peça que o gerente de projeto registre um problema na lista problemas do projeto se for apropriado.

Avaliar e verificar seus resultados

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 tomem parte nele 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 eles. 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.

Tente lembrar-se de que o RUP é um processo iterativo e que, em vários casos, os artefatos evoluirão com o passar do 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 finais, utilize um recurso administrativo para tarefas de apresentação.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process