Resumo Livro BCTS: Capítulo 4 – Análise de Riscos

Capítulo 4 – Análise de Riscos


1.1. Definição de risco

Ao avaliar os riscos de um projeto, estamos buscando aqueles fatos cujas ocorrências poderão acarretar perdas para empresa. Nem sempre é possível aliar um risco a uma perda – um risco presente nem sempre vai gerar uma perda. Em resumo, podemos dizer que o risco é a possibilidade de ocorrência de uma perda para empresa.

Segundo o dicionário Houaiss, Risco é a “probabilidade de insucesso, de malogro de determinada coisa, em função de acontecimento eventual, incerto, cuja ocorrência não depende exclusivamente da vontade dos interessados.”

O que leva um risco a potencialmente se tornar uma perda é a ameaça de sua ocorrência.

As ameaças podem ser reduzidas através de mecanismos de controle. Controlar as ameaças é uma das maneiras de evitar sua ocorrência.

Quando os meios de controle são insuficientes ou inadequados para administrar a ocorrência de um risco, surgem então as vulnerabilidades.

Análise de riscos é o processo de avaliar os riscos, ameaças , controles e vulnerabilidades.

Conceito usados em gerenciamento de riscos

Risco O risco é uma perda em potencial para organização.

Análise de Riscos É uma avaliação dos recursos de informação de uma organização, seus controles e suas vulnerabilidades.

Ameaça Capacidade de alguém explorar a vulnerabilidade de um sistema de computador ou aplicação

Vulnerabilidade É uma falha no desenho, implementação ou operação que permite a concretização de uma ameaça.

Controle É uma maneira de tentar reduzir as causas dos riscos, evitando desse modo sua ocorrência ou, pelo menos reduzindo sua freqüência de ocorrência.

1.2. Riscos decorrentes da tecnologia da informação

O risco é, portanto, a materialização de uma ameaça. A análise de risco tenta identificar os riscos e medir seu nível de severidade. Desse modo, uma ameaça é a possível ocorrência de um evento que causa danos.

Os riscos presentes na área de tecnologia da informação podem ser gerados por ameaças físicas ou decorrentes da ação de pessoas.

O trabalho do audito de sistemas é procurar e identificar esses riscos, estimar sua severidade e montar processos de teste de auditoria para mapear os possíveis riscos derivados de sua ocorrência.

1.3. Riscos relativos ao teste de software

Em geral, os testadores tentam cobrir as partes mais importantes do software, aquelas nas quais se concentrarão os maiores riscos para o negócio. No Plano de Testes, esses riscos receberão os maiores níveis de prioridade.

Ao fazer a análise de riscos, devemos levar em conta o seguinte:

• A probabilidade de ocorrência do risco.

• O impacto e a perda associada a esse risco.

Esses dois pontos deverão ser levados em conta para definição da cobertura dos testes.

Podemos afirmar que o total de testes a ser executado está diretamente ligado ao total de riscos envolvidos.

1.4. Riscos do Processo de teste

Dentre os possíveis riscos para o processo de teste, a ser identificados pelo gerente de teste, destacamos:

• Orçamento; insuficiente para execução dos serviços de teste;
• Qualificação da equipe de teste; equipe sem treinamentos;
• Ambiente de teste; ambiente de teste mais próximo do ambiente de produção;
• Ferramentas; faltas de ferramentas necessárias para sucesso de um tipo de teste;
• Metodologias; falta de metodologia adequada e condizente com o desenvolvimento;
• Cronograma de recebimento de programas para teste e cronograma para devolução; Caso os prazos sejam exíguos. Negociar.
• Testware; ter metodologia para guardar a documentação de teste para uso futuro;
• Novas Tecnologias; uso de tecnologias não dominadas pela equipe de teste.

1.5. Determinação da magnitude dos riscos

O problema muitas vezes, consiste em determinar como classificar o risco e qual o custo de criação de um controle que evite a ocorrência desse risco. O controle de risco custa dinheiro, é necessário fazer uma análise de custo versus benefício para determinar se vale a pena investir em algum tipo de controle de risco.

Em resumo, quando se fala em risco, existe uma relação entre o custo da ocorrência do risco e o custo dos mecanismos de controle para evitar que o risco ocorra.

