ORGANIZAÇÃO DE ESTRUTURA DE TESTES EM UM AMBIENTE

COORPORATIVO DE TI
Leonardo Mayer de Souza

Resumo: Qualidade de software é assunto cada vez mais abordado dentro da Engenharia de
Software, pois um sistema sem qualidade dificilmente será bem aceito pelos usuários. Assim, os
testes de software são utilizados para aferir a confiabilidade de um sistema. Porém, caso os
testes sejam executados somente dentro de um contexto de uma fase do desenvolvimento,
validações importantes podem ser esquecidas e o tempo de execução também tende a ser alto.
Nesse sentido, este estudo de caso propõe uma melhoria sobre o processo de testes utilizado em
uma empresa de desenvolvimento de software de Florianópolis que começou a adotar a
metodologia ágil como metodologia de desenvolvimento de seus sistemas.

Palavras-chave: processo, qualidade, organização, desenvolvimento, software, estrutura,

metodologia.

1 INTRODUÇÃO

A implantação de um processo de qualidade de software é uma realidade que vem

preocupando empresas atualmente no Brasil. Até poucos anos atrás era difícil ouvir falar em um
setor de testes em empresas de desenvolvimento de sistemas, culturalmente não era visto como
algo necessário.

Acontece que nos últimos anos a tecnologia está se desenvolvendo de forma bastante
acelerada no mercado de trabalho. Muitas empresas, demandas, inovações, competitividade.
Essa competitividade faz com que os empresários busquem diferenciais. A qualidade de
software é um dos diferenciais que uma empresa de tecnologia pode ter atualmente.

“Em muitos aspectos a engenharia de software pode ser comparada à engenharia civil.
Na engenharia civil o projeto, em geral, tem os seguintes passos: contexto, arquitetura, projeto
técnico, construção e validação.” (MARTINS, 2008, p. 10). O ponto que se quer chegar neste
trabalho se apresenta na última palavra da frase de Martins (2008): Validação.

A validação se faz na última etapa da construção civil. Mas e na construção do

software? É diferente? Com um estudo aprofundado em qualidade de software, formou-se o
entendimento que a validação no processo de desenvolvimento do software pode e deve ser
implantada logo na primeira etapa de concepção do produto e mantida nas demais fases.

Segundo Pezzè (2008) compreende-se atualmente que:

Embora alguns processos primitivos de desenvolvimento de software

concentrem o teste e a análise no final do ciclo de desenvolvimento, e o cargo
de “testador” em algumas organizações ainda se refira a uma pessoa que
meramente executa casos de teste em um produto completo, hoje em dia é
amplamente compreendido que a execução do teste é uma pequena parte do
processo de verificação e validação necessária para avaliar e manter a
qualidade de um produto de software.(PEZZÈ, 2008, p.27)

Se o processo de teste de software precisa começar logo na primeira etapa de concepção

do produto, como deve ser estruturada a equipe de testadores? Quais papeis eles têm na
corporação? O que o gerente de projetos espera com a implantação de uma equipe especializada
em testes? Como implantar e com quais metodologias e técnicas?

O objetivo deste artigo foi elaborar uma proposta de organização de estrutura de testes
de sistema, identificando onde os níveis, tipos e técnicas de teste devem ser utilizados e em qual
momento para aperfeiçoar o processo já existente.

Antes de caracterizar a pesquisa, se faz necessário definir o que é uma pesquisa.

Conforme Gil (2008, pág. 26), “pesquisa é um processo formal e sistemático de
desenvolvimento do método científico. O objetivo fundamental da pesquisa é descobrir
respostas para problemas mediante o emprego de procedimentos científicos”. Com este
entendimento sobre a pesquisa, podemos caracterizá-la. Quanto à natureza, se classifica como
qualitativa.

Foi realizada uma pesquisa bibliográfica, visto que referenciais teóricos relativos ao
tema foram discutidos e o estudo de caso, visto que foi uma pesquisa em uma empresa da área
de desenvolvimento de software.

Essa pesquisa foi feita descritiva, da qual mostrou características de um determinado

Laboratório, onde neste caso, os colaboradores do laboratório são os sujeitos. A pesquisa foi
aplicada no Laboratório Bridge, localizada em Florianópolis-SC, que possuía a metodologia
tradicional modelo cascata e passou adotar uma variação do SCRUM para o desenvolvimento
de seus sistemas. A pesquisa foi feita na forma de entrevista para a coleta de dados e foram
analisadas as respostas posteriormente.

Nas próximas páginas serão descritos o modelo de desenvolvimento atual da empresa e a

proposta de melhoria do processo.
2 ORGANIZAÇÃO DO PROCESSO

2.1 – Processo de desenvolvimento de software

Com a inovação dos computadores após a segunda guerra mundial teve-se um grande
aumento na dinamização da indústria de computadores e, por conta disso, o processo de
construir softwares para que os mesmos automatizassem os processos que eram manuais e
pudessem facilitar situações complexas que fazem parte do dia-a-dia das organizações.
A partir deste cenário que surgiu a necessidade de criar modelos de desenvolvimento de
software que pudessem atender as novas demandas e ao mesmo tempo ser utilizados na
elaboração de softwares. Conforme Bezerra (2015, p.31), “O desenvolvimento de um sistema
envolve diversas fases e a um encadeamento específico dessas fases para a construção do
sistema dá-se o nome de Modelo de Ciclo de Vida”.
Segundo Audy e Prikladnicki (2007, p.14), o modelo cascata “é um ciclo de vida que
utiliza um método sistemático e sequencial, em que o resultado de uma fase constitui a entrada
de outra, cada fase é estruturada como um conjunto de atividade que podem ser executadas por
pessoas diferentes, simultaneamente ou não”. Este modelo é constituído pelas atividades de
análise, projeto, codificação, teste e implementação. Nota-se que neste processo a atividade de
testar o produto ocorre somente após as três primeiras.

O processo das atividades é bem parecido no modelo Iterativo e Incremental. Segundo

Schach (2010, p22), “O modelo iterativo e incremental é um dos processos recomendados para
o desenvolvimento de aplicações WEB, pois permite incorporar requisitos de segurança e de
qualidade à medida que o software é desenvolvido. Também possibilita que as funcionalidades
sejam divididas em partes menores ou iterações”. Neste modelo, a ordenação das atividades é a
seguinte: Planejamento, Análise, Projeto, Implementação, Testes. Novamente tem-se que
atividade de testar em um momento específico e isolado, em que o teste só estará presente na
última fase do desenvolvimento do software.

Em fevereiro de 2001, na cidade de Utah, um grupo de dezessete pessoas que se

intitularam “The Agile Alliance”, dão início a um manifesto declarando princípios que
fundamentam o desenvolvimento de software de forma ágil. Este manifesto foi chamado de
“Manifesto Ágil” e é composto por quatro valores fundamentais:

• Os indivíduos e suas interações acima de procedimentos e ferramentas;

• O funcionamento do software como prioridade ao invés de documentação abrangente;
• A colaboração dos clientes acima da negociação de contratos;
A capacidade de resposta a mudanças acima de um plano pré-estabelecido;
O manifesto ágil também é composto por doze princípios do desenvolvimento ágil:

• Garantir a satisfação do cliente, entregando rápida e continuamente software funcionais;

• Software funcionais são entregues frequentemente (semanal, ao invés de mensal);
• Software funcionais são a principal medida de progresso do projeto;
• Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
• Cooperação constante entre as pessoas que entendem do 'negócio' e os desenvolvedores;
• Projetos surgem por meio de indivíduos motivados, devendo existir uma relação de
confiança.
• Design do software deve prezar pela excelência técnica;
• Simplicidade;
• Rápida adaptação às mudanças;
• Indivíduos e interações mais do que processos e ferramentas;
• Software funcional mais do que documentação extensa;
• Colaboração com clientes mais do que negociação de contratos;
• Responder a mudanças mais do que seguir um plano.
Com base nessas premissas diversas metodologias e melhores práticas para o
desenvolvimento de software foram desenvolvidos e vem sendo aplicados na área de TI, tais
como o SCRUM, XP, Crystal Clear, etc.

