Iniciando o desenvolvimento, ler a RCU prestando atenção aos detalhes, buscando entender o processo a ser alterado ou corrigido. Fragmentar a RCU em partes mais isoladas e, ao longo do desenvolvimento, marcar os pontos já realizados, a fim de deixar evidente o que ainda está pendente de desenvolvimento. Se necessário, é possível fragmentar a RCU de maneira visual usando qualquer ferramenta, conforme exemplo abaixo:
Ou simplesmente fragmentá-la mentalmente e grifar na própria RCU quais pontos já foram abordados, conforme exemplo abaixo:
Ao longo do desenvolvimento, em caso de dúvidas sobre a alteração a ser feita ou sobre as regras de negócio por trás da alteração ou do processo sendo alterado, perguntar ao analista a fim de entender de maneira geral o processo (como é atualmente, por que está sendo alterado e qual o objetivo da alteração). Nesta sessão não há exemplos de dúvidas específicas sobre regras de negócio de determinadas empresas ou recursos dos produtos, uma vez que estas normalmente trato pessoalmente ou via call, não via chat, por ser mais simples de entender certos detalhes que poderiam ser omissos ou implícitos em conversa por texto. Abaixo segue um exemplo prático no qual, durante o desenvolvimento, surgiram certas dúvidas em relação às alterações a serem realizadas. Na primeira imagem, a RCU com destaque ao trecho sobre o qual foi falado com o analista. Nas imagens seguintes a conversa com o analista.
Em casos que se perceba, ou que se tenha alguma dúvida, que uma alteração sendo realizada poderia impactar em outro processo, perguntar ao analista, uma vez que certos detalhes podem não ter sido previstos inicialmente e possivelmente exigem um contorno na solução pensada inicialmente. Abaixo segue um exemplo prático no qual foi percebido, durante o desenvolvimento, um possível ponto de impacto da alteração sendo realizada em um protocolo de integração entre os produtos Gestão de Pátio e Base Centralizada. Em conversa com o analista verificou-se que uma parte relevante da alteração não tinha sido prevista em análise e precisaria ser abordada.
Quando em dúvida sobre como proceder com uma alteração, por ter mais de uma forma de atingir o mesmo objetivo, comunicar ao analista, a fim de alinhar qual solução seria a mais ideal para o caso ou qual solução se alinha mais à ideia inicial da análise. Abaixo segue um exemplo prático de um caso em que seria possível realizar uma alteração de duas maneiras, ambas igualmente corretas. Em conversa com o analista foi definido qual abordagem se aproxima mais à ideia inicial da análise. Na primeira imagem, a RCU com destaque ao trecho sobre o qual foi falado com o analista. Na imagem seguinte a conversa com o analista.
Uma vez que seja retornado um refluxo de teste é importante saber tudo o que foi feito para chegar à falha a fim de verificar se é um equívoco de teste, uma parametrização que não foi realizada, ou de fato uma falha a ser corrigida. Também relativo ao teste, na TUF enviada junta às alterações buscar explicar de modo simplificado logo no início do documento o que foi alterado e qual o objetivo da alteração e, se relevante, mencionar o motivo da alteração. Uma vez que a equipe de teste tem uma visão mais ampla sobre o escopo das alterações e não somente um passo-a-passo, pode-se buscar pontos de impacto não pensados anteriormente. Abaixo segue um exemplo do início de uma TUF em uma solicitação de correção do LogTime, mencionando o comportamento anterior e incorreto da aplicação e o comportamento correto após alterações realizadas:
Abaixo segue um exemplo da TUF de duas alterações do Dunamissubdivididas na mesma solicitação. O início da primeira parte da TUF menciona o recurso alterado e seu funcionamento antes e depois da alteração. O início da segunda parte além de mencionar o recurso alterado e o funcionamento antes e depois da alteração, também comenta sobre o motivo da alteração:
