É bem comum atualmente comparar um software com produtos físicos em termos de qualidade e funcionamento. Evidentemente esta comparação até faz algum sentido, pois trata-se de consumo, porém é infundada quando se trata do quesito testes, uma vez que um produto físico é algo tangível, e um software é algo intangível. Claro que, se este software atua em uma área de segurança por exemplo, este precisa ter muito mais atenção no seu lançamento para que apresente menos falhas. Mas qual seria a diferença entre um software qualquer e um software de segurança? Apenas o investimento de tempo e recursos na área de testes ou Q.A. (Quality Assurance), ou ainda, garantia de qualidade. Portanto é importante ficar claro que não existe produto digital criado completamente do zero que não apresente falha alguma, e para isto existem recalls ou retorno para reparos. O que se faz em geral é dar muita atenção a áreas vitais do funcionamento do produto e menos atenção às áreas não vitais. Existem diversos níveis de teste de produtos, desde o básico até o profundo, tanto por parte da empresa que desenvolve como também por parte do cliente. Sim, é isso mesmo, o cliente é quem testa o seu produto de fato, então, se prepare para testar!

A diferença é que os níveis de teste do desenvolvedor são mais em níveis de funcionalidade, se um dado está indo para o lugar certo, se um campo está de acordo com o solicitado entre outros, enquanto que o teste do cliente está em nível de Layout, cores, visual, tipos de caracteres aceitos em cada campo, formas de entradas de dados e de usabilidade e experiência de usuário e o mais importante, em ambiente real, e não em ambiente simulado. Portanto, prepare-se para testar muito o seu produto durante a construção, mesmo em módulos ainda não finalizados conforme as etapas forem concluídas. Pense na construção de uma obra se está saindo de acordo com o projeto. A diferença básica é que sem o aval do cliente quando recebe algumas funcionalidades para testar, a obra não continua se for um software. O teste real acontece em produção, onde somente neste ambiente podemos medir o comportamento do produto com muitas conexões e possibilidades diferentes de uso e pessoas diferentes que pensam de formas diferentes e inserem dados de formas diferentes testam de fato o produto. Por isso é importante ter um bom suporte para que você se sinta seguro ao lançar seu produto e que responda rápido em eventuais falhas. Honestamente, até é possível reduzir e muito o nível de eventuais falhas de um software, mas isto consumiria tanto tempo e recursos financeiros que a probabilidade de inviabilidade econômico/financeira, bem como o custo de oportunidade seria altíssima.

A título de exemplo, talvez possamos estruturar os testes como sendo em níveis como segue:

1. Testes de nível 1:os mais superficiais, consumiram 10% do total do tempo e custos da construção do produto digital, e testaram funcionalidades básicas como entradas e armazenamento de dados, logins, cálculos e outras funções.
2. Testes de nível 2: Nível Médio. Consumiram cerca de 50% do total do tempo e custos de construção do produto digital e abrangem além dos já citados no nível 1, também validações de entradas de dados, tais como CPF, Número de conexões válidas, algo em termos de segurança.
3. Testes de Nível 3: Nível mais profundo. Consumiram até cerca de 200% do total do tempo e custos de construção do produto digital e abrangem além das anteriores, níveis muito fortes de segurança, ataques, testes em ambientes de produção, simulações entre outros.

Claro que ao longo do tempo este produto terá versões de correções suficientes para que as falhas sejam minimizadas ao máximo, mas é uma constante, basta verificar que IOS, Android e Windows e outros softwares lançam atualizações para correções de falhas constantemente.

Principais causas:
1. Não saber que precisa testar o produto durante a construção;
2. Não saber que existem níveis diferentes de testes de produtos digitais e que estes podem ser adquiridos conforme o nível de confiabilidade exigido pela finalidade do produto;
3. Acreditar que é possível testar absolutamente tudo em um produto digital antes de lançá-lo;
4. Comparar o nível de testes de um produto físico com um produto Digital. Não testar, mas retornar ao parceiro que testou e comprometer o resultado final do produto;

Principais consequências:
1. Pensar que um produto digital não tem qualidade em função de apresentar falhas que não podem ser testadas em ambientes de teste;
2. Gerar frustração com relação à expectativa inicial que era de perfeição e
funcionamento total sem falhas;

Soluções Possíveis e Boas Práticas:
1. Diminua um pouco suas expectativas quanto ao perfeito funcionamento de tudo no seu produto digital, e invista num parceiro que apresenta respostas rápidas e eficazes nos recalls correções que seu produto apresentar;
2. Deixe muito claro no discovery o que realmente é importante para que os testes sejam concentrados onde realmente importa;
3. Apresente os seus principais receios na fase inicial da concepção do produto. Algumas pessoas querem lançar rápido, não importa como o produto esteja, outros preferem que o produto esteja quase perfeito antes de ser lançado. Pessoas diferentes pensam de formas diferentes;
4. Verifique para qual público se destina o produto, e se precisar de níveis de testes profundos caso seu produto lide com dinheiro ou segurança de pessoas, tenha uma reserva suficiente para que testes mais profundos sejam aplicados ao seu produto antes do lançamento;
5. Considere adquirir um SLA (tempo de resposta reduzido) e/ou uma equipe disponível no momento do lançamento do seu produto até um tempo depois para que as eventuais falhas importantes sejam corrigidas rapidamente sem comprometer o relacionamento com seus clientes e usuários;

A Plathanus é um parceiro de confiança que trabalha para entregar a melhor experiência aos seus clientes no processo de desenvolvimento de um produto seja qual ele for, garantindo resultados satisfatórios.

