V_TSoftware

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

Conteudista: Prof. Me. Ariel da Silva Dias
Revisão Textual: Prof.ª Dra. Luciene Oliveira da Costa Granadeiro
 
Objetivos da Unidade:
Compreender o conceito de testes funcionais;
Reconhecer as principais ferramentas de testes funcionais;
Aplicar testes de software utilizando a ferramenta Selenium.
˨ Material Teórico
˨ Material Complementar
˨ Referências
Testes Funcionais
Apresentando o Conceito de Testes Funcionais
O teste funcional é o processo pelo qual os QAs (Quality Assurance ou Garantia de Qualidade)
determinam se uma parte do software está agindo de acordo com os requisitos pré-
determinados. Ele usa técnicas de teste de caixa preta, nas quais o testador não tem
conhecimento da lógica interna do sistema. O teste funcional se preocupa apenas em validar se
um sistema funciona como planejado, ou seja, se ele tem um comportamento aceitável ou não. 
O teste de caixa preta é definido como uma técnica de teste na qual a funcionalidade do aplicativo
é testada sem examinar a estrutura interna do código, os detalhes da implementação e o
conhecimento dos caminhos internos do software. Esse tipo de teste é baseado inteiramente nos
requisitos e especificações do sistema. No teste de caixa preta, focamos apenas nas entradas e
saídas do sistema de software sem nos preocuparmos com o conhecimento interno do
programa, como ilustrado na Figura 1.
Figura 1 – Estrutura de um teste de caixa preta
 
#ParaTodosVerem: Imagem com a palavra “Entrada” e logo após possui uma
seta que indica um retângulo na cor azul com a palavra “caixa preta” no centro,
deste sai uma seta que leva á palavra “Saída”. Fim da Descrição.
1 / 3
˨ Material Teórico
A caixa preta da Figura 1 pode ser qualquer sistema de software que você deseja testando. Por
exemplo, um sistema operacional como o Windows, um site como o Google, um banco de dados
como o Oracle ou até seu próprio aplicativo personalizado. No teste de caixa preta, você pode
testar esses aplicativos apenas concentrando-se nas entradas e saídas sem conhecer sua
implementação de código interno.
Aqui estão as etapas genéricas seguidas para realizar qualquer tipo de teste de caixa preta:
Deve haver algo que defina o que é um comportamento aceitável e o que não é. Isso é definido
em uma especificação funcional ou de requisito. Trata-se de um documento que descreve o que
um usuário tem permissão para fazer, para que ele possa determinar a conformidade do
aplicativo ou sistema com ele. Além disso, às vezes, isso também pode implicar que os cenários
reais do lado do negócio sejam validados.
Portanto, o teste de funcionalidade pode ser realizado por meio de duas técnicas populares:
Etapa 1: Inicialmente, os requisitos e especificações do sistema são examinados;
Etapa 2: O testador escolhe entradas válidas (cenário de teste positivo) para verificar
se o sistema as processa corretamente. Além disso, algumas entradas inválidas
(cenário de teste negativo) são escolhidas para verificar se o sistema é capaz de
detectá-las;
Etapa 3: O testador determina as saídas esperadas para todas essas entradas;
Etapa 4: O testador de software constrói casos de teste com as entradas
selecionadas;
Etapa 5: Os casos de teste são executados;
Etapa 6: O testador de software compara as saídas reais com as saídas esperadas;
Etapa 7: Se ocorrer algum bug ou defeito, ele será corrigido e testado novamente.
Os testes e a garantia de qualidade são uma grande parte do processo SDLC (Software
Development Life Cycle ou Ciclo de Vida de Desenvolvimento de Sistemas). Como testadores,
precisamos estar cientes de todos os tipos de teste, mesmo que não estejamos diretamente
envolvidos com eles diariamente.
Como o teste é um leque muito amplo, seu escopo é muito vasto, e temos testadores dedicados
que realizam diferentes tipos de teste. Provavelmente, todos nós devemos estar familiarizados
com a maioria dos conceitos, mas não fará mal organizar tudo aqui.
A Figura 2, a seguir, apresenta uma hierarquia em tabela dos tipos de testes funcionais.
Figura 2 – Tipos de testes funcionais
Teste com base em requisitos: Contém todas as especificações funcionais que
formam a base para todos os testes a serem realizados;
Teste com base em cenários de negócios: Contém as informações sobre como o
sistema será percebido a partir de uma perspectiva de processos de negócios.
 