2.2 Níveis de teste no processo de desenvolvimento de software

Para entender sobre o processo de teste de software, é necessário entender alguns

conceitos. Para Bartié (2002, p. 22) “Teste é um processo sistemático e planejado que tem por
finalidade única a identificação de erros”. A partir da identificação desses erros é que definimos
a estratégia que utilizaremos para garantir a qualidade do software. Como descrito
anteriormente, os testes estão presentes em diversas fases do desenvolvimento, portanto existem
alguns níveis de teste.

Testes de unidade:

Segundo Wazlawick:

Os testes de unidade são os mais básicos e costumam consistir em verificar se

um componente individual do software (unidade) foi implementado
corretamente. Esse componente pode ser um método ou procedimento, uma
classe completa ou, ainda, um pacote de funções ou classes de tamanho
pequeno e moderado. Os testes de unidade costumam ser realizados pelo
 próprio programador, e não pela equipe de teste. (WAZLAWICK, 2011, P.
292)

Testes de integração:

Para Humble e Fearley (2014, p.97), devem ser aplicados “se sua aplicação se comunica
com vários sistemas externos por meio de diferentes protocolos, ou se a aplicação em si consiste
em uma série de módulos de baixo acoplamento com interações complexas entre eles”.

Testes de sistema:

Conforme Pressman (2011, p.409), são “...uma série de diferentes testes cuja finalidade
primária é exercitar totalmente o sistema”. Os testes de sistema são executados pensando no
sistema como um todo e em como o usuário vai utilizar o mesmo.

Testes automatizados:

Bartié (2002, p. 198) define que os testes automatizados como “a utilização de

ferramentas de teste que possibilitem simular usuários ou atividades humanas de forma a não
requerer procedimentos manuais no processo de execução de testes”. Os testes automatizados
podem ser utilizados para realização de testes funcionais, de regressão e de carga ou
performance.

2.3 Contextualização da organização apresentada

No Laboratório Bridge o modelo utilizado anteriormente era o modelo cascata. O

processo de testes se iniciava quando os programadores integravam uma parte do código
alterado e geravam uma versão para teste. Os testadores eram responsáveis por testar essas
alterações específicas do sistema e o mesmo como um todo garantindo que nenhuma outra
funcionalidade foi afetada. Para isso, cada testador fica responsável por testar determinados
módulos do sistema, que são trocados mensalmente. Acontece que o processo de
desenvolvimento mudou para o modelo ágil e com isso os desenvolvedores e analistas foram
separados em equipes, denominadas equipes ágeis, e alguns testadores manuais se
especializaram em automação de testes. A partir disso, o processo de teste de software precisa
ser aperfeiçoado para se adaptar ao novo modelo de desenvolvimento de software visando a
qualidade do produto final.
2.4 Entrevistas e coleta de dados.

A coleta de dados foi feita na forma de entrevistas com os colaboradores em regime

CLT do Laboratório Bridge que atuam na equipe de qualidade de software. A equipe de
qualidade é formada por testadores que possuem responsabilidades diferentes: desenvolvimento
de automatização de casos de teste, preparação de ambiente para os testes, elaboração de testes
manuais. As entrevistas foram feitas individualmente com os cinco profissionais da equipe que
possuem mais tempo de casa e não serão gravadas visando o anonimato das pessoas, com
objetivo de que dessa forma as mesmas se sintam mais à vontade para apontar problemas e
sugestões de melhorias.
15/08/2016 08:00 – Analista de Teste 1:

1. Você tem clareza do seu papel na equipe?

R: - Sim

2. Por favor, descreva seu papel na equipe.

R: - Meu papel é construir casos de teste e testar o sistema para garantir a
qualidade.

3. Quais são as suas responsabilidades?

R: - Minha responsabilidade é de garantir que uma determinada parte do sistema está
funcionando.

4. Como é seu fluxo de trabalho no dia-a-dia?

