Técnicas de Testes de Software

Assuntos Gerais
#23

[quote]Fernando, tem sim algum material interessante sobre scrum


http://www.amazon.com/Agile-Software-Development-S…&s=books&qid=1254361503&sr=1-2

Um livro sobre user stories, mas bastante interessante pra quem esta estudando scrum.

Tambem sobre extreme programming
http://www.amazon.com/Extreme-Programming-Explaine…&s=books&qid=1254361372&sr=1-1[/quote]

Obrigado cara! Quero ficar mais afiado no assunto, apliquei em tempos de faculdade mas pouco na área comercial (aqui em minha cidade, Salvador).

O que quis argumentar, acima de tudo é que existem sim diferentes especializações, decisões, formas de aplicar, construir. Todas têm vantagens e desvantagens.

Fazendo uma analogia, uma professora minha de faculdade critica os alunos por falarem o tempo inteiro de novas tecnologias como frameworks Java, mcritias ela considera que eles têm GAPS em conceitos de engenharia de software. Já o pessoal mais técnico da minha empresa, critica o setor da qualidade, pois consideram que eles são profissionais fora do “mundo de ti”.

Resumindo: cuidado com conceitos radicais. Dificilmente existirá alguma situação em que um profissional aprende e se dedica a algum segmento e acaba conquistando cargos meio que “na enganação” só por que os "diretores adoram. Eu convivo com profissionais que não confio no ponto de vista, mas procuro respeitar.

YvGa,

acima de tudo, gostei da troca de idias. Espero voltar a estudar um pocuo de SCRUM assim que possível e voltar aqui para torcarmos mais “figurinhas”

[]´s
Fernando Palma.
http://gsti.blogspot.com/
http://testesdesoftware.blogspot.com/

#24

[quote]

O pessoal usa as ferramentas de maneira errada e acreditam que só por usa-las estão garantindo a qualidade. Já vi projetos atrasarem porque o gerente de projetos não conseguia arrumar o MS Project direito e deixou os desenvolvedores esperando ele concertar a m*.

É a mesma coisa daqueles que reunem todo dia e chamam isso de Scrum, depois saem falando que metodologia ágil não funciona.[/quote]

Marcos: você disse tudo :slight_smile:

#25

Concordo, Fernando, mas no meu caso, nao sao conceitos, e por mais que possam parecer radicais, sao experiencias praticas. Eu trabalhei numa empresa em que estava sendo intruduzido o uso de Scrum + xp e as coisas funcionavam e aplicacoes ate mais criticas das que trabalho hoje, saí pra ir pra outra que fazia propaganda da utilizacao de XP. É uma empresa séria, nao é esbornia nao, ela busca entregar um produto de qualidade, mas usa conceitos e metodologias que só atrapalham.

É por experiencia pratica, nao teoria, que eu te digo o que funciona e o que nao funciona. Parece pretensao, mas é vivencia pratica.

#26

[quote]
Concordo, Fernando, mas no meu caso, nao sao conceitos, e por mais que possam parecer radicais, sao experiencias praticas. Eu trabalhei numa empresa em que estava sendo intruduzido o uso de Scrum + xp e as coisas funcionavam e aplicacoes ate mais criticas das que trabalho hoje, saí pra ir pra outra que fazia propaganda da utilizacao de XP. É uma empresa séria, nao é esbornia nao, ela busca entregar um produto de qualidade, mas usa conceitos e metodologias que só atrapalham.

É por experiencia pratica, nao teoria, que eu te digo o que funciona e o que nao funciona. Parece pretensao, mas é vivencia pratica.[/quote]

Entendo bem você: eu sinto isso no dia-a-dia tb. Principalmente quando mudo de projeto/empresa. As vezes temos vontade de dizer que está tudo errado… Bom, eu vou seguir sua dica e estudar mais o SCRUM. Já tive experiências boas e ruins com que usei até hoje. Será um conhecimento a mais.