#ParaTodosVerem: Imagem de um fluxograma com alguns retângulos na cor
azul e com escritas na cor branca. Na parte superior um retângulo grande com
título “Categorias de Teste Funcional” abaixo do título, um retângulo do lado
esquerdo em posição horizontal escrito “Teste de Unidade” e logo ao lado
direito deste, possui quatro retângulos em posição vertical com as palavras
“Teste de Unidade”, “Teste de fumaça”, “Teste de regressão” e “Teste de
Usabilidade”. Na parte inferior do lado esquerdo da imagem possuem três
retângulos na posição vertical com as seguintes informações “Cobertura de
linha”, “Cobertura de método” e “Cobertura de caminho de código”. Fim da
Descrição.
A partir da Figura 2, observe a descrição de cada um dos tipos de testes a seguir.
Teste de Unidade
O teste de unidade geralmente é realizado por um desenvolvedor que escreve unidades de código
diferentes que podem estar relacionadas ou não para atingir uma funcionalidade específica. Isso
geralmente envolve escrever testes de unidade que chamariam os métodos em cada unidade e os
validariam quando os parâmetros exigidos fossem passados e seu valor de retorno fosse o
esperado. 
A cobertura do código é uma parte importante do teste de unidade, onde os casos de teste
precisam existir para cobrir os três abaixo:
Teste de Sanidade
Cobertura de linha;
Cobertura de caminho de código;
Cobertura de método.
O objetivo principal deste teste é determinar se as alterações ou a funcionalidade proposta estão
funcionando conforme o esperado. Se o teste de sanidade falhar, a construção é rejeitada pela
equipe de teste para economizar tempo e dinheiro. É executado somente após a construção ter
passado no teste de fumaça e ser aceita pela equipe de garantia de qualidade para testes
adicionais. O foco da equipe durante este processo de teste é validar a funcionalidade do
aplicativo e não o teste detalhado.
Nesse ponto, é importante adicionar que o teste de sanidade geralmente é feito no final de um
ciclo de teste de software em que a construção do software é estável. Por esse motivo, essa forma
de teste costuma ser improvisada. É executado para verificar se a funcionalidade foi corrigida
onde havia erros anteriores. Portanto, não é uma forma ampla de teste que requer
documentação intensiva. Porém, possui três etapas bem definidas, são elas:
Teste de Fumaça
Também conhecido como “Build Verification Testing”, é um tipo de teste de software que
compreende um conjunto não exaustivo de testes que visa garantir o funcionamento das
funções mais importantes. O resultado desse teste é usado para decidir se uma construção
(build) é estável o suficiente para continuar com os testes. Também pode ser usado para decidir
se deve anunciar um lançamento de produção ou reverter. O termo "teste de fumaça" veio para o
Etapa 1 – Identificação: A primeira etapa ao realizar o teste de sanidade, como com
qualquer outro tipo de teste, é estabelecer exatamente o que precisa ser testado. Isso
inclui todas as funcionalidades, recursos e modificações que foram introduzidos no
código relevante;
Etapa 2 – Avaliação: Nessa etapa, os testadores verificarão e avaliarão todas as
funcionalidades, recursos e modificações identificados na etapa anterior. Isso é
para ver se eles funcionam como deveriam;
Etapa 3 – Teste: Nesta etapa, os testadores verificarão todas as funcionalidades,
parâmetros e elementos relevantes associados à funcionalidade avaliada acima. Isso
garantirá que todas as suas bases sejam cobertas no que diz respeito ao
funcionamento correto do software. 
 