R: - Testar as tarefas aguardando teste no Redmine e se não tiver nenhuma faço
a validação dos requisitos funcionais dos módulos atribuídos pra mim, assim
como o teste exploratório do mesmo.

5. Você considera que o fluxo de trabalho da sua área está bem definido? Explique
porquê.
R: - As vezes não fica muito claro o que é prioridade e se faz necessário
perguntar ao líder.

6. Você considera que existe alguma atividade que poderia ser incluída no seu
fluxo de trabalho? Qual?
R: - Gostaria de aprender a automatizar os testes.

7. Na sua opinião, há tempo perdido em alguma parte do fluxo de trabalho? Caso

positivo, descreva o problema.
Não conseguiu responder.

8. A automatização e casos de teste traz benefícios à qualidade dos softwares do

Laboratório? Se sim, quais?
R: - Sim, nos poupa muito tempo.

9. Em qual etapa do processo você acha que os casos de teste devem começar a
serem automatizados?
R: - Quando a regra de negócio estiver bem sólida

10. Gostaria de manifestar algo que acha importante e as perguntas acima não
contemplam? Caso positivo, o que?

R: Não.
15/08/2016 08:20 – Automatizador de Teste 1:

1. Você tem clareza do seu papel na equipe?

R: - Sim

2. Por favor, descreva seu papel na equipe.

R: - Construir casos de teste e automatizá-los.

3. Quais são as suas responsabilidades?

R: - Construir novos cenários de teste através do Selenium para que o produto não tenha
falhas.

4. Como é seu fluxo de trabalho no dia-a-dia?

R: - Eu verifico a execução do dia anterior se tudo correu bem, arrumo ou
reporto os testes que falharam e construo novos testes.

5. Você considera que o fluxo de trabalho da sua área está bem definido? Explique
porquê.
R: - Sim, raramente a rotina muda.

6. Você considera que existe alguma atividade que poderia ser incluída no seu
fluxo de trabalho? Qual?
R: - Não

7. Na sua opinião, há tempo perdido em alguma parte do fluxo de trabalho? Caso

positivo, descreva o problema.
R: As vezes as regras de negócio mudam várias vezes e eu acabo perdendo
tempo com refatoração de testes.

8. A automatização e casos de teste traz benefícios à qualidade dos softwares do

Laboratório? Se sim, quais?
R: - Sim, nos poupa muito tempo.

9. Em qual etapa do processo você acha que os casos de teste devem começar a
serem automatizados?
R: - Desde a etapa de desenvolvimento, existem testes que podem ser feitos a
nível de código.

10. Gostaria de manifestar algo que acha importante e as perguntas acima não
contemplam? Caso positivo, o que?

R: Gostaria de propor que os testadores manuais escrevessem casos de teste para que os
automatizadores programem no Selenium, assim os testes ficariam mais completos pois
teriam a visão de duas pessoas.
15/08/2016 16:30 – Automatizador de Teste 2:

1. Você tem clareza do seu papel na equipe?

R: - Sim

2. Por favor, descreva seu papel na equipe.

R: - Eu automatizo testes e dou manutenção nas execuções.

3. Quais são as suas responsabilidades?

R: - Garantir que os testes automatizados continuem funcionando e atualizados.

4. Como é seu fluxo de trabalho no dia-a-dia?

R: - Dar manutenção aos testes que falharam na execução que roda a noite e
quando sobra tempo produzir novos casos de teste.

5. Você considera que o fluxo de trabalho da sua área está bem definido? Explique
porquê.
R: - Sim, as atividades mudam por conta da demanda, mas o fluxo sempre é o
mesmo.

6. Você considera que existe alguma atividade que poderia ser incluída no seu
fluxo de trabalho? Qual?
R: - Automatizar os casos de teste junto às equipes ágeis.

7. Na sua opinião, há tempo perdido em alguma parte do fluxo de trabalho? Caso

positivo, descreva o problema.
R: Somente por causa das mudanças de requisitos da documentação que faz com
que a gente adapte os testes várias vezes.

