Pressman e Maxim (2016, p. 432) fazem a seguinte distinção entre esses termos em relação ao software:
- Erro: um problema de qualidade encontrado antes que o software seja entregue aos usuários finais. Pode ser fruto de instruções ou comandos incorretos.
- Defeito: um problema de qualidade encontrado depois que o software foi entregue aos usuários finais. Pode ser fruto de inconsistência em relação à especificação.
- Falha: um problema que ocorre no software já em produção. Pode se revelar como um comportamento inconsistente em função de entradas de dados distintas.
Os autores argumentam que não há consenso entre os especialistas em relação à distinção entre estes três termos, principalmente em desenvolvimento com base em metodologias ágeis, em que pré e pós-entrega não são conceitos bem definidos. Mas é fato que cada um destes problemas pode causar diferentes impactos financeiros e humanos no negócio. As pessoas envolvidas no desenvolvimento querem evitar defeitos para que não fiquem com sua imagem manchada.
Mas é possível argumentar a favor das diferenças entre os termos. Considere a seguinte frase: “A melhor maneira de tentar construir a confiança é tentar destruí-la”.
Parece um paradoxo, concorda?
Pois saiba que não apenas parece, é um paradoxo.
Na tentativa de destruir a confiança por encontrar defeitos, falhas ou erros, na verdade estamos construindo uma confiança cada vez mais sólida no produto desenvolvido.
Pense, por exemplo, nos exaustivos testes automobilísticos, quando as montadoras literalmente destroem seus veículos para provar a qualidade de seus bens produzidos. Não concorda que estão provando com isso a segurança que você espera em um momento crítico, como um acidente de colisão frontal em uma estrada em alta velocidade?
Os projetos podem ter uma grande complexidade, então entendemos claramente que será impossível que eles não possuam alguns defeitos, principalmente porque em um grande projeto temos várias cabeças pensantes, com formações e lógicas diferentes, trabalhando juntas para atingir os objetivos.
Vários poderiam ser os motivos para alegar a impossibilidade de um software sem qualquer tipo de erro, falha ou defeito, mas não queremos contribuir nem para a busca da perfeição, que não existe, nem para o relaxamento relacionado à inexistência de perfeição.
Hoje não podemos falar de qualidade de software sem falar de desenvolvimento ágil, que tem sido considerado um conceito avançado de desenvolvimento e busca na eliminação de erros, falhas e defeitos.
Qualidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade são atributos buscados incansavelmente no desenvolvimento de software e o que nos propomos a fazer na consideração deste assunto é como o testador pode contribuir para esta busca quase que inalcançável.
O processo de testes é efetivo quando encontra defeitos e é eficiente quando encontra os defeitos com a menor quantidade de recursos possível.
Fundamentos de teste de software
De acordo com Pressman e Maxim (2016), um software é testado para descobrir erros que foram introduzidos inadvertidamente no momento em que foi projetado e construído.
“Teste é um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Por esta razão deverá ser definido para o processo de software, um modelo para o teste, que é um conjunto de etapas no qual podem ser empregadas técnicas específicas de projetos de casos de teste e métodos de teste.” (PRESSMAN; MAXIM, 2016, p. 466).
Pressman e Maxim (2006, p. 467) listam um conjunto de perguntas e respostas que apresentam os principais fundamentos que embasam os testes de software, quais sejam:
- Quem realiza? O gerente do projeto, os engenheiros de software e especialistas em testes devem desenvolver uma estratégia de testes, de forma que o projeto tenha um plano formal de testes.
- Porque é importante? O teste é a atividade que requer maior esforço de projeto dentro do ciclo de desenvolvimento de software. Se for conduzido ao acaso, pode implicar em desperdício de tempo e esforço, além de abrir espaço para a infiltração de erros. Assim, é muito importante que se estabeleça uma estratégia sistemática para o teste de software.
- Quais são as etapas envolvidas? O teste inicia no pequeno e segue para o grande, ou seja, começa em um componente ou em um grupo de componentes relacionados; depois estes são integrados de forma a abarcar todo o sistema. A partir deste ponto, uma série de testes de alto nível é executada para descobrir erros relativos aos requisitos do cliente. À medida que erros forem encontrados, é necessário fazer um diagnóstico e buscar sua correção através do processo de depuração do sistema.
- Qual é o artefato? Uma especificação de teste documenta a abordagem da equipe que realiza os testes, definindo um plano para a estratégia global e um procedimento que designa as etapas específicas de testes e os tipos de testes que serão realizados.
- Como garantir que o trabalho de testes foi feito corretamente? Para se certificar da corretude do teste, deve-se realizar uma revisão na especificação do teste antes de sua execução para avaliar a integralidade dos casos de teste e das tarefas planejadas. Um plano e um procedimento de testes eficazes levarão à construção coordenada do software e à descoberta de erros em cada fase da construção do produto de software.
Samsung suspende fabricação e venda do Galaxy Note 7
“A Samsung suspendeu a fabricação do telefone Galaxy Note 7, informou a agência sul-coreana de notícias Yonhap, citando como fonte uma fornecedora da empresa. A iniciativa ocorre após um recall de 2,5 milhões de aparelhos no mundo todo por conta do risco de explosão da bateria.
A empresa também anunciou que ordenou a suspensão das vendas e trocas de unidades do Galaxy Note 7 enquanto acontecem as investigações sobre os problemas recentes.
O caso
Fabricante número 1 de smartphones no mundo, a Samsung enfrenta tempos difíceis desde que, em 2 de setembro de 2016, semanas após o lançamento antecipado do Galaxy Note 7, teve de anunciar o recall de 2,5 milhões de unidades vendidas em 10 países. O motivo era que as baterias podiam explodir.
A decisão de suspender temporariamente a produção foi tomada em coordenação com as autoridades de proteção ao consumidor da Coreia do Sul, Estados Unidos e China, informou a fonte, que pediu anonimato, à agência.
A AT&T e T-Mobile anunciaram a interrupção das vendas do Galaxy Note 7, à espera de investigações adicionais.
‘Estamos tentando ajustar os volumes de produção para melhorar o controle de qualidade e permitir investigações mais profundas após as crescentes explosões do Galaxy Note 7’, afirmou o grupo em um comunicado.
As imagens de telefones carbonizados inundaram as redes sociais de todo o mundo nas últimas semanas. Os incidentes com aparelhos que já haviam sido substituídos agravaram ainda mais a situação da Samsung.
A crise ocorre num momento que não podia ser pior. Após os anos excepcionais de 2012 e 2013, a Samsung começou a sofrer com o avanço da Apple e dos grupos chineses. O grupo sul-coreano contava com este smartphone para sustentar seu crescimento até o fim do ano, em um mercado cada vez mais competitivo. Os analistas consideram que o custo deste recall pode chegar a US$ 2 bilhões.
‘É novamente algo muito grave’, declarou S. R. Kwon, analista da Dongbu Securities. ‘Podem chegar a retirar o Note 7 do mercado. O mais inquietante é que as coisas não parariam por aí.’ ‘Isso vai danificar a imagem de marca da Samsung e penalizará as vendas de outros smartphones Galaxy’, previu.”
Fonte: <g1.globo.com>
Princípios do teste de software
De acordo com o Syllabus, em ISTQB (2011, p. 14, adaptado), há sete princípios que fornecem um guia geral para o processo de teste de software:
Princípio 1 – Teste demonstra a presença de defeitos
O teste pode demonstrar a presença de defeitos, mas não pode provar que eles não existem. O teste reduz a probabilidade que os defeitos permaneçam em um software, mas mesmo se nenhum defeito for encontrado, não prova que ele esteja perfeito.
Princípio 2 – Teste exaustivo é impossível
Testar tudo (todas as combinações de entradas e pré-condições) não é viável, exceto para casos triviais. Em vez do teste exaustivo, riscos e prioridades são levados em consideração para dar foco aos esforços de teste.
Princípio 3 – Teste antecipado
A atividade de teste deve começar o mais breve possível no ciclo de desenvolvimento do software ou sistema e deve ser focado em objetivos definidos.
Princípio 4 – Agrupamento de defeitos
Um número pequeno de módulos contém a maioria dos defeitos descobertos durante o teste antes de sua entrega ou exibe a maioria das falhas operacionais.
Princípio 5 – Paradoxo do Pesticida
Pode ocorrer de um mesmo conjunto de testes que são repetidos várias vezes não encontrarem novos defeitos após um determinado momento. Para superar este “paradoxo do pesticida”, os casos de testes necessitam ser frequentemente revisados e atualizados. Um conjunto de testes novo e diferente precisa ser escrito para exercitar diferentes partes do software ou sistema com objetivo de aumentar a possibilidade de encontrar mais erros.
Princípio 6 – Teste depende do contexto
Testes são realizados de forma diferente conforme o contexto. Por exemplo, softwares de segurança crítica são testados diferentemente de um software de comércio eletrônico.
Princípio 7 – A ilusão da ausência de erros
Encontrar e consertar defeitos não ajuda se o sistema construído não atende às expectativas e necessidades dos usuários.
Nenhum comentário:
Postar um comentário