teste de software a partir de um tipo semelhante de teste de hardware, no qual um dispositivo
passa no teste se não pegar fogo (fumegou ou saiu fumaça) na primeira vez em que foi ligado.
O teste de fumaça ajuda a expor a integração e os principais problemas no início do ciclo. Pode
ser conduzido tanto em software recém-criado quanto em software aprimorado. O teste de
fumaça é realizado manualmente ou com a ajuda de ferramentas/scripts de automação. Se as
compilações forem preparadas com frequência, é melhor automatizar o teste de fumaça.
Conforme e quando um aplicativo se torna maduro, com adição de mais funcionalidades, o teste
de fumaça precisa ser mais expansivo. Às vezes, é necessário apenas um caractere incorreto no
código para tornar um aplicativo inteiro inútil.
Teste de Regressão
Trata-se de uma parte do teste de software projetado para determinar se um sistema é resistente
a falhas e funcional após uma alteração de código. Nesse estágio, um testador executa
novamente um conjunto de casos que executou durante o estágio inicial de desenvolvimento
para garantir que não haja impacto negativo. Observe que é importante testar não apenas a parte
do código que foi modificada ou um recurso recém-adicionado, mas todo o sistema.
Existem várias abordagens para o teste de regressão. Aqui está um breve resumo das técnicas
mais amplamente utilizadas.
Teste tudo novamente: Essa abordagem implica que todos os testes do sistema
devem ser executados novamente. Embora seja a maneira mais segura de garantir
que o projeto esteja livre de bugs, é preciso muito tempo e muito empenho para
executar um conjunto completo de testes. É por isso que a prática de "reteste tudo"
raramente é usada entre os testadores e, no caso em que uma equipe decida
continuar com ela, as sessões provavelmente serão automatizadas;
Seleção do teste de regressão: Ao selecionar um subconjunto de casos de teste
existentes, um especialista em QA pode cortar os custos operacionais
tremendamente em comparação com o novo teste de todo o sistema. Existem várias
práticas que os testadores usam para selecionar um caso de sessões de teste de
regressão. Para começar, você só pode testar um conjunto que produza cobertura
Para reduzir o custo e o número de horas necessárias para o teste de regressão completo, a
maioria das empresas executa sessões automatizadas. Dessa forma, eles são capazes de manter
uma maior precisão e reduzir o erro humano, bem como executar testes ininterruptos 24 horas
por dia, 7 dias por semana.
Teste de Integração
Se um sistema requer vários módulos funcionais para funcionar de maneira eficaz, o teste de
integração é feito para garantir que os módulos individuais funcionem conforme o esperado ao
operar em combinação uns com os outros. Ele valida se o resultado de ponta a ponta do sistema
atende a esses padrões necessários. Por tanto, o teste de integração é um tipo de teste destinado
a verificar as combinações de diferentes unidades, suas interações, a forma como os
subsistemas se unem em um sistema comum e a conformidade do código com os requisitos.
O teste de integração é executado usando o método da caixa preta. Esse método implica que uma
equipe de teste interaja com um aplicativo e suas unidades por meio da interface do usuário –
clicando em botões e links, rolando, deslizando, entre outros. Eles não precisam saber como o
código funciona ou considerar a parte de back-end dos componentes.
O teste de integração e o teste de unidade são dois níveis de teste de software, em que a unidade é
a básica e a integração é a sequencial.
para a seção modificada do programa original. Outra abordagem popular é uma
técnica segura, em que um testador trabalha com o número de casos que expõem
uma ou várias falhas no programa modificado. Outras abordagens para seleção de
teste incluem técnicas de cobertura de fluxo de dados e técnicas aleatórias;
Priorização de casos de teste: Essa abordagem permite que um especialista em QA
se concentre em testar as funcionalidades e casos usados com mais frequência que
têm um impacto comercial crucial, enquanto coloca temporariamente todos os
recursos secundários de lado. Ao priorizar os casos de teste, você reduzirá
enormemente o tamanho do conjunto de testes e terá mais tempo para avaliar
completamente o desempenho das partes cruciais do sistema.
O teste de unidade implica verificar as menores partes funcionais do código separadamente. O
teste de integração vai além: procuramos erros que acontecem quando as unidades começam a
interagir. O fato de as unidades terem passado com sucesso nos testes dos estágios anteriores
não garante que funcionem bem juntas. 
Portanto, quaisquer problemas que surjam quando montamos várias partes menores em um
subsistema podem estar associados às particularidades da interação entre essas unidades.
Quanto mais cedo notarmos algo anormal, menor será o custo de um erro.
Teste de Usabilidade
O Teste de Usabilidade é feito durante o processo de design de uma aplicação, com o objetivo de
testar se o aplicativo desenvolvido é conveniente e fácil de usar.
O teste de usabilidade oferece muita flexibilidade para alterações no design do aplicativo que está
sendo desenvolvido.
Por exemplo, quando um novo site de comércio eletrônico está sendo projetado, uma equipe de
teste inicia o Teste de usabilidade antes mesmo de o site terminar. Essas pessoas verificarão sua
usabilidade para saber como é conveniente e rápido pesquisar itens diferentes, obter opções
diferentes, pesquisar por palavras-chave, fazer login, navegar, colocar itens em um carrinho e
modos de pagamento.
O objetivo desse tipo de teste é revelar áreas de confusão e descobrir oportunidades para
melhorar a experiência geral do usuário. A seguir, estão 3 dos principais testes de usabilidade:
Teste de guerrilha: trata-se da forma mais simples de teste de usabilidade. Neste
teste, um moderador vai até um local público como shopping, mercado, entre outros,
para apresentar seu protótipo às pessoas e questioná-las sobre ele. Essas pessoas
são escolhidas aleatoriamente entre diversas pessoas no local e, em seguida, são
convidadas para realizar um teste de usabilidade. No final do processo, como
agradecimento, essas pessoas recebem algum tipo de presente;
Teste Usabilidade Moderado Versus o Não Moderado
Como você pode observar, temos sessões de teste moderada e não moderada. No primeiro caso,
toda a sessão do teste é administrada (seja pessoalmente ou remotamente) por um membro da
equipe de desenvolvimento ou de teste. Por outro lado, um teste não moderado não possui
acompanhamento ou supervisão de alguém, permitindo que os participantes estejam em
laboratórios, em suas próprias casas e em seus próprios dispositivos.
Como, durante uma sessão de teste moderado, o participante está em contato direto com o
pesquisador, então, como saída, temos resultados mais detalhados. Por outro lado, por haver a
necessidade de reservar um espaço e prepara todo o ambiente, esse tipo de teste acaba sendo
mais caro de se organizar e também de realizar a sua execução.
Qual teste usar então? Bem, o teste moderado deve ser empregado para analisar o
comportamento do usuário, bem como o raciocínio para desempenhar tarefas na aplicação. Por
outro lado, os testes não moderados são usados para analisar os padrões de comportamento do
usuário.
Teste Usabilidade Remoto Versus o Pessoalmente
Teste de laboratório: Trata-se de um teste que é feito em um ambiente especial
(laboratório) e é supervisionado por um moderador, que é o profissional que deseja
obter feedback do usuário. Durante um teste moderado, os moderadores estão
facilitando os participantes do teste por meio de tarefas, respondendo às suas
perguntas e respondendo aos seus comentários em tempo real;
Teste remoto não moderado: Diferente do teste de laboratório onde existe um
moderador que acompanha todo o processo, o teste de usabilidade remota não
moderado ocorre sem um moderador, adicionando ainda uma outra característica
de que pode ser feito a distância. Desse modo, todos aqueles que participam
do teste
devem concluir tarefas que são desempenhadas a distância, sejam elas em seus
próprios computadores ou smartphones, sem a presença ou orientação de um
moderador. Devido a isso, o custo de testes não moderados acaba sendo bem
menor, porém, gera resultados com poucos detalhes.
Até aqui você pode compreender que os testes podem ser com ou sem moderador. Além disso, o
teste pode ser feito a distância (remoto) ou pessoalmente. Os testes, quando são feitos pela
internet, são chamados de testes remotos. Agora, quando o teste exige a presença do
participante fisicamente no laboratório ou no ambiente de teste, chamamos de teste pessoal.
Cada um desses testes tem seus objetivos bem definidos. Quando há a necessidade de analisar a
linguagem corporal e/ou expressões faciais, torna-se fortemente recomendável que o tipo de
teste seja presencial. A desvantagem é que os testes presenciais são caros e demorados. Afinal, é
necessário preparar um local adequado e realizar o pagamento para os participantes (muitas
vezes lanches e bebidas).
O teste remoto não possibilita uma análise profunda do raciocínio do participante, porém,
permite que um grande número de participantes estejam disponíveis para o teste, independente
da área geográfica em que se encontram.
Muitos testes funcionais serão projetados em torno de determinadas especificações de
requisitos  atender aos requisitos de negócios é uma etapa vital no projeto de qualquer aplicativo.
Por exemplo, um requisito para um site de comércio eletrônico é a capacidade de comprar
mercadorias.
Um exemplo prático disso é: quando um cliente finaliza a compra de uma cesta de compras, ele
deve ser encaminhado para uma página de pagamento segura, a seguir, para a verificação de
segurança do banco e, em seguida, deve receber um e-mail de confirmação. O teste funcional
verifica se cada uma dessas etapas funciona.
Estudo de Caso
Para compreender melhor o teste funcional, considere o seguinte caso: um portal on-line
possibilita que o usuário efetue login com sua conta de usuário e senha. A página de login possui
dois campos de texto, sendo um para nome de usuário e outro para senha. Também possui dois
botões: Login e Cancelar.
Quando bem-sucedido, a página de login direciona o usuário para a página inicial do portal. O
botão cancelar cancela o login.
Primeiramente, precisamos levantar as especificações desta aplicação:
O cenário de caso de uso apresentado pode ser testado por meio de uma variedade de técnicas de
teste funcional.
O campo de identificação do usuário requer um mínimo de 6 caracteres, um máximo
de 10 caracteres, números (0-9), letras (az, AZ), caracteres especiais (apenas são
permitidos sublinhado, ponto final e hífen). O campo não pode ser deixado em
branco. O ID do usuário deve começar com um número/caractere. Não pode incluir
caracteres especiais;
O campo de senha requer um mínimo de 6 caracteres, um máximo de 8 caracteres,
números (0-9), letras (az, AZ), todos os caracteres especiais. Não pode ficar em
branco.
Teste de sistema: teste o sistema para avaliar se todos os componentes estão
funcionando perfeitamente em combinação. No exemplo, isso envolveria testar a
jornada do cliente – carregamento do aplicativo web, inserção de credenciais
precisas, direcionamento para a página inicial, execução de tarefas, logout do
sistema. Esse teste garante que o fluxo de trabalho prossiga e seja concluído sem
erros;
Teste de equivalência: os dados de teste são segregados em partições chamadas
casos de dados de equivalência. Nesse teste, os dados em cada partição devem
responder da mesma maneira. Consequentemente, você só precisa testar uma
condição em todas as partições. Se a condição não funcionar em uma partição, não
funcionará em nenhuma das outras. No exemplo, como o campo de id do usuário
pode acomodar no máximo 10 caracteres, ele deve se comportar da mesma forma
sempre que forem inseridos mais que 10 caracteres;
Teste de valor limite: esses testes são usados para verificar como o sistema se
comporta quando os limites de dados são implementados. No exemplo, uma vez que
A automação pode certamente reduzir o tempo e o esforço na execução de testes funcionais. O
erro humano também pode ser reduzido, evitando que os bugs passem da fase de teste.
Principais Ferramentas
Com o avanço das tecnologias de desenvolvimento de software, muitas ferramentas são criadas
com o objetivo de melhorar a produtividade, qualidade, principalmente, melhorar o tempo de
entrega de cada produto, trazendo assim a satisfação do cliente. Desse modo, o teste de software,
apoiado por suas ferramentas, contribuem para que as empresas de desenvolvimento atinjam
esses objetivos.
Existem diversas ferramentas para testes, sendo assim, a seguir, estão elencadas as principais e
mais utilizadas no mercado.
Selenium
Selenium é uma ferramenta que permite automatizar aplicações web. Se você estiver testando um
aplicativo em um navegador e quiser acelerar o processo e talvez se livrar de alguns erros, pode
automatizar o processo com o Selenium.
O Selenium fala a linguagem do navegador, o que significa que pode ser usado para orientar o
comportamento do navegador, como digitar em uma barra de pesquisa, clicar em um botão,
rolar uma página para baixo e assim por diante.
O Selenium consiste em uma série de ferramentas que fazem coisas diferentes: 
a id do usuário requer um mínimo de 6 caracteres, esse teste será usado para
verificar como o sistema responde quando menos de 6 caracteres são inseridos.
Selenium IDE: Selenium IDE é uma ferramenta de gravação e reprodução que pode
ajudá-lo a criar e editar casos de teste e suítes de teste. O IDE é um plugin do
Firefox que é usado para criar e executar casos de teste. Ele permite que você crie
Essas ferramentas suportam vários navegadores, sistemas operacionais e linguagens de
programação, de modo que o Selenium se adapta essencialmente às necessidades de muitos
testadores de software. Selenium também é de código aberto, o que significa que você pode
baixá-lo gratuitamente, estender e modificar o código-fonte como quiser e obter ajuda de uma
grande comunidade de usuários.
Após compreender os conceitos básicos do Selenium, vamos dar uma olhada mais de perto em
como usá-lo. 
casos de teste registrando suas interações com o navegador. Suas interações são
transformadas em etapas na própria linguagem da Selenium. Essas etapas podem
ser exportadas em diferentes linguagens de programação, incluindo Java, Python e
Ruby, que podem ser executadas posteriormente. O resultado final é o script de teste
completo na linguagem de sua escolha; 
Selenium WebDriver: Selenium WebDriver é uma interface de programação que pode
ser usada para criar e executar casos de teste. O WebDriver permite que você teste
todas as principais linguagens de programação, navegadores e sistemas
operacionais;
Selenium Grid: O Selenium Grid permite que você execute vários testes ao mesmo
tempo em várias máquinas, também conhecido como teste paralelo. Trata-se de um
ambiente com vários sistemas, mas um sistema mestre (o hub) que controla os
sistemas filhos (os nós). Os sistemas filhos podem ser, por exemplo, Nó 1:
Windows 10 rodando Chrome, Nó 2: MAC rodando Safari, Nó 3: Linux rodando
Chrome e assim por diante.
Existem seis etapas básicas na criação de um script Selenium para testar
um aplicativo da web:
Para executar essas etapas no Selenium, torna-se necessário escrever scripts de teste na
linguagem de programação de escolha da equipe. Depois que o script é escrito, a equipe de teste
pode executá-lo para testar qualquer aplicativo da web.
TestComplete
TestComplete é uma ferramenta automatizada de teste de IU desenvolvida pela
SmartBear Software. TestComplete tem a capacidade de criar testes funcionais automatizados
para aplicativos de desktop, web e móveis. Os recursos de plataforma cruzada do TestComplete,
abrangendo Desktop, Mobile e Web, unificam sua pilha de automação oferecendo uma
abordagem dedicada. Se o objetivo é: necessidade de uma ferramenta comum em toda a
organização para teste; consolidação de relatórios de várias tecnologias diferentes;
implementação de uma abordagem unificada para automação de teste. Seja qual for o objetivo,
ter uma ferramenta para aprender, uma ferramenta para implementar com uma abordagem
comum e uma plataforma com suporte profissional para automação simplifica e melhora a
eficiência do desenvolvimento e execução de testes automatizados.
Crie uma instância WebDriver;1
Navegue para uma página da web;2
Localize um elemento HTML na página da web;3
Execute uma ação no elemento HTML;4
Antecipe a resposta do navegador;5
Conclua o teste.6
TestComplete é uma ferramenta sem script que não requer habilidades de programação
obrigatórias para começar, além de ser muito fácil de usar e, desse modo, ajuda na criação de
scripts robustos. 
Outra característica é que o TestComplete é muito mais poderoso e rico em recursos em
comparação com o Selenium. Mas o custo do TestComplete é mais alto e as empresas optam por
ferramentas de código aberto como o Selenium, o qual oferece mais oportunidades de
crescimento e aprendizado na carreira, pois você precisa ser bom em programação. 
Portanto, o TestComplete é mais adequado para uma equipe de habilidade média e restringe os
projetos de cronograma para a criação mais rápida de scripts de teste. O orçamento do projeto
pode ser ajustado reduzindo o número de recursos necessários.
Watir
Watir é um grupo de bibliotecas Ruby para navegadores da web automatizados. Permite escrever
testes de fácil leitura e manutenção. Em outras palavras, é uma ferramenta simples e flexível.
Watir manipula os navegadores da mesma forma que as pessoas, verificando os resultados,
garantindo, assim, a aparência do texto esperado na página. Watir oferece suporte a qualquer
aplicativo – não importa a tecnologia em que seja desenvolvido, suportando apenas Internet
Explorer no Windows. O Watir-WebDriver oferece suporte a diferentes navegadores, como o
navegador Chrome, Firefox, Internet Explorer e Opera.
Escolhendo a Melhor Ferramenta
A seleção de ferramentas geralmente é baseada em critérios que não são ideais. 
Sendo assim, veremos a seguir cinco critérios principais os quais devem ser considerados na
escolha de uma ferramenta para teste funcional. 
De Acordo com o Defeito
Quais são os bugs bloqueadores que aparecem e onde eles aparecem? Essa é uma pergunta fácil
de fazer; a maioria das equipes com um rastreador de bugs pode encontrar a resposta na hora do
almoço. Esse tipo de pesquisa pode encontrar a maioria dos bugs na lógica de negócios, na
camada de banco de dados ou na interface gráfica do usuário (GUI).
Se os bugs mais importantes estiverem na GUI, a automação de teste da lógica de negócios por
meio de testes de unidade não agregará muito valor. Certamente não será o primeiro lugar por
onde começar.
Embora esta seja a primeira pergunta, também pode ser a última. Depois de selecionar uma
ferramenta, volte a esta questão. Reveja os defeitos recentes que importam, encontrados tanto
no teste quanto na produção, e pergunte se a ferramenta pode realmente detectar esses tipos de
defeitos. Se a resposta for "provavelmente não" ou pior, reinicie o processo de seleção da
ferramenta.
Ajuste da Equipe
Não existe uma ferramenta que resolva todos os problemas, bem como
não existe uma ferramenta que é a melhor ou a pior. Cada ferramenta é
desenvolvida para casos específicos. 
A próxima pergunta é provavelmente: "Quem fará a automação?". Se a automação for feita por
programadores ou programadores/testadores, a ferramenta provavelmente deve ser uma
biblioteca de código ou pacote. Da mesma forma, um grupo de testadores não técnicos ficará
mais confortável se a ferramenta tiver um front-end de gravação/reprodução.
Algumas ferramentas gravam ações e, em seguida, criam código ou criam um front-end visual
que permite aos programadores entrarem para ver o código por trás da visualização. Eles
oferecem o melhor dos dois mundos.
O principal problema aqui é que as pessoas que devem aprender a ferramenta precisam estar
dispostas e capazes de fazer isso e também ter tempo para fazê-lo. Se o processo de teste estiver
atrasado, designar testadores para aprender uma nova ferramenta adicionará trabalho,
retardando ainda mais o processo de entrega do software.
Se o processo de teste de regressão levar dias ou semanas para ser executado, automatizá-lo,
especialmente no front-end, tornará o teste mais lento, criando um acúmulo de trabalho até
algum ponto de equilíbrio. Mesmo após o ponto de equilíbrio, em que a ferramenta não está mais
atrasando os testadores, o antigo acúmulo de pedidos precisará ser eliminado.
Claro, se o projeto for novo, ou se a empresa pretende contratar uma nova pessoa para fazer o
trabalho da ferramenta de teste, essas objeções podem não se aplicar. Então, faça uma análise de
como a ferramenta será adicionada à equipe, o que ela atrapalhará, quem fará o trabalho e se
essas pessoas têm capacidade e tempo para fazer o trabalho.
Linguagem de Programação
Se a ferramenta tiver uma linguagem de programação, existem duas abordagens: use uma
linguagem de alto nível incrivelmente poderosa e fácil de aprender, como Ruby, ou escreva na
mesma linguagem que os programadores de produção.
Se o teste for escrito na mesma linguagem do código de produção e executado durante a
execução da integração contínua (CI), pode ser possível falhar no commit e fazer com que os
programadores corrijam o bug. Melhor ainda, a ferramenta poderia ser executada como um
plug-in dentro do ambiente de desenvolvimento integrado (IDE) do desenvolvedor,
minimizando a quantidade de troca que os programadores precisam fazer.
Se a ferramenta for executada fora do IDE e usar uma linguagem de programação diferente, é
improvável que os programadores aprendam a nova ferramenta ou façam o trabalho de suporte
da ferramenta quando ela relatar falhas.
Gerenciamento de Dados de Teste
Uma empresa fictícia comprou uma ferramenta de automação de teste popular com um período
de avaliação de 30 dias. A empresa tinha três ambientes de teste diferentes, usava contas de
usuário de teste compartilhadas e não tinha uma maneira fácil de excluir pedidos depois de
criados. Os pedidos podiam ser cancelados, mas continuavam a aparecer como pedidos
cancelados na tela principal dos "pedidos de hoje", com os primeiros aparecendo primeiro.
Depois que o sistema criou 10 pedidos, os novos pedidos não apareciam mais na página inicial.
O processo de teste de fumaça criou três pedidos, o que significava que só podia ser executado
três vezes por dia.
Foi realizado um grande progresso nos dias anteriores ao término do teste e gasto vários
milhares de dólares comprando a ferramenta e realizando o treinamento. O problema era que
não tinha como limpar os dados ou criar novas contas a partir da linha de comando  tudo era
conduzido por telas de administração.
Nesse caso, as ferramentas certas provavelmente envolveriam recursos para criar contas,
limpar pedidos, exportar uma conta e pedidos associados como "dados de teste válidos
conhecidos" e, em seguida, importá-los novamente. Isso permitiria que os testes comecem
sempre com uma configuração válida.
Isso aceleraria imediatamente todo o processo de teste, incluindo os humanos fazendo o
trabalho.
Outra área comum de melhoria é a capacidade de criar servidores de teste sob demanda de
acordo com um branch ou commit. As equipes que buscam o IC e que desejam que a verificação de
ponta a ponta seja executada como parte do IC geralmente precisam criá-lo de qualquer
maneira.
 Se o maior gargalo no processo de teste for a configuração, ou se a verificação repetível for