Valeu!
Fernando Palma.
http://gsti.blogspot.com/
http://testesdesoftware.blogspot.com/

#27

Bom, só mais alguns detalhes, para não deixar de pontuar :slight_smile:

[quote]
Essa é uma ideia absurda, se é economicamente inviavel voce testar todas as possibilidades, voce TEM que conversar com o cliente, explicar que nao é possivel por agora ter todas as possibilidades de consulta. [/quote]

Não me parece tão absurda. Todo sistema tem um nível de testes planejado.

Imagine o exemplo: no meu contrato estou desenvolvendo 2 sistemas. Um deles é SRH (de rcursos humanos) que atenderá 12 mil usuários. O outro é um sistema para o setor de administração de arquivos (SIARC). 10 pessoas trabalham neste sistema.

O nível de qualidade do primeiro deverá ser maior, fatalmente. Imagine que exista uma tela em que a usabilidade pe ruim, existe um erro não tratado ou um campo de CPF sem mascara, uma consulta com N campos (como o exemplo).

Se exemplos de uma tela com má usabilidade ocorrerem no SRH, terei centenas de chamados por dia para o servicedesk e irá acabar impactando no meu setor de desenvolvimento também. O cliente, por sua vez, também irá perder: tempo parado por causa da indisponibilidade.

Já no caso so SIARC, apenas 10 profissionais usam. A chance deles cairem neste erro não tratado, ou inserir um CPF invalido, etc, é bem menor. Digo mais: se eu treinar eles apenas uma vez e pedir atenção a estes pontos, é possível que o servicedesk nunca receba uma ligação destes profissionais.

Eu fiz questão de dar este exemplo porque ele é real. Mas quero sua opinião e dos demais aqui. O que você(s) acha(m)? Não é razoável investir na qualidade apropriada para cada situação? O plano de gestão de qualidade não é válido?

Fernando Palma
http://testesdesoftware.blogspot.com/
http://gsti.blogspot.com/

#28

Tenho nojo de coisas que funcionam mais ou menos.

Tenho dó de seus clientes.

Permitir que um bug passe por erro, descuido, falha em prever que determinado fluxo seria utilizado de determinada forma, isso tudo bem. É um erro e todos cometemos erros. Mas assim que descobertos tem que ser solucionados.

Permitir que um erro vá para a producao, tendo ciencia de que ele existe é subestimar o usuario. No seu exemplo voce esta tratando os usuarios do RH com mais presteza do que os do admnistrativo, e estes nao vao gostar disso, pode apostar. Isso está muito proximo de má fé.

Um cliente que nao tem seus requisitos todos atendidos nao deveria pagar pelo produto. A tendencia é que as coisas mudem e os clientes fiquem cada vez mais exigentes, porque aos poucos eles vao tomando conhecimento de que esse “pessoal de informatica” adora uma papagaiada e nao resolve nada.

#29

correção: “O seu sistema não é livre de bugs e logo a qualidade no seu sistema não existe”.

Isto é uma grande asneira. Esta forma de trabalho é uma enganação. Estúpidos são os clientes que caem nesta asneira.
A razão é muito simples : O que seria o % de bugs ? numero de bugs sobre numero de features ? Errado
numero de bugs conhecidos sobre numero de features. O problema é que em um sistema com testes corretos (automáticos e com cobertura) o objetivo e descobrir e eliminar todos os bugs. E “todos” significa os que conhecemos e os que não conhecemos.
Teste é na realidade uma forma de fazer o bug sair da sua toca… e depois pisá-lo.

O Aceite é uma forma incompetente de resolver a situação. É forçar o cliente a aceitar pagar por algo que tem defeitos.
Este clientes não sabem o que estão fazendo e estão sendo enganados.

É como ir fazer uma cirurgia e tolerar que o médico cometa uma % de erros . Vc se arriscaria a ser operado com margem a 1% de erros ? Basta 1 erro para que vc morra. Da mesma forma , basta 1 erro para que o cliente perca milhares de reais.