O QAI estabelece que um risco pode ser determinado por quatro maneiras, descritas a seguir:

• Intuição ou discernimento  Um técnico experiente da área de testes usa sua intuição, aliada a sua experiência para dizer que a ocorrência de um dado risco pode custar mais caro que os controles necessários para evitá-lo.

• Consenso; Trata-se de um consenso entre a equipe de que aquele risco te um nível elevado de severidade.

• Fórmula de risco; Existe dados financeiros que permitem medir o custo da perda pela ocorrência do risco.

• Estimativas de perdas anuais; Este caso é uma combinação do consenso com a fórmula de risco.

Outras definições de riscos e avaliação de riscos:

Avaliar Riscos: Avaliar os danos para o sucesso do negócio causados pelos defeitos não detectados antes da operação do software e que poderão ocorrer quando o software estiver sendo usado.

Risco: possibilidade de falha X prejuízo causado pela falha

1.6. Riscos baseados nas características de qualidade

O risco de ocorrência de defeitos é maior num software mal testado.

Considerando as características de qualidade da norma ISO 9126-1, podemos relacionar os seguintes testes.

• Funcionalidade; Teste de Funcionalidade;
• Confiabilidade; Teste de Estresse;
• Usabilidade; Teste de Usabilidade;
• Eficiência; Teste de Desempenho;
• Manutenibilidade; Teste Caixa-Branca, etc.
• Portabilidade; Teste de Produção, Alfa, etc.

1.6.1. Outros riscos do projeto de testes

• Ausência do cronograma detalhado do projeto de desenvolvimento;
• Datas finais dependentes da execução dos testes;
• Bases de testes não disponíveis nas datas programadas;
• Baixa qualidade da base de testes;
• Falta de métrica adequada para medir o sistema e o processo de teste;
• Disponibilidade de pessoal para testes;
• Crescimento do sistema;
• Disponibilidade do ambiente de teste.
Uma das maneiras de reduzir os riscos do software é testá-lo adequadamente.

1.7. Controle dos riscos

A melhor maneira de controlar um risco é tentar identificá-lo na análise de requisitos de negócio, no momento em que os requisitos de teste são criados, pois assim haverá tempo hábil para que algumas ações possam ser planejadas enquanto o projeto segue seu curso normal.

Duas abordagens que podemos usar são:

• Se aumentarmos o esforço de teste, a tendência será minimizar os riscos de ocorrência de defeitos.

• Tomar como base o Princípio de Pareto de que 20% do software é responsável por 80% de suas funcionalidades.

1.8. Gerenciamento dos riscos dos projetos – Conforme PMBOK

Segundo o PMI, o gerenciamento de risco é um processo sistemático de identificar e analisar os riscos do projeto, bem como responder a eles.

Fluxo de atividades do gerenciamento de riscos.

O modelo PMI divide o gerenciamento de Riscos nos seguintes processos:

• Planejamento do Gerenciamento de Riscos;
• Identificação dos Riscos;
• Análise Qualitativa dos Riscos;
• Análise Quantitativa dos Riscos;
• Planejamento de Resposta a Riscos;
• Controle e Monitoração de Riscos.

O PMI acrescenta uma terminologia que não havíamos abordado anteriormente, pois, segundo o instituto, os riscos podem ser tanto ameaças ao sucesso do projeto quanto oportunidades de implementar melhorias.

1.8.1. Identificação dos riscos

Consiste em listar todos os riscos do projeto de teste. Pode ser:

• Através de reuniões com os técnicos envolvidos no projeto;
• Listas de riscos publicadas;
• Base de informações de projetos anteriores.

1.8.2. Análise de riscos

De acordo com o PMI os riscos devem ser analisados qualitativa e quantitativamente.

A análise qualitativa dos riscos é feita com base na definição da probabilidade de ocorrência do risco e de sua severidade.

Muitas vezes a análise quantitativa PE realizada em conjunto com análise qualitativa. O objetivo da análise qualitativa é analisar numericamente a probabilidade de cada risco, de modo que seja possível, depois definir seu tratamento. Essa análise é feita dentro do contexto global do projeto.

1.8.3. Planejamento dos riscos

O planejamento dos riscos envolve a escolha dos planos para responder aos riscos. É realizado de acordo com o caminho de melhor custo-benefício.