impossível sem automatizar a configuração, a ferramenta de teste funcional certa pode ser
apenas automatizar a configuração do teste use
Relatórios
Sem uma saída significativa que alguém possa usar, uma ferramenta
de teste é um mau
investimento. Painéis e gráficos podem ser recursos poderosos – a menos que a equipe planeje
enviar os resultados para outro sistema com relatórios melhores.
O rastreamento de execuções de teste ao longo do tempo também pode ser um recurso
poderoso. As partes interessadas em diferentes níveis se preocupam com diferentes tipos de
resultados. Os executivos em um nível alto o suficiente podem nem mesmo querer saber as
taxas de aprovação/reprovação tanto quanto as tendências. Os gerentes de nível médio desejam
entender o fluxo do processo. O pessoal técnico vai querer detalhar exatamente o que deu errado
em um determinado teste, assistindo a um vídeo da execução, se possível.
Em Síntese 
Nesta Unidade, você pode compreender o conceito de teste funcional,
bem como os diferentes tipos de testes relacionados a este. Você
também conheceu um pouco mais sobre as principais ferramentas de
teste funcional, dentre elas, o Selenium, uma poderosa ferramenta de
teste que é utilizada por diversas empresas por todo o mundo devido à
sua facilidade de uso e por ser gratuita.
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
  Livros  