Qualidade não é negociável. Tentar fazer isso é sinal que estamos lidando com uma péssima empresa.
Todos os defeitos são críticos.Todos eles causam dano. O que acontece é que uns tem que ser resolvidos com mais prioridade que outros.

Isto é simplesmente uma palhaçada sem pés nem cabeça. O curioso é que sim é uma prática comum.
Agora , vc senhor cliente que paga por estes software, imagine o dinheiro que lhe estão estorquindo.
Ele obrigam vc a aceitar coisa com defeito (indo contra o codigo do consumidor … ah! putz software não é um consumivel…)
e depois cobram para corrigir esses defeitos (que eles mesmos colocaram). Vc contrata empresas assim porquê ? Não tem nada melhor que fazer com o seu dinheiro ?

A ISO 9126 não cobre bugs. Ela cobre qualidade no sentido ISO do termo que nada têm a haver com numero de defeitos.
Qualidade neste sentido é o mesmos que atenção a requisitos não funcionais. E nesse caso o software atende ou não atende. E isso é medido quando ele não tem defeitos. Por exemplo, o sistema deve ter disponibilidade 99.99% ( veja bem que as qualidades ISO são mensuráveis). Se ele tem disponibilidade 99,9% não atende. Isto não tem nada a haver com bugs.

#30

[quote]Tenho nojo de coisas que funcionam mais ou menos.

Tenho dó de seus clientes.

Permitir que um bug passe por erro, descuido, falha em prever que determinado fluxo seria utilizado de determinada forma, isso tudo bem. É um erro e todos cometemos erros. Mas assim que descobertos tem que ser solucionados.

Permitir que um erro vá para a producao, tendo ciencia de que ele existe é subestimar o usuario. No seu exemplo voce esta tratando os usuarios do RH com mais presteza do que os do admnistrativo, e estes nao vao gostar disso, pode apostar. Isso está muito proximo de má fé.

Um cliente que nao tem seus requisitos todos atendidos nao deveria pagar pelo produto. A tendencia é que as coisas mudem e os clientes fiquem cada vez mais exigentes, porque aos poucos eles vao tomando conhecimento de que esse “pessoal de informatica” adora uma papagaiada e nao resolve nada.[/quote]

Eu não sei se eu entendi bem, mas vicê sugere que para todos os sistemas todos os bugs sejam corigidos? Você entende o custo disso?

Eu trabalhei como Analista de Testes durante 2 anos e meio. Gosto de ver os bugs corrigidos. Mas uma coisa é clara: nem todos os bugs são corrigidos para todos os sistemas. Isso é fato. Quando o meu analista de testes encontra 250 erros, fazemos uma avaliação. Normalmente 200 são corrigidos e o restante realmente pode ficar para próximas entregas. Não considero isso algo "próximo de agir de má fé. Você já gerenciou custos? Já comparou o custo de eliminar o bug com o custo do impacto dele? É só uma pergunta para provocar mais diálogo, não entenda como desafio (a linguagem escrita é uma fonte de maus entendidos).

Só para complementar: quando eu testava, se me colocassem 50 vezes para homologar, eu achava bugs nas 50 vezes. Se fossem 100, tb. Sempre existem alguns bus residuais, escondidos.

O tamanho da aplicação e para o que ela será usada é importante sim. Se você produz bicicletas ou brinquedos para crianças, existem níveis de qualidade exigidos pelo inmetro. Se você produz aeronaves, os níveis são infinitamente maiores: cada equipamento dentro de um avião de voo doméstico tem nu mínimo duas redundâncias e níveis de testes extremos.

Imagine outro cenário: você desenvolve sistemas para supermercados e para hospitais. Qual deve exigir um nível extremo de testes e correções? Os dois devem ter os mesmos cuidados?

Mais alguém acha que para todo produto devem ser realizados todos os níveis de testes e corrigido o máximo de bugs?

Fernando Palma.

