SyntaxHighlighter

domingo, 13 de setembro de 2015

O que é Ciclo de Vida do Defeito ou Bug em Testes de Software?

O ciclo de vida do defeito ou bug ocorre sempre que um defeito é identificado durante o ciclo de vida da aplicação e termina quando o defeito tem seu estado alterado para 'fechado' após ser confirmada a sua correção. Lembre-se: o Ciclo de vida do defeito é relacionado ao bug encontrado durante os testes.

Bugginho Developer

O bug tem estados diferentes dentro do ciclo de vida, o que pode ser mostrado na figura abaixo:
Ciclo de Vida de um defeito
O ciclo de vida do Defeito ou do Bug incluem os seguintes passos ou estados:
  1. New (Novo): Quando um defeito é identificado e cadastrado na primeira vez. Seu estado é dado como Novo,
  2. Assigned (Atribuído): Após o testador ter cadastrado o defeito, seus Gerente verifica se esse defeito é realmente novo e então atribui o defeito para que o desenvolvedor e seu time possa corrigí-lo. Seu estado é dado como Atribuído.
  3. Open (Aberto): Neste estado, o desenvolvedor já começa a análise e o trabalho para a correção do defeito.
  4. Fixed (Corrigido): Quando o desenvolvedor faz alterações no código, então, ele muda o estado do Bug para 'Corrigido' e o passa ao Time de Testes.
  5. Pending retest (Pendente Reteste ou Revalidação): Após corrigir o defeito, o desenvolvedor entrega essa alteração para que o testador refaça o teste. Neste caso, o teste está pendente aguardando o fim do teste, logo, seu estado é pendente reteste.
  6. Retest (Reteste): Neste estágio, o testador começa a fazer o reteste da alteração feita pelo desevolvedor, que repassou ao tester para reteste. É neste estágio que o testador informa ao desenvolvedor se o defeito foi corrigido ou não.
  7. Verified (Verificado ou Validado):  O testado testa novamente a correção após ele ser corrigido pelo desenvolvedor, se o defeito não for mais localizado no Software, então, o testador informa que o defeito foi consertado e muda o estado para "Validado" ou "Verificado".
  8. Reopen (Reaberto): Se o defeito ainda existir mesmo após o mesmo ter sido corrigido pelo desenvolvedor, o testador muda o estado para 'Reaberto', Então, o defeito inicia todo o ciclo de vida novamente.
  9. Closed (Fechado):  Uma vez que o defeito foi corrigido, testado e verificado que o Defeito não mais existe, o testador muda o estado para 'Fechado'. Este estado informa que o defeito está corrigido, testado e aprovado.
  10. Duplicate (Duplicado): Se o defeito é repetido ou existe mais de menção do mesmo defeito, então um desses defeitos recebe o estado de "duplicado".
  11. Rejected (Rejeitado): Se o desenvolvedor identificar que o defeito não é novo, ele rejeita tal defeito. Então, seu estado é modificado para "Rejeitado".
  12. Deferred (Postergado): O defeito quando tem seu estado alterado para "Postergado" é porque ele será corrigido em versões futuras do software. As razões para isso, é que o defeito pode ser de baixa prioridade, falta de tempo ou o defeito pode não causar sérios danos ao funcionamento do Software e com isso, pode ser postergado.
  13. Not a bug (Não é um defeito):  Esse estado é dado para o defeito quando não existir qualquer alteração nas funcionalidades da aplicação. Por exemplo: se o cliente pergunta sobre alguma alteração na parte visual ou nas disposições dos campos como a troca de cor de algum texto, isso não é um defeito, apenas houve uma mudança não informada no design da aplicação.
Fonte: ISQTB

quarta-feira, 9 de setembro de 2015

4. Técnicas de Modelagem de Testes - O que é análise de Teste? Ou como identificar as condições para o Teste?

