tag:blogger.com,1999:blog-2941525253452945348.post3246210866429027598..comments2023-07-26T03:00:06.033-07:00Comments on Testes De Software: Execução de Testes e Gestão de TestesFernando Palmahttp://www.blogger.com/profile/04082297387052587820noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-2941525253452945348.post-69186260092554022882008-09-09T07:53:00.000-07:002008-09-09T07:53:00.000-07:00excelente artigo publicado, estou começando agora ...excelente artigo publicado, estou começando agora no ramo de teste de software e ache muito interessante dicas e expecificações!gostaria de estar sempre me atualizando sobre o assunto, se puder postar mais assuntos.obrigadoMaikhttps://www.blogger.com/profile/03226991223830467930noreply@blogger.comtag:blogger.com,1999:blog-2941525253452945348.post-64686620152368613172007-10-23T08:22:00.000-07:002007-10-23T08:22:00.000-07:00Este comentário foi removido pelo autor.tesTsethttps://www.blogger.com/profile/08939477030525786583noreply@blogger.comtag:blogger.com,1999:blog-2941525253452945348.post-57373911386570099382007-05-01T13:45:00.000-07:002007-05-01T13:45:00.000-07:00Olá, Lucio,Como tentei abordar no fim do Artigo...Olá, Lucio,<BR/>Como tentei abordar no fim do Artigo, penso que podemos até atingir uma qualidade razoável usando poucos recursos e menor quantidade de testes. Mas com uma quebra destes ciclos gerenciais que mencionei acho pouco possível. Por exemplo: você pode decidir fazer 50% dos testes e ter um resultado razoável ou até bom. Mas se decidir testar sem um ambiente de homologação já está se arriscando demais.<BR/>Espero que tenha abordado o que realmente você quis expressar...<BR/><BR/>Eu estou terminando um Artigo que não é exatamente o que propôs, mas é bem semelhante, fala de como evoluir o processo dentro de uma estrutura simples, com apenas um profissional de testes. Aguarde !<BR/><BR/>obrigado pela sua visita e comentário!<BR/>Até mais.Fernando Palmahttps://www.blogger.com/profile/04082297387052587820noreply@blogger.comtag:blogger.com,1999:blog-2941525253452945348.post-58437947462828607412007-05-01T09:08:00.000-07:002007-05-01T09:08:00.000-07:00Nando,Massa essa iniciativa que esse blog tenha bo...Nando,<BR/>Massa essa iniciativa que esse blog tenha bons frutos!<BR/><BR/>abraço!<BR/>depois visite http://estudantenaengenharia.blogspot.comDanilo Mascarenhashttps://www.blogger.com/profile/15108845978213864526noreply@blogger.comtag:blogger.com,1999:blog-2941525253452945348.post-58494183801933961932007-04-30T06:22:00.000-07:002007-04-30T06:22:00.000-07:00Trabalho numa empresa pequena que busca melhorar a...Trabalho numa empresa pequena que busca melhorar a qualidade de seus software. Conseguimos alcançar boas marcas com teste de software, mas nosso problema é a continuidade; manter constante as boas práticas demanda tempo, que numa pequena empresa corresponde a dedicação, coisa difícil quando um profissional "joga em todas posições".<BR/>Se é que é possível, sugiro um artigo sobre manter a qualidade de software com poucos recursos.<BR/>No mínimo, é um desafio.Lucio Antoniolohttps://www.blogger.com/profile/02709705734650275550noreply@blogger.comtag:blogger.com,1999:blog-2941525253452945348.post-53903279093553409032007-04-29T10:09:00.000-07:002007-04-29T10:09:00.000-07:00Fernando, muito bom o artigo! E excelente iniciati...Fernando, muito bom o artigo! E excelente iniciativa de ter um espaço a mais sobre testes. Parabéns!!!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2941525253452945348.post-91814708143448777112007-04-28T17:09:00.000-07:002007-04-28T17:09:00.000-07:00Ótimo conteúdo !Ótimo conteúdo !Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2941525253452945348.post-13948017970847563652007-04-26T13:11:00.000-07:002007-04-26T13:11:00.000-07:00Ok, João! Realmente, neste caso não haveria grande...Ok, João! Realmente, neste caso não haveria grandes problemas funcionais em existir o paralelismo entre as atividades de homologação e correção. Portanto que sejam em ambientes diferentes. <BR/><BR/>O importante é que o que está sendo testado não sofra modificações. E que os erros sejam devidamente documentados (mesmo os que forem tratados no outro ambiente antes dos testes terminarem, como propôs).<BR/><BR/>Talvez, isso pudesse ser acrescentado ao artigo, como uma tática que é desenvolvida na pratica para acelerar o processo sem comprometer a qualidade. É verdade que as fabricas de software realmente adotam esse recurso. <BR/><BR/>Mas é preciso tomar alguns cuidados, que muitas vezes tornam essa estratégia não recomendada. Vamos às ressalvas:<BR/> <BR/>1. Para corrigir um erro, o programador precisa de uma avaliação do Analista do Sistema/Gerente do Projeto, uma espécie de “ok, temos que corrigir isso!”. Mas pra esta decisão, o responsável pelos testes deve estar presente e participar da decisão (algo como, defender o trabalho dele). Só que ele ainda está testando o sistema.<BR/><BR/>2. Quando os programadores não conseguem simular os erros encontrados, pedem ajuda ao homologador que o encontrou. Se isso acontecer enquanto a homologação estiver ocorrendo, pode dispersar o profissional. <BR/><BR/>3. Uma parte das falhas encontradas são influenciadas pelo ambiente, pela configuração. Portanto só podem ser avaliadas e corrigidos no ambiente de homologação. <BR/><BR/>4. Quanto aos outros erros (que não dependem de ambiente), os programadores devem tratar em desenvolvimento e ao final do trabalho do homologador, repetir seus testes unitários no ambiente de Homologação. Ou seja, ele não pode pré-supor que está funcionando porque corrigiu em desenvolvimento. Isso significa que ele se vê obrigado a fazer o teste unitário 2 vezes; enquanto no processo tradicional, faria uma vez só no lugar definitivo : em homologação.<BR/><BR/>5. Quando um programador acompanha um relatório de erros e vai os corrigindo na medida que toma conhecimento, corre o riso de ter que fazer uma correção que envolve e modifica algo que ele acabou de corrigir (há 5 erros atrás, por exemplo). Por isso, costumo propor uma leitura completa antes de iniciar as correções. Essa pratica não seria possível antes do fim dos testes. <BR/><BR/>Mesmo assim, a estratégia ainda pode ser usada se for tomado o devido cuidado e criadas algumas “regras alternativas” (baseadas nos problemas elencados aqui).<BR/><BR/>Boa observação!<BR/>Até mais.Fernando Palmahttps://www.blogger.com/profile/04082297387052587820noreply@blogger.comtag:blogger.com,1999:blog-2941525253452945348.post-48439658026899499592007-04-26T13:06:00.000-07:002007-04-26T13:06:00.000-07:00Este comentário foi removido pelo autor.Fernando Palmahttps://www.blogger.com/profile/04082297387052587820noreply@blogger.comtag:blogger.com,1999:blog-2941525253452945348.post-27726873940560458562007-04-26T12:07:00.000-07:002007-04-26T12:07:00.000-07:00Ótimo artigo, Fernando!Um comentário sobre o "Cong...Ótimo artigo, Fernando!<BR/>Um comentário sobre o "Congelamento de baselines". Você disse que é necessário que a correção dos erros deve ser realizada depois da conclusão dos testes. Se você separar em dois ambientes, um para desenvolvimento e outro para homologação, não seria viável corrigir os erros durante a realização dos testes, tentando otimizar o tempo de correção e de testes? Existem desvantagens em abordar este paralelismo?JotaBêhttps://www.blogger.com/profile/12133073191975329965noreply@blogger.com