http://testesdesoftware.blogspot.com
http://gsti.blogspot.com

#31

Isso vindo de alguém que foca na qualidade do software, me assusta.

#32

[quote]Mas uma coisa é clara: nem todos os bugs são corrigidos para todos os sistemas.

Isso vindo de alguém que foca na qualidade do software, me assusta.[/quote]

Converse com alguns profissionais da Qualidade. Leia um livro do Alexandre Bartie ou qualquer outro que aborde com profundidade os testes de software.

Qualquer literatura ou prática sobre testes, esta afirmação é verdadeira: muitos cenários são considerados bugs. O bom nível de qualidade garante que o sistema atende aos requisitos e não trará impacto negativo no processo do negócio do cliente (ou interno, como meu caso).

Eliminar todos os bugs de um sistema é uma tarefa impossível. Não existem sistemas livres de bugs. Repito: quanto mais um sistema é testado, mais bugs são encontrados. Sejam eles de mínimo, pequeno, médio ou grande impacto. Eu tenho conciência em não enviar sistemas para produção que contenham bugs de grande impacto. Mas, quanto aos de impacto mínimo, eles irão. Os exemplos que ilustrei tentam demonstrar isso: o número de usuários e para o que este sistema será utilizado também são fatores determinantes da qualidade. Eu também já coordenei servicedesks: sistemas com que são utilizdos por milhares de usuários tendem a provocar mais dúvidas de usabilidade que os que tem 5 ou 10 usuários. Por isso, devemos nos preocupar mais com a usabilidade deles. Sites precisam de um nível alto de usabilidade, pois se o usuário não se adapta, ele não volta..

A diferença entre o usuário de sistema desktop para usuário web:

  • em desktop, nós usamos e depois avaliamos;
  • na web, nós avaliamos e depois usamos.

Alguém já conhecia esta teoria?]

Fernando Palma
http://testesdesoftware.blogspot.com
http://gsti.blogspot.com

#33

A menos que vc tenham uma definição de bug que significa “tudo com o que eu não concordo” é possivel sim ter um sistema livre de bugs. quando vc diz “bug” e pensa “a cor do label está errada” isso não é considerado um bug do ponto de vista do desenvolvedor.
Bug no entender do desenvolvimento é vc apertar um botão e o sistema lançar uma excection ou não produzir o resultado esperado.

Quando certo promenor do software não está de acordo com a especificação isso é chamado : defeito. Bugs não são defeitos no sentido que , embora ele vão contra a especificação, não era suposto. Não era propósito do desenvolvedor que acontecesse aquilo.
Portanto, quando se colocar o label azul em vez de amarelo ou o botão está 3px mais para o lado esquerdo isso não é um bug.

Sistema sem bug é possivel sim. Basta que vc tenha uma equipa qualificada de desenvoldedores seguindo boas práticas te tendo testes automáticos. Um sistema livre de defeitos realmente não é possivel porque sempre vão existir descrepâncias entre o era suposto e o que está lá. Isto se deve na realidade ao mito de que é possivel documentar toda a especificação de um software e é considerado defeito aquilo que, embora nunca tenha sido especificado vai contra aquilo que a equipe de “qualidade” pensa ou acha ,mesmo quando é totalmente ridiculo.

Se vc seguir esta linha e nunca especificar vc vai deduzir logicamente que todo o software é um enorme defeito porque nem sequer a existência do software está especificada. Este é o clássico exemplo de que porque as metodologia tradicionais não funcionam. elas são baseadas em lógicas falhas.

O entendimento moderno é o seguinte:
Se o label está verde e não ha especificação, então não ha defeito ali. O que ha é opção de melhoria. E melhoria sempre é opcional, não critica e negociável (exactamente o contrário de correção de defeito que é obrigatória, critica e não negociável).
O defeito só vem se havia uma especificação explicita e clara que deveria estar diferente.

