Técnicas de Testes de Software

[quote=fernando.palma]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?[/quote]
Um bug só existe quando alguém o identificou, então é possível ter um sistema livres de bugs sim… basta corrigi-los!

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

Bom, este ponto é abstrato para abordar, prefiro não colocar “lenha na fogueira”. mas existem sim, aplicações complexas que conterão bugs pro resto de usa existência.

cara, não sei se esta semântica está correta. Acredito que um bug existe independente de ter sido encontrado. Mas vou rever este conceito, pode ser que você esteja certo…

[quote=fernando.palma][quote]O que é isso ? uma desculpa ?
Não importa o tamanho da aplicação (não existem aplicações pequenas) . Competência é competência.[/quote]

Bom, este ponto é abstrato para abordar, prefiro não colocar “lenha na fogueira”. mas existem sim, aplicações complexas que conterão bugs pro resto de usa existência. [/quote]

Apenas e só se ninguém procurar pelos bugs. Se vc procura e não encontra é porque não tem. bugs só existem quando identificados e reproduzidos, sim. A repetabilidade é condição sin qua non para que seja considerado um bug porque só bugs que podem ser repetidos podem ser resolvidos.

O erro é pensar como vc por que isso simplesmente leva ao desleixo. Vc não procura o bug vc deixa o bug ser encontrado. É diferente.
A metodologia de testes moderna obriga vc a procurar o bug. A exercitar o sofware de mil maneiras antes dele estar pronto para homologação. Estar testado e com zero bugs identificados é condição sin qua non para que o software seja considerado pronto e intergável.

qualquer coisa fora disto é desleixo, reserva mental ou falta de profissionalismo. Tudo razões para o contrato seja terminado , indenizações sejam pedidas e pessoas sejam demitidas.

Aahh! isso explica muitas coisas…
Vc tem duas opções , ou aprende a fazer direito ou desiste de ser gerente. O seu ponto de vista é totalmente retrógrado e ultrapassado.

Discord totalmente. Um bug não identificado é um BUG não identificado. Assim que encontrar, tem de corrigir e tomar medidas pra evitar que outro aconteça.

Percebem que a discussão é porque estão chamando de bugs a coisas diferentes?

Bug em si, o máximo que dá pra ser negociado é o prazo de entrega, se identificou 10 bugs, sendo 3 críticos e o cliente está precisando, poderia estudar liberar uma versão com a correção dos principais e deixar os mais demorados pra entregar em seguida.

Essa é a máxima tolerância que acredito que um software pode ter. Passar um bug batido acontece, tanto no Google quanto no Windows. Recentemente a MS corrigiu um bug do IE que tinha 9 anos!!

[/quote]

Cite um caso de bug num software do google. fiquei curioso …
Que os softwares da MS tem bugs não é novidade. E os têm exactamente porque a microsoft adopta a politica que vcs estãos defendendo - que é lícito enviar software com bug para o cliente.

Vc está confundindo “risco” com “erro”. Vc deixaria-se ser operador por um médico que comprovadamente deixa material de cirurgia
dentro do paciente em 1 de cada 10000 operações ? eu não deixaria.

É claro que existe o risco de qualquer médico fazer isso, mas a probabilidade é tanto menor quanto a qualidade e o profissionalismo dele.

O problema não é o erro acontecer , o problema é ele não ser corrigido e existem forma de os corrigir antes que aconteçam.

cenário 1: vc é operado e vai para casa . depois vc descobre que tem uma tesoura dentro si. Vc processa o hospital. O erro aconteceu e permaneceu.
cenário 2: vc é operado e o médico deixa a tesoura dentro de si. antes de vc da sala o material é contabilizado. É dado por falta da tesoura. Vc é aberto e a tesoura tirada. Vc vai para casa e sem problemas. O erro aconteceu mas foi corrigido a tempo. Ninguem é processado.

A analogia é simples: O software é vc, a tesoura deixada é o bug. O médico é equipe/empresa de desenvolvimento. contabilizar o material é boa prática. é isto que vcs não entenderam : se vc seguir boas práticas os defeitos entregues são ZERO. Isso não significa que não aconteceram, o sistema pode ter milhões de defeitos. quer dizer que TODOS foram corrigidos. Não tem essa de entregar o software com alguns erros. Seja 1 , 10 ou mil.

Entregar software com erros identificados é absolutamente imperdoável. O problema é que os clientes ainda não aprenderam a se defender disso. Eles não enxergam que podem processar a empresa que fez o software.

Qualidade de software é exigida mas não é verificada. Esse é o problema. E por isso ideias como as vossas ainda sobrevivem e é por isso que a produção de software atrai tantos picaretas anti-profissionais.

Nunca aconteceu com você de tentar acessar o e-mail do google e dar erro?

Veja:

http://www1.folha.uol.com.br/folha/informatica/ult124u617990.shtml

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

Nunca aconteceu com você de tentar acessar o e-mail do google e dar erro?

Veja:

http://www1.folha.uol.com.br/folha/informatica/ult124u617990.shtml

[/quote]

Tem graça. Se vc chama isso é um bug , isso diz muitas coisas sobre você…
Isso não é um bug do software do google. Leia a noticia direito!

E não , nunca deu erro quando acesso o gmail (nem nenhum outro software ou api do google)

P.S. Pare de cria sobre-assinaturas. Use o recurso de assinatura…ah! vc já está usando… use direito.

A indisponibilidade do sistema demonstra uma falha de requisitos não funcional. Disponibilidade é um requesito de qualquer sistema: não funcional.

Se ele ficou indisponível, ocorreu uma falha, que em GSTI nós chamamos de incidente. O software do google falhou.

Dei um ctrl + C no texto:

[quote]
Ele acrescenta que estão tentando resolver o problema e esperam ter mais informação a respeito em breve.

Sugere ainda o uso de IMAP ou POP --para receber e-mails via softwares como Outlook Express, por exemplo-- enquanto o problema persiste.

O escritório do Google no Brasil informa que ainda não sabe a extensão, [size=18]tampouco a causa do problema[/size]. No entanto, a companhia diz que a instabilidade não atingiu todas as contas ao mesmo tempo. Alega que ainda há contas funcionando e que o retorno das outras será gradual.

O analista de pesquisas Júlio Boaro, da Escola do Futuro da USP, afirma que é nessa hora que percebe como depende da internet. “Todo o laboratório usa, é o e-mail padrão daqui”, diz ele. “Dá vontade de ir pegar o ônibus para ir embora, ou começar a arrumar papéis.”

Em fevereiro e maio deste ano, internautas também relataram dificuldades para acessar o e-mail do Google.[/quote]

Ok, vou usar menos as assinaturas. Não quero infrigir regras da comunidade.

Alguém concorda/discorda que isto é uma falha de sistema? Independente da característica semântica da palavra “bug”.

Quando planejamos uma aplicação, devemos evitar falhas de requisitos não funcionais tais como performance, disponibilidade, segurança entre outros.

Outros bugs do google:

-No inicio do orkut, ocorriam pagias de erro.
-Não sei se ainda ocorre hoje, mas as vezes o orkut dava um número de amigos/usuários de comunidade errado: enumera(va) 12 onde existe(am) 13 ou 14
[b]
Com o número de fãs isso sempre ocorreu.

Existe até uma comunidade:[/b]

http://www.orkut.com.br/Main#Community?cmm=123990

Mais sobre bugs do orkut: http://www.cdmj.com.br/forum/index.php?showtopic=3360&st=0

Fernando, esse exemplo que voce postou nao tem nada a ver com o assunto que esta sendo discutido.

Como esta bem claro no texto, ninguem sabe o que aconteceu. E voce ja diz logo que é bug. Isto pode ser causado por n problemas. E ainda que sejam bugs, ninguem vai ser obrigado a daqui pra frente conviver com eles, porque um gerente qualquer gritou la da sala dele: “Ei, deixa isso assim mesmo. Isso nao é importante.”

Os erros acontecem, mas conhecendo o erro permitir que ele va pra producao é irresponsabilidade e descaso.

As tuas ideias beiram o absurdo, e o pior de tudo é que sao frequentes.

Bugs do gmail: http://www.webmasterworld.com/forum100/77.htm

Bugs no google chrome: http://www.chromebrasil.com.br/google-chrome-bugs/

Eu nao uso produtos do google com tanta constancia pra dizer se é livre de bugs ou nao.

Sobre o Orkut, lembre de que ele nao foi feito pela Google, ele foi comprado e melhorou muuuuuuuito depois disso.

Aceitar que o sistema será entregue com uma % de bugs é o mesmo que aceitar a baixa qualidade da equipe técnica. Hoje existem metodologias e técnicas que impedem que erros de implementação ocorram.

Se basear no google ou em outro software open source não é correto, pois em sua grande maioria são criados por hobbistas e com o tempo vão amadurecendo até se tornarem aplicativos realmente a nível de produção, é só notar que o google normalmente coloca a palavra BETA nos aplicativos ainda novos.

Agora se uma empresa chega pra mim com um sistema CRUD e me coage a assinar um aceite eu no mínimo mudarei meu fornecedor.

Na boa, você claramente não sabe do que está falando.
Disponibilidade nunca é 100%. É esperado que possa existir falha (falha não é bug!!!) por isso se mede em percentagem.
A disponibilidade mede-se pelo tempo de disponibilidade sobre o tempo de funcionamento. Se o google ficou fora algumas horas , ou mesmo 1 dia. Isso é uma disponibilidade de (365-1)/365 = 99,73 % o que é muito bom. Teriamos que comparar com a disponibilidade
prevista para saber se houve incidente. Se o previsto foi 99% não houve. Se foi 99.9% houve. E repare que vc precisa de esperar 365 dias para concluir se houve ou não. Mesmo que tenha havido não é um bug do software. Disponibilidade é uma qualidade da aplicação! O software do google não falhou.

Na boa, se vc não sabes estas distinções básicas vc quer vir explicar como se testa software ? Assim não dá. Não de explicar o que não se sabe.

Concordo!

[quote]Teriamos que comparar com a disponibilidade
prevista para saber se houve incidente. Se o previsto foi 99% não houve. Se foi 99.9% houve. [/quote]

Sempre que um sistema fica indisponível (indisponibilidade não prevista) é um incidente.. Incidente é qualquer evento que cause ou possa causar parada em um serviço de TI.

A comparação que você fez foi para saber se o nível de Acordo de Nível de Serviço foi ou não violado. Caso sim, pode existir uma multa contratual, pois o nível de serviço entregue foi abaixo do que foi acordado.

Discord totalmente. Um bug não identificado é um BUG não identificado. Assim que encontrar, tem de corrigir e tomar medidas pra evitar que outro aconteça.
[/quote]
você não entendeu… ninguém não pode falar que um sistema está bugado enquanto não tiver um erro para apontar! Portanto, aquelas pessoas com lama até o pescoço, virem com aquele papo “todo software tem bugs” pra cima de quem corrige e previne problemas é muita cara de pau!
[/quote]