Você está na página 1de 7

Modulo 1

1. O que é um software? E quais são os seus tipos?


 Um software é um programa utilizado para realizar tarefas do usuário.
o System software (Device Drivers, Sistemas operacionais, Servidores,
Utilities e etc.)
o Programming software (Compiladores, Debuggers, interpreters e etc.)
o Application software (Web application, Mobile apps, Desktop Applications
e etc.

Banco  IT Company  Develop  Test Deliver  Banco

2. O que é um teste de software?


 Teste de software é uma parte do processo de desenvolvimento de software.
 É uma atividade de detectar d identificar os defeitos em um software.
 O objetivo é liberar a qualidade do produto para o cliente.

3. Descrevendo a qualidade de software.


 Livre de bugs
 Entregue no tempo determinado
 Dentro do orçamento
 Atendendo requisitos e expectativas
 Sustentável

4. Projeto VS Produto
 Se o software é desenvolvido especificamente para um cliente com base em
seus requisitos, ele será chamado de projeto.
 Se o software é desenvolvido especificamente para vários clientes e seus
requisitos são baseados no mercado, ele será chamado de produto.

5. Defect, Error, Bug e Failure


 O defect é um erro encontrado APÓS o software entrar em produção.
 O error é mal-entendido por parte dos desenvolvedores de software.
 O bug é um resultado de um erro de codificação. Um erro encontrado no
ambiente de desenvolvimento, antes do produto ou projeto ser enviado ao
cliente.
 O failure é uma falha, é a incapacidade do sistema ou do componente do
software de executar sua função exigida nos requisitos.
6. Por que softwares tem bugs?
 Má comunicação ou não comunicação
 Complexidade do software
 Erro na programação
 Mudança de requisitos
 Falha de testadores qualificados

7. SDLC – Software develompent life cycle / Ciclo de vida de desenvolvimento de


software
 O SDLC é um processo utilizado pela indústria de software para projetar,
desenvolver e testar o software.

Ciclo de vida de desenvolvimento de software

Analise de Requisitos  Projetar  Desenvolver  Testar  Manutenção

8. Modelo Cascata / Waterfall Model

 Analise de Requisitos
 Projetar sistema
 Implementação
 Teste
 Desenvolvimento
 Manutenção

Obs: A etapa seguinte só começa quando a etapa anterior é finalizada.

Vantagens:

 Qualidade do produto / projeto será boa.


 Desde que os requisitos não mudem, as chances de encontrar bugs serão
pequenas
 Investimento menor, já que os testadores são contratados nas etapas finais
 Preferência de projetos ou produtos pequenos com poucos requisitos.

Desvantagens:

 Mudanças de requisitos não são possíveis.


 Se houver um defeito nos requerimentos ele vai continuar até a última fase.
 O valor total investido é maior, por conta do tempo utilizado para realizar um
rework.
 Os testes serão realizados somente após a codificação.
9. Spiral Model

 Começando no centro da espiral.


 O modelo espiral é interativo, por conta da sua capacidade de repetir as interações
em determinados módulos.
 O Modelo espiral pode voltar a uma etapa, diferente da modelo cascata.
 Em todos os ciclos, será lançado um novo software para o usuário.
 O software vai conter múltiplas versões, por isso também é chamado de version
control model.

Vantagens:

 Testes são realizados em todos os ciclos, antes de ir para o próximo ciclo.


 Cliente vai utilizar o software de todos os módulos.
 Requisitos podem ser alterados no final de todos os ciclos, começando a levar
eles em conta no próximo ciclo.

Desvantagens:

 Requisitos não podem ser mudados antes de finalizar um ciclo.


 Todo ciclo no modelo espiral é como o modelo cascata.
 Testes não são realizados nas fases de requerimentos e de projeto.

Protótipo é o mesmo que blueprint do projeto.

Requerimentos iniciais  Protótipo  Cliente  Projetar, Desenvolver, testar e etc.


Gmail case

 Login
 Check Inbox
 Compose
 Sent
 Recive e-mail
 Etc...

Banking Case

 Login
 Check Balance
 Fund Transfer
 Req statment
 Add Payee
 Etc...

 Cada função é um Modulo



10. V-Model // VV Model

V V Model  Verification Validation Module


11. Técnica para testar
 Teste estático ou Static Testing é o teste realizado no documento
o Review
 Uma análise realizada para remover ambiguidades, redundâncias e
erros nos documentos
o Walkthrough
 Um especialista verifica o erro para que não haja problemas no
decorrer do desenvolvimento ou na fase de testes.
o Inspection ()
 Uma verificação de alta prioridade com mesma intensidade que o
SRS (Software Requirement Specifications)

 Teste Dinâmico ou Dynamic Testing é o teste realizado no


o Unit Testing
 Teste realizado em uma pequena parte do código pelos
desenvolvedores
o Integration
 Teste realizado após o Unit Testing, utilizando todas as unidades
individuais testáveis, realizados pelos desenvolvedores e
testadores
o System Testing
 Teste realizado para garantir o funcionamento do sistema baseado
nos requisitos, geralmente realizado quando o sistema está
pronto.
o UAT
 Teste realizado para verificar se o sistema está atendendo as
regras de negócios.

12. Verificação / Validação

 Verifica se o produto / projeto está sendo construído da maneira correta.


 Foco na documentação
 Verificação geralmente envolve Reviews, Walkthrougs e Inspections.

 Verifica se o produto / projeto está sendo construído da maneira correta.


 Começa quando a verificação é completada
 Foco no Software
 Validação tipicamente envolve Unit testing, integration, system testing e UAT
testing
 Vantagens
o Testes são realizados em cada uma fase
 Disvantagens
o Documentação Maior
o Investimento maior

13. QA vs QC

QA – Relata o processo
QC – Realiza o teste de software

QA – Foco em construir a qualidade


QC – Foco em testar a qualidade

QA – Previne os defeitos
QC – Detecta os defeitos

QA – Processo orientado (Se envolve em quase todos os processos)


QC – Produto orientado (Se envolve somente no teste do produto)

QA – Envolvido em todo ciclo de vida do software


QC – Envolvido somente na parte do teste do SDLC

QE  Quality engineering

Diferença entre:

Software Enginner SE  Escreve o código em função do software


Quality Enginner QE  Escreve o código em função da qualidade de software
 Escreve o código e o utiliza para testar o software

P – People (QC) TESTER


P – Processo (QA)
P – Produto

Processos do SDLC

 Requirement Analisys - QA
 Desing - QA
 Coding - QA
 Testing - QC
 Deploymenet - QA
 Maintainance – QA

Você também pode gostar