Um outro problema na metoodologia tradicional é que o estado de desenvolvimento sempre reflete o request mais recente. então se a especificação escrita pedia azul , mas o cliente mudou para verde , verde é o correto. É comum a equipa de qualidade depois dizer que é um defeito porque foi especificado azul. O problema é que eles não atualizaram a especificação para aquilo que o cliente pediu. Modernamente o tester está dentro da equipa de desenvolvimento e sabe quando e porque a especificação foi alterada. Desta forma,mesmo não havendo um documento escrito existe sempre uma estória que pede a alteração. Isso é suficiente para a rastrabilidade.

Não é possivel ter uma ambiente de testes correto numa metodologia tradicional. Simplesmente não funciona.

Se vc tem uma equipa competente, metodologia competente e gerencia competente sim vc consegue ter zero bugs e zero defeitos.
Não que eles não aparecem, mas que vc sempre os vai resolver antes da entregua.

Entregar software com defeitos ou bugs conhecidos é reserva mental. Punivel por lei e moralmente e profissionalmente inaceitável.

#34

Cara, acredite: até sistemas da microsoft e google contém bugs. Mesmo no coneito moderno: algo que realmente em determinada situação não funciona.

Repito: procure um analista de testes experiente e faça essa pergunta: é possível eliminar todos os bugs de um sistema?

#35

Eu ja li aquele livro do Alexandre e do Emerson Rios, para a certificação da ALATS e até fiz a prova, mas não passei.

Uma coisa é você identificar o bug e deixar passar, outra coisa é não conseguir identificar e consequentemente não corrigir. É isso que a metodologia prega(ou não), os software não são livres de erros, porém o processo tem que garantir a menor quantidade possível, independente do impacto ou não.

Esse seu argumento de que a quantidade de usuários fará com que se sejam encontrados mais erros não me parece muito correto.

Imagine o cenário:

Um software que controla uma aeronave, se tiver um bug, por mínimo que seja, vai causar um grande impacto. Quantos usuário utilizaram este sistema? Piloto e co-piloto?

Ok, vamos para a web então, já que é um ambiente “palpável”:

No site da TAM ou GOL, tem uma passagem que é de 38,40 ao invés de 384,00. É um erro simples, um label incorreto, nada de grave. Imagine a quantidade de pessoas que acessam os sites para comprar passagens.

Um erro não deixa de ser erro pela quantidade de usuário que serão impactados. Erro é sempre erro, para 1000 usuários ou para 1.

Você vai negociar com o seu cliente essa qualidade?

#36

[quote=fernando.palma]quote
Um cliente que nao tem seus requisitos todos atendidos nao deveria pagar pelo produto. A tendencia é que as coisas mudem e os clientes fiquem cada vez mais exigentes, porque aos poucos eles vao tomando conhecimento de que esse “pessoal de informatica” adora uma papagaiada e nao resolve nada.[/quote]

Eu não sei se eu entendi bem, mas vicê sugere que para todos os sistemas todos os bugs sejam corigidos? Você entende o custo disso?
[/quote]

O custo é zero se eles nunca existirem para começo de conversa. O problema não é a correção do bug, mas a sua existência.

Se o sistema tem 250 erros perto da homologação pelo cliente, despeça a sua equipe de desenvolvimento. A sua equipa de qualidade ou o seu gerente. Ou todos, já que é de uma incompetência incrivel todos deixarem as coisas chegarem nesse estado.

E já comparou com o custo de ele não existir ? O custo de resolver um bug que não existe é zero.
O fato é que software bem feito não tem bug. E não tem bug porque os desenvolvedores usam metodologias corretas para os evitar
e não porque existe uma equipa de testes.

claro, que , se todos as equipas de desenvolvimento usarem essas metodologias centenas de equipas de qualidade serão despedidas. E claro que eles não querem isso. Portanto eles têm que defender que é natural um software ter bug e farão de tudo
para isso seja verdade (até não alterar a especifcação para depois poder dizer que está errado)

E o seu gerente não despediu esses desenvolvedores incompetentes ? algum está errado nessa historia.

[quote]
O tamanho da aplicação e para o que ela será usada é importante sim. Se você produz bicicletas ou brinquedos para crianças, existem níveis de qualidade exigidos pelo inmetro. Se você produz aeronaves, os níveis são infinitamente maiores: cada equipamento dentro de um avião de voo doméstico tem nu mínimo duas redundâncias e níveis de testes extremos.

[quote]

outro erro comum de quem vive na antiguidade. Software não é produto industrializável. Essas normas do inmetro de que fala não se aplicam.

Nese tipo de software - se o cliente, o hospital, soubesse o que faz - faria auditoria de software independente. Isso é que é o correto.
Ou seja, a qualidade é medida por pessoas diferentes de quem o fizeram e de forma imparcial. Detalhes, para isso é preciso uma especificação ( ou seja, não vai funcionar porque a especificação nunca é completa)

Qualquer desenvolvedor profissional acha. E todos acham ainda mais :esses testes têm que ser automáticos (aka não precisamos de equipas de qualidade e redatores de especificações. Precisamos de desenvolvedores que saibam programar testes automáticos!)

#37

Rubens, todos os seus pontos foram sensatos. Achoq ue você postou um bom tópico:

[quote]Um software que controla uma aeronave, se tiver um bug, por mínimo que seja, vai causar um grande impacto. Quantos usuário utilizaram este sistema? Piloto e co-piloto?

Ok, vamos para a web então, já que é um ambiente “palpável”:

No site da TAM ou GOL, tem uma passagem que é de 38,40 ao invés de 384,00. É um erro simples, um label incorreto, nada de grave. Imagine a quantidade de pessoas que acessam os sites para comprar passagens. [/quote]

Em TODOS estes casos o nível de qualidade deve ser grande, no caso da aeronave extremo. Eu realmente dei o exempo baseado em quantidade de usuários, mas não é a única variável. Talvez, seria melhor colocar a palavra piroridade do bug. Estes seus exemplos demonstram erros simples, mas de prioridade máxima. Não pode deixar passar.

Agora, se você está desenvolvendo um sistema para uso próprio (uma agenda, pro exemplo), imagino que o nível de testes e correção de erros será menor, sim?

Muito legal o nosso ponto de discussão, estou gostando…

[size=18]
Fernando Palma.
http://testesdesoftware.blogspot.com
http://gsti.blogspot.com/
[/size]

#38

Eu estou pegando um exemplo de quando eu testava sistema: um sistema com centenas de telas e funcionalidades que gerencia as solicitações de projetos para a infraestrutura de salvador. É comum sistemas maiores terem quantidades grandes de bugs, ou melhorias.

o custo existe. Existe uma tecnica de testes de inserir espaços em branco nos campos e tentar salvar. Isso pode gerar erro. É algo simples de corrigir, apenas usar “trin”, por isso se eu encontrar este erro em qualquer sistema eu mando voltar e corrigir. Mas, caso fosse algo custoso de corrigir, eu avaliaria: quem vai usar? Quantos usuários? Qual a probabilidade de alguém inserir espaços em branco? Qual seria o impacto disso? (no caso do avião o imacto é imenso).

Daí é realizada a comparação: custo de corrigir x custo do impacto caso ocorra x probabilidade de ocorrer.

Quando testamos aplicações grandes com infinitos fluxos, sempre existem bugs residuais que serão descobertos.

[size=18]Fernando Palma.
http://testesdesoftware.blogspot.com
http://gsti.blogspot.com[/size]

#39

[quote=fernando.palma]Rubens, todos os seus pontos foram sensatos. Achoq ue você postou um bom tópico:

[quote]Um software que controla uma aeronave, se tiver um bug, por mínimo que seja, vai causar um grande impacto. Quantos usuário utilizaram este sistema? Piloto e co-piloto?

Ok, vamos para a web então, já que é um ambiente “palpável”:

No site da TAM ou GOL, tem uma passagem que é de 38,40 ao invés de 384,00. É um erro simples, um label incorreto, nada de grave. Imagine a quantidade de pessoas que acessam os sites para comprar passagens. [/quote]

Em TODOS estes casos o nível de qualidade deve ser grande, no caso da aeronave extremo. Eu realmente dei o exempo baseado em quantidade de usuários, mas não é a única variável. Talvez, seria melhor colocar a palavra piroridade do bug. Estes seus exemplos demonstram erros simples, mas de prioridade máxima. Não pode deixar passar.

Agora, se você está desenvolvendo um sistema para uso próprio (uma agenda, pro exemplo), imagino que o nível de testes e correção de erros será menor, sim?

Muito legal o nosso ponto de discussão, estou gostando…
[/quote]

Realmente a discussão está muito boa, muito saudável.

Atualmente estou desenvolvendo um sistema para a minha sogra, cadastrar pedidos dos clientes. Coisa simples, o famoso CRUD. Qual é o nível de qualidade que eu devo garantir? O que eu devo priorizar? Para ela, fará alguma diferença se um campo de CPF estiver com máscara ou não? Se o campo nome não tiver um limite de caracteres? Se o botão de incluir estiver desalinhado?

Uma coisa é garantir a satisfação do cliente, outra coisa é garantir a qualidade do software.

Eu garanto pra ela que o sistema vai incluir, alterar, exlcuir e emitir relatórios, porém não vou garantir a interface mais bonitinha possível.

E então, o meu sistema pode ser considerado um sistema de qualidade? Ou posso dizer que eu atendi as necessidades do cliente? Ou posso dizer que garanti a satisfação do cliente?

#40

.

#41

O ponto é :alguem especificou para o desenvolvedor que veria ser possivel salva campos com espaços em branco ?
Não ? Então não é defeito. Vc não tem nem sequer a opção de “mandar voltar”. O máximo que vc pode fazer é sugerir uma melhoria.

(esse conceito de mandar volta já errado para começo de conversa, mas pronto)

Esta é a melhor. Vc é só o tester. Quem é você saber a importância ou o impacto disso ?
Esta é uma caracteristica da equipe de qualidade. Acham que sabem tudo e têm poder de veto.
Essa responsabilidade é do gerente de projeto e do cliente , não é da equipe de testes.

Quando testamos aplicações grandes com infinitos fluxos, sempre existem bugs residuais que serão descobertos.
[/quote]

O que é isso ? uma desculpa ?
Não importa o tamanho da aplicação (não existem aplicações pequenas) . Competência é competência.

#42

[quote]
O ponto é :alguem especificou para o desenvolvedor que veria ser possivel salva campos com espaços em branco ?
Não ? Então não é defeito. Vc não tem nem sequer a opção de “mandar voltar”. O máximo que vc pode fazer é sugerir uma melhoria.

(esse conceito de mandar volta já errado para começo de conversa, mas pronto) [/quote]

Você está certo. Deveria estar especificado ou pelo menos em um banco de conhcimento da equipe.

[quote]Mas, caso fosse algo custoso de corrigir, eu avaliaria: quem vai usar? Quantos usuários? Qual a probabilidade de alguém inserir espaços em branco? Qual seria o impacto disso? (no caso do avião o imacto é imenso).
Daí é realizada a comparação: custo de corrigir x custo do impacto caso ocorra x probabilidade de ocorrer.

Esta é a melhor. Vc é só o tester. Quem é você saber a importância ou o impacto disso ?
Esta é uma caracteristica da equipe de qualidade. Acham que sabem tudo e têm poder de veto.
Essa responsabilidade é do gerente de projeto e do cliente , não é da equipe de testes. [/quote]

Eu já fui analista de testes, mas hoje sou gerente de projetos. Neste expelo, estou me colocando como gerente de projetos.

[size=18]Fernando Palma.
http://testesdesoftware.blogspot.com
http://gsti.blogspot.com[/size]