Testes de Software
Neste capítulo, será tratado o conteúdo de teste um pouco mais aprofundado, com a apresentação de conceitos e técnicas que auxiliam na prevenção e combate de erros em sistemas projetos por desenvolvedores.
As principais técnicas de testes tratados aqui serão os testes unitários, de que irão tratar as unidades que compõem o software produzido. Em seguida, as técnicas: serão apresentados os testes de integração, que, como o próprio nome diz, trata de verificar a integração dos módulos, classes, e outros do sistema, para que assim possam ser verificados possíveis erros.
Em complemento, será ainda apresentado a técnica de teste de validação, que trabalha em cima da validação do software, a fim de verificar-se ele faz o que foi programado para fazer. Além disso, o teste de sistema e teste de aceitação serão também apresentados.
O processo de teste de software possui dois objetivos distintos: um deles é demonstrar ao desenvolvedor e ao cliente que o software atende a todos os requisitos propostos; e, também, descobrir situações em que o sistema se comporta de maneira indesejável (SOMMERVILLE, 2011).
Ao se tratar de testes de software, devemos ter em mente que podemos utilizar diversas estratégias para a ação de testar. De um lado, podemos esperar até que o sistema esteja totalmente construído e, aí, sim, começar a executar testes à procura de erros, o que não é muito bom, pois resultará em um software defeituoso, podendo deixar alguns erros despercebidos. Em contrapartida, podemos aplicar os testes de forma modular, diariamente, sempre à procura de erros. Embora mais trabalhosa do que a primeira forma, pode ser muito mais eficaz. Muitas vezes, utiliza-se de uma visão incremental para a realização dos testes, começando com simples testes de unidade e evoluindo até determinados outros testes que levam a finalizar o processo do software.
O Teste Unitário tem como objetivo verificar testes na menor unidade do projeto do sistema, ou seja, realizar testes em componentes, classes ou módulos que pertencem ao projeto de software (PRESSMAN; MAXIM, 2016).
Testes de entrada e saída de uma unidade são realizados para descobrir erros que estão dentro do limite deste módulo unitário, ou seja, os erros aqui encontrados são limitados ao trecho do código exposto.
Nesse tipo de teste, você deve projetar testes, fornecendo uma cobertura para todas as características da unidade. Por exemplo, para uma classe desenvolvida, você deve testar operações e métodos presentes, definir valores para os atributos e manipular o objeto em todas as formas possíveis, o que significa que devemos simular ações que realizam mudanças no estado dessa classe (SOMMERVILLE, 2011).
Testes de unidade são os tipos de testes mais comuns. Inclusive, a maior parte dos testes escritos e recomendados por pesquisadores são testes unitários.
De uma forma geral, quando escrevemos testes unitários para uma determinada classe, esta bateria de testes testará o funcionamento desta classe sem interações com outras classes. Isso também acontece em relação aos testes unitários de componentes, de módulos, etc. Esquematicamente falando, Pressman e Maxim (2016) esquematizam os testes de unidade na figura 2.2:
No esquema proposto, a interface assegura que os testes flutuam de forma correta tanto para dentro quanto para fora da unidade testada. Já a estrutura dos dados são examinadas e devem garantir a integridade dos dados durante a execução do software. As condições de limite, como o próprio nome diz, agem no limite do módulo testado, limitando ou restringindo o processamento dentro do módulo. E, por fim, são testados todos os caminhos de manipulação de erros.
No Teste de Unidade, deve se dar atenção ao fluxo de dados, e este fluxo deve ser testado antes de qualquer outro teste. Se os dados não entram e saem corretamente, os outros testes se tornam discutíveis (PRESSMAN; MAXIM, 2016).
Casos de teste se utilizam de estruturas de dados, fluxo de controles e dados diversos, que podem conter diversos erros. Estes casos de testes deverão ser projetados cujo intuito principal é o de descobrir problemas. Um dos principais testes de unidade é o teste de fronteira, já que, de uma forma ou de outra, os softwares produzem falhas em suas fronteiras.
A partir das definições acima, entendemos assim que o teste de unidade é considerado como um assistente na etapa de implementação do código-fonte, podendo ser realizado até antes de se começar a codificação, ou após a sua geração pelo programador.
Devemos ter em mente, também, que o teste é custoso e que é importante escolher casos efetivos de testes, o que significa que os casos devem mostrar o que determinado módulo/componente/classe deve realizar; e, se houver defeitos, estes devem ser revelados por testes (SOMMERVILLE, 2011).
O que auxilia, também, é a seleção de diretrizes que podem ser utilizadas para a geração destes testes, como a escolha de entradas que possibilitam o sistema gerar todas as possíveis mensagens de erros que causem estouro de buffers de entrada, que obrigue a geração de saídas inválidas e cálculos que possuem valores grandes ou pequenos, e outros.
Aplicando essas características, a unidade é bem testada, os erros em sua maioria tratados; e de uma forma ou de outra, o testador ganha experiência na aplicação das diretrizes e testes.
Um software é um programa que normalmente é desenvolvido para suprir e auxiliar o usuário a determinadas tarefas e necessidades do dia a dia. Para obter um software “redondo” é necessário aplicar testes de software. A alternativa que contempla corretamente o intuito de um teste de software é:
Demonstrar ao usuário que o software foi construído em tempo hábil.
Alternativa incorreta. O intuito é demonstrar se o software atende o que foi solicitado e se o sistema se comporta de maneira coerente.
Demonstrar se o software está de acordo e descobrir problemas de execução relacionados ao software.
Alternativa correta. Um dos intuitos de um teste de software é demonstrar ao desenvolvedor e ao cliente que ele atende a todos os requisitos ao que foi proposto; e, também, descobrir situações em que o sistema se comporta de maneira incorreta, incoerente ou ainda, de forma indesejável ao que foi especificado.
Demonstrar que o software precisa ser totalmente refeito após as descobertas de erros.
Alternativa incorreta. Não é necessário jogar tudo que foi feito fora, e sim adequar o que foi feito para como o que o usuário espera e se o sistema executa de forma adequada.
Demonstrar que o usuário sempre tem a razão quando começa a utilizar o software e encontra erros.
Alternativa incorreta. Podemos dizer que o usuário ele auxilia no encontro de erros, mas não que ele tem sempre a razão ao testar o software.
Demonstrar que o sistema não precisa ter a aplicação de testes muito coesos.
Alternativa incorreta. Um sistema sempre deve ter testes aplicados de forma coesa, e que encontrem possíveis problemas.
Vimos que os testes unitários são testes que analisam os erros da unidade do sistema que está sendo produzido, isolando cada parte do sistema para garantir o seu funcionamento adequado. Para o auxílio na realização destes testes, existem plataformas de testes para diversas linguagens, algumas até com interface gráfica. É importante estarmos cientes dessas ferramentas e ampliarmos conhecimentos. Vamos ler? Acesse o link: medium.com/assertqualityassurance.
Quando chegamos a essa etapa do teste, as vezes é inevitável nos perguntarmos: Se os módulos individuais, que foram testados, já funcionam individualmente, porque quando os juntamos devemos duvidar que eles podem não funcionar integrados? Bom, é uma resposta não tão difícil de se obter, não acham? Dados podem se perder quando módulos forem integrados, ou mesmo podem ter efeitos inesperados. E isso deve ser testado e consertado antes de prosseguir adiante.
Segundo Rios e Moreira (2013), o teste de integração é uma técnica utilizada para se construir a arquitetura de um software, e ao mesmo tempo, aplicar testes para a descoberta de erros quando integrados, e claro, com as suas interfaces.
Em muitos casos, programadores já tentam realizar estes testes quando terminam alguns módulos, integrando-os; porém podem resultar em problemas não previstos, e virar um caos ao final da construção do software, sendo encontrados diversos erros e consequentemente tendo a sua correção dificultada.
Temos alguns tipos de integração que auxiliam os nossos testes, como a integração incremental, na qual o sistema é construído e testado em pequenos incrementos e os seus erros são mais fáceis de serem isolados e corrigidos (RIOS; MOREIRA, 2013).
Um ponto importante em testes de software é decidir quando devemos testar e como começar a testar. Por isso devemos entender os principais conceitos e o funcionamento de cada tipo de teste de software. Nesse sentido separamos um link importante sobre o teste de integração, que lhe ajudará a entender um pouco mais sobre esse tipo de teste. Vamos conferir pelo link: blog.caelum.com.br.
Dentro da integração incremental, temos estratégias como o Teste Big-Bang, Teste Bottom-up, Teste de Fluxo de Dados, Teste Funcional e Teste Top-down. Vamos estudá-los nos próximos tópicos:
O teste Bottom-up, ou também conhecido como Teste de integração ascendente, começa a ser produzido e testado em classes/módulo que possuem um nível mais baixo na estrutura do programa construído.
Podemos aplicar uma estratégia de integração, seguindo os seguintes passos (RIOS; MOREIRA, 2013):
Este teste também é chamado de teste de integração descendente, e como o próprio nome diz, os módulos são integrados movendo-os para baixo a partir da arquitetura do sistema produzido, começando pelo módulo de controle principal (RIOS; MOREIRA, 2013).
Neste tipo de teste, os módulos são incorporados a estrutura: primeiro-em-profundidade (depth-first) ou primeiro-em-largura (breadth-first), e o processo de integração é realizado através dos seguintes passos (RIOS; MOREIRA, 2013):
Este tipo de teste verifica os principais pontos de controle ou decisão no processo de teste do software de forma antecipada, o que torna um gerador de confiança para as partes interessadas no programa.
Na técnica de Fluxo de dados, a integração dos componentes, programas, módulos ou subsistemas, é feita pelo desenho de fluxo de dados (RIOS; MOREIRA, 2013).
Desta forma, podemos entender que um teste de fluxo de dados é um método que seleciona caminhos de testes de um programa de acordo com a localização das definições. Assim, os caminhos são integrados e verificados possíveis problemas de comunicação, dependendo de como o fluxo dos dados são realizados; e posteriormente corrigidos.
Ter um sistema que comprometa algo em uma empresa pode causar diversos transtornos. Isso afeta a imagem ou o negócio da organização. De que forma afeta a organização socialmente? E economicamente? De quais outras formas a imagem da organização é afetada por isso?
Na técnica funcional, a integração é feita baseada na junção de componentes, programas, módulos ou subsistemas que produzam um resultado funcional significativo para os usuários (RIOS; MOREIRA, 2013).
Em outras palavras, podemos dizer que essa técnica verifica se os requisitos funcionais, depois de serem integrados nos módulos, programas, classes e outros, continuam tendo a sua funcionalidade, conforme especificado no início do sistema, e que ainda tenha significado para o usuário final quando utilizado por eles.
Segundo Rios e Moreira (2013), a abordagem “big-bang” combinam componentes, programas, módulos ou subsistemas de uma só vez; após serem testados isoladamente, como podemos verificar na imagem a seguir.
Esse tipo de teste normalmente é utilizado devido às pressões que ocorrem diariamente e desta forma, demonstram como o sistema está sendo operado.
O maior problema do uso desta técnica é caso ocorra problemas relacionados na interface de um módulo com outro, sendo difícil assim encontrar a causa de sua falha. Normalmente é aconselhável utilizar esta técnica para sistemas menores, estáveis e bem estruturados cujos componentes já passaram por testes de unidade e em implementações orientadas a objetos.
Dificilmente esta técnica trará benefícios para outros tipos de sistemas que não sejam esses citados, podendo sim significar em ganho de diversos problemas do que a resolução.
Existem várias técnicas que contemplam os testes de software, e cada uma pode ser aplicado em um determinado momento, ou em qualquer momento do desenvolvimento do software. A técnica do teste de integração é definida corretamente como:
Teste que realiza a descoberta de erros em partes unitárias do software produzido.
Alternativa incorreta. Esse tipo de teste são os testes unitários.
Teste para a descoberta de erros quando módulos, classes e outros são integrados com as interfaces.
Alternativa correta. É uma técnica utilizada para se construir a arquitetura de um software, e ao mesmo tempo, aplicar testes para a descoberta de erros quando integrados, e claro, com as suas interfaces.
Teste que verifica somente a integração com a interface do banco de dados utilizado.
Alternativa incorreta. Neste teste é trabalhado a integração de todos os módulo, classes do sistema, juntamente com a interface.
Teste que verifica a integração do software com o usuário final, ou seja, se o usuário interage corretamente com o software produzido.
Alternativa incorreta. O teste de integração visa a integração dos módulos/classes,e não a integração com o usuário.
Teste que trabalha com problemas relacionados a integração entre os desenvolvedores do software.
Alternativa incorreta. Não existe teste que verifica esse tipo de problema. A integração diz respeito à integração dos módulos; classes do sistema.
Como vimos, o teste beta também é conhecido como teste aceitação que aproxima o contato entre a equipe de desenvolvimento e o cliente, analisando se há uma aceitação ou não por parte do cliente das funções desenvolvidas pelo desenvolvedor. Desta forma, separamos um link interessante com conceitos e boas práticas a respeito do teste de aceitação. Acesse: blog.caelum.com.br.
O Teste de Validação tem por objetivo autenticar algo. Ele se inicia ao término do teste de integração. Assim sendo, são executados quando os módulos de cada unidade já foram testados e o software está completamente integrado e seus erros de interface já foram devidamente corrigidos (PRESSMAN; MAXIM, 2016).
Esse tipo de teste está ligado a ações perceptíveis ao usuário e as saídas reconhecidas pelo próprio usuário. Assim, a validação é bem sucedida quando o sistema está funcionando da maneira esperada pelo cliente.
Entendemos que a validação é um sucesso quando o software executa o que o cliente espera, ou seja, cumpre com suas expectativas. Tendo isso em mente, pense sobre o seguinte: o quão importante é ouvir e compreender o que o cliente deseja?
Temos que a validade do software é realizada a partir de casos testes que averiguam, e por consequente, demonstram a conformidade dos requisitos, ou seja, procedimentos de testes definem características específicas, que conduzidas adequadamente, garantem que os requisitos funcionais sejam satisfeitos, que todas as características relacionadas ao comportamento do sistema sejam obtidas, que a documentação esteja correta, e por fim, que qualquer outra característica relacionada ao requisitos sejam cumpridos (PRESSMAN; MAXIM, 2016).
Nesta etapa, após a validação ocorrer, podemos perceber que as características propostas e o desempenho estão de acordo, e assim são aceitas; ou ainda, pode-se descobrir determinados problemas que geram deficiências. Estes desvios raramente são corrigidos antes do prazo de entrega do sistema ao cliente, desta forma, deverá haver um consenso sobre um novo prazo para resolver estas pendências (RIOS; MOREIRA, 2013).
Quando falamos em processo de software, necessitamos entender alguns conceitos. Temos que o seu resultado são programas de computadores, sejam eles o código-fonte ou o executável; dados ou conteúdos que estão contidos nos programas ou externos a ele; e por fim, os produtos que descrevem os programas de computador. Estes itens entram como informações do processo de criação do software e que são chamados de configuração do software (PRESSMAN; MAXIM, 2016).
Assim, dizemos que a gestão de configuração de software é um conjunto de atividades desenvolvidas com a finalidade de gerenciar possíveis alterações a partir do ciclo de vida do software construído.
Segundo Pressman e Maxim (2016), a revisão da configuração é uma etapa importante no processo de validação, já que tem a finalidade de revisar e garantir que todos os elementos relacionados a configuração do sistema tenham sido tratados, desenvolvidos e documentados; para desta forma, auxiliar nas atividades relacionadas ao suporte do software.
Instruções de uso podem ser mal interpretadas, podem acontecer combinações estranhas de dados, resultados que são claros para o pesquisador podem ser confusos para um usuário ao executar o sistema, e assim por diante. É complicado, mas possível. E quando tratamos de um único cliente que utilizará o sistema, fica mais fácil validar os requisitos. Porém, quando se trata de diversos usuários, o problema fica maior e mais difícil.
Nesse sentido, muitos construtores de software usam processos chamados de teste alfa e beta para que, assim, seja possível descobrir erros que apenas o usuário final pode encontrar.
Desta forma, Pressman e Maxim (2016) citam o teste alfa, que é realizado na instalação pelo desenvolvedor do sistema e executado por um grupo de usuários finais, ou seja, o desenvolvedor do sistema analisa como os usuários do sistema utilizam-no em seu cenário natural, o da empresa.
Assim, o desenvolvedor consegue registrar todos os erros e problemas causados por uma possível utilização errônea por parte do usuário; conduzindo os testes em um ambiente controlado.
Já o teste beta é conduzido nas instalações de um ou mais usuários finais. Nesse tipo de teste, o desenvolvedor geralmente não fica presente, e, consequentemente, não pode ter o controle pelas ações realizadas pelo cliente. Assim, é essencial que o cliente faça o registro dos problemas encontrados, e de posse destes problemas, o engenheiro de software realiza possíveis modificações (PRESSMAN; MAXIM, 2016).
Teste Beta também recebe o nome de teste aceitação do cliente, que executa um determinado número de testes específicos com a finalidade de encontrar erros antes de o software desenvolvido ser entregue totalmente.
Esse tipo de teste está ligado a ações perceptíveis ao usuário. Desta forma, é verificada a funcionalidade do sistema como se o cliente estivesse de acordo com o que está sendo executado. Essa descrição trata da definição do teste de:
Unitário.
Alternativa incorreta. O teste unitário trata de verificação de erros em unidades do sistema.
Validação.
Alternativa correta. O Teste de Validação tem por finalidade validar algo. Se inicia ao término do teste de integração, quando os módulos da unidade já foram testados e o software está integrado e sem erros.
Integração.
Alternativa incorreta. O teste de integração verifica problemas na integração entre os módulos/classes do sistema.
Sistema.
Alternativa incorreta. O teste de sistema verifica problemas relacionados a segurança, esforço e outros.
Conexão.
Alternativa incorreta. Não existe um teste com esse nome.
Como vimos, o teste beta também é conhecido como teste aceitação que aproxima o contato entre a equipe de desenvolvimento e o cliente, analisando se há uma aceitação ou não por parte do cliente das funções desenvolvidas pelo desenvolvedor. Desta forma, separamos um link interessante com conceitos e boa práticas a respeito do teste de aceitação. Acesse: blog.caelum.com.br.
Realizar um teste de sistema envolve a integração de componentes para que assim seja criada uma outra versão do sistema e, em seguida, o teste integrado do sistema. Assim, o teste de sistema é, na realidade, uma série de diferentes testes que verificam se todos os componentes são compatíveis quando são integrados corretamente nesta versão do sistema (SOMMERVILLE, 2011).
Pressman e Maxim (2016) dizem que o teste do sistema deve centrar-se em testar todas as interações entre objetos e componentes que compõem um sistema. Essa interação deve procurar bugs que são revelados quando um componente é utilizado por outros componentes na junção final do sistema. O teste de interação ajuda a verificar possíveis equívocos realizados pelos desenvolvedores de módulos sobre outros módulos do software.
Você já deve ter passado, durante uma implementação de sistemas, com problemas relacionados a falhas em sistemas, e que, de uma forma ou de outra, retornam falhas que interferem no processamento do sistema, podendo até causar paradas inesperadas.
Na maioria das vezes, os sistemas devem tolerar estas falhas para que não gerem essa paralisação do sistema. Testes de recuperação são testes que têm o objetivo de forçar as falhas de várias maneiras, para que, no final, se verifique se a recuperação após as falhas está sendo executada corretamente (PRESSMAN; MAXIM, 2016).
Neste caso, se a recuperação for executada de forma automática pelo sistema, os mecanismos de verificação, reinicialização e recuperação de dados são avaliados quanto à uma possível correção. Se esta recuperação requer intervenção humana, deve ser avaliado o tempo médio de reparo para determinar se está dentro dos limites aceitáveis (SOMMERVILLE, 2011).
O teste de segurança deve verificar se mecanismos de proteção do sistema vão proteger de fato contra possíveis acessos indevidos. Sabemos que qualquer software que trabalha com informações importantes é sempre alvo de pessoas que desejam adquirir essas informações que não lhes pertence.
Podemos chamar esses invasores de Hackers, funcionários que possuem problemas com a empresa e querem estas informações para prejudicar a empresa e diversos outros. Assim, a segurança deve ser testada para que essa vulnerabilidade seja tratada.
Sommerville (2011) diz que, durante o teste de segurança, os pesquisadores devem fazer o papel da pessoa que está invadindo o sistema, devem pensar e analisar as diversas formas papéis que o mesmo utiliza para esta ação. Uma destas atividades é tentar obter senhas por meios externos ao sistema, atacar o software, projetando o rompimento das defesas implementadas, sobrecarregar o sistema ou outros meios que possam causar erros.
Um bom teste de segurança, em seu final, conseguirá cumprir o seu papel, que é invadir o sistema; porém isso leva tempo e recurso. Desta forma, o papel principal do desenvolvedor é tornar o custo para a invasão do seu sistema maior do que as informações que o próprio sistema armazena.
Sabemos que a segurança é fundamental, seja qual sistema for. Um sistema coerente e que possui uma integridade em seus dados, podemos afirmar que possui implementado um módulo de segurança.
O teste de esforço nada mais é do que colocar o sistema em situações anormais de execução. Normalmente, testes produzem uma ou duas interrupções, o que são normais; os testes de esforço visam aumentar esse número de interrupções para que assim o sistema possa ser verificado mais adequadamente para cada ação. São executados diversos casos de testes que requerem o máximo de memória ou outros recursos; teste que podem causar excessiva procura por dados residentes em disco; e outros; podemos dizer assim que o teste de esforço procura “quebrar” o programa (PRESSMAN; MAXIM, 2016).
Como variação deste teste, temos o teste de sensibilidade, que tem como objetivo descobrir combinações de dados dentro de classes/módulos de entradas válidas que talvez causem instabilidade ou processamento inadequado do software.
“Se você está tentando encontrar verdadeiros defeitos no sistema e ainda não submeteu o seu software a um verdadeiro teste de esforço, então é hora de começar a fazê-lo.” Boris Beizer (apud PRESSMAN; MAXIM, 2016, p. 487).
Segundo Sommerville (2011) e Pressman e Maxim (2016), o teste de desempenho é projetado para testar, como o próprio nome diz, o desempenho em tempo de execução do sistema em relação a um sistema integrado. O teste de desempenho pode ser realizado em todas as etapas de teste, como por exemplo, em nível de unidade; no entanto, o seu verdadeiro desempenho só poderá ser válido, de fato, quando ele for verificado a partir da integração de todos os elementos do sistema.
Usualmente os testes de desempenho são acoplados ao teste de esforço, que trabalham com partes de hardware e software, ou seja, medindo a utilização dos recursos, monitorando assim o sistema com os instrumentos presentes e suas possíveis falhas.
Como em outros tipos de testes, o teste de desempenho também irá mostrar se o sistema atende aos requisitos e também auxiliará na descoberta de defeitos e problemas. Vejamos um exemplo prático disso:
Por exemplo, digamos que você está testando um sistema de processamento de transações que é projetado para processar até 300 transações por segundo. Você começa a testar esse sistema com menos de 300 transações por segundo; então, aumenta gradualmente a carga no sistema para além de 300 transações por segundo, até que esteja bem além da carga máxima de projeto do sistema e o sistema falhe. (SOMMERVILLE, 2011, p.159).
Esse tipo de teste é também conhecido como teste de estresse e tem duas funções: primeiro, a de testar o comportamento de falha do sistema e, também, a de estressar o sistema e trazer à tona defeitos ainda não descobertos.
O intuito do teste de disponibilização é verificar se o software implementado funciona adequadamente no ambiente operacional que o mesmo deve operar. Se o mesmo foi implementado para operar em diversas plataformas, o mesmo deve ser testado para a verificação de possíveis problemas.
Pressman e Maxim (2016) dizem que o teste de disponibilização examina todos os procedimentos de instalação do sistema que serão utilizados pelos clientes e toda a documentação gerada ao final do sistema que será usada para fornecer o software para os usuários finais.
Para finalizar, integrado aos testes de disponibilização, devemos também realizar os testes de segurança citados anteriormente, já que a questão da segurança é um problema importante que deve ser tratado.
É um teste que verifica se o sistema possui robustez, disponibilidade e confiança diante de condições extremas. A alternativa que contempla corretamente tipo de teste definido é:
Regressão.
Alternativa incorreta. A definição acima diz respeito ao teste de estresse.
Estresse.
Alternativa correta. São consideradas condições de estresse o alto acesso de usuários simultâneos, limitações de recursos computacionais e volume excessivo de dados, o que faz com que haja muita perda de recursos.
Carga.
Alternativa incorreta. A definição acima diz respeito ao teste de estresse.
Segurança.
Alternativa incorreta. A definição acima diz respeito ao teste de estresse.
Desempenho.
Alternativa incorreta. A definição acima diz respeito ao teste de estresse.
Temos diversas técnicas que auxiliam a melhorar o desempenho através da detecção de erros em possíveis gargalos, e claro, aplicando diferentes tipos de circunstâncias. Falamos sobre testes de desempenho, carga e estresse. Vamos dar uma conferida em alguns outros? Para isso, disponibilizamos o link a seguir. Acesse: testar.me.
Este teste pode revelar erros e omissões na definição dos requisitos do sistema e também pode revelar problemas de requisitos em que os recursos do sistema não atendam às necessidades do usuário ou o desempenho do sistema seja inaceitável.
Um teste de aceitação também é utilizado para realizar a aproximação com o cliente final em relação ao resultado que se espera do sistema, além claro, do próprio usuário poder auxiliar desenvolvedores no que eles esperam, e assim garantir o mais próximo possível com a conformidade esperada (RIOS; MOREIRA, 2013).
Podemos completar ainda, afirmando que o teste de aceitação é a última ação antes da implantação do software, e é realizado para avaliar a sua qualidade externa e também quanto à qualidade de uso; desta forma, é um teste que exprime a relação com o cliente, que deve ser colocado a par neste teste de software, já que o intuito principal é verificar se este software produzido está pronto para uso dos próprios usuários (SOMMERVILLE, 2011).
Dentro do teste de aceitação temos os testes denominados de “alfa”, “beta” e ainda “paralelo”. Assim podemos explanar que o teste alfa verifica a qualidade externa, o teste beta a qualidade de uso, e o teste de paralelo quando um sistema é desenvolvido para substituir outro que já está em funcionamento (RIOS; MOREIRA, 2013).
Agora que nos aprofundando um pouco mais sobre as estratégias de testes comuns no teste de aceitação, iremos conceituar um pouco mais sobre três estratégias propostas, sendo a aceitação formal, a aceitação informal (teste alfa) e o teste beta.
Este tipo de teste é uma extensão ao teste de sistema e deve ser projetado como tudo o que é feito no sistema, com muito cuidado e muito detalhado. Sendo assim, podemos dizer que estes testes são subconjuntos dos testes de sistema.
Este teste pode ser executado pelo grupo de teste de uma organização que representam o usuário final, ou ainda, executado inteiramente pelos usuários finais.
Como benefício, temos que as funções e os recursos que devem ser testados são conhecidos por inteiro, e podem ser também medidos; o seu progresso pode ser monitorado e critérios de aceitabilidade do sistema também conhecidos; e por fim, este tipo de teste pode ser automatizado (RIOS; MOREIRA, 2013).
Testes, em sua maioria, geram benefícios, porém testes também podem não revelar determinados defeitos que o software contém, já que, em sua maioria, os testes que são executados são para a procura de defeitos preestabelecidos, ou seja, esperados.
Neste tipo de teste, as características e métodos para a execução não são realizados com o mesmo rigor apresentado no teste de aceitação formal. Neste teste, o testador individual determina o que e como fazer. Desta forma o teste se torna mais subjetivo do que o teste apresentado anteriormente.
O teste de aceitação informal normalmente é realizado pela organização do usuário que irá utilizar o sistema e possui alguns benefícios em sua aplicação, como o conhecimento das funções e recursos testados, critérios de aceitabilidade e monitoramento; e aqui serão revelados defeitos mais subjetivos (RIOS; MOREIRA, 2013).
Neste tipo de teste, também possuímos alguns problemas, pois como os testes são realizados pela organização do usuário final, não há um controle sobre os casos testes que são utilizados, e ainda pode acontecer uma comparação do novo sistema a ser implementado com o sistema antigo, o que prejudica a procura de erros no sistema (RIOS; MOREIRA, 2013).
O teste beta é um dos testes menos controlados das opções apresentadas para o teste de aceitação. As características e a abordagem adotada aqui é de inteira responsabilidade do testador individual, ou seja, cada testador pode criar seu próprio ambiente de testes com funções, recursos e tarefas; desta forma cada um cria critérios para a aceitação ou não do sistema (RIOS; MOREIRA, 2013).
Este teste é o mais subjetivo entre os apresentados e por ser implementado por usuários finais, não possui nenhum gerenciamento por parte dos desenvolvedores do sistema.
Este tipo de teste aumenta a satisfação do cliente em relação aqueles que participam. Porém, com ele é difícil medir o progresso de como está o teste, pois usuários podem se adaptar ao sistema e não conseguir encontrar mais defeitos; além da possível comparação com o sistema antigo (RIOS; MOREIRA, 2013).
O teste de aceitação visa revelar erros e omissões na definição dos requisitos do sistemas, e que desta forma, não atendem às necessidades dos usuários. Essa técnica possui três estratégias, que estão representadas na alternativa:
Teste de Fluxo de Dados e Teste Funcional.
Alternativa incorreta. Esses testes pertencem a técnica de testes de integração.
Teste de Aceitação Formal, Teste de Aceitação Informal e Teste Beta
Alternativa correta. Teste formal deve ser projetado como tudo o que é feito no sistema, com muito cuidado e muito detalhado, são subconjuntos dos testes de sistema. No teste informal, o testador individual determina o que e como fazer, se torna mais subjetivo do que o teste apresentado anteriormente. No este Beta, cada testador pode criar seu próprio ambiente de testes com funções, recursos e tarefas.
Teste de Recuperação e Teste de Segurança.
Alternativa incorreta. Esses testes pertencem a técnica de testes de sistema.
Teste Bottom-up e Teste Big-Bang.
Alternativa incorreta. Esses tipos de testes pertencem a técnica de testes de integração.
Teste de Disponibilização e Teste de Desempenho.
Alternativa incorreta. Esses tipos de testes pertencem a técnica de testes de sistemas.
Todo tipo de teste tem sua parcela de importância na construção de um software, e o teste de aceitação não é diferente disso. Desta forma, separamos uma matéria que apresenta boas práticas em relação a aplicabilidade do teste de aceitação. Acesse: shipit.resultadosdigitais.com.br.
Nome do livro: Engenharia de Software. Uma Abordagem Profissional
Editora: AMGH
Autor: Roger S. Pressman
ISBN: 978-8580555332
O livro de Pressman segue a linha dos livros mais importantes da área de Engenharia de Software. Essa última edição está amplamente atualizada para incluir os novos tópicos da “engenharia do século 21”. Há novos capítulos que abordam sobre um dos quesitos mais importantes atualmente, que é a segurança de software e os desafios específicos ao desenvolvimento para aplicativos móveis.
Nome do filme: Piratas do Vale do Silício
Gênero: Drama
Ano: 1999
Elenco principal: Paul Freiberger, Michael Swaine
Um filme que conta um pouco da história da tecnologia e o surgimento de Steve Jobs e Bill Gates. A história é narrada quando, os dois, ainda estudantes, lideraram uma revolução que integrou os computadores ao nosso dia a dia. Se deu assim o surgimento das maiores empresas de tecnologia mundial.
