Antes de conhecer os axiomas associados ao teste de software, precisamos saber que um axioma é uma sentença ou preposição que não é provada ou demonstrada e é considerada como óbvia ou como um consenso inicial necessário para a construção ou aceitação de uma teoria.
Por essa razão, é aceito como verdade e serve como ponto inicial para dedução e inferências de outras verdades (dependentes de teoria) (Fonte: Wikipédia)
Assim axiomas de testes de software são afirmações sobre testes admitidas como válidas ! Vamos então conhecer nove axiomas sobre os testes de software.
- O número de entradas, caminhos internos e saídas são muito grandes
Ex.: Uma simples entrada de um número inteiro pode receber um grande número de possibilidades: número inteiros, números reais, caracteres, símbolos como “.” “,”
- A especificação do software é subjetiva, dúbia ou incompleta
- A avaliação de alguns aspectos do software é subjetiva
- Os critérios de avaliação podem mudar com o tempo
Assim nunca se deve dizer que em um determinado software não existem erros, mas apenas que em função dos testes realizados não foram encontrados erros!
Leia mais …
Esse artigo faz parte da categoria de artigos conceituais e descreve os tipos de testes de software. Em outro artigo havia escrito sobre as fases de testes, e acredito que esse novo artigo contribua para o correto entendimento de conceitos fundamentais sobre testes.
Cada tipo de teste tem foco em um objetivo particular, por exemplo:
- em uma funcionalidade, a ser realizada pelo software;
–em uma característica da qualidade não-funcional, como a confiabilidade ou usabilidade,
–a estrutura ou arquitetura do software ou sistema;
– efeitos colaterais de mudanças ocorridas em partes do software, sobre as partes que não houveram mudanças.
Leia mais …
Durante a execução dos testes funcionais por uma equipe independente do desenvolvimento, é importante estabelecer uma forma comunicação para o relato do progresso da execução dos testes.
No momento da execução a equipe já tem em mãos o total de caso de testes e se for uma equipe que possui registros históricos de outros projetos executados, terá também a produtividade dos executores medida em casos de testes executados por hora.
A partir disso suponha uma equipe com 5 executores, 8 horas de trabalho diário, com produtividade de 6 casos de testes por hora, e que estão a frente de um projeto para executar 1.000 casos de testes no prazo de 5 dias.
A tabela abaixo mostra um exemplo para o relato diário do progresso da execução dos testes funcionais para esse cenário proposto:
Leia mais …
A elicitação de requisitos para o desenvolvimento de software tem sido um desafio para os praticantes da engª de software. Todos sabemos que um requisito mal elicitado causará problemas em todo o restante do desenvolvimento, mas mesmo assim ainda cometemos muitos erros. Segue abaixo três abordagens que julgo serem importantes e que nos ajuda muito na elicitação dos requisitos:
Leia mais …
Na linha de que uma imagem vale por mil palavras, estava buscando na internet um vídeo que ilustrasse a importância da engenharia de requisitos para o desenvolvimento de um software com boa qualidade e custos e prazos controlados. Encontrei então o vídeo abaixo, que ilustra de forma leve e bem humarada os problemas que a engenharia de requisitos busca resolver.
Esse vídeo foi adaptado e traduzido a partir de http://www.youtube.com/watch?v=6LCEGR7s6W8
O desenvolvimento de software nos dias atuais demanda por prazos e custos reduzidos, e qualidade elevada. Conjugar esses três fatores no processo de desenvolvimento não é tarefa fácil e uma das coisas que pode ajudar a obter um software de qualidade é exatamente a qualidade do requisito que foi elicitado. Veja abaixo oito características de um bom requisito:
Leia mais …
Ao estudar o guia do PMBOK sempre senti falta de uma figura que me desse a visão geral das áreas de conhecimento integradas aos cinco grupos de processos: iniciação, planejamento, execução, controle e encerramento. A partir dessa necessidade gerei a figura que publico abaixo, para eventualmente ajudar a outras pessoas que possam ter sentido essa mesma necessidade. Sei que não é novidade e é fácil encontrar no google imagens figuras com esse tipo de representação. Mas ela ajuda muito e daí resolvi fazer a minha.
E você, gerencia seus projetos utilizando as boas práticas contidas no PMBOK?
A elicitação de requisitos visa identificar e descrever os requisitos de um software a ser desenvolvido. O processo para a elicitação de requisitos prevê primeiramente a identificação dos objetivos gerais do software, informações sobre os problemas atuais existentes e por fim as necessidades que devem ser endereçadas pelo software.
Sabendo-se que o objetivo de um software é o de servir vários usuários, pode-se supor que a maneira mais simples de se elicitar os requisitos é simplesmente perguntar aos usuários quais são suas necessidades quanto ao novo software a ser desenvolvido. Infelizmente esse processo não é tão simples quanto parece. Conheça as seis principais barreiras na elicitação de requisitos: Leia mais …
Nessa época do ano o calendário nos chama para a necessidade de reflexões: o que fizemos de bom no ano que se encerra e o que queremos mudar no ano vindouro é geralmente a base de muitas reflexões. Aproveitando esse espírito de renovação que um novo ano nos traz, que tal planejar para o próximo ano os oito passos para a melhoria da qualidade do software? Esse artigo aborda o tema de qualidade de software e o coloca sob uma perspectiva da melhoria contínua, e não um algo com começo meio, e fim.
De modo geral as pessoas tratam a qualidade de software como resultado final de um esforço pontual, ou ainda como um destino que se quer chegar, se possível com o mínimo esforço. E qualidade de software não é isso. É sim uma viagem que nunca termina. À medida que se começa a efetuar medições no processo de desenvolvimento e a gerenciar a qualidade do processo e do produto de software, irá se aprender mais sobre o processo e sobre o produto de software. Em seguida, cada passo de melhoria irá proporcionar novos conhecimentos, experiências e dados necessários para o próximo passo. Assim deve-se focar na melhoria contínua e ajudar as equipes de desenvolvimento de software à realmente acreditar e seguir os princípios da gestão da qualidade. Como as necessidades de cada desenvolvedor são diferentes, deve-se reconhecer onde cada um dos desenvolvedores está nessa jornada para que possam ser orientados a dar o próximo passo. Os oito passos na jornada da qualidade são os seguintes: Leia mais …