8. A automatização e casos de teste traz benefícios à qualidade dos softwares do

Laboratório? Se sim, quais?
R: - Sim, o teste de regressão que é feito é muito importante para garantir que as
funcionalidades continuem estáveis.

9. Em qual etapa do processo você acha que os casos de teste devem começar a
serem automatizados?
R: - Acho que na construção do produto dentro das equipes ágeis os testadores
podem começar.

10. Gostaria de manifestar algo que acha importante e as perguntas acima não
contemplam? Caso positivo, o que?

R: - Não
16/08/2016 09:00 – Analista de Teste 2:

1. Você tem clareza do seu papel na equipe?

R: - Sim

2. Por favor, descreva seu papel na equipe.

R: - Testar o sistema

3. Quais são as suas responsabilidades?

R: - Garantir a confiabilidade do sistema.

4. Como é seu fluxo de trabalho no dia-a-dia?

R: - Primeiro verificar se não tem tarefa no Redmine aguardando teste, depois
testar os módulos que foram atribuídos para mim pelo líder.

5. Você considera que o fluxo de trabalho da sua área está bem definido? Explique
porquê.
R: - Sim, acho que um exemplo disso é o tempo que um funcionário novo leva
pra se adaptar que é bem rápido, o sistema é grande e complexo mas o fluxo de
trabalho é simples.

6. Você considera que existe alguma atividade que poderia ser incluída no seu
fluxo de trabalho? Qual?
R: - Poderíamos ter testadores direto nas equipes ágeis.

7. Na sua opinião, há tempo perdido em alguma parte do fluxo de trabalho? Caso

positivo, descreva o problema.
R: Acho que se tivesse um testador 100% do tempo em uma equipe o código
seria integrado com muito mais qualidade pois seria mais uma parte do processo
sendo testado.

8. A automatização e casos de teste traz benefícios à qualidade dos softwares do

Laboratório? Se sim, quais?
R: - Sim, não precisamos nos preocupar em testar os mesmos campos todos os
dias pois se estiver automatizado já estará fazendo esse trabalho.

9. Em qual etapa do processo você acha que os casos de teste devem começar a
serem automatizados?
R: - Acho que quando o desenvolvimento estiver pronto e tiver certeza que não
irá mudar nenhum requisito do sistema.

10. Gostaria de manifestar algo que acha importante e as perguntas acima não
contemplam? Caso positivo, o que?
R: Não
17/08/2016 11:45 – Analista de Teste 3:

1. Você tem clareza do seu papel na equipe?

R: - Sim

2. Por favor, descreva seu papel na equipe.

R: - Meu papel é realizar testes funcionais e exploratórios no sistema para
garantir que defeitos não sejam entregues ao cliente.

3. Quais são as suas responsabilidades?

R: - Conforme dito anteriormente, minha responsabilidade é garantir que o sistema
chegue nas mãos do cliente sem erros de regras de negócio ou falhas na aplicação que
impossibilitem o mesmo de utiliza-la.

4. Como é seu fluxo de trabalho no dia-a-dia?

R: - A primeira coisa é sempre verificar no Redmine se há alguma tarefa
pendente que precise ser testada. Após liberar todas as tarefas começo o teste de
algum módulo do sistema.

5. Você considera que o fluxo de trabalho da sua área está bem definido? Explique
porquê.
R: - Com certeza, pois não tenho dúvidas sobre o que eu preciso fazer no meu
dia-a-dia.

6. Você considera que existe alguma atividade que poderia ser incluída no seu
fluxo de trabalho? Qual?
R: - Acho que seria interessante acompanharmos o trabalho do desenvolvedor e
testar em paralelo a ele, assim pode ser que evitemos que o bug seja integrado na
versão.

7. Na sua opinião, há tempo perdido em alguma parte do fluxo de trabalho? Caso

positivo, descreva o problema.
R: Não

8. A automatização e casos de teste traz benefícios à qualidade dos softwares do

Laboratório? Se sim, quais?
R: - Sim, é muito mais rápido um robô executar os testes do que um humano,
mas tem que tomar cuidado pois testes automatizados precisam ser sempre
planejados enquanto manual é mais passível a mudanças.