Engenharia de Software Moderna 
No livro o autor dedica o capítulo 8 para falar sobre testes, explicando a
definição de teste de integração e teste de unidade, além de abordar os
testes automatizados. Trata-se de uma leitura indicada para quem
deseja se aprofundar nos conceitos sobre teste de software. 
VALENTE, M. Engenharia de software moderna. São Paulo: Editora
Independente, 2020.
Introdução ao Teste de Software 
No livro  os autores apresentam no capítulo 8 uma introdução aos
conceitos de testes para aplicações web. Partindo do teste estrutural,
bem como teste baseado em modelos de especificação e apresentação de
ferramentas. Trata-se de uma leitura indicada para compreender,
2 / 3
˨ Material Complementar
principalmente, as fases e critérios de um teste de software. 
DELAMARO, M.; MALDONADO, J.; JINO, M. Introdução ao teste de
software. São Paulo: Elsevier, 2007.
Teste de Software 
No livro o autor apresenta no capítulo 11 uma extensa e importante
descrição das características e conceitos relacionados ao teste em
aplicações web para internet. Trata-se de uma literatura recomendada
para iniciantes e também para usuários intermediários. 
RIOS, E. Teste de Software. Rio de Janeiro: Alta books. 2013.
  Leitura  
Um Pouco Sobre Cobertura de Código e Cobertura de Testes 
No artigo o autor relaciona e diferencia estes dois tipos de coberturas,
apresentando exemplos durante sua descrição. O autor prende a atenção
ao destacar detalhes importantes dos testes automatizados, bem como
cita bons exemplos.
Clique no botão para conferir o conteúdo.
ACESSE
https://ggle.io/4Ztb
BRAGA, P. H. C. (org.). Teste de Software. São Paulo: Pearson Education do Brasil, 2016. (e-book)
CANDIDO, A. Um pouco sobre cobertura de código e cobertura de testes. 2019. Disponível em:
. Acesso em: 20/11/2021.
DELAMARO, M. E.; MALDONADO, J. C.; JINO, M. Introdução ao teste de software. Rio de Janeiro:
Elsevier, 2016. (e-book)
FERREIRA, V. Apocalipse ou enganação: o que foi o Bug do Milênio? 2017. Disponível em:
. Acesso em 01/10/2021.
FOWLER, M. The Practical Test Pyramid. Disponível em:
. Acesso em 01/10/2021.
LEAPWORK. Na Introduction to Codeless Selenium Test Automation. Disponível em:
. Acesso em: 22/11/2021.
MCGOVERN, G. O que é teste de automação. Disponível em:
. Acesso em: 20/10/2021. 
VALENTE, M. T. Engenharia de software moderna: princípios e práticas para desenvolvimento de
software com produtividade. Disponível em: . Acesso em:
Acesso em: 04/05/2021.
3 / 3
˨ Referências