Os seguintes planos devem ser elaborados:

• Plano de Mitigação;

• Plano de Contingência.

1.8.4. Controle e monitoração dos riscos

Controlar e monitorar riscos é acompanhar a evolução dos riscos no desenvolvimento dos projetos, o que envolve a avaliação permanente dos riscos e, caso algum já tenha ocorrido, como funcionou a resposta atribuída a sua ocorrência.

Veja também:

• Resumo livro BCTS: Capítulo 2 – Processo de teste;

Abraços e até o próximo post, onde estaremos falando de Planejamento.

Resumo livro BCTS: Capítulo 2 – Processo de teste

Capítulo 2 – Processo de teste


1.1. Ciclo de vida de desenvolvimento de software (CVDS)

O CVDS é formado pelas seguintes fases:

• Estudo preliminar;

• Análise de requisitos; Também nesta fase são levantadas as primeiras informações necessárias para a realização dos testes, tais como as regras para testar os requisitos e os pré-requisitos que permitem tal realização. Inclui-se ainda o Plano de Teste, que contempla o planejamento das principais atividades de teste, bem como recursos e os prazos para realizá-los.

• Desenho do sistema;

• Construção; Nos programas preparados, devem ser aplicados os testes unitários conforme os planos de teste e os casos de teste preparados.

• Implantação; Nesta fase são efetuados os testes de integração e sistema. Finalmente o sistema deve ser aceito pelo usuário ou cliente.

• Operação.

1.2. Conceito “V” de teste

O ciclo de vida de testes pressupõe que sejam realizados testes ao longo de todo o processo de desenvolvimento.

Os ciclos de vida de testes e de desenvolvimento são totalmente interdependentes, mas o ciclo de teste é dependente da conclusão dos produtos das atividades de desenvolvimento.

As atividades do ciclo de vida de teste devem ser realizadas por um grupo formalmente definido para tal. Esse grupo pode ser :

• Interno; formado por profissionais pertencentes ao projeto ou por uma área especial para as atividades de teste.

• Externo; Formado por profissionais especializados em teste de uma empresa externa.

No conceito de ciclo de vida de testes, os processos de desenvolvimento e teste têm início simultaneamente: a equipe que desenvolve o sistema inicia o processo de desenvolvimento do sistema, e a equipe que está conduzindo os testes começa o planejamento do processo de teste.

A equipe de teste usa os mesmos requisitos com o propósito de testar o sistema.

No conceito “V” de teste, os processos de FAZER e CONFERIR convergem do início até fim do projeto. O grupo que FAZ trabalha com o objetivo de implementar o sistema, e a equipe que CONFERE, simultaneamente, executa procedimentos de teste visando minimizar ou eliminar riscos.

1.3. Processo de teste de software

Baseado no conceito “V” de teste, o processo de teste de software tem como atividades de testes, onze passos a serem realizados paralelamente às atividades do desenvolvimento. Os primeiros cinco passos usam técnicas de verificação como principal meio de avaliar a correção dos produtos do desenvolvimento de software. Os outros passos usam técnicas de validação para testar o software durante as atividades que vão desde construção até a implantação. A verificação e validação devem ser usadas para o desenvolvimento e a manutenção de software.

Os passos do processo de teste são:

• Acesso ao Plano de Desenvolvimento; Pré-requisito para a construção do Plano de Teste.

• Desenvolvimento do Plano de Teste; A preparação do Plano de Teste deve seguir os mesmos padrões da preparação do plano de desenvolvimento.

• Inspeção ou teste dos requisitos do software; Avaliação dos requisitos do software por meio do uso de técnicas de verificação.

• Inspeção ou teste de desenho do software; Avaliação do desenho – interno ou externo – do software através do uso de técnicas de verificação.

• Inspeção ou teste da construção do software;

• Execução dos testes; Envolve testar o código em estado dinâmico.

• Teste de aceitação; Avaliação da aplicabilidade e usabilidade do software pelos usuários.

• Informação dos resultados dos testes; informação dos defeitos, etc.

• Teste de instalação do software; Visa verificar a interoperabilidade com o sistema operacional, etc.

• Teste de mudança no software; Cobre mudanças que ocorrem em todo processo de desenvolvimento e as que vão ocorrer após a implantação do software.

• Avaliação da eficácia dos testes; Responsável pelas melhorias no processo de teste.

1.4. Ciclo de vida do processo de teste

O ciclo de vida do processo de teste abordado é composto por diversas etapas ou fases, sendo quatro delas seqüenciais ou em cascata e duas paralelas. Este modelo é baseado na metodologia TMap. Este modelo é conhecido como Modelo 3PX3E.

• Procedimentos Iniciais;
• Planejamento;
• Preparação;
• Especificação;
• Execução e
• Entrega.

1.4.1. Procedimentos iniciais

Nesta etapa deverá ser aprofundado um estudo dos requisitos do negócio que dará origem ao sistema de informação a ser testado, de modo a garantir que o mesmo esteja completo e sem nenhuma ambigüidade. No final desta etapa é elaborado o GOT – Guia Operacional de Teste.

1.4.2. Planejamento

Consiste em elaborar a Estratégia de Teste e o Plano de Teste a ser utilizados de modo a minimizar os principais riscos do negócio e fornecer os caminhos para as próximas etapas.

A atividade de planejamento deve permanecer até a conclusão do projeto.

1.4.3. Preparação

Nesta etapa, o objetivo básico é preparar o ambiente de teste (equipamentos, pessoal, ferramentas de automação, hardware e software), para que os testes sejam executados corretamente.

A atividade de preparação deve permanecer até a conclusão do projeto.

1.4.4. Especificação

Os objetivos básicos desta etapa são:

• Elaborar/revisar casos de teste;

• Elaborar/revisar roteiros de test.

Os casos de teste e os roteiros de teste devem ser elaborados dinamicamente durante o decorrer do projeto de teste.

1.4.5. Execução

Os testes deverão ser executados de acordo com os casos de teste e os roteiros de teste.

Devem ser usados scripts de teste, caso seja empregada alguma ferramenta de automação de testes.

1.4.6. Entrega

Nesta etapa o projeto de teste é finalizado.

1.5. Técnicas de teste

1.5.1. Teste Estrutural versus Teste funcional

Teste Funcional; Os testes funcionais do sistema são desenhados para garantir que os requisitos e as especificações do sistema tenham sido atendidos.

Teste Estrutural; Garante que os softwares e os programas sejam estruturalmente sólidos e que funcionem no contexto técnico onde serão instalados. Isto implica (1) testar a robustez e o funcionamento da estrutura do programa; (2) testar o funcionamento de todos os aspectos da estrutura em toda a sua extensão.

As técnicas para esse tipo de teste são desenhadas não para garantir que o sistema seja funcionalmente correto, e sim para que ele seja estruturalmente robusto.

Técnicas de Teste Funcional

Testes de Requisitos;
Testes de Regressão;
Testes de Tratamento de Erros;
Testes de Suporte Manual;
Testes de interconexão com outros softwares;
Testes de Controle;
Testes Paralelos;

Técnicas de Teste Estrutural

Testes de Estresse;
Testes de Execução;
Testes de Recuperação (contingência);
Testes de Operação;
Testes de Conformidade;
Testes de Segurança;

1.5.1.1. Técnicas de Teste Estrutural

Teste de Estresse

O objetivo desse teste é avaliar o comportamento do software sob condições críticas, tais como restrições significativas de memória, de área de disco e de CPU. Os testes de estresse visam também identificar o comportamento do software quando submetido a variados volumes de dados e acima das médias esperadas.

Nos testes de estresse, o sistema deve ser executado como seria de fato executado no ambiente de produção.

Os testes de estresse são empregados quando existe incerteza quanto à quantidade ou ao volume de trabalho que a aplicação pode tratar sem falhas.

Testes de Execução

Os testes de execução são desenhados para avaliar o comportamento do sistema no ambiente de produção e verificar se são atendidas as premissas de desempenho estabelecidas.

O teste de execução é empregado para determinar se o sistema pode atingir os critérios de desempenho específicos.

• Determinar o desempenho da estrutura do sistema;

• Verificar o nível de utilização do hardware e software;

• Determinar o tempo de resposta das transações on-line;

• Determinar o tempo de processamento das transações.

Os testes de execução devem ser empregados no início do processo de desemvolvimento.

Testes de Recuperação (Contingência)

A recuperação é a capacidade de reiniciar operações após a perda da integridade de uma aplicação.

O teste de recuperação não só verifica o processo de recuperação como também a eficácia das partes componentes do processo.

• Manter backup dos dados;

• Armazenar os dados do backup em local seguro;

• Documentar os procedimentos de recuperação;

• Etc.

Testes de Operação

Os testes de operação são desenhados principalmente para estabelecer se o sistema é executável durante a operação normal. Os objetivos são:

• Determinar se a documentação da operação está completa;

• Avaliar se o treinamento dos operadores está completo;

• Garantir que mecanismos de suporte foram preparados e funcionam de modo adequado. Ex: Scheduling.

• Etc.

Testes de Conformidade

Os testes de conformidade verificam se a aplicação foi desenvolvida de acordo com os padrões, procedimentos e guias de TI. Pode ser mais importante executar testes de conformidade durante a fase de requisitos.

Os testes de conformidade são realizados para garantir a conformidade com as metodologias e encorajar e auxiliar os profissionais de TI a adotá-las. Os objetivos são:

• Verificar se as metodologias de desenvolvimento de software e de manutenção são seguidas;

• Garantir a conformidade aos padrões, procedimentos e guias de TI;

• Avaliar se a documentação do sistema de aplicação é racional e está completa.

Teste de Segurança

São um processo necessário para garantir a confidencialidade das informações e a proteção dos dados contra acesso indevido de terceiros.

Os testes de segurança são desenhados com o intuído de avaliar a adequação dos procedimentos de proteção e contramedidas projetadas.

Os testes de segurança visam descobrir defeitos muito difíceis de identificar.

Entre os objetivos temos:

• Determinar se foi dada atenção adequada á identificação de riscos de segurança;

• Determinar se foi preparada uma definição de regras de acesso e se estas foram implementadas de acordo com as regras;

• Etc.

Os testes de segurança podem ser divididos em segurança física e lógica. A física trata da invasão por pessoas não autorizadas, ao passo que a lógica trata do uso dos recursos computacionais e de comunicações para acessar indevidamente as informações.

Os testes de segurança devem ser empregados quando a informação e/ou o ativo protegido pelo sistema de aplicação são de valor significativo para a organização e realizados antes e depois de o sistema ser passado para a produção.

1.5.1.2. Técnicas de Testes Funcionais

Testes de Requisitos

Os testes de requisitos visam verificar se o sistema executa corretamente as funcionalidades e se é capaz de sustentar essa correção após sua utilização por um período de tempo contínuo.

Os objetivos dos testes consistem em verificar se:

• Os requisitos dos usuários estão implementados;

• A correção é mantida por períodos prolongados de tempo;

• O processamento da aplicação está em conformidade com as políticas e os procedimentos da organização.

Os testes de requisitos são realizados basicamente através da criação de condições de testes e checklists de funcionalidades. Recomenda-se que as condições de teste sejam derivadas diretamente dos requisitos.

Teste de Regressão

Os testes de regressão voltam a testar segmentos já testados após a implementação de uma mudança em outra parte do software.

Sempre que mudanças são efetuadas num segmento de código, problemas podem ocorrer em outros segmentos já testados. Desse modo, entre os objetivos dos testes de regressão temos:

• Determinar se a documentação do sistema permanece atual;

• Determinar se os dados e as condições de teste permanecem atuais;

• Determinar se as funções previamente testadas continuam funcionando corretamente após a introdução de mudanças no sistema.

O teste de regressão deve ser executado sempre que o software sofre uma alteração.

Os testes de regressão são empregados quando é muito alto os riscos de novas mudanças afetarem áreas não alteradas da aplicação.

Teste de Tratamento de Erros

Os testes de tratamento de erros determinam a capacidade do sistema de tratar apropriadamente transações incorretas.

Os objetivos específicos são:

• Determinar se todas as condições de erro esperadas são reconhecidas pelo sistema;

• Determinar se foi atribuída responsabilidade para processar os erros identificados;

• Determinar se é mantido um controle sobre os erros durante o processo de correção.

Um ótimo método para desenvolver testes de tratamento de erros é realizar um brainstorm com pessoas de Ti, da área usuária e de auditoria, procurando identificar o que pode dar errado no sistema.

Teste de Suporte Manual

• Verificar se os procedimentos de suporte manual estão documentados e completos;

• Determinar se as responsabilidades pelo suporte manual foram estabelecidas;

• Determinar se o suporte manual e o segmento automatizado estão interligados apropriadamente;

Os testes manuais envolvem a avaliação da adequação do processo e, sua execução que pode ser feita juntamente com o teste normal do sistema.

Testes de Interconexão

Estes testes são desenhados para garantir que a interconexão entre software de aplicação funcione corretamente. Entre os objetivos temos:

• Determinar se os parâmetros e dados são transferidos corretamente entre os softwares;

• Garantir o momento certo de execução e a existência de coordenação das funções entre os softwares;

• Determinar se a documentação pertinente é correta e completa.

Testes de Controle

Os testes de controle é a ferramenta de gestão necessária para assegurar que o processamento seja realizado conforme sua intenção. Os objetivos são garantir que:

• Os dados estejam completos e corretos;

• As transações sejam autorizadas;

• A manutenção das informações de trilha de auditoria seja realizada;

• Os processamentos sejam eficientes, eficazes e econômicos;

• O processamento atenda às necessidades dos usuários.

O teste de controle pode ser considerado um sistema dentro do outro.

Testes Paralelos

O teste paralelo serve para determinar se os resultados de um novo software de aplicação são consistentes com o processamento do antigo sistema ou da antiga versão do sistema.

Objetivos:

• Assegurar que a nova versão do software de aplicação execute corretamente;

• Demonstrar consistências e inconsistências entre duas versões do mesmo software de aplicação.

1.5.2. Atributos de qualidade

Os atributos de qualidade a serem atendidos devem também fazer parte do Plano de Teste.

1.5.2.1. Procedimentos para identificar a importância dos fatores de qualidade

Existem diversas técnicas para identificar os fatores de qualidade do software. Sugerimos que sejam seguidos os passos adiante:

• Considerar as características básicas da aplicação;

• Considerar as implicações no ciclo de vida;

• Realizar uma avaliação de custo versus benefício da lista de fatores de qualidade;

• Identificar os fatores de qualidade mais importantes;

• Fornecer explicações para as escolhas.

Fatores de qualidade:

• Correção; satisfaz as especificações e atende aos objetivos do usuário;

• Confiabilidade; executa as funções programadas com a precisão requerida;

• Eficiência; A quantidade de recursos computacionais e de dados para executar uma função.

• Integridade; o acesso ao software ou aos dados por pessoa autorizada pode ser controlada;

• Usabilidade; esforço requerido para aprender e operar o sistema;

• Manutenibilidade; esforço requerido para localizar e corrigir um erro;

• Testabilidade; esforço requerido para testar um programa;

• Flexibilidade; esforço requerido para modificar um programa;

• Reusabilidade; um programa pode ser usado em outra aplicação;

• Interoperabilidade; esforço requerido para juntar um sistema com outro;

• Portabilidade; facilidade do software operar em vários ambientes.

Os fatores de qualidade não devem ser confundidos com as características ou subcaracterísticas de qualidade da norma ISO 9126-1. Aqui trata-se apenas de uma abordagem didática.

1.5.3. Garantia da qualidade versus Controle da qualidade

Métodos de qualidade podem ser segmentados em duas categorias: métodos preventivos e métodos de detecção. Essa distinção é o mecanismo usado para diferenciar atividades de garantia da qualidade das atividades de controle da qualidade.

• Garantia da qualidade; A garantia da qualidade é um conjunto sistemático e planejado de atividades, necessárias para proporcionar a confiança adequada de que produtos e serviços estarão em conformidade com requisitos especificados e atenderão às necessidades do usuário.

• Controle de qualidade; O controle de qualidade é um processo pelo qual a qualidade do produto é comparada com os padrões aplicáveis; quando uma não-conformidade é detectada, são tomadas as devidas providências.

Tanto a garantia da qualidade quanto o controle da qualidade se distinguem da função de auditoria interna. A auditoria interna é uma atividade independente dentro da organização, tem o propósito de revisar as operações e é uma tarefa de gerenciamento.

A qualidade tem duas definições de trabalho:

• Do ponto de vista do produtor, a qualidade é o comprimento de requisitos.

• Do ponto de vista do consumidos, é o atendimento às necessidades do cliente.

Na visão do CMMI, o propósito da Garantia da Qualidade de Software (GQS) é fornecer ao gerenciamento a visibilidade da eficácia, no sentido de produzir um software de qualidade. A GQS envolve rever e auditar partes do produto, de maneira a verificar se estão de acordo com os padrões definidos e fornecer os resultados dessas revisões para os implicados no processo.

A garantia da qualidade é uma atividade que estabelece e avalia o processo que gera os produtos. Caso não exista processo, não há razão para a garantia da qualidade.

As atividades de controle da qualidade se concentram na identificação de defeitos em produtos. Essas atividades começam no início do processo de desenvolvimento do software, com revisão dos requisitos, e continuam até que o teste do aplicativo esteja completo e o sistema esteja implementado.

• O controle da qualidade

o Está relacionado a um produto ou serviço específico;
o Verifica se um produto ou serviço específico tem um atributo específico;
o Identifica defeitos com o propósito principal de corrigi-los;
o É responsabilidade da equipe/do funcionário.

• A garantia da qualidade

o Ajuda a estabelecer processos;
o Determina programas de medida para avaliar processos;
o Identifica fraquezas em processos e os aperfeiçoa;
o É uma responsabilidade de gerenciamento;
o Está relacionada com todos os produtos que serão gerados por um processo;
o Avalia se o controle da qualidade está funcionando.


FURPS

Uma metodologia muito usada no mercado é a FURPS. Uma metodologia que faz parte do RUP.

• Funcionalidade (Functionality);
• Usabilidade (Usability);
• Confiabilidade (Reability);
• Desempenho (Performance);
• Suportabilidade (Suportability).

Funcionalidade

Para atender a categoria da funcionalidade, o software em teste tem de estar de acordo com a especificação funcional.

Testes que podem ser aplicados:

• Teste funcional;
• Teste de regressão (smoke test);
• Teste de volume;
• Teste de segurança.

Usabilidade

Representa a facilidade de uso do sistema pelos usuários.

Testes que podem ser aplicados:

• Teste de interface;
• Teste de usabilidade.

Confiabilidade

Garante a confiabilidade do sistema, a permanência de operação, a integridade dos dados, a confiabilidade da estrutura de dados e também da aplicação.

Testes que podem ser aplicados:

• Teste de integridade;
• Teste de estrutura;
• Teste de estresse;
• Smoke teste.

Desempenho

Garante a velocidade de processamento da informação.

Testes que podem ser aplicados:

• Teste de avaliação de desempenho ou benchmark;
• Teste de contenção;
• Teste de carga;
• Perfil de desempenho.

Suportabilidade

Representa a capacidade do programa de funcionar em diversos ambientes diferentes.

Testes que podem ser aplicados:

• Teste de configuração;
• Teste de instalação.


Mesmo que não pareça... hehehe este foi o resumo para o capítulo 2.
Até o próximo post.!!!

Resumo de Capítulos do livro: Base de Conhecimento em Teste de Software

Olá Pessoal!

Todos sabemos que a principal referência para prova de certificação da ALATS - CBTS - é o livro Base de Conhecimento em Teste de Software, escrito por Emerson Rios, Ricardo Cristalli, Aderson Bastos e T. Moreira .

Para me auxiliar nos estudos e preparação para prova, resumi alguns capítulos que julguei interessante.

Gostaria de deixar claro que, antes mesmo de resumir tais capítulos, eu já havia lido todo o livro algumas vezes e os resumos foram feitos com o objetivo a dar foco em pontos que julguei importantes sobre os capítulos escolhidos. No entanto, não aconselho à aqueles que pretendem fazer a prova em novembro se basearem simplesmente nos resumos. Aconselho leituras de todo o livro para que se tenha conhecimentos gerais do assunto tratado em cada capítulo.

Os resumos a serem publicados serão dos seguintes capítulos:

Capítulo 2 – Processo de teste;
Capítulo 4 – Análise de Riscos;
Capítulo 5 – Planejamento dos Testes;
Capítulo 7 – Execução dos testes;
Capítulo 8 – Gestão de Defeitos;
Capítulo 11 – Estimativas.

Abraços e até o próximo post.