Menu

Como revisar o documento SRS e criar cenários de teste - Treinamento de teste de software em um projeto ativo - Dia 2

how review srs document

Experimente Nosso Instrumento Para Eliminar Problemas

Este é o segundo tutorial em nosso ‘Treinamento de Teste de Software online grátis em um projeto ao vivo’ Series. Se você é novo aqui, verifique o primeiro tutorial de introdução: Treinamento de teste de software de ponta a ponta em um projeto ao vivo.

Vamos agora fazer uma análise detalhada de como um passo a passo de SRS acontece, o que precisamos identificar a partir desta etapa, quais pré-etapas precisamos realizar antes de começar, quais são os desafios que podemos enfrentar, etc. de forma detalhada.

Como revisar o documento SRS e criar cenários de teste_

como abrir um arquivo .eps

Fase de Design SDLC:

A próxima fase do SDLC é o “Design” - é aqui que os requisitos funcionais são traduzidos em detalhes técnicos. As equipes de desenvolvimento, design, ambiente e dados estão envolvidas nesta etapa. O resultado desta etapa é normalmente um Documento de Projeto Técnico - TDD.

A entrada é o documento SRS para a criação do TDD e para a equipe de QA começar a trabalhar no aspecto de QA do projeto - que é revisar o SRS e identificar o objetivo do teste.

O que você aprenderá:

O que é uma revisão SRS?

SRS é um documento criado pela equipe de desenvolvimento em colaboração com analistas de negócios e equipes de ambiente / dados. Normalmente, este documento, uma vez finalizado, será compartilhado com a equipe de QA por meio de uma reunião onde um passo a passo detalhado é organizado.

Às vezes, para um aplicativo já existente, podemos não precisar de uma reunião formal e de alguém nos guiando neste documento. Podemos ter as informações necessárias para fazer isso por nós mesmos.

A revisão do SRS nada mais é do que examinar o documento de especificação de requisitos funcionais e tentar entender como será o aplicativo de destino.

O formato formal e uma amostra foram compartilhados com todos vocês no artigo anterior. Isso não significa necessariamente que todas as SRSs serão documentadas exatamente dessa maneira. Sempre o a forma é secundária ao conteúdo .

Algumas equipes escolherão apenas escrever uma lista com marcadores, algumas equipes incluirão casos de uso, algumas equipes incluirão capturas de tela de amostra (como o documento que tínhamos) e algumas apenas descreverão os detalhes em parágrafos.

Pré-etapas para revisão de especificações de requisitos de software

Passo 1) Os documentos passam por várias revisões, portanto, certifique-se de que temos a versão correta do documento referenciado, o SRS.

Passo 2) Estabeleça diretrizes sobre o que é esperado no final da revisão de cada membro da equipe. Em outras palavras, decida quais entregas são esperadas desta etapa - normalmente, a saída desta etapa é identificar os cenários de teste. Os cenários de teste nada mais são do que ponteiros de uma linha de 'o que testar' para determinada funcionalidade.

Etapa 3) Também estabeleça diretrizes sobre como este produto deve ser apresentado - quero dizer, o modelo.

Passo 4) Decida se cada membro da equipe vai trabalhar no documento inteiro ou divida-o entre eles. É altamente recomendável que todos leiam tudo, pois isso impedirá a concentração de conhecimento com determinados membros da equipe.

Mas no caso de um projeto grande, com os documentos SRS executando perto de 1000 páginas, a abordagem de dividir o módulo do documento e atribuí-la a membros individuais da equipe é mais prática.

Etapa 5) A revisão do SRS também ajuda a compreender melhor se existem pré-requisitos específicos necessários para o teste do software.

Etapa # 6) Como subproduto, uma lista de consultas em que alguma funcionalidade é difícil de entender ou se mais informações precisam ser incorporadas aos requisitos funcionais ou se erros são cometidos no SRS.

O que precisamos para começar?

  • A versão correta do documento SRS
  • Instruções claras sobre quem vai trabalhar, o que e quanto tempo eles têm.
  • Um modelo para criar cenários de teste.
  • Outras informações sobre quem contatar em caso de dúvida ou a quem relatar em caso de inconsistência na documentação

Quem forneceria essa informação?

Os líderes de equipe geralmente são responsáveis ​​por fornecer todos os itens listados na seção acima. No entanto, as contribuições dos membros da equipe são sempre importantes para o sucesso de todo este esforço.