9. Em qual etapa do processo você acha que os casos de teste devem começar a
serem automatizados?
Não conseguiu responder.

10. Gostaria de manifestar algo que acha importante e as perguntas acima não
contemplam? Caso positivo, o que?
R: - Sim, gostaria de dar uma sugestão: gostaria que a rotatividade dos testes dos módulos fosse
mais frequente pois gostaria de aprender outras partes do sistema que ainda não testei.

2.5 Análise dos dados coletados

No início da conversa as perguntas foram direcionadas ao papel e às responsabilidades

que o profissional tem na equipe, com objetivo de identificar alguma incoerência entre o que
cada um realiza no dia-a-dia. Observou-se que todos souberam dizer o que fazem e porquê o
fazem, conforme dito pelo analista de testes:

Minha responsabilidade é garantir que o sistema chegue às mãos do cliente

sem erros de regras de negócio ou falhas na aplicação que impossibilitem o
mesmo de utilizá-la. (Analista de teste 3, pergunta 3 do questionário)

Quando foram questionados sobre o fluxo de trabalho no dia-a-dia onde mostraram

estarem bem definidas as atividades em que cada um deve desenvolver. Como melhoria do
processo, alguns falaram sobre as novas equipes que foram criadas. O analista de testes 2, na
pergunta de número 6, sugeriu: “Poderíamos ter testadores direto nas equipes ágeis”.

Essa sugestão faz com que seja frequente a participação dos testadores na concepção
das regras de negócio dos softwares, onde poderiam auxiliar no impacto em que as mudanças de
requisitos sofrem no desenvolvimento do sistema. Nesta etapa o teste do tipo funcional deve ser
utilizado, pois é neste momento que os requisitos funcionais são fabricados. Os testadores
também receberão as alterações do sistema previamente tendo assim a oportunidade de realizar
os testes no momento em que o sistema é desenvolvido. Neste momento predominaria o teste do
tipo exploratório, para garantir que falhas na aplicação não sejam integradas ao sistema.

Com a presença de testadores exclusivos para cada equipe ágil, mais uma possibilidade
de melhoria foi citada pelo automatizador de teste 2, na pergunta número 6, quando perguntado
se existe alguma atividade que poderia ser inclusa no seu fluxo de trabalho, o mesmo
respondeu: “Automatizar os casos de teste junto às equipes ágeis.”

Se algum tempo for investido com treinamento de automatização aos testadores das
equipes ágeis em parceria com os desenvolvedores, é possível que o laboratório consiga
trabalhar em testes a nível de código, testando as possibilidades de entrada e saída
automaticamente. Como consequência, a abrangência de um nível de teste que o Laboratório
não possui hoje: Testes de unidade.
 Outra questão levantada foi referente a importância da automatização e onde os testes
começam a ser automatizados. Sobre a importância da automatização, o padrão de resposta se
repetiu entre os entrevistados. Quando foi falado da importância que se tem em automatizar e os
benefícios que a mesma trás, poupando tempo de teste manual e até mesmo garantindo cenários
repetitivos que é inviável para os testes manuais abordarem, ouve um padrão de concordância
nas respostas. Um dos analistas de teste ainda disse:

Não precisamos nos preocupar em testar os mesmos campos todos os dias pois se
estiver automatizado já estará fazendo esse trabalho. (Analista de teste 2, pergunta 8
do questionário)

Através da entrevista foi possível perceber também que há retrabalho quando o roteiro
de testes de um requisito novo é desenvolvido. As mudanças que os clientes solicitam no
decorrer do desenvolvimento do software impactam diretamente nos casos de teste
automatizados que param de funcionar e precisam ser refatorados. Diante desses pontos de
vista, podemos concluir que no Laboratório Bridge, podemos utilizar a automatização de testes
nos níveis de teste de unidade e de sistema, contemplando os tipos de teste: de componente,
funcionais e de regressão.

Foi dada a oportunidade de qualquer proposta de melhoria que as perguntas não

