5 Grandes mentiras sobre Teste de Software | Base2
Thursday, 11 de April de 2013 Thursday, 7 de June de 2018 admin
← Qualister oferece curso de Automação de Testes
TAM vende passagens mais caras para brasileiros →
Márcio Eduardo Luz disse:
Friday, 17 de April de 2015 às 19:35
O item 5 é parcialmente verdade, trabalhar junto ou em grupo ou em parceria não necessariamente é ser amigo. Nesse caso, é necessário um trabalho complementar, pois o desenvolvedores tem um pensamento e os testadores tem outro, para funcionar, deve-se ter essa complementariedade e ainda, a maioria dos(as) divergências/erros/defeitos somente outras pessoas podem apontar.
Wednesday, 11 de February de 2015 às 02:19
O item 3 está fundamentalmente correto. É como um carro, você não paga (ou não gostaria de pagar) pelos selos da inspeção de qualidade, você paga pela qualidade em si (aliás aqueles selinhos no vidro são um pé, ninguém vê valor neles…). Prá mim não importa se a Rolls-Royce ou a Fiat inspeciona os carros, nem quantas vezes, me importa que eles sejam bons. A inspeção é desperdício na medida que se aumenta a qualidade (fazer certo exige menos teste). Se a qualidade DO PRODUTO (não do processo) depende de inspeção, sinal de que há pouca qualidade (no processo). A questão é que raramente se faz software que não precise de inspeção. Na linha da Lean Manufacturing e redução de defeitos (um dos sete tipos de desperdício da Lean): correção na origem. Claro que na prática a teoria é outra.
Tuesday, 20 de January de 2015 às 18:34
Assino embaixo do ítem 4. Para quem possui um processo de testes bem definido, é fato que uma automação bem feita parte minimamente de duas execuções manuais, não há como se ter automação bem feita sem um bom testador para realizá-la.
Everson Souza de Araujo disse:
Thursday, 11 de December de 2014 às 15:03
Não concordo com Cibele Scalon ate porque os testes automatizados so garante as funcionalidades se a regra de negocio mudar o teste também irá ter que mudar, alem do mais todos os testes automatizados precisa sempre de um humano, e por incrível que pareça ainda não é fato decisório nas empresas.
Anne Caroline Oliveira disse:
Tuesday, 19 de August de 2014 às 21:08
Na minha opinião o teste automatizado não sobrevive sem os testes manuais. Pois, não há teste que rode com o sistema cheio de bugs. Ou seja, antes do teste automatizado sempre tem que haver o teste manual para identificar diversos tipos de erros no sistema, para então serem criados os testes automatizados, que terão o papel de realizar o teste de regressão.
Monday, 7 de April de 2014 às 00:23
Com relação ao item 4, penso que a Automação não vai tomar o lugar de todos os testadores, mas que irá diminuir o volume de de testadores, isso é fato.
Escuto outras pérolas: "A área de Teste de Software tem que garantir a qualidade do software", bom se algo foi mal pensado, mal especificado, mal desenvolvido, como querem que no teste tudo saia maravilhosamente bem e correto?
Mais uma: " A área de Teste de Software tem que entregar o aplicativo sem nenhum erro"…como explicar que isso é impossível? Uma vez que raramente temos ambientes de teste que sejam uma reprodução mais ou menos parecida do ambiente de produção, só para citar um exemplo.
Tem mais: O software foi entregue com atraso e inúmeros erros. Devido a isso, em vários momentos do dia, a equipe de teste fica parada nas execuções. O que escutamos? "Não admito ouvir que vocês estão parados, deve haver algo que vocês possam executar". Ou, "De que adianta enviar o aplicativo para vocês testarem? Quando chega em vocês tudo fica parado?"
Wladeilson Stos de Almeida disse:
Monday, 28 de October de 2013 às 22:34
Olhá aí rodrigo gomes.
Monday, 2 de September de 2013 às 09:17
Vanessa Perote disse:
Friday, 30 de August de 2013 às 15:33
Menahem Beguin olha ai!! rrsrrs
Friday, 2 de August de 2013 às 16:32
Muito bom! Porem como o amigo Camilo mencionou, o item 4 pode ser discutível.
Saturday, 11 de May de 2013 às 18:10
Essa é pro pessoal do CQS…
Saturday, 20 de April de 2013 às 06:43
Não sei até onde concordo com o item 4 (A Automação vai tomar o lugar dos testadores). Se por testador entende-se executor de testes (que executa manualmente casos de teste) isso já é uma realidade em agile.