Os líderes de equipe costumam perguntar: Que tipo de informações? Não seria melhor atribuir um determinado módulo a alguém interessado nele do que a um membro da equipe que não está? Não seria bom decidir sobre a data alvo com base na opinião da equipe do que impor uma decisão sobre eles? Além disso, para o sucesso de um projeto, os modelos são importantes.

Como regra geral, os modelos têm uma taxa maior de eficiência quando são adaptados para a conveniência e conforto da equipe específica. Deve-se, portanto, observar que os líderes de equipe, mais do que tudo, são membros da equipe. Fazer com que sua equipe participe das decisões do dia-a-dia é crucial para o bom andamento do projeto.

O modelo é necessário para cenários de teste?

Por que um modelo para cenários de teste - não é suficiente apenas fazermos uma lista?

Com certeza é. No entanto, os projetos de software não são programas de 'um homem só'. Eles envolvem trabalho em equipe .

Imagine uma equipe de 4 se cada um deles decidir revisar um módulo da especificação de requisitos de software cada. O membro da equipe A fez uma lista em uma folha de papel. O membro da equipe 2 usou uma planilha do Excel. O membro da equipe 3 usou um bloco de notas. O membro da equipe 4 usou uma palavra doc. Como consolidamos todo o trabalho feito para o projeto no final do dia?

Além disso, como podemos decidir qual é o padrão e como podemos dizer o que é certo e o que não é se não criamos as regras, para começar?

Isso é o que o modelo é: Um conjunto de diretrizes e um formato acordado para uniformidade e concorrência para toda a equipe.

Como criar um modelo para cenários de teste de controle de qualidade?

software de extração de dvd grátis para windows

Modelos não precisa ser complicado ou inflexível.

Tudo o que eles precisam ser é um mecanismo eficiente para criar um artefato de teste útil. Algo simples como o que vemos abaixo:

modelo de cenários de teste

O cabeçalho deste modelo contém o espaço necessário para capturar informações básicas sobre o projeto, o documento atual e o documento referenciado.

A tabela abaixo nos permitirá criar cenários de teste. As colunas incluídas são:

Coluna # 1) ID do cenário de teste
Cada entidade em nosso processo de teste deve ser identificável de forma única. Portanto, a cada cenário de teste deve ser atribuído um ID. As regras a seguir ao atribuir este ID devem ser definidas.

Para o propósito deste artigo, vamos seguir a convenção de nomenclatura como TS (prefixo que significa Cenário de Teste) seguido por ‘_’, nome do módulo MIM (Módulo My Info do projeto Orange HRM) seguido por ‘_’ e então a subseção ( Por exemplo, MIM para o módulo My Info, P para fotografia e assim por diante) seguido por um número de série. Um exemplo seria: “TS_MI_MIM_01”.

Coluna # 2) Requisito
Ajuda que, quando criamos um cenário de teste, devemos ser capazes de mapeá-lo de volta para a seção do documento SRS de onde o selecionamos. Se os requisitos tiverem IDs, podemos usar isso. Do contrário, serão suficientes os números de seção ou mesmo os números de página do documento SRS de onde identificamos um requisito testável.

Coluna # 3) Descrição do cenário de teste
Um one-liner especificando 'o que testar'. Também nos referiríamos a ele como o objetivo do teste.

Coluna # 4) Importância
Isso é para dar uma ideia sobre a importância de certas funcionalidades para o AUT. Valores como alto, médio e baixo podem ser atribuídos a este campo. Você também pode escolher um sistema de pontos, como 1-5, 5 sendo o mais importante, 1 sendo menos importante. Qualquer que seja o valor que esse campo possa assumir, ele deve ser pré-decidido.

Coluna # 5) Nº de casos de teste
Uma estimativa aproximada de quantos casos de teste individuais podemos acabar escrevendo aquele cenário de teste. Por exemplo, Para testar o login, incluímos estas situações: Nome de usuário e senha corretos. Nome de usuário correto e senha incorreta. Senha correta e nome de usuário errado. Portanto, validar a funcionalidade de login resultará em 3 casos de teste.

Nota: Você pode expandir este modelo ou remover os campos conforme achar necessário.

Por exemplo , você pode adicionar “Revisado por” no cabeçalho ou remover a data de criação, etc. Também na tabela, você pode incluir um campo “Criado por” para designar o testador responsável por um determinado cenário de teste ou remover o “Não. de casos de teste ”. A escolha é sua. Escolha o que funciona melhor para toda a equipe.

Vamos agora revisar nosso documento Orange HRM SRS e criar os cenários de teste

Dica profissional: verifique o índice no exemplo de SRS que fornecemos nos primeiros tutoriais para ter uma boa ideia de como qualquer documento irá fluir e quanto trabalho ele pode envolver.

Seção 1 é o objetivo do documento. Nenhum requisito testável lá.

Seção 2.1 : Visão geral do projeto - Público - também não há requisitos testáveis.

Seção 2.2 : Hardware e Hospedagem - Esta seção fala sobre como o site Orange HRM será hospedado. Agora, essas informações são importantes para nós, testadores? A resposta é sim e não. Sim, porque quando testamos, precisamos ter um ambiente semelhante ao ambiente de tempo real.

Isso nos dá uma ideia de como deve ser. Não, porque não é um requisito testável - uma espécie de pré-requisito para que o teste aconteça.

Seção 3: Há uma tela de login aqui e os detalhes do tipo de conta que precisamos ter para entrar no site. Este é um requisito testável. Portanto, ele precisa fazer parte de nossos cenários de teste.

Consulte o documento de cenários de teste onde os cenários de teste para algumas seções do SRS foram adicionados. Para praticar, adicione o resto dos cenários de maneira semelhante. No entanto, vou direto para a seção 4 do documento.

Seção 4: Requisitos e diretrizes estéticas / HTML - esta seção explica melhor como alguns requisitos podem não fazer sentido para a equipe de teste no momento da revisão do SRS, mas a equipe deve anotar todos eles como requisitos testáveis.

Como testá-los e se precisamos de uma configuração específica / ajuda de qualquer equipe para validá-los são detalhes que talvez não saibamos neste momento. Mas torná-los parte de nosso escopo de teste é o primeiro passo para garantir que não os percamos.

Exemplos de cenários de teste para o aplicativo OrangeHRM: (clique para ampliar a imagem)

modelo de cenários de teste

=> Consulte e baixe o documento Test Scenarios Para maiores informações.

Algumas observações importantes sobre a revisão de SRS

# 1) Nenhuma informação deve ser deixada descoberta.
#dois) Faça uma análise de viabilidade se um determinado requisito está correto ou não e também se ele pode ser testado ou não.
# 3) A menos que exista um desempenho / segurança separado ou qualquer outra forma de equipes de teste, é nosso trabalho garantir que todos os requisitos não funcionais sejam levados em consideração.
# 4) Nem todas as informações são direcionadas aos testadores, por isso é importante entender o que observar e o que não.
# 5) A importância e não. de casos de teste para um cenário de teste não precisa ser preciso e pode ser preenchido com um valor aproximado ou pode ser deixado em branco.

Resumindo, a revisão SRS resulta em:

  • Lista de cenários de teste
  • Resultados da revisão - Erros de documentação / requisitos encontrados ao passar / verificar estaticamente o documento SRS
  • Uma lista de perguntas para melhor compreensão - no caso de qualquer
  • A ideia preliminar de como o ambiente de teste deve ser
  • Identificação do escopo do teste e uma ideia aproximada de quantos casos de teste podemos acabar tendo - então, quanto tempo precisamos para documentação e, eventualmente, execução.

Pontos importantes a serem observados:

# 1) Os cenários de teste não são produtos externos (não compartilhados com analistas de negócios ou equipes de desenvolvimento), mas são importantes para o consumo interno de QA. Eles são nosso primeiro passo em direção a uma meta de cobertura de teste de 100%. Os cenários de teste, uma vez concluídos, passam por uma revisão por pares e, uma vez feita, todos são consolidados.

Para obter mais detalhes sobre como os documentos de controle de qualidade são revisados, consulte o artigo: Como realizar análises de documentação de teste em 6 etapas simples.

#dois) Poderíamos usar uma ferramenta de gerenciamento de teste como HP ALM ou qTest para criar os cenários de teste. No entanto, a criação de cenários de teste em tempo real é uma atividade manual. Na minha opinião, é mais conveniente manualmente. Uma vez que é o passo 1, não precisamos trazer as armas grandes ainda. Planilhas Excel simples são a melhor maneira de fazer isso.

A próxima etapa desta série é que - trabalharemos na criação de casos de teste e avançaremos na fase de design de teste. Antes disso, também entraremos em - O que é o planejamento de teste?Onde ele se encaixa em todo o projeto de QA? Como sempre, trabalhe conosco para os melhores resultados.

exemplo de aplicativo da web de documento de plano de teste

Dia de treinamento de controle de qualidade 3: Como escrever um documento SRS do zero.

Por favor, continue enviando suas perguntas e comentários. Agradecemos imensamente o seu leitor!

Leitura recomendada

^