Versões comparadas

Chave

  • Esta linha foi adicionada.
  • Esta linha foi removida.
  • A formatação mudou.

Introdução

Aqui, forneceremos algumas diretrizes sobre como padronizar a documentação para uso dos departamentos responsáveis ​​na edição das “Notas de versão”, bem como “Manuais” e outros documentos que possam ser editados para uso interno/externo.

Índice

Índice
minLevel2
maxLevel2
indent10px
printablefalse

1. Prints de tela

Nas documentações não podem haver prints de vídeo, desta forma devemos ter dentro dos documentos feitos pelos testers/desenvolvedores, prints de telas com boa definição.

Exemplo 1.1

Aviso

Incorreto: A imagem não pode ficar desfocada, com o nome de tela e nem a logo da empresa (Guarani) cortada.

Dica

Correto: Imagem com boa definição, apresentando logo da empresa sem cortes e a tela completa para melhor entendimento.


2. Grifos de tela

As imagens inseridas nos documentos devem ser grifadas com formas geométricas retangular ou quadrada no tom vermelho e na espessura 2px ou 3px. Não podem haver setas nas imagens para destacar nenhum campo específico.

Exemplo 2.1

Aviso

Incorreto:Destaques em tela, não podem ser selecionados de outra cor e nem setados.

Dica

Correto:Os pontos destacados estão na cor padrão e não há setas na imagem.


3. Imagens com conteúdos esmaecidos

Para ocultarmos as informações dos clientes é necessário que isso seja feito de uma forma que esteticamente não fique fora do padrão. Trabalhamos com o sistema de esmaecimento do ShareX, pois é possível sua configuração com um único click esmaecer as informações dos clientes. É necessário utilizar o sistema de blur para esmaecer.

Exemplo 3.1

Aviso

Incorreto: Documento com as informações ocultadas, não pode ficar com aparência de borrão. Sendo assim, o excesso de esmaecimento não cabe.

Dica

Correto: Deveráocultar todas as informações dos clientes para que nenhum dado fique visível, mas de forma apresentável.

Exemplo 3.2

Aviso

Incorreto: Não podem sumir as informações contidas nos campos, pois é necessário saber do seu preenchimento.

Dica

Correto:Nesta imagem, exemplificamos a forma no qual devem ser ocultados os dados dos clientes.


4. Textos dentro das imagens

Não colocar indicações, textos ou explicações por escrito dentro da imagem selecionada para a documentação.

Exemplo 4.1

Aviso

Incorreto: Não colocar observações e ou apontamentos dentro dos prints.

Dica

Correto: Manter as imagens com boa resolução e sem poluição visual.


5. Informações necessárias para documentar

Para fazermos uma boa documentação, quando o ticket for uma “Solicitação” ele deverá conter sempre o relato da ocorrência e a solução.

Exemplo 5.1

Aviso

Incorreto: Documentação onde não há o relato da ocorrência e na solução, não ficou explicado o que foi ajustado.

Dica

Correto:Resultado na nota de versão, depois de buscarmos dentro dos tickets atrelados, as possíveis soluções.

Exemplo 5.2

Aviso

Incorreto: Na documentação (testers), não haviam informações suficientes para elaboração da nota de versão.

Informações

No documento do desenvolvedor, haviam informações para uma possível documentação da nota de versão.

Dica

Correto: Foi utilizada a documentação do desenvolvedor para a solução, mas foi uma publicação com a limitação de informações.


6. Exemplo Ideal de Nota de Versão

Dica

Para documentarmos devidamente, é necessário que o ticket contenha a Solução Simples (Testers) e Solução Técnica (Desenvolvedor).

Dica

Desta forma, conseguimos elaborar uma “Nota de versão ideal”.


Índice
minLevel2
maxLevel2
typeflat
printablefalse

Rv macro
titleVisitantes recentes

📣 Deixe seu feedback

Essa documentação foi útil pra vc? Comente embaixo.