Atividade:
| ||||||||||||||||||||||||||||||||||||||||||||
| Detalhamentos do Fluxo de Trabalho: |
| Finalidade: | Compreender a avaliação atual dos problemas de qualidade do produto que a equipe de teste identificou no sumário. |
Comece examinando os sumários de avaliação de testes que a equipe de teste preparou. Compare as informações de avaliação com o Plano de Teste da iteração, a fim de compreender o sumário no contexto do trabalho planejado. Discuta quaisquer ambigüidades e preocupações com os membros da equipe de teste que preparam o sumário e resolva-as.
Neste passo e nos passos subseqüentes referentes à coleta de informações e à avaliação da qualidade do software, tente obter uma visão balanceada incorporando medidas objetivas e subjetivas. Lembre-se de que os números objetivos oferecem somente parte do panorama e precisam ser respaldados e explicados pelo "clima" de projeto atual. Por outro lado, não dê ouvidos a boatos e especulações subjetivas sobre a qualidade do software: busque evidências objetivas comprovadas. Recomendamos que você complemente os dados objetivos através de discussões com os líderes de equipe ou, quando possível, com cada membro da equipe, a fim de reunir avaliações subjetivas e estimar até que ponto pode confiar nos dados objetivos.
| Finalidade: | Obter uma compreensão mais aprofundada dos resultados de teste que respaldam a avaliação atual de qualidade de produto identificada nos sumários. |
Com base nos sumários de avaliação de testes, examine os resultados de teste selecionados em busca de contexto adicional. Pesquise os resultados até ter a certeza de que compreende as questões importantes que foram identificadas nos sumários de avaliação de testes.
Além disso, revise os dados e procure as tendências importantes evidentes nos dados dos resultados de teste que possam estar ausentes. Em geral, é mais importante identificar o que as tendências relativas dos dados estão indicando do que observar números absolutos. Fique atento a indicações como falhas em áreas que estejam relacionadas a falhas de outras áreas.
| Finalidade: | Obter as informações detalhadas que possibilitarão uma discussão eficaz das questões pendentes mais importantes e suas possíveis soluções. |
Recomendamos que você limite este exercício às questões mais urgentes e às solicitações de mudança associadas. Você será capaz de dedicar mais atenção a um menor número de questões e, em geral, há uma probabilidade maior de elas exercerem o maior impacto sobre a qualidade do produto. Se você tiver uma lista maior dos problemas-chave, recomendamos que dê a atenção devida a elas, tendo como base sua prioridade relativa: não desperdice os recursos defendendo questões de pouca importância. No entanto, observe que um número significativo de Solicitações de Mudança pendentes de baixa prioridade pode tornar uma declaração sobre a qualidade dos produtos tão importante quanto as poucas mudanças de prioridade alta. Tente agrupar as Solicitações de Mudança de baixa prioridade em aspectos lógicos de qualidade, com base nos riscos de qualidade que elas representam. Isso o ajudará a articular e defender o efeito combinado sobre a qualidade de modo mais claro.
Identifique as tendências importantes que aparecem nos dados gerais de Solicitação de Mudança. Em geral, é mais importante identificar o que as tendências relativas dos dados estão indicando do que observar números absolutos. Procure pontos positivos, como uma taxa contínua estável de resolução de defeitos, ou um aumento contínuo gradativo e uma diminuição subseqüente da taxa de resolução, no decorrer do tempo. Fique atento a picos e baixas na taxa de resolução que indiquem que a equipe de desenvolvimento pode estar prestes a se deparar com problemas processuais, ambientais, políticos etc. que reduzirão a produtividade.
Observação: talvez você também queira aproveitar a oportunidade para melhorar a clareza das Solicitações de Mudança associadas, eliminando a ambigüidade e a linguagem e argumentação emotivas. Se você mesmo fizer essas mudanças, discuta as melhorias obtidas com as pessoas que criaram esses artefatos, a fim de que elas possam compreender por que as melhorias são importantes.
| Finalidade: | Formular a compreensão dos problemas-chave no que diz respeito ao risco que eles representam para a qualidade do produto, além de formular a compreensão do risco associado que ameaça o sucesso do projeto de desenvolvimento de software. |
Identifique cada brecha de qualidade e avalie o impacto e o risco associados de cada problema que está gerando essa brecha. Considere as estratégias de diminuição e contingência, formule suas idéias iniciais sobre essas estratégias e discuta-as com outros membros da equipe.
Leve em consideração que uma qualidade "perfeita" é, de certa forma, um conceito mítico. Tenha cuidado para usar uma "barra de qualidade" realista e atingível ao avaliar a qualidade e identificar as brechas de qualidade. Consulte Conceito: Qualidade do Produto
| Finalidade: | Produzir uma lista realista mínima das ações necessárias para negociar a resolução satisfatória dos problemas-chave. |
Para cada brecha de qualidade importante, considere as possíveis estratégias de diminuição e contingência. Formule suas idéias iniciais sobre essa estratégia e discuta-as informalmente com outros membros da equipe para ter uma visão maior e validar seus pensamentos. Caso você queira obter soluções, o ideal é ter várias opções: elas ajudarão você a valorizar as compensações e a adotar a melhor solução para o contexto em questão.
Trabalhe com um conjunto de possíveis soluções e sugestões úteis que auxiliará a equipe do projeto a lidar adequadamente com cada brecha de qualidade. É importante que você faça isso para que o esforço de teste seja reconhecido como um salutar contribuidor para a resolução de problemas, e não como um mero informador de problemas. Esse é um aspecto importante, que defende o valor da equipe de teste e conquista o respeito e a cooperação dos outros membros da equipe.
| Finalidade: | Reunir informalmente o suporte para resolver os problemas-chave e obter uma compreensão das propostas que têm mais probabilidade de serem aceitas. |
Não é nada engraçado apoiar uma causa perdida. Geralmente, a abordagem mais eficaz é identificar soluções para problemas em que há mais probabilidade de a equipe do projeto apoiar, aceitar e se comprometer. Mantenha um relacionamento estreito com os principais tomadores de decisão e comece tornando esses problemas-chave informalmente visíveis através de uma discussão bidirecional. Muitas vezes, essa será uma excelente maneira de conquistar apoio e chegar a soluções possíveis.
Haverá ocasiões em que você não terá escolha, a não ser adotar uma solução que não é muito bem aceita pela equipe de desenvolvimento. Quando possível, será até mesmo mais importante saber quem pode lhe dar apoio e encontrar formas de vender a solução que apresente seu valor da maneira mais clara possível ou expor claramente a terrível conseqüência da não resolução do problema.
| Finalidade: | Defender uma solução apropriada a ser colocada em prática em um período de tempo aceitável que não prejudique a qualidade. |
Este é o dilema da defesa da qualidade: ser capaz de negociar uma solução adequada que satisfaça a equipe de desenvolvimento e não reduza significativamente a qualidade do produto. Lembre-se de que, na maioria dos casos, a equipe de teste é basicamente um conselheiro de qualidade. Portanto, você deve ter cuidado para não exigir que uma determinada resolução seja executada.
Entretanto, é importante que a equipe de teste faça um bom trabalho como advogada da qualidade, o que implica, algumas vezes, ser portadora de notícias que a equipe do projeto não gosta de ouvir. É aqui que equipes de teste eficientes fornecem o esforço de desenvolvimento com o máximo de discernimento do problema e de suas possíveis soluções e com o máximo de compreensão das compensações de cada opção. Você deve atuar, de certa forma, como um agente dos eventuais clientes do produto e ajudar a negociar as soluções que serão de maior interesse para eles.
| Finalidade: | Permanecer no controle, envolvido e ciente do andamento da resolução dos problemas. |
Às vezes, os defeitos e outras solicitações de mudança se perdem no processo de desenvolvimento contínuo básico do produto e no processo de expansão das características. Isso acontece, por um lado, porque é mais atrativo para os desenvolvedores trabalhar com "material novo" do que precisar corrigir os códigos antigos e cheios de erros e, por outro lado, porque o valor do negócio pode ser mais obviamente manifestado na inclusão de algo novo do que no conserto de algo quebrado. Como advogados da qualidade, a equipe de teste precisa ajudar o projeto a ver consertos de defeito importantes.
As equipes de software de sucesso encontram um bom equilíbrio entre a melhoria incremental da qualidade através da resolução de defeitos e a expansão incremental das características. A equipe de teste pode auxiliar a equipe de projeto encontrando formas de estimular e apoiar a melhoria incremental da qualidade, em vez de desempenhar o papel menos útil e mais controverso de "guarda da qualidade".
| Finalidade: | Confirmar que as resoluções dos problemas-chave serão realizadas sem nenhum efeito negativo significativo. |
Seja qual for a solução adotada pela equipe de desenvolvimento para resolver um problema de qualidade, a resolução deve melhorar finalmente a qualidade. Certifique-se de que avaliou a melhoria na qualidade após uma determinada resolução e que essa resolução não exerce nenhum impacto prejudicial na qualidade de outras maneiras.
No caso de soluções que oferecem algum nível de risco, talvez seja útil executar alguns testes em um possível release inicial antes de despender muito tempo e esforço para concluir a resolução.
| Finalidade: | Verificar se a atividade foi concluída apropriadamente e se os artefatos resultantes são aceitáveis. |
Agora que você já concluiu o trabalho, recomenda-se verificar se ele é suficientemente importante ou se você apenas desperdiçou grandes quantidades de papel. Você deve avaliar se o trabalho oferece a qualidade apropriada e se ele está completo o suficiente para ser útil aos membros da equipe que o utilizarão como entrada para seus trabalhos. Quando possível, use as listas de verificação fornecidas no RUP para verificar se a qualidade e a abrangência são "satisfatórias".
Faça com que as pessoas que executam as atividades subordinadas que servem como entrada para seu trabalho participem da revisão do mesmo. Faça isso enquanto você ainda tem tempo disponível para tomar medidas que resolverão as preocupações delas. Você deve também avaliar o trabalho com base nos principais artefatos informados, a fim de assegurar que os representou de modo preciso e suficiente. Talvez seja útil fazer com que o autor do artefato informado revise o trabalho nessa base.
Tente lembrar que o RUP é um processo iterativo e que, em vários casos, os artefatos evoluem no decorrer do tempo. Sendo assim, geralmente não é necessário — e, muitas vezes, é contraproducente — desenvolver completamente um artefato que será apenas parcialmente utilizado ou não será utilizado no trabalho imediatamente subseqüente. Isso acontece porque há uma grande probabilidade de mudança na situação em torno do artefato — e de que os pressupostos feitos quando o artefato foi criado se mostrem incorretos — antes que ele seja usado, resultando em esforço perdido e retrabalho dispendioso. Além disso, evite a armadilha de gastar vários 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 usar um recurso administrativo para executar as tarefas de apresentação.
|
Rational Unified Process
|