É bem comum atualmente comparar um software com produtos físicos em termos de qualidade e funcionamento. Evidentemente esta comparação até faz algum sentido, pois trata-se de consumo, porém é infundada quando se trata do quesito testes, uma vez que um produto físico é algo tangível, e um software é algo intangível. Claro que, se este software atua em uma área de segurança por exemplo, este precisa ter muito mais atenção no seu lançamento para que apresente menos falhas. Mas qual seria a diferença entre um software qualquer e um software de segurança? Apenas o investimento de tempo e recursos na área de testes ou Q.A. (Quality Assurance), ou ainda, garantia de qualidade. Portanto é importante ficar claro que não existe produto digital criado completamente do zero que não apresente falha alguma, e para isto existem recalls ou retorno para reparos. O que se faz em geral é dar muita atenção a áreas vitais do funcionamento do produto e menos atenção às áreas não vitais. Existem diversos níveis de teste de produtos, desde o básico até o profundo, tanto por parte da empresa que desenvolve como também por parte do cliente. Sim, é isso mesmo, o cliente é quem testa o seu produto de fato, então, se prepare para testar!

A diferença é que os níveis de teste do desenvolvedor são mais em níveis de funcionalidade, se um dado está indo para o lugar certo, se um campo está de acordo com o solicitado entre outros, enquanto que o teste do cliente está em nível de Layout, cores, visual, tipos de caracteres aceitos em cada campo, formas de entradas de dados e de usabilidade e experiência de usuário e o mais importante, em ambiente real, e não em ambiente simulado. Portanto, prepare-se para testar muito o seu produto durante a construção, mesmo em módulos ainda não finalizados conforme as etapas forem concluídas. Pense na construção de uma obra se está saindo de acordo com o projeto. A diferença básica é que sem o aval do cliente quando recebe algumas funcionalidades para testar, a obra não continua se for um software. O teste real acontece em produção, onde somente neste ambiente podemos medir o comportamento do produto com muitas conexões e possibilidades diferentes de uso e pessoas diferentes que pensam de formas diferentes e inserem dados de formas diferentes testam de fato o produto. Por isso é importante ter um bom suporte para que você se sinta seguro ao lançar seu produto e que responda rápido em eventuais falhas. Honestamente, até é possível reduzir e muito o nível de eventuais falhas de um software, mas isto consumiria tanto tempo e recursos financeiros que a probabilidade de inviabilidade econômico/financeira, bem como o custo de oportunidade seria altíssima.

A título de exemplo, talvez possamos estruturar os testes como sendo em níveis como segue:

1. Testes de nível 1:os mais superficiais, consumiram 10% do total do tempo e custos da construção do produto digital, e testaram funcionalidades básicas como entradas e armazenamento de dados, logins, cálculos e outras funções.
2. Testes de nível 2: Nível Médio. Consumiram cerca de 50% do total do tempo e custos de construção do produto digital e abrangem além dos já citados no nível 1, também validações de entradas de dados, tais como CPF, Número de conexões válidas, algo em termos de segurança.
3. Testes de Nível 3: Nível mais profundo. Consumiram até cerca de 200% do total do tempo e custos de construção do produto digital e abrangem além das anteriores, níveis muito fortes de segurança, ataques, testes em ambientes de produção, simulações entre outros.

Claro que ao longo do tempo este produto terá versões de correções suficientes para que as falhas sejam minimizadas ao máximo, mas é uma constante, basta verificar que IOS, Android e Windows e outros softwares lançam atualizações para correções de falhas constantemente.

Principais causas:
1. Não saber que precisa testar o produto durante a construção;
2. Não saber que existem níveis diferentes de testes de produtos digitais e que estes podem ser adquiridos conforme o nível de confiabilidade exigido pela finalidade do produto;
3. Acreditar que é possível testar absolutamente tudo em um produto digital antes de lançá-lo;
4. Comparar o nível de testes de um produto físico com um produto Digital. Não testar, mas retornar ao parceiro que testou e comprometer o resultado final do produto;

Principais consequências:
1. Pensar que um produto digital não tem qualidade em função de apresentar falhas que não podem ser testadas em ambientes de teste;
2. Gerar frustração com relação à expectativa inicial que era de perfeição e
funcionamento total sem falhas;

Soluções Possíveis e Boas Práticas:
1. Diminua um pouco suas expectativas quanto ao perfeito funcionamento de tudo no seu produto digital, e invista num parceiro que apresenta respostas rápidas e eficazes nos recalls correções que seu produto apresentar;
2. Deixe muito claro no discovery o que realmente é importante para que os testes sejam concentrados onde realmente importa;
3. Apresente os seus principais receios na fase inicial da concepção do produto. Algumas pessoas querem lançar rápido, não importa como o produto esteja, outros preferem que o produto esteja quase perfeito antes de ser lançado. Pessoas diferentes pensam de formas diferentes;
4. Verifique para qual público se destina o produto, e se precisar de níveis de testes profundos caso seu produto lide com dinheiro ou segurança de pessoas, tenha uma reserva suficiente para que testes mais profundos sejam aplicados ao seu produto antes do lançamento;
5. Considere adquirir um SLA (tempo de resposta reduzido) e/ou uma equipe disponível no momento do lançamento do seu produto até um tempo depois para que as eventuais falhas importantes sejam corrigidas rapidamente sem comprometer o relacionamento com seus clientes e usuários;

A Plathanus é um parceiro de confiança que trabalha para entregar a melhor experiência aos seus clientes no processo de desenvolvimento de um produto seja qual ele for, garantindo resultados satisfatórios.