abordaram e que o funcionário achasse importante falar. Duas sugestões foram feitas, a primeira
delas pelo automatizador de testes 1:

Gostaria de propor que os testadores manuais escrevessem casos de teste para que os
automatizadores programem no Selenium, assim os testes ficariam mais completos,
pois teriam a visão de duas pessoas. (Automatizador de Teste 1, pergunta 10 do
questionário)

Esta sugestão mostrou que seria muito mais produtivo se os testadores manuais
compartilharem os casos de testes feitos para com os automatizadores, a fim de abranger o
ponto de vista de mais de uma pessoa a um determinado módulo ou requisito. A outra sugestão
foi feita pelo analista de teste 3 e diz respeito as tarefas que são realizadas, o testador pede para
que a rotatividade da distribuição dos módulos seja feita com mais frequência para aprender
mais sobre o mesmo:

Gostaria que a rotatividade dos testes dos módulos fosse mais frequente pois gostaria
de aprender outras partes do sistema que ainda não testei. (Analista de teste 3,
pergunta 10 do questionário)

Após a entrevista, através de uma conversa informal, foi esclarecido que essa
rotatividade é feita a cada mês, pois é o tempo necessário para o testador aprender o módulo de
forma mais profunda. O testador concordou que este realmente era o melhor cenário e não tinha
pensado por esse ponto de vista.
3 CONCLUSÕES

A qualidade dos softwares tem cada vez mais importância para as corporações, uma vez
que a sua falta pode ocasionar prejuízos financeiros e de imagem aos usuários que utilizam
sistemas com funcionamentos que não se comportam conforme esperado, ou até mesmo que
possuem falhas ou erros. Assim, os testes são utilizados para garantir e aferir a qualidade dos
produtos seja para confirmar que o software está funcionando como esperado ou descobrindo
erros. Baseando-se nisso, este artigo foi feito para melhorar o processo de testes de uma
empresa de desenvolvimento de software afim de promover uma melhoria na qualidade dos
produtos. O estudo foi realizado em forma de entrevista, coletando informações do processo
com alguns dos colaboradores da empresa. Após as entrevistas uma análise dos dados foi
realizada apresentando propostas de melhoria e visando uma qualidade do produto superior ao
que era anteriormente.

O processo de desenvolvimento do software no mundo se atualiza e se adapta em um

ritmo muito acelerado, cada dia existem novas tecnologias, processos, ferramentas, etc. As
empresas necessitam acompanhar essas mudanças para que continuem competitivas no
mercado, portanto é necessário se adaptar diariamente.
REFERÊNCIAS

Audi, Jorge; Prikladnicki, Rafael. Desenvolvimento Distribuído de Software. ed. Elsevier: 2007.
Bartié, Alexandre.Garantia da qualidade de software: adquirindo maturidade organizacional,
Campus, 2002.
Bezerra, Eduardo. Princípios de Análise e Projeto de Sistemas com UML, 2015
GIL, Antonio Carlos. Métodos e técnicas de pesquisa social. 6 ed. São Paulo: Atlas, 2008.
Humble, Jez; Fearley, David. Entrega Contínua: Como Entregar Software de Forma Rápida e
Confiável. Ed. Bookman: 2014
Martins, José Carlos Cordeiro. TÉCNICAS PARA GERENCIAMENTO DE PROJETOS DE
SOFTWARE. ed. Brasport Livros e Multimídia Ltda: 2007.
Pezzè, Mauro; Young, Michal. TESTE E ANÁLISE DE SOFTWARE. ed. Bookman: 2008.
Pressman, Roger. Engenharia de Software: Uma Abordagem Profissional. Ed McGraw Hill
Brasil: 2009
Wildt, Daniel; Moura, Dionatan; Lacerda, Guilherme; Helm, Rafael. eXtreme Programming. ed.
Casa do Código: 2008.
Schach, Stephen R. Engenharia de Software. ed. AMGH: 2010.
Wazlawick, Raul. Engenharia de Software: Conceitos e Práticas. Ed Elsevier: 2011