Análise de Teste: Identificando condições para teste
A análise do teste é o processo que procura por algo que possa ser convertido em informações para teste. Também é chamada de Base do Teste.
  • A base do teste é a informação necessária para começar a análise do teste e criar nossos próprios casos de teste. É uma documentação na qual casos de teste são baseados, tais como requisitos, especificações de projeto, análises de risco de produto, arquitetura e interfaces com o usuário.
  • Podemos utilizar os documentos da base de teste para compreender o que o sistema fará quando for construído. Em alguns casos, os testes pode se basear no conhecimento que o usuário tem do sistema e isso pode não estar documentado.
  • Da perspectiva do teste, nós olhamos a base de testes para ver o que pode ser testado. Essas são as condições de teste.  Uma condição de teste é algo que nós podemos testar.
  • Enquanto identificamos as condições de teste ideal dentro das muitas condições que temos e então selecionar quais delas serão realmente úteis em nossos casos de testes, a isso chamados de possibilidade de teste.
  • Como já é sabido, testar tudo no sistema é impraticável, tal procedimento é chama-se teste exaustivo. Devemos escolher apenas um conjunto dos testes possíveis. Na prática, tal conjunto pode ser pequeno diante do tamanho sistema, porém, ele tem uma grande probabilidade de encontrar a maioria dos defeitos.
  • Precisamos de muita inteligência no processo para organizar nosso conjunto e a essa inteligência damos o nome de técnicas de teste. As condições para teste que foram escolhidas, vão depender da estratégia de teste ou de uma abordagem de teste mais detalhada. Por exemplo, precisam ser baseados no risco, modelos de sistema e etc.
  • Uma vez identificada a lista de condições para o teste, é muito importante priorizá-los, então a condições mais importante será identificada. Tais condições podem ser identificadas por dados de testes bem como para entradas e para saídas, por exemplo diferentes tipos de registros, diferentes tamanhos de registros ou campos em um registro. As condições de teste estão documentadas na IEEE 829 que se chama "Especificação de Modelagem para Testes".
Fonte: ISTQB

terça-feira, 8 de setembro de 2015

Como passar no Exame de Certificação de Testes Foundation da ISTQB/BSTQB (CTFL) de primeira like a boss ou like a Messi

Aqui temos algumas dicas e macetes para passar no Exame de Certificação Nível Foundation (CTFL) da BSTQB/ISTQB.
Bem, fazendo pela BSTQB, em português,o resultado demora 6 dias para ser divulgado, já se fizer na ISTQB o resultado sai na hora... por acaso alguém já conhece a piada sobre o Inferno Brasileiro? é quase a mesma coisa.
  1. Estude todo o Syllabus do Foundations. Vamos cobrir, ou pelo menos tentar, todo o Syllabus em nosso  Blog. Os Tópicos, 5 no total, são explicados de maneira própria dentro de cada assunto e suas terminologias que caem normalmente no exame.
  2. Após ler todo o conteúdo do Syllabus corretamente, faça alguns simulados e responda à questionários. Você pode fazer alguns aqui. Uma outra dica muito importante: Nunca estude inicialmente pelos simulados, isso pode causar mais confusão do que auxílio, tente seguir à risca essa receitinha de bolo, que você vai se dar bem.
  3. Fazer o simulado te dará uma idéia dos tópicos que vão precisar de mais atenção. Também vai te ajudar a entender as diferentes perguntas que são feitas.
  4. Após resolver algumas questões dos questionários ou simulados, volte ao Syllabus e leia-o novamente. Sim, isso mesmo, leia-o novamente, é muito importante.
  5. Isso vai te ajudar a entender os tópicos e as terminologias de uma forma melhor e você terá uma melhor compreensão dos tópicos.
  6. Você também pode fazer uma lista de terminologias e as definições que caem normalmente no Exame, através dos simulados.
  7. Você precisar ter bastante atenção à alguns tópicos como teste de Caixa Preta (Partição de Equivalência, Análise de Valor Limite), teste de Caixa Branca, teste de Cobertura e Tipos de Cobertura com cobertura de Declaração, cobertura de Decisão e cobertura por Condição.
  8. Após ler todo o syllabus duas vezes e resolver alguns questionários, tente fazer um simulado dentro do tempo de prova, ou seja, 40 questões dentro de 60 minutos.
  9. Isso significa que você terá 1,5 minutos,ou um minuto e meio, para responder cada questão. Esse tempo é suficiente para resolver perguntas de múltipla escolha.
  10. Candidatos conseguem se preparar em até dois meses ou menos, mesmo trabalhando e com suas esposas a TPM. 
