BSTQB - Certified Tester CTFL Foundation Level

BSTQB - Certified Tester CTFL Foundation Level

1. termos

   • estória do usuário
     • uma Estória de usuário (User Stories) é uma especificação de uma ou mais sentenças na linguagem de negócio que siguinifica: usuário final ou usuário do sistema que captura o que um usuário faz ou necessita fazer como parte de sua função de trabalho.
   • elicitação de requisitos
     • Na elicitação de requisitos são percebidas as necessidades do sistema e as características que esse sistema deve ter
   • Testware
     • Testware é uma ferramenta para automação de testes de caixa preta, que visa auxiliar na definição de casos de teste e sua execução.
   • Syllabus
   • paradox do pesticida
     • Se os mesmos testes forem repetidos várias vezes, esses testes não encontrarão novos defeitos. Para detectar novos defeitos, os testes existentes e os dados de teste podem precisar ser alterados e novos testes precisam ser gravados. (Testes não são mais eficazes em encontrar defeitos, assim como pesticidas não são mais eficazes em matar insetos depois de um tempo.)
   • A Regra 10 de Myers
     • A Regra 10 de Myers, foi criada por Glenford Myers, um dos pioneiros na área em testes de software, esta regra estabelece que o custo da correção de defeitos é bem mais custoso quanto mais tarde o defeito é encontrado.
   • qualidade
     • é o grau até o qual um componente,sistema ou processo atende aos requisitos especificados e as necessidades e expectativas do usuário ou consumidor
   • confiabilidade
     • é a probabilidade de que o software não causará uma falha no sistema por um tempo especificado,sob condição determinada
   • gestão de qualidade
     • garantia de qualidade
       • quando todas as atividades da gestão são realizadas
     • inclui todas as ativdades que direciona e controão uma organização em relação a qualidade
   • shift-left
     • refere-se ao teste inicial
   • suite de testes
     • Uma suíte de testes é uma coleção de casos de teste ou specs destinados a testar um programa para verificar um determinado comportamento

2. erro

   • defeito
     • falhas
       • efeito
       • sistema para de funcionar
       • tudo o que for observado pelo usuário como diferente do resultado esperado
       • obs
         • Além das falhas causadas devido a defeitos no código, falhas também podem ser causadas por condições ambientais. Por exemplo, radiação, campos eletromagnéticos e poluição
           • um software pode conter defeitos,mas mesmo assim nunca falahar
     • exemplo: entrada indevida
     • tem
       • causa raiz
         • As causas-raiz dos defeitos são as primeiras ações ou condições que contribuíram para a criação dos defeitos. Os defeitos podem ser analisados para identificar suas causas-raiz, de modo a reduzir a ocorrência de defeitos similares no futuro.
           • Ao realçar as causas-raiz mais significativas, a análise de causa-raiz pode levar à melhorias de processo que evitam a introdução de um número significativo de defeitos futuros.
             • Um pequeno número de módulos geralmente contém a maioria dos defeitos descobertos durante o teste de pré-lançamento ou é responsável pela maioria das falhas operacionais. Agrupamento de defeitos previstos e os agrupamentos de defeitos observados reais em teste ou produção, são uma entrada importante em uma análise de risco usada para focar o esforço de teste
     • manifestação de um erro no software
   • exemplo: quando feito o código permitiu a entradas de dados indevidos pelo usuário
   • ação humana em qualquer fase do desenvolvimento de software

3. O BSTQB é o representante oficial do ISTQB no Brasil. É uma entidade sem fins lucrativos responsável pela aplicação do exame para a certificação em Teste de Software.

4. teste

   • detalhes
     • detecção
       • falsos negativos
         • a falsos negativos. Falsos negativos são testes que não detectam defeitos que deveriam ser detectados;
       • falsos positivos
         • falsos positivos são relatados como defeitos, mas na verdade não são defeitos.
     • contexto
       • O teste é feito de forma diferente em diferentes contextos. Por exemplo, o software de controle industrial de segurança crítica é testado de forma diferente de um aplicativo móvel de comércio eletrônico. Como outro exemplo, o teste em um projeto ágil é feito de forma diferente do que o teste em um projeto de ciclo de vida sequencial
     • critérios de cobertura
       • Os critérios de cobertura podem atuar efetivamente como indicadores-chave de desempenho (KPIs) para conduzir as atividades que demonstram a realização dos objetivos de teste de software
     • objetivo
       • testes podem possuir diferentes tipos de erros
         • •encontrar defeitos/erros •previnir defeitos/erros •ganho de confiança sobre o nível de qualidade e prover informações
     • responsabilidade
       • teste
         • encontrar defeito
       • depuração
         • encontrar a causa raiz e corrigir
     • técnicas de teste
       • https://www.youtube.com/watch?v=QyXN_zAhqJA
       • caixa preta|comportamentais|baseadas no comportamento
         • sem acesso ao código
           • As técnicas de teste caixa-preta se concentram nas entradas e saídas do objeto de teste sem referência a sua estrutura interna.
         • Particionamento de equivalência
           • https://www.youtube.com/watch?v=8lHosehtIaY
           • O particionamento de equivalência divide os dados em partições (também conhecidas como classes de equivalência), de tal forma que todos os membros de uma determinada partição devem ser processados da mesma maneira
           • validos
             • são valores que devem ser aceitos pelo componente ou sistema. Uma partição de equivalência contendo este tipo de valores é chamada de "partição de equivalência válida".
           • invalidos
             • Valores inválidos são valores que devem ser rejeitados pelo componente ou sistema. Uma partição de equivalência contendo estes valores é chamada de "partição de equivalência inválida".
             • muito alto
             • muito baixa
           • As partições podem ser identificadas para qualquer elemento de dados relacionado ao objeto de teste, incluindo entradas, saídas, valores internos, valores relacionados a tempo (p.e., antes ou depois de um evento) e para parâmetros de interface (p.e., componentes integrados sendo testados durante o teste de integração).
           • analise de valor limite
             • https://pt.wikipedia.org/wiki/An%C3%A1lise_do_valor_limite
             • A análise de valor limite é uma extensão do particionamento de equivalência, mas só pode ser usada quando a partição é ordenada, consistindo em dados numéricos ou sequenciais. Os valores mínimo e máximo (ou primeiro e último valores) de uma partição são seus valores limites
         • teste tabela de decisão
           • Técnicas de teste combinatórias são úteis para testar a implementação de requisitos do sistema que especificam como diferentes condições de combinações levam à resultados diferentes. Uma abordagem para esse teste é o teste de tabela de decisão.
           • regra de decisão
             • define o conjunto de ações a ser tomado, a partir de um conjunto de condições.
             • uma área de condições
               • de são relacionadas as condições que devem ser verificadas para que seja executado um conjunto de ações;
             • uma área de ações
               • que exibe o conjunto de ações que deve ser executado caso um determinado conjunto de condições ocorra;
             • regras de decisão
               • representadas pelas colunas, que apresentam a combinação das condições com as ações a serem executadas.
         • Teste de transição de estado
           • Uma tabela de transição de estado mostra todas as transições válidas e potencialmente inválidas entre estados, bem como os eventos, condições de proteção e ações resultantes para transições válidas. Os diagramas de transição de estado normalmente mostram apenas as transições válidas e excluem as transições inválidas.
         • caso de uso
           • Os testes são projetados para exercitar os comportamentos definidos (básico, excepcional ou alternativo e tratamento de erros). A cobertura pode ser medida pela porcentagem de comportamentos de casos de uso testados dividida pelo número total de comportamentos de casos de uso, normalmente expressos como uma porcentagem.
       • caixa branca|técnicas estruturais|baseadas na estrutura)
         • com acesso ao código
           • são baseadas em uma análise da arquitetura, do detalhamento do projeto, da estrutura interna ou o código do objeto de teste
         • verificação do fluxo de dados
           • instruções
             • Esta técnica testa as decisões existentes no código e o código executado com base nos resultados da decisão.
               • Para fazer isso, os casos de teste seguem os fluxos de controle que ocorrem de um ponto de decisão (p.e., para uma instrução IF, um para o resultado verdadeiro e outro para o resultado falso; para uma instrução CASE, os casos de teste seriam necessários para todos os possíveis resultados, incluindo o resultado padrão
           • Teste de decisão
             • mede em termos de quantidade de colunas das tabelas que foram devidamente testadas
       • Técnicas de teste baseadas na experiência
         • Suposição de erro
         • Teste exploratório
         • Teste baseado em lista de verificação
           • Em testes baseados em listas de verificação, os testadores modelam, implementam e executam testes para cobrir as condições de teste encontradas em uma lista de verificação.
         • os casos de teste são derivados da habilidade e intuição do testador e de sua experiência com aplicativos e tecnologias semelhantes.
       • O objetivo de uma técnica de teste é ajudar a identificar as condições de teste, os casos de teste e os dados de teste.
     • requisitos
       • funcionais
         • Os requisitos funcionais correspondem a tudo o que o sistema deverá fazer. Em outras palavras, chamamos de requisitos funcionais o conjunto de funções do sistema.
       • não funcionais
         • requisitos não funcionais são aqueles relativos ao uso do sistema, ao desempenho, à segurança e à disponibilidade, além de outros não ligados às funcionalidades do sistema diretamente.
     • tipos de teste
       • teste de integração
         • Os testes de integração de componentes e os testes de integração de sistemas devem se concentrar na própria integração. Por exemplo, se integrar o módulo A com o módulo B, os testes devem focar na comunicação entre ambos e não na funcionalidade dos módulos individualmente
       • teste de aceite
         • O teste de aceite pode produzir informações para avaliar a situação do sistema para implantação e uso pelo cliente (usuário final). Os defeitos podem ser encontrados durante o teste de aceite, mas encontrar defeitos muitas vezes não é um objetivo, e encontrar um número significativo de defeitos durante o teste de aceite pode, em alguns casos, ser considerado um grande risco de projeto.
       • teste caixa branca
         • A modelagem e a execução do teste caixa-branca podem envolver habilidades ou conhecimentos especiais, como a maneira como o código é construído (p.e., usar ferramentas de cobertura de código), como os dados são armazenados (p.e., avaliar possíveis consultas de banco de dados) e como usar ferramentas de cobertura interpretando corretamente seus resultados.
       • testes funcionais
         • teste funcional
           • O teste funcional de um sistema envolve testes que avaliam as funções que o sistema deve executar.
         • teste não funcional
           • Os testes não funcionais de um sistema avaliam as características de sistemas e de softwares, como usabilidade, eficiência de desempenho ou segurança.
       • teste de mudanças
         • reteste
           • teste que executa casos de teste reprovados durante sua última execução
         • teste de regreção
           • teste realizado em partes do software que não sofreram alterações,mas que podem ter sofrido impacto negativos apos algumas modificações feitas em outras regiões do software
       • teste de manutenção
         • Modificação
           • como aprimoramentos planejados (p.e., baseados em versão), alterações corretivas e emergenciais, alterações no ambiente operacional (como sistema operacional ou atualizações de banco de dados),
         • migração
           • como de uma plataforma para outra, que pode exigir testes operacionais do novo ambiente, bem como do software alterado, ou testes de conversão de dados quando os dados de outro aplicativo serão migrados para o sistema que está sendo mantido.
             • Quando um aplicativo ou sistema é retirado, isso pode exigir o teste de migração ou arquivamento de dados.
         • Aposentadoria:
           • como quando um aplicativo atinge o fim de sua vida útil.
   • obs
     • por que é importante?
       • O teste reduz a probabilidade de defeitos não descobertos permanecerem no software, mas, mesmo se nenhum defeito for encontrado, o teste não é uma prova de correção.
     • é bom não encontrar nenhum erro/falha?
       • na maioria das vezes não,porque provavelmente isso significa q o teste é fraco ou,q o teste é fraco e o software também,mas tem uma pequena chance do software ser realmente muito bom e não apresentar erros/falhas
     • modelos de desenvolvimento de software podem se misturar
       • os próprios modelos de ciclo de vida de desenvolvimento de software podem ser combinados. Por exemplo, um Modelo V pode ser usado para o desenvolvimento e teste dos sistemas de apoio e suas integrações, enquanto um modelo de desenvolvimento Ágil pode ser usado para desenvolver e testar a interface do usuário e a funcionalidade.
     • perguntas básicas para escolher o modelo correto
       • Todas as informações estão disponíveis?
       • Há risco de mudanças nos requisitos durante o desenvolvimento?
       • É necessário mostrar alguma coisa pronta ao cliente em um curto espaço de tempo?
       • Existem pessoas experientes na equipe para trabalhar em várias frentes de desenvolvimento paralelo?
   • teste é o processo que consiste em todas as atividade do ciclo de vida,tanto estáticas quanto dinâmicas. voltadas para o planejamento,preparação e avaliação de produtos de software e produtos de trabalho relacionados a fim de determinar se elas satisfazem os requisitos especificados e demonstrar que estão aptas para sua finalidade e para a detecção de defeitos
   • abordagens
     • micro
       • como definir o que testar?
         • fazendo teste por prioridade e estabelecendo o nível de risco do projeto
           • Os objetivos do teste podem variar, dependendo do contexto do componente ou sistema que está sendo testado, do nível de teste e do modelo de ciclo de vida de desenvolvimento de software. Essas diferenças podem incluir, por exemplo:
             • Durante o teste de aceite, um objetivo pode ser confirmar que o sistema funciona como esperado e satisfaz os requisitos. Outro objetivo deste teste pode ser fornecer informações às partes interessadas sobre o risco de liberar o sistema em um determinado momento pelo risco de erros que podem acarretar em um desgaste na imagem da empresa/produto ou mesmo risco de poder gerar uma morte (projetos de alto risco).
       • modelos de busca de erros
         • modelo genérico
           • não faz o que não deve fazer faz o que deve fazer
             • modelo incorreto
         • modelo de Myers
           • faz o que não deve fazer não faz o que deve fazer
             • modelo correto
       • característica dos testes
         • tipo de estado do testes
           • dinâmico
             • inclui atividade de planejamento,execução e controle do teste e necessita que o software seja executado
               • é o mais utilizado pelas empresas de desenvolvimento de softwares
             • dinâmico mais caro do que estático e mais trabalhoso em por em pratica
           • estático
             • inclui atividades de revisão,inspeção e análise estática do código de forma a corrigir: Práticas ruins; Erros de sintaxe; Falhas de segurança.
               • revisão e inspeção podem ser realizadas em qualquer documentação do projeto e também no código-fonte durante a etapa de construção do software
                 • Uma das principais distinções é que o teste estático encontra os defeitos diretamente em produtos de trabalho, em vez de identificar as falhas causadas por defeitos quando o software é executado.
         • nível de teste
           • unitário/componente/módulo
             • testa os componentes/módulos do sistema de forma individual
               • requer acesso ao código
                 • usa ambiente de desenvolvimento
                   • executado pelo desenvolvedor que escreveu o código, mas obrigatoriamente requer acesso ao código que está sendo testado.
                   • Teste de unidade identifica erros de lógica e de implementação em cada módulo do software, separadamente.
             • integração
               • testa de integração é a fase do teste de software em que módulos são combinados e testados em grupo.
                 • geralmente é automatizado
                   • usa ambiente de teste
               • sistema
                 • O teste de sistema é uma fase do processo de teste de software e de hardware em que o sistema já completamente integrado é verificado quanto a seus requisitos num ambiente de produção.
                 • aceitação
                   • Tem por função verificar o sistema em relação aos seus requisitos originais, e às necessidades atuais do usuário.
           • O ambiente de testes deve ser definido pelo nível de testes a ser executado, ou seja, quanto maior o nível, mas, o ambiente de teste deverá ser capaz de reproduzir as características do ambiente de produção.
     • macro
       • modelo de ciclo de vida de desenvolvimento de software / modelo de processo
         • Um modelo de ciclo de vida de desenvolvimento de software descreve os tipos de atividades realizadas em cada estágio de um projeto de desenvolvimento de software e como as atividades se relacionam umas com as outras de forma lógica e cronológica.
           • Há vários modelos de ciclo de vida de desenvolvimento de software, cada um dos quais requer abordagens diferentes para o teste.
         • modelo desenvolvimento dinâmico
           • modelo incremental
             • Neste modelo, de Mills em 1980, os requisitos do cliente são obtidos, e, de acordo com a funcionalidade, são agrupados em módulos. Após este agrupamento, a equipe, junto ao cliente, define a prioridade em que cada módulo será desenvolvido, escolha baseada na importância daquela funcionalidade ao negócio do cliente.
               • No Modelo Incremental, partes do sistema são desenvolvidas em paralelo e integradas posteriormente. Cada parte do sistema corresponde a um “incremento”, e cada incremento tem seu próprio ciclo de desenvolvimento
           • modelo iterativo
             • O Modelo Iterativo promove um processo de vários ciclos sucessivos ou iterações. Tais ciclos aprofundam o conhecimento do sistema tanto para o desenvolvedor quanto para o cliente. Nesse modelo, uma nova versão do produto é produzida em cada etapa. Vejamos:
           • modelo espiral
             • Desse modo, o desenvolvimento de partes do projeto ocorre em paralelo, mas com a disponibilização rápida de partes funcionais para avaliação e testes. As partes disponibilizadas para avaliação são os protótipos – como vimos no Modelo de Prototipação.
               • Uma característica que diferencia o Modelo Espiral dos demais é a utilização de uma estratégia baseada em ciclos, com a realização de uma análise de risco em cada ciclo. Isso reduz potenciais problemas e aumenta o grau de conclusão do sistema simultaneamente.
         • modelo desenvolvimento sequencial
           • Um Modelo de Desenvolvimento Sequencial descreve o processo de desenvolvimento de software como um fluxo sequencial e linear de atividades. Isso significa que qualquer fase do processo de desenvolvimento deve começar quando a fase anterior estiver concluída.
           • cascata / Waterfall
             • https://www.google.com/search?biw=1920&bih=920&tbm=isch&sa=1&ei=-5paXZWiIZ6y5OUP-s-GmA4&q=modelo+cascata&oq=modelo+cascata&gs_l=img.3...3966.4910..5117...0.0..0.140.900.0j7......0....1..gws-wiz-img.......0i7i30.I-rePvZMPIU&ved=0ahUKEwjVi-O6_I7kAhUeGbkGHfqnAeMQ4dUDCAY&uact=5#imgrc=57oDW_eoBHQWPM:
             • uma atividade só pode ser iniciada se a anterior tiver sido completa
               • nesse modelo, as atividades de teste só ocorrem após todas as outras atividades de desenvolvimento terem sido concluídas.
           • v
             • https://upload.wikimedia.org/wikipedia/commons/thumb/b/b6/V-model-en.png/1200px-V-model-en.png
             • o Modelo V integra o processo de teste ao longo do processo de desenvolvimento, implementando o princípio de testar do início.
           • Em contraste com os modelos sequenciais, os modelos iterativo e incremental podem fornecer software utilizável em semanas ou até dias, mas podem entregar o conjunto completo de requisitos ao longo de meses ou até anos.
           • Modelo de Prototipação / modelo evolucionario
             • Por meio dos ciclos, o objetivo é partir dos requisitos para a entrega de um protótipo rapidamente.
   • processo de teste
     • contem um conjunto de atividades
     • grupo de atvidades
       • atividades
       • principais grupos de atvidades
         • planejamento do teste/modelagem de teste
           • análise do teste/base de teste
             • monitoramento e controle do teste
               • envolve a comparação contínua do processo de teste com plano de teste, atuando em forma de planejamento para tomada de ações para atender os objetivos
             • A análise do teste é o processo que procura por algo que possa ser convertido em informações para teste para posteriormente estabelecer os dados da modelagem de teste
               • define o que testar
             • modelagem do teste
               • implementação do teste
                 • Execução do teste
                   • conclusão do teste
                     • As atividades de conclusão do teste coletam os dados das atividades de teste já concluídas para consolidar a experiência, o testware e qualquer outra informação relevante.
                   • Durante a execução do teste, os conjuntos de testes são executados de acordo com a programação de execução do teste.
                 • desenvolve e prioriza scripts/suites automatizados ou não e também organiza e cria um cronograma de acompanhamento e constrói um ambiente de teste
                   • define se agora temos tudo para executar os testes?
               • Projetar e prioriza determinados casos de teste e conjuntos de casos de teste,identificar os dados de teste necessários para comportar as condições de teste e os casos de teste,projetar o ambiente de teste e identificar qualquer infraestrutura e ferramenta necessária.,capturar a rastreabilidade bidirecional entre a base de teste, as condições de teste e casos de teste junto com seus procedimentos de teste
                 • define como testar
           • define as atividades,propósito e abordagem do teste para atender aos objetivos do teste dentro das restrições
       • geram
         • Produtos de trabalho do teste

5. revisão

   • obs
     • só existe um tipo de foco na revisão
       • O foco de uma revisão depende dos objetivos acordados da revisão
         • (p.e., encontrar defeitos, obter entendimento, treinar os participantes, como testadores e novos membros da equipe, ou discutir e decidir por consenso)
   • abordagens
     • tipos
       • pag 57
       • informal
         • função de detectar erros e gerar documentação rasa
       • acompanhado
         • função de detectar erro melhorar software e avaliar conformidades
       • técnica
         • função de obtenção de consenso e a detecção de defeitos potenciais.
       • inspeção
         • Os principais objetivos são detectar os defeitos potenciais e avaliar a qualidade e criar confiança no produto de trabalho, evitando futuros defeitos semelhantes por meio do aprendizado do autor e da análise da causa-raiz.
     • técnicas
       • tipos
         • Ad hok
           • Uma técnica que trabalha de forma sequencial sem nenhuma ou pouca preparo e pode gerar muitos problemas dependendo da experiencia do revisor
         • check list
           • técnica que trabalhar de forma simples mas com cobertura sistemática dos típicos tipos de defeitos.
             • Um checklist de revisão consiste em um conjunto de perguntas baseadas em possíveis defeitos, que podem ser derivados da experiência.
         • cenário e teste pratico
           • Uma abordagem baseada no cenário dá suporte
             • baseado em checklist
         • baseada em papeis
           • Uma revisão baseada em papéis é uma técnica na qual os revisores avaliam o produto de trabalho na perspectiva dos papéis individuais das partes interessadas. Os papéis típicos incluem tipos específicos de usuário final (experiente, inexperiente, sênior, jovem, etc.) e papéis específicos na organização (administrador do usuário, administrador do sistema, testador de desempenho, etc.). (Página 60).
         • Baseado na perspectiva
           • Os pontos de vista comuns das partes interessadas incluem o usuário final, marketing, designer, testador ou operador. Usar diferentes pontos de vista das partes interessadas leva a uma maior profundidade na revisão individual, com menos duplicidade de problemas entre os revisores.
   • A formalidade de um processo de revisão está relacionada a fatores como o modelo de ciclo de vida de desenvolvimento de software, a maturidade do processo de desenvolvimento, a complexidade do produto a ser revisado, e quaisquer requisitos legais ou regulatórios ou a necessidade de uma trilha de auditoria.
   • organização
     • pag 55
     • Planejar
     • Iniciar revisão
     • Revisão individual (ou seja, preparação individual)
     • Analisar e comunicar
     • Corrigir e reportar

6. Usabilidade

   • usabilidade é a qualidade que caracteriza o uso de um sistema interativo.
     • Ela se refere à relação que se estabelece entre usuário, tarefa, interface, equipamento e demais aspectos do ambiente no qual o usuário utiliza o sistema.
   • Heurísticas
     • 10 Heurísticas de Nielsen
       • princípios gerais do design de interface
       • visibilidade do estado do sistema
       • mapeamento entre o sistema e o mundo real;
       • liberdade e controle ao usuário;
       • consistência e padrões;
       • prevenção de erros;
       • reconhecer em vez de relembrar;
       • flexibilidade e eficiência de uso;
       • design estético e minimalista;
       • suporte para o usuário reconhecer, diagnosticar e recuperar erros;
       • ajuda e documentação.
       • quem foi nielsen
         • Jakob Nielsen, um dos maiores especialistas em usabilidade nos Estados Unidos, é autor de um livro clássico sobre o assunto, Usability engineering, de 1994, no qual ele propõe um conjunto de dez heurísticas de usabilidade (NIELSEN, 1994):
     • regras de ouro de Ben Shneiderman
       • perseguir a consistência;
       • fornecer atalhos;
       • fornecer feedback informativo;
       • marcar o final dos diálogos;
       • fornecer prevenção e manipulação simples de erros;
       • permitir o cancelamento das ações;
       • fornecer controle e iniciativa ao usuário;
       • reduzir a carga de memória de trabalho.
     • princípios de dialogo
       • princípios de dialogo tem como base a norma ISO 9241:10 propõe em sua parte 10, Princípios de Diálogo, sete princípios ergonômicos para o projeto e a avaliação de Interfaces Humano- Computador para aplicações de escritório
         • o que é ISO 9241:10 ?
           • Esta norma descreve os princípios gerais de ergonomia considerados importantes para a concepção e avaliação dos diálogos entre o utilizador e os sistemas de informação
             • o que é ergonomia ?
               • Ergonomia é a disciplina científica relacionada ao entendimento das interações entre seres humanos e outros elementos de um sistema, e também é a profissão que aplica teoria, princípios, dados e métodos para projetar a fim de otimizar o bem-estar humano e o desempenho geral de um sistema.
       • adaptação à tarefa;
       • auto-descrição (feedback);
       • controle ao usuário;
       • conformidade às expectativas do usuário;
       • tolerância aos erros;
       • facilidade de individualização;
       • facilidade de aprendizagem.
     • Critérios ergonômicos
       • sistema de qualidade
         • São parâmetros ou um conjunto de qualidades que as interfaces de usuário devem ser seguidas. Esses critérios sistematizam a avaliação e permitem a replicação das mesmas de maneira mais fácil e com base nos parâmetros.
           • Critérios estudados: Bastien & Scapin
       • obs
         • existem diferentes tipos de critérios ergonômicos
       • qualidades principais
         • condução
           • convite
             • Esta qualidade elementar engloba os meios utilizados para levar o usuário a re- alizar determinadas ações. Eles dizem respeito às informações que permitem ao usuário identificar o estado ou o contexto no qual ele se encontra na interação, as ações alternativas, bem como as ferramentas de ajuda e o modo de acesso.
               • um bom convite tem
                 • títulos claros para as telas, janelas e caixas de diálogo;
                 • informações claras sobre o estado (disponível, em foco selecionado, entre outros) dos componentes do sistema
                 • informações sobre o preenchimento de um formulário sobre as entradas esperadas, como seu nome, sua descrição, seu formato e as unidades de medida;
                 • opções de ajuda claramente indicadas.
           • agrupamento e distinção entre itens
             • agrupamento e distinção por localização
               • esta é a qualidade que caracteriza o software bem organizado espacialmente, isto é, aqueles que permitem ao usuário perceber rapidamente os grupamentos a partir da localização das informações nas interfaces.
                 • um produto com um bom agrupamento e distinção por localização deve ter
                   • apresentar grupos e opções de menu definidos logicamente (em função dos objetos e das ações que a eles se aplicam)
                   • apresentar os campos de um formulário em seqüência lógica (em função da ordem da tarefa, de sua importância ou freqüência de uso);
                   • apresentar listas de dados ou informações coesas (somente informações de um mesmo tipo dentro de determinada lista) e ordenadas logicamente;
                   • separar e aproximar itens e grupos nas telas conforme as relações lógicas que se estabelecem entre eles.
             • agrupamento e distinção por formato
               • Esta é a qualidade do software graficamente organizado, isto é, aquele que permite ao usuário perceber rapidamente as similaridades ou diferenças entre as informações a partir da forma gráfica de componentes da interface como tamanho, cor (figura ou fundo), estilo dos caracteres etc.
               • um produto com um bom agrupamento e distinção por formato deve ter
                 • estabelecer uma distinção visual entre áreas abrigando elementos de funções diferentes (comandos, ferramentas, dados, informações etc.);
                 • distinguir graficamente rótulos e dados em um formulário de entrada.
             • legibilidade
               • A legibilidade é uma qualidade a serviço de todos, mas particularmente das pessoas idosas e com problemas de visão. Ela diz respeito às características que possam dificultar ou facilitar a leitura das informações textuais (brilho do caractere, contraste letra/fundo, tamanho da fonte, espaçamento entre palavras, espaçamento entre linhas, espaçamento de parágrafos, comprimento da linha etc.).
               • um produto com uma boa legibilidade deve ter
                 • o texto longo que deve ser lido rapidamente aparece em letras mai- úsculas e minúsculas misturadas naturalmente (maiúsculas no início de frases e nomes próprios) em vez de somente com maiúsculas;
                 • este mesmo tipo de texto é apresentado em linhas com comprimento adequado e com um contraste efetivo com o fundo;
                 • o texto que deve ser lido por idosos ou pessoas com problemas de visão aparece em letras claras sobre um fundo escuro. Para essas pessoas o fundo brilhante pode ofuscar completamente as letras escuras.
             • feedback imediato
               • o feedback imediato aglutina a rapidez do feedback e como a qualidade do entendimento do dialogo com base no o que esta acontecendo dentro do sistema
               • um produto com um bom feedback imediato deve ter
                 • relata ao usuário o recebimento de todas as entradas por ele efetuadas (as entradas confidenciais serão relatadas de modo a não revelar o seu conteúdo, por exemplo, com asteriscos) (
                 • indica ao usuário que um tratamento demorado está sendo realizado, bem como a sua conclusão e o seu resultado
                 • fornecimento da informação em geral de forma rapida
             • Esta é uma qualidade a serviço da “intuitividade” da interface e visa a facilitar a vida de todo tipo de usuário, tanto do novato como do experiente.
         • gestão de erro
           • proteção contra os erros
             • O critério correção dos erros diz respeito aos meios colocados à disposição do usuário com o objetivo de permitir a correção de seus erros. Os erros são bem menos perturbadores quando são fáceis de corrigir.
             • um produto com uma boa proteção contra erros deve ter
               • fornece funções desfazer e refazer;
               • fornece a possibilidade de o usuário refazer apenas a parte errada de uma entrada (indica o dado errado em um formulário, mantendo todos os outros intactos);
               • fornece ligação direta entre o relatório de erro e o local onde ele se produz
           • qualidade das mensagens de erros
             • A qualidade das mensagens refere-se à pertinência, à legibilidade e à exatidão da informação dada ao usuário sobre a natureza do erro cometido (sintaxe, formato etc.), e sobre as ações a serem executadas para corrigi-lo. A qualidade das mensagens favorece o aprendizado do sistema.
             • um produto com uma boa qualidade das mensagens de erros deve ter
               • indica ao usuário a razão ou a natureza do erro cometido, o que ele fez de errado, o que deveria ter feito e o que deve fazer para sair da situação de erro
               • é orientada para a tarefa, emprega termos específicos e é breve;
               • tem um tom neutro, não-reprovador ou humorístico.
           • correção dos erros
             • A proteção contra os erros diz respeito aos mecanismos empregados para detectar e prevenir os erros de entradas de dados ou de comandos, e impedir que ações de conseqüências desastrosas e/ou não-recuperáveis ocorram.
             • um produto com uma boa correção dos erros deve ter
               • informa ao usuário sobre o risco de perda de dados não-gravados ao final de uma sessão de trabalho;
               • não oferece um comando destrutivo como opção default;
               • detecta os erros já no momento da digitação de uma entrada individual em vez de fazê-lo apenas no momento da validação do formulário inteiro
           • Este critério se aplica em todas as situações, em particular quando as ações dos usuários forem sujeitas a erros de grande responsabilidade, envolvendo a perda de dados,
         • carga de trabalho
           • brevidade
             • concisão
               • O software conciso minimiza a carga perceptiva, cognitiva e motora associada à realização de saídas e entradas individuais
                 • um produto com uma boa concisão deve ter
                   • apresenta títulos (de telas, janelas e caixas de diálogo), rótulos (de campos, de botões, de comandos) e denominações curtas;
                   • apresenta códigos arbitrários (nome de usuário, senha) curtos;
                   • fornece valores default (para os campos de dados, listas, check boxes) capazes de acelerar as entradas individuais;
                   • fornece o preenchimento automático de vírgulas, pontos decimais e zeros à direita da vírgula nos campos de dados.
             • ações minimas
               • esta qualidade caracteriza o software que minimiza e simplifica um conjunto de ações necessárias para o usuário alcançar uma meta ou realizar uma tarefa. Ao limitar, tanto quanto possível, o número de telas pelas quais deve passar, ele estará diminuindo a carga de trabalho e a probabilidade de ocorrência de erros
                 • um produto com uma boa legibilidade deve ter
                   • não solicita aos usuários dados que podem ser deduzidos pelo sistema;
                   • não força o usuário a percorrer em seqüência todas as páginas de um documento de modo a alcançar uma página específica;
                   • não solicita o mesmo dado ao usuário diversas vezes em uma mesma seqüência de diálogo.
             • qualidade que baseia-se no nível de esforço necessário para chegar em determinada meta ou função
           • densidade informacional
             • qualidade que baseia-se no nível de esforço necessário para compreender as informações na tela pelo número de componentes visuais na tela.
             • um produto com uma boa densidade informacional deve ter
               • apresenta somente os itens que estão relacionados à tarefa (o restante deve ser removido da tela)
               • não força os usuários a transportar mentalmente dados de uma tela a outra;
               • não força os usuários a realizar procedimentos complicados, como a transformação da unidade de medida;
               • não coloca os usuários diante de tarefas cognitivas complexas, como as de especificação de buscas avançadas.
           • Este critério principal se aplica a um contexto de trabalho intenso e repetitivo, no qual os profissionais que operam o sistema precisarão de interfaces econômicas sob o ponto de vista cognitivo e motor, isto é, que lhes economizem leitura e memorização desnecessárias, assim como deslocamentos inúteis e repetição de entradas.
         • controle explícito
           • ações explicitas
             • Ações explícitas do usuário: se aplica antes da realização de ações longas, sequenciais e de tratamento demorado ou ainda que tenham repercussão importante para o usuário. Em tais situações o computador deve executar somente aquilo que o usuário quiser se somente quando ele ordenar. Esse critério se refere à ligação explícita que deve existir entre uma ação do usuário e um processamento do sistema.
             • um produto com uma boa ação explicita deve ter
               • sempre solicita uma ação explícita do usuário de validação global em um formulário para entrada de diversos dados ou parâmetros;
               • separa as ações de seleção de uma opção e de ativação dessa opção quando se referir a um tratamento demorado
               • não coloca o usuário diante de comandos de dupla repercussão (por exemplo, salvar + fechar).
           • controle do usuário
             • um produto com uma bom controle do usuário deve ter
               • Cada possível ação do usuário deve ser antecipada, e as opções apropriadas devem ser oferecidas
           • Este critério se aplica em particular às tarefas longas seqüenciais e nas quais os processamentos sejam demorados. São situações delicadas, nas quais a falta de controle do usuário sobre as ações do sistema pode implicar perda de tempo e de dados.
         • adaptabilidade
           • flexibilidade
             • Este critério se aplica quando há grande variabilidade de estratégias e de condições de contexto para a realização de uma tarefa.
             • um produto com uma boa flexibilidade deve ter
               • diferentes maneiras de realizar a entrada de dados (por digitação, por seleção, por manipulação direta);
               • diferentes caminhos para chegar a uma funcionalidade freqüentemente utilizada (ícone na barra de ferramenta, opção em um painel de menu, atalho de teclado);
               • diferentes opções de formato de arquivos e de unidades para os dados
               • A personalização se refere aos meios colocados à disposição de usuários mais experientes para que estes personalizem a interface de modo a levar em conta as exigências da tarefa, de suas estratégias ou de seus hábitos de trabalho.
           • consideração do usuário
             • Este critério se aplica quando a variabilidade no público-alvo se referir es- pecificamente aos diferentes níveis de experiência dos usuários. O software deve ser usado tanto por novatos como por experientes,
             • fornece aos especialistas atalhos que permitem acesso rápido às funções do sistema;
             • fornece aos usuários intermitentes diálogos passo a passo;
             • fornece aos usuários totalmente inexperientes diálogos sob a iniciativa do computador
           • A adaptabilidade é uma qualidade particularmente esperada em sistemas em que o público-alvo é vasto e variado. Nestes casos, fica evidente que uma única in- terface não pode atender plenamente a todos os diferentes tipos de usuários.
         • homogeneidade/ consistencia
           • O critério homogeneidade/coerência refere-se à forma na qual as escolhas no projeto da interface (códigos, denominações, formatos, procedimentos etc.) são conservadas idênticas em contextos idênticos e diferentes para contextos diferentes.
           • um produto com uma bom controle do usuário deve ter
             • os códigos e denominações são definidos pelos mesmos critérios em contextos idênticos;
             • a distribuição, a apresentação e a denominação dos objetos nas telas são padronizadas
             • a sintaxe dos procedimentos é padronizada (utiliza os mesmos meios para obter os mesmos resultados).
         • significado de códigos e denominação
           • O critério significado dos códigos e denominações diz respeito a adequação entre o objeto ou a informação apresentada ou pedida, e sua referência.
           • um produto com uma boa significado de códigos e denominação deve ter
             • os nomes de funções e objetos de interação são familiares para os usuários
             • os códigos são representativos do conteúdo que veiculam e são dis- tintos (por exemplo: M – Masculino / F – Feminino, em vez de 1 – Homens / 2 – Mulheres);
             • as abreviações são de imediata interpretação.
         • compatibilidade
           • compatibilidade com o usuário
             • um produto com uma boa proteção contra compatibilidade com usuário deve ter
               • os procedimentos e as tarefas são organizados de maneira a respeitar expectativas ou costumes do usuário
               • as traduções, as transposições, as interpretações ou referências à documentação são minimizadas (as telas são compatíveis com os do- cumentos em papel, as denominações de comandos são compatíveis com o vocabulário do usuário etc.);
           • compatibilidade com a tarefa (ou a maneira como ele realiza a tarefa)
             • um produto com uma boa proteção contra compatibilidade com a tarefa deve ter
           • compatibilidade com o ambiente (com outros sistemas rodando em um mesmo ambiente operacional).
           • critério compatibilidade diz respeito ao grau de similaridade entre diferentes objetos de estudo
     • Método/processo feito para encontrar soluções de um problema.
       • avaliação heurística
         • a quantidade ideal de avaliadores em uma heurística é 3 a 5
         • Entre 3 e 5 avaliadores.
         • é um método rápido e barato

7. tipo de defeitos

   • Defeitos em requisitos
     • p.e., inconsistências, ambiguidades, contradições, omissões, imprecisões e redundâncias
   • Defeitos de design
     • (p.e., algoritmos ineficientes ou estruturas de banco de dados, alto acoplamento, baixa coesão).
   • Defeitos de codificação
     • (p.e., variáveis com valores indefinidos, variáveis que são declaradas mas nunca usadas, código inacessível, código duplicado).
   • Desvios dos padrões
     • (p.e., falta de aderência aos padrões de codificação).
   • Especificações de interface incorretas
     • Especificações de interface incorretas (p.e., unidades de medida diferentes usadas pelo sistema de chamada do que pelo sistema chamado).
   • Vulnerabilidades de segurança
     • (p.e., suscetibilidade a estouro de buffer)
   • Lacunas ou imprecisões na rastreabilidade ou cobertura da base de teste
     • (p.e., falta de testes para um critério de aceite).

8. Organização de teste

   • obs
     • quem são os testadores
       • As tarefas de teste podem ser executadas por pessoas em um papel de teste específico ou por pessoas em outros papéis
         • Um certo grau de independência geralmente torna o testador mais eficaz em encontrar os defeitos devido às diferenças entre os vieses cognitivos do autor e do testador (Página 73).
     • trabalho da equipe de teste
       • gerenciamento de risco/garantia de qualidade
     • desenvolvedores não testão?
       • testam pois é preciso entregar um código funcional
   • grau de independência
     • nível 1
       • somente desenvolvedores são responsáveis pelos testes
     • nível 2
       • testadores independentes dentro da equipe de desenvolvimento
     • nível 3
       • equipe de teste independente
     • nível 4
       • especialistas em teste independente para um objetivo despesifico de teste,como testes de usabilidade,segurança ou certificação
     • nível 5
       • equipe de teste terceirizada ou independente da organização
   • estrategia de teste ou abordagem
     • Uma estratégia de teste fornece uma descrição geral do processo de teste, comumente no nível do produto ou organizacional.
     • planos de teste
       • politica de teste
         • define como a organização conduzirá os teste
       • plano de teste mestre
         • define como o teste será realizado no projeto
       • plano de teste unitário,sistema e aceitação
         • define como cada nível de teste será rconduzido
       • devem ser flexiveis
     • tipos
       • analitica
         • testes são baseado nas áreas do software com maior risco
       • baseado em modelos
         • teste são baseado em dados informacionais estatísticos sobre a taxa de erros
       • compatível com processos ou padrões
         • teste são baseado em padrões da industria ou varias metodologias ágeis
       • dinâmica e heurística
       • baseado em conselho
         • teste são baseados em conselhos de especialistas em tecnologia ou negócio
       • regressão
   • resposabilidades usuais
     • desenvolvedores
       • teste de integração(componente) e teste unitario
     • testadores
       • teste de aceite,teste de integrado(sistema) e teste de sistema