Introdução ao trabalho do testador de software
Qual é a primeira coisa que vem à sua mente quando você pensa em um trabalho de teste de software? Um trabalho sem codificação? Ou uma profissão que é muito fácil, pois oferece a você oportunidades de encontrar erros no trabalho de outras pessoas (encontrar erros quando nos outros é a tarefa mais fácil para todos nós)? Ou você pensa nisso como a profissão que lida com a verificação da exatidão do produto? Todos esses pensamentos estão corretos e são as atividades diárias do trabalho de um testador de software. No entanto, o teste de software não se limita apenas a essas atividades.
Entendendo o aplicativo
O aplicativo pode ser de qualquer domínio - Assistência Médica, Seguros, Finanças, etc. Aprender o domínio do aplicativo é muito importante para qualquer trabalho de software que abra as portas para pensar sob vários ângulos e várias perspectivas do usuário durante o teste do aplicativo. Descobrir e validar os caminhos de aplicação óbvios e não tão óbvios é sempre a principal expectativa disso. Ter um conhecimento profundo do aplicativo ajuda a validar o produto de forma eficaz, ao mesmo tempo em que o testador pode se tornar um ativo para um projeto em que é considerado uma das principais fontes de conhecimento em relação ao comportamento do produto.
Embora aprender domínio e funcionalidade seja um processo contínuo para qualquer outro fator importante, é ter conhecimento sobre o processo de teste.
Processo de teste
O processo de teste pode variar de empresa para empresa ou mesmo de um projeto para outro. Hoje, temos vários modelos de desenvolvimento de software, como o modelo V, modelo de prototipagem ou uma metodologia completamente diferente, como a abordagem ágil do desenvolvimento de software. Com a mudança no modelo de desenvolvimento, a abordagem de teste a ser seguida também varia. Trabalhar em um modelo V terá processos bem definidos, enquanto espera-se que esse trabalho em metodologia ágil seja testado em condições em constante mudança.
O trabalho ainda não é fácil com o conhecimento do domínio aceitável e a compreensão do processo de teste, o próximo desafio que vem com a vida é o aprendizado de várias ferramentas.
Ferramentas
As ferramentas implicam ferramentas de gerenciamento de teste, ferramentas de registro de defeitos, ferramentas de gerenciamento de banco de dados e assim por diante.
Com vários softwares de registro de defeitos, qualidades e ferramentas, algumas de código aberto e outras licenciadas, é sempre uma vantagem ter conhecimento de mais de uma ferramenta. Ajuda a fazer a transição fácil de projetos ou equipes, seguindo diferentes ferramentas. Com o conhecimento adequado do domínio, processo e ferramentas, há mais na vida do trabalho do Software Tester, o que torna seus dias de trabalho desafiadores e emocionantes. A colaboração dentro das equipes é um dos fatores importantes no sucesso de qualquer projeto e, para uma colaboração eficaz, a comunicação desempenha um papel muito importante.
Cursos recomendados
- Curso Completo de J2EE
- Treinamento de Programação R Online
- Curso de programação
- Treinamento de certificação on-line no programa Haskell
Comunicação
A comunicação desempenha um papel muito importante para as qualidades do software, desde as fases iniciais do desenvolvimento do software, os membros da equipe de teste estão envolvidos (como uma melhor prática) na discussão dos requisitos, questionando os analistas de negócios em caso de dúvidas ou lacunas no requisito. Um tster com habilidades de comunicação eficazes pode comunicar os riscos de forma eficaz, pode se comunicar de forma eficaz com a equipe de desenvolvimento e pode comunicar efetivamente os resultados e relatórios de teste.
Planejamento de obras do Software Tester
Como o nome sugere, o planejamento do teste é a fase em que a preparação para o teste é feita. A preparação para um tster envolverá vários tipos de atividades que um tster realiza para que o aplicativo seja eficaz. Isso ajudará na validação do aplicativo e na descoberta efetiva dos defeitos no aplicativo. Para iniciar o planejamento, um teste percorre os requisitos para entender as expectativas.
1. Requisitos
Os requisitos podem ser fornecidos à equipe de teste na forma de wireframes, storyboards, folhas de excel. O objetivo de todos esses documentos é apresentar os requisitos do cliente de maneira eficiente e fácil de entender. O documento de estrutura de arame nada mais é do que um documento que pode estar na forma de apresentação do PowerPoint que descreve os requisitos do cliente. Nas mesmas linhas, os storyboards geralmente descrevem a aparência / design necessários das telas. Atualmente, estão disponíveis no mercado várias ferramentas que podem ser usadas para preparar os documentos necessários. A criação dos documentos necessários é de responsabilidade principal de um analista de negócios. Espera-se que uma amostra compreenda completamente os requisitos. Para que o teste e os desenvolvedores entendam os requisitos corretamente, os analistas de negócios mantêm o fórum aberto para que todos possam criar e obter respostas às consultas sobre qualquer um dos requisitos. A plataforma para discutir e comunicar as perguntas e consultas abertas varia de projeto para projeto. Pode ser a cadeia de e-mails ou uma chamada em conferência ou até mesmo um repositório de unidades compartilhadas para manter o controle de todas as perguntas em aberto e suas respostas, conforme fornecido pelo analista de negócios.
Comunicação clara e registro de comunicação desempenham um papel muito importante para uma prova. Uma pequena suposição no requisito às vezes pode levar a um grande defeito no produto. Em todas as etapas, recomenda-se às qualidades de um testador de software manter a comunicação limpa. A comunicação do Software Tester Work pode ser com analistas de negócios ou mesmo dentro de uma equipe. A comunicação clara ajuda a manter as suposições afastadas durante o planejamento e a execução. Ao mesmo tempo, é recomendável ter um registro de comunicação (preferencialmente, comunicação por email). Ter uma comunicação por escrito sobre consultas nos requisitos ajuda nos estágios posteriores da execução do teste, onde a funcionalidade pode não ter sido desenvolvida conforme confirmado na comunicação gravada.
2. Cenário
Depois que os requisitos são entendidos, o testador começa a documentar os cenários no documento Cenário de Teste. Um cenário como o nome sugere é um fluxo de funcionalidade que o usuário segue para realizar uma tarefa.
Exemplos de cenários -
- O usuário deve conseguir fazer login com sucesso.
- O usuário deve poder reservar tickets no sistema.
- O usuário deve poder cancelar tickets no sistema.
- O usuário deve poder visualizar / atualizar os detalhes do perfil.
Essas são as tarefas lógicas que um usuário executa no sistema. Essas tarefas lógicas, quando agrupadas, ajudam o provador a anotar todos os cenários possíveis que um usuário deve executar. Esses cenários geralmente são documentados nas planilhas do Excel ou, às vezes, usando algumas ferramentas. Um provador tenta extrair todos esses cenários dos documentos de requisitos. Um documento que contém esses cenários é chamado de Documento de cenário de teste (ou em algum lugar como Documento de cenário de alto nível). Este documento serve como um documento de entrada para a elaboração de casos de teste.
3. Caso
Este caso é a versão mais detalhada do cenário de trabalho do Software Tester, em que o cenário é dividido em etapas mais detalhadas que o usuário realmente executará enquanto estiver usando o aplicativo. Um exemplo simples baseado nos cenários mencionados acima é:
Cenário - O usuário deve conseguir fazer login com êxito.
Casos de teste:
- Verifique se o usuário pode inserir o nome de usuário correto.
- Verifique se o usuário pode digitar a senha.
- Verifique se, ao clicar no botão Login, após digitar o nome de usuário e a senha corretos, o usuário pode efetuar login com êxito.
Essa lista desses casos pode incluir uma verificação de validação em cada campo, verificação de cenários negativos e assim por diante.
Abaixo estão alguns dos exemplos adicionais desses casos -
- Verifique se esse nome de usuário, quando não digitado, o sistema gera um erro apropriado.
- Verifique essa senha quando não inserida, o sistema gera um erro apropriado.
- Verifique se o nome de usuário e a senha, quando não digitados, o sistema gera um erro apropriado.
- Verifique se, digitando a senha incorreta, o sistema lança uma mensagem de erro apropriada.
- Verifique se, digitando o nome de usuário incorreto, o sistema lança uma mensagem de erro apropriada.
4. Matriz de rastreabilidade de requisitos (RTM)
A matriz de rastreabilidade de requisitos, como o nome sugere, ajuda a verificar e incorporar a cobertura dos requisitos fornecidos pela Business nos documentos de teste, como cenários e casos de teste.
Como prática recomendada, este é um documento separado que mostra o mapeamento do número do requisito com o dos cenários / casos que incorporam esse requisito.
Este documento não pode ser usado por todos os tipos de projetos, mas, quando usado, ajuda bastante a rastrear os cenários de alto nível mapeados para os requisitos. Ele indica a cobertura e pode ser usado para verificar a presença de pelo menos um desses casos em relação a todos os requisitos. A criação e manutenção do documento RTM é considerada a melhor prática, no entanto, nem todos os tipos de projetos (como o Agile) usam o documento de trabalho com comprovação de software. Quando os requisitos mudam com muita frequência, a manutenção deste documento pode ser ouvida. Para evitar essa sobrecarga e ao mesmo tempo ter uma maneira de rastrear requisitos, alguns projetos incorporam a parte de rastreabilidade no caso de trabalho do Software Tester ou no próprio documento do cenário.
O aspecto importante é ter uma maneira de rastrear cenários / casos para requisitos e vice-versa. Os requisitos bem documentados facilitam a tarefa de criação e manutenção desses documentos para o Prover. Requisitos ambíguos, requisitos em constante mudança tornam a vida do provador mais desafiadora e podem levar a documentos entregáveis inconsistentes que resultam na perda de alguma validação e, portanto, um defeito no produto final.
A jornada até agora para um testador estava planejando e se preparando para o teste. Como a preparação para a guerra faz parte da guerra, o mesmo se aplica aqui. Quanto mais concisos esses documentos são criados, é mais fácil para o provador validar a funcionalidade e descobrir quase todos os defeitos. A próxima fase da jornada do testador é a execução.
Execução do testador de software funciona
Essa é a fase em que todos os documentos mencionados acima são colocados em uso. Os requisitos foram usados para criar um cenário, o cenário foi usado para criar casos. este documento de caso é o documento autossuficiente aqui para começar a validar o aplicativo. O Prover inicia a validação do aplicativo executando etapas deste documento de caso. Vários casos podem ser usados para validar um único cenário ou até mesmo um único caso de teste pode corresponder a um único cenário de teste. Tudo depende da complexidade dos cenários ou, às vezes, do padrão seguido na equipe de teste. Portanto, um único documento de caso de teste pode conter de 20 a 50 casos de teste ou pode ter 100-120 casos de teste. Esses números são apenas para fins de explicação, podem variar muito de projeto para projeto. O resultado desta fase são os defeitos de teste. O número de defeitos válidos levantados nesta fase fornece uma boa idéia sobre a estabilidade da aplicação, qualidade dos testes, qualidade da construção e muitos desses fatores que afetam diretamente o produto. Essa fase é a fase mais importante à medida que o testador prospera para cobrir todos os casos de teste (validando quase todos os caminhos de usuário necessários) e, ao mesmo tempo, elevar o maior número possível de defeitos válidos. Toda a preparação, habilidades de comunicação e consultas solicitadas pela empresa entram para atuar nesta fase de teste.
Defeitos do testador de software funciona
Durante a execução desse caso, qualquer comportamento que não seja igual ao resultado esperado é gerado como o Defeito. Cada caso de teste possui uma Descrição, Resultado Esperado e uma coluna para Resultado Real. Embora esses documentos de planejamento do Software Tester Work tenham uma descrição e os resultados esperados, e uma coluna Em branco para Resultados reais. Durante a execução dos casos de teste, o testador deve preencher a coluna de resultados real. Ao mesmo tempo, se o real não for igual ao resultado esperado, o defeito será registrado. Registrar um defeito não significa informar o desenvolvedor sobre o problema. É novamente um processo formal geralmente feito com a ajuda de uma ferramenta. Atualmente, existem várias ferramentas no mercado, algumas de código aberto e outras licenciadas. Qualquer ferramenta de registro de defeitos possui os seguintes campos -
- Nome do Projeto / Liberação
- Resumo de Defeitos
- Descrição detalhada do defeito
- Severidade do Defeito
- Prioridade de Defeitos
- Fase em que o defeito foi encontrado
- Atribuído a
- Anexos
Como podemos ver, o objetivo de todos esses campos é ter um processo formal com detalhes sábios do problema. Isso ajuda os desenvolvedores a reproduzir o defeito em seu ambiente e corrigi-lo. Abaixo está a breve descrição de todos esses campos -
- Nome do Projeto / Liberação - Nome da liberação em que o defeito foi encontrado, geralmente o projeto possui várias liberações e o mesmo projeto pode ter vários subprojetos. Este campo ajuda a levantar um problema para uma versão específica.
- Resumo do defeito - Uma breve descrição de uma linha do defeito encontrado.
- Descrição detalhada do defeito - Esta é a descrição detalhada do defeito, deve incluir detalhes como o ambiente em que o defeito foi encontrado e os dados de teste utilizados, os resultados reais esperados pelo resultado e qualquer informação adicional que adicione informações mais valiosas para que as partes interessadas compreendam o problema. defeito.
- Gravidade do defeito - Significa a gravidade do defeito. Geralmente, possui valores semelhantes aos valores Crítico, Alto, Médio, Baixo ou numérico como 4, 3, 2, 1.
- Prioridade do Defeito - Significa o quão urgente é corrigir o defeito.
- Fase em que o defeito foi encontrado - Como há muitas fases em que um defeito pode ser registrado, fase de teste de unidade, SIT (teste de integração do sistema), UAT (teste de aceitação do usuário) ou mesmo fase de produção.
- Atribuído a - Nome do desenvolvedor ou líder de desenvolvimento.
- Anexos - Isso deu uma opção ao testador para anexar o instantâneo da tela em que o problema foi encontrado.
Execução de teste e registro de defeitos é a fase em que há muitos desafios que um testador pode enfrentar. Alguns deles estão se comunicando efetivamente com os desenvolvedores. Podemos argumentar que está registrando um defeito com todas as informações necessárias insuficientes para que os desenvolvedores entendam o defeito?
É e, em alguns casos, requer explicações / discussões adicionais com os desenvolvedores. Há casos em que um testador encontra um comportamento inesperado que pode não ter certeza se é um defeito. Essas circunstâncias geralmente são enfrentadas por provadores que são novos na equipe, com conhecimento limitado no domínio ou ambiguidade nos requisitos. Bem, o testador não deve ser responsabilizado aqui se houver prazos apertados e requisitos em constante mudança e, na maioria dos casos, o provador aprender sobre o domínio enquanto estiver planejando e executando os casos de teste. Como podemos ver, o caminho de um testador não é tão fácil quanto é percebido. Exige sempre uma atitude de aprendizado, boas habilidades de comunicação, boas habilidades de colaboração e ânsia de se ajustar nas condições em que há mudanças nos domínios, ferramentas, processos utilizados. Enquanto falamos sobre a jornada dos testadores manuais, o processo geral também se aplica aos testadores de automação. A automação, por outro lado, tem mudanças significativas no processo, pois o escopo de teste e planejamento, a execução varia significativamente.
Considerando a jornada do provador, conforme discutido acima, ainda podemos dizer que o trabalho das qualidades dos testadores de software é mais fácil do que o de um desenvolvedor?
Pode-se dizer que, mais do que comparar as funções de desenvolvedor do testador v / s, será mais útil ter uma discussão sobre como a colaboração de dois pode levar a um grande sucesso do produto como um todo. Às vezes esquecemos que o trabalho do testador é encontrar problemas no aplicativo e não apontar erros dos desenvolvedores. Quando esquecemos a própria idéia de nosso trabalho, às vezes isso leva a discussões desnecessárias. No entanto, observou-se que existem equipes de desenvolvimento e teste igualmente boas, onde todos entendem que o objetivo final é fazer com que o aplicativo funcione conforme o esperado. Esperemos que todos olhem para o lado positivo do trabalho de teste como um papel que ajuda na limpeza do produto e não como aquele que apenas encontra erros!
Artigos recomendados
Este foi um guia para descobrir e validar os caminhos óbvios e não tão óbvios do aplicativo, sempre a principal expectativa do trabalho de um testador de software. Estes são os links externos a seguir relacionados ao trabalho do testador de software.
- Ciclo de vida de defeitos em testes de software
- 6 perguntas mais surpreendentes da entrevista sobre testes de software
- Carreiras em Teste de Software