Algumas dicas à respeito das questões do exame:

  1. As questões são apresentadas de um modo em que todas as opções são bastante parecidas. Então, é muito importante, estar relaxado e ler a questão e suas opções com muito cuidado..
  2. Se você encontrar mais de uma resposta correta, então comece eliminando as óbvias, após fazer isso, foque-se na terminologia ou definição ou resposta e então faça a marcação correta.
  3. Leia a questão duas ou três vezes e tente compreendê-la. Existem algumas palavras na questão que precisam de maior atenção como "NÃO", "NUNCA","TODOS","TUDO" e etc.
  4. Após responder as questões do simulado, verifique as suas respostas e veja a sua pontuação. Você precisa resolver 26 questões corretamente, no mínimo, para passar no exame.
Desde que você tenha lido todo o Syllabus por duas ou três vezes e resolvido 20 à 30 questionários em um tempo estimado. Eu acho que você está pronto para fazer o exame e passar de primeira Like a Boss.
Mas, se mesmo assim você não se sentir seguro, você pode fazer um curso excelente aqui

E aí, você vai me perguntar:
- Gabriel, e o Teste de Caixa Cinza, o famigerado Grey Box?
E eu vou responder com o maior prazer:
- Grande amigo, esse negócio de Grey é coisa de Teoria da Conspiração, Área 51, isso é com o pessoal do Arquivo X. E agora tem umas Testers ai que só querem saber de 50 Testes de Caixa Cinza... melhor a gente não tocar muito nesse assunto não... Véi na boa! Isso nem está na documentação da ISTQB, porque Grey Test é um híbrido tipo o Chupacabras,Optimus Prime... essas coisas!
E mais uma vez: The treta has planted!
Fonte: ISTQB

segunda-feira, 7 de setembro de 2015

Quais são as fases do Ciclo de Vida de Desenvolvimento de Software (SDLC) ?

Essa é para puxar na memória.
Lembra quando você tinha essa matéria, que era decoreba, na faculdade ou no curso tecnico de processamento de dados? (Caramba! Curso de Processamento de Dados... acho que entreguei a minha idade agora!).
Pior que tinha sempre um professor que as colocava fora de ordem e na multipla escolha tínhamos que acertar qual a ordem certa, mas tinha sempre aquela maldita opção das "N.R.A."  - Nenhuma das Respostas Acima, pois é...
Hoje em dia, por mais que você a ignore, ela tem um peso muito grande.
Gigantes como a Microsoft estão focando suas equipes e aplicativos em frameworks que facilitam o SDLC, porém, com um outro nome: o ALM (Application Lifecycle Management) - Gerencimento do Ciclo de Vida da Aplicação. O nome ficou mais bonito e pomposo, mas na prática é a mesma coisa. A única grande novidade é que, na Microsoft com o Team Foundation Server, você pode escolher entre utilizar CMMI, Agile ou Scrum para gerenciar o seu trabalho. Mas, isso é assunto pra um outro artigo, quando eu abordar um ALM completo com TFS e depois um ALM completo totalmente Open Source, com Jenkins.
Se você ainda está na faculdade e está às voltas com essa sigla, que você acha que tem parte com o Capiroto, fique tranquilo, vamos exorcizar essa pobre alma em algumas linhas abaixo.
Existem várias abordagens definidas e projetadas para desenvolvimento de Software que são utilizadas/empregadas durante o processo. Tais abordagens também são definidas como Modelos de Processos do Desenvolvimento de Software, por exemplo, temos o Modelo Cascata, Modelo Incremental, Modelo V, que não é o de Vingança, o Modelo Iterativo e etc etc). Cada modelo de processos segue um ciclo de vida específico na sua forma de produzir sucesso, ou fama lê-se Martin Fowler, no desenvolvimento de software.
Os modelos de ciclo de vida do Software descrevem suas fases e a ordem nas quais devem ser executadas. Cada fase produz entregáveis necessários para que a próxima fase tenha início, ou seja, são fases dependentes - pegando um pouquinho de carona com o pessoal PMI na veia. Requisitos são traduzidos em Modelagem. Código é produzido de acordo com a modelagem - pelo menos deveria - no que é chamada de fase de desenvolvimento. Após Codificar, os "Codar", os testes de verificação do produto final para verificar se estão de acordo com o que fora levantado, se sim, então podemos "subir" a aplicação em Produção, que é quando o usuário vai poder utilizar o Sistema e fazer os milagres que sempre faz em encontrar erros e também dizer "pior que isso funciona!".
É verdade que listamos muitos modelos, mas você vai me perguntar: 
- Gabriel, você tá doidão? e o Scrum, XP e outras abreviações ágeis?
A minha resposta será: 
- Estão no Desenvolvimento Iterativo!
The treta has planted!
Apesar da treta estar plantada, existem 6 fases padrão, pelo menos por enquanto, em todo ciclo de vida de desenvolvimento de um Software, o SDLC ou o ALM da Skynet e do Ultron não contam:

  1. Levantamento de Requisitos e Análise
  2. Modelagem
  3. Implementação ou Codificação - (É  a gente mesmo!)
  4. Testes - (É nóis na fita, ladrão!)
  5. Publicação ou Implementação em Produção
  6. Manutenção ou Sustentação
1) Levantamento de Requisitos e análise: Requisitos do Negócio são levantados nessa fase. Essa fase é o foco principal dos colaboradores e dos gerentes de projeto e dos POs também  - pros agilistas ficarem no meu blog. - Entrevistas com gerentes, colaboradores envolvidos no negócio e usuários de todos os tipos e espécies em seu habitat natural, todos são colocados em fila para determinar, inspecionar e nos ensinar cada vez melhor , veja bem! - sobre as Regras de Negócio envolvidas, tais como: Quem vai utilizar o Sistema? Quais dados serão inseridos no Sistema? Quais dados o sistema irá mostrar aos usuários? Estas são perguntas gerais que devem ser respondidas durante a fase de levantamentos de requisitos (É, realmente deveriam né? mas a realidade... bem, a realidade... xá pra lá!). Após o levantamento de requisitos, estes são analisados, validados e é estudada a possibilidade do que deve ou não ser incorporado aos requisitos do sistema a ser desenvolvido.
Finalmente, é... ainda não acabou, um documento de Especificação de Requisitos é criado e serve (uhum, sei!) como guia para as próximas fases do Modelo.
Diante do que foi dito nessa primeira fase, você já notou como tudo fica mais difícil quando um requisito é mal modelado ou quando uma Estória de Usuário é entregue sem Regra de Aceitação ou quando uma Regra de Aceitação é mal feita ou a própria Estória de Usuário na verdade é um Épico e você não compreendeu? Olha bem o quanto de dinheiro é gasto nessa fase e quanto que se ainda vai gastar caso algo dê errado. Pensa aí e depois coloca lá nos comentários, vamos debater sobre isso.
2)  Modelagem: Nessa fase, o produto e o ambiente, são modelados e projetados de acordo com as especificações de requisitos estudadas e informadas na fase 1. O projeto do sistema ajuda a especificar o hardware e os requisitos também auxiliam no geral à Arquitetura do Sistema - não existe almoço grátis. As especificações de projeto e modelagem de sistema servem como entrada para a próxima fase.
3)  Implementação ou Codificação: Ao receber os documentos de modelagem, o trabalho é dividido em módulos/unidades e a codificação atual é iniciada. Assim que esta fase começa a produzir o código propriamente dito, o foco principal é para o desenvolvedor. Essa é a fase mais longa do ciclo de vida do desenvolvimento de software, para quem não acredita, aqui vai uma estorinha "das trincheiras" que tá na moda: Imagine que Deus (Gerente de Projetos) avisa pra você que a humanidade vai acabar ("cara, esse projeto é de emergência") e ainda te avisa que vão chover 40 dias e 40 noites ("... esse projeto tem muita gente graúda, precisamos entregar isso logo senão estamos fritos...") e então te manda construir uma arca ("Cara, faz de um jeito rápido que dê pra entregar e tá bom. Rodou... Xablau!") e aí vem a chuva, quando você ainda está terminando os testes de aceitação, mas o XGH  - Extremme Go Horse - é quem manda e o resto você já sabe né... não é à toa que essa fase 3 é a mais demorada. Em alguns lugares ela dura por anos... (o grifo é nosso).
4)  Teste:  Após o código ser desenvolvido, ele é testado de acordo com o que está escrito nos requisitos, aí que começa o "sapeca iá iá", para verificar se o Produto está realmente resolvendo os problemas dos quais fora contratado para resolver nas fases anteriores, o que significa, que se tudo der certo, saber também se a equipe de desenvolvimento vai ganhar uma PLR gorda no final do ano ou um Cestão (ferrados! é claro). Durante essa fase, todos os testes que a mente maligna e criativa do tester criar serão utilizados: Teste unitário, Teste de Integração, Teste de Sistema, Teste de Aceitação e dentre outros. Não especifiquei todos porque estou escrevendo antes de dormir e não quero ter pesadelos.
5)  Publicação em Produção: Ufa! depois que nosso trabalho sobreviveu a fase de testes, vamos faturar. O produto é entregue e publicado em produção para que o cliente o utilize.
6) Maintenance: Mas, nem tudo são flores e quando os clientes começam a utilizar o sistema de forma massiva, e é aí que eles fazem cada coisa...operam verdadeiros milagres, até cheat codes utilizam, então os problemas começam a aparecer e precisam ser solucionados de tempos em tempos.  Tal processo, onde damos um carinho e uma amolecida no nosso produto desenvolvido, é mais conhecido como Manutenção ou Sustentação, mas o usuário teima em chamar de Porcaria, fazer o quê?

Fonte: ISTQB

Qual o significado de Defeito, Bug ou Erro e Falhas em Teste de Software?

Um regrinha rápida para compreender:
1) Erro é cometido por um ser humano
2) um Defeito é gerado no Sistema, quando programado de forma errada.
3) Falha é o que é retornado para o usuário através de um aviso na tela.
4) Bug é quando uma grande quantidade de erros, defeitos ou falhas são encontrados no Software. 
Para evitar essa dor de cabeça quando o seu Produto de Software for entregue, é muito útil que se use o Teste de Software, como já dissemos, durante todo o seu ALM.
Agora, vamos de definição.

Definição:
  • Um defeito é um erro ou um bug, dentro da aplicação quando ela é criada. Um desenvolvedor quando está modelando e construindo o Sistema, pode cometer enganos ou erro. Esses enganos ou erros significam que existem falhas no Sistema, tais falhas são chamadas de defeitos.
  • Quando o resultado atual desvia do resultado esperado durante os testes então isso é um defeito. Consequentemente, qualquer desvio da especificação mencionado no Documento de Especificação funcional do produto é considerado um defeto. Em empresas diferentes isso é frequentemente chamado de bug, issue, problema ou incidente.
  • Quando a Produto final não supre a expectativa do usuario final ou não respeita os Requistos Modelados, então isso resultado em um Bug ou Defeito. Esses defeitos, ou bug, ocorrem porque houve um erro de lógica ou erro no código que resulta em uma falha ou resultado imprevisivel ou imprevisto.
Informações adicionais sobre Defeitos/Bugs:

Quando uma aplicação ou um Produto de Software é testado, se um grande número de defeitos são encontrados então ela é considerada "Bugada" ou que contém um "Bug".
Quando um testador encontra um Bug ou um Defeito,é necessário informar sobre os mesmos com os desenvolvedores. Para tal, ele coloca tais defeitos em um Relatório detalhando os passos efetuados até chegar no defeito encontrado, esse Relatório tem vários nomes: Relatório de Bugs, Relatório de Issues, Relatório de Defeitos, Relatório de Problemas e etc.
Este Relatório consiste, basicamente, em conter a seguinte informação:
  • ID do Defeito – Todo Bug ou Defeito tem um número de identificação único.
  • Descrição do Defeito – A explicação sobre o que foi encontrado.
  • Versão do Produto – A versão do Produto, aplicação, no qual o defeito é encontrado.
  • Detalhes Passo a passo – Os passos detalhados do problema com prints de tela anexados para que os desenvolvedores possam simular o mesmo em seu ambiente.
  • Data do Ocorrido – A data de quando o Bug foi encontrado e relatado.
  • Reportado Por – As informações do Testador que encontrou e reportou o Problema, tais como o nome e o Id do Testador.
  • Estado – O Estado do defeito como: Novo, Encaminhado à alguém, Aberto, Retestado, Verificação, Fechado, Falho, Igorado ou Deferred e etc.
  • Corrigido por – Os detalhes do desenvolvedor que corrigiu o defeito como Id e Nome do Desenvolvedor.
  • Data de Finalização – A data em que o defeito foi resolvido e a entrada finalizada.
  • Severidade – Baseado na severidade (Crítica, Principal, Menor), nos diz sobre o impacto do defeito ou bug na aplicação.
  • Prioridade – Baseado em um conjunto de prioridades (Alta, Média, Baixa), a ordem de corrigir o defeito pode ser dada.
Fonte: ISTQB

1. Fundamentos de Teste - 1. O que é Teste?

Teste de software é o processo de executar uma aplicação com a intenção de encontrar bugs. Também pode ser definido como o processo de validação e verificação feito em um software:


  • Atende aos requisitos técnicos e de negócios que orientaram seu design e desenvolvimento.
  • Trabalha como esperado.
  • Pode ser implementado com características similares.

Colocando uma Máquina de Raios-X sobre a definição de Teste de Software, a vemos em partes, como já dizia Jack:

1)  Processo:  Testar é um processo, e esse processo é melhor do que uma atividade única, ou fazer algo de uma única vez e validar no final.
2)  Ativo em todo o Ciclo de Vida: Teste é um processo que é executado durante todo o Ciclo de Vida da Aplicação (ALM).
  • O processo de modelagem dos testes, desde o inicio e durante o ciclo de vida, pode ajudar a prevenir defeitos antes que estes sejam introduzidos no código. Algumas vezes é definido como “verificação da base de testes de acordo com a modelagem do Sistema.”
  • A Base de Testes inclui documentos, tais como as especificações de Requisitos e de Modelagem da aplicação.
 3)  Teste Estático: Quando executado, pode encontrar defeitos sem precisar executar o código. O Teste Estático inclui revisão de documentos (incluindo código fonte da aplicação) e análise estática de código. É um teste útil e barato. Esse tipo de teste é muito executado pelas IDEs modernas como Visual Studio, Eclipse, NetBeans e afins, para ver na prática, basta errar alguma palavra reservada da linguagem  ou algum comando que a IDE vai sublinhar o erro e com isso evitando que a aplicação seja montada e executada até que o erro seja corrigido.
4)  Teste Dinâmico: Em um teste dinâmico, o código fonte que precisamos testar é executado, ou "rodado", para demonstrar como ele responde. É feito durante o processo de validação. Exemplos de testes dinâmicos: teste unitário, teste de integração, teste de sistema e etc.
 5)  Planejamento:  Precisamos planejar o que queremos fazer. Controlando as atividades do teste, informando o progresso do teste e o estado do sistema durante os testes, ou seja, como o sistema responde durante essa tarefa, é muito importante anotar tudo o que se encontra e depois fazer uma reunião para selecionar que informação realmente importa ou não.
6)  Preparação:  Precisamos escolher qual tipo de teste faremos, escolhendo as condições para teste e modelando os casos de teste.
7)  Avaliação: Durante a avaliação, precisamos checar os resultados e avaliar o software sob nossa responsabilidade e os critérios de compleição, critério de "passou", "falhou" ou "inconclusivo", que nos ajuda a decidir quando terminar de testar e se o produto passou nos testes propostos.
8)  Produtos de Software e artefatos de resultado gerados:  Junto com o teste de código, os testes de Requisitos e as especificações de modelagem e outros documentos relacionados ao usuário, materiais de treinamento são muito importantes.
Fonte: ISTQB