domingo, 3 de julho de 2022

HIT THE ROAD BUG, AND DON’T YOU COME BACK

 

 



 

PS: meu presente artigo foi publicado em 2/7/2022 no meu Linkedin.


Hoje meu artigo gira em torno de um parafraseio de um famoso pedaço de uma música: “hit the road bug, and don’t you come back”, que em tradução livre seria “pegue a estrada bug, e não volte”. Sim, frase é inspirada na famosa música de Ray Charles (“Hit the Road Jack”), um blues altamente dançante que vale a pena ouvir a versão cantada pelo grupo “Sweet Systers” e tocada pela “Tokyo Ska Paradise Orchestra” (veja AQUI).

Sim, quem trabalha em TI, sobretudo no apoio ao desenvolvimento de sistemas, que não deseja que os bugs fossem embora. Fizessem as malas e fossem embora.

Não é bem assim. Desenvolvedores, analistas de QA, gestores de projeto, usuários é que precisam expulsar o bug (por mais que seja 100% impossível) ou manda-lo para bem longe ou até isolá-lo. Todos precisam fazer isso juntos. Encontrar bugs e elimina-los não é tarefa apenas do QA/tester. É tarefa de todos.

“Mas sou faço isso, mas tem temos prazo a cumprir”.

“Não escreveu, não leu ou não validou, passou. O usuário tem de aceitar. A gente não vai pagar por isso não”.

“O bug é do colega do lado”.

“Bug não existe. Nosso sistema não tem falhas. Quando acontece é um comportamento aleatório”.

“Não precisamos melhorar o processo. Nosso processo é perfeito. Tudo funciona como uma máquina”.

“Nossos analistas de QA e desenvolvedores não precisam melhorar. Eles precisam entrar prontos aqui. Quem não sabe rua”.

“Aqui não tem isso. Usamos Ágil e usamos BDD. Sabemos fazer testes”.

Frases como essas permeiam todo o processo de desenvolvimento. E isso e ruim. Falácias claras (digo isso, com minha experiência de 30 anos em QA, por conhecer várias ferramentas de testes e usá-las, e ter escrito 10 livros técnicos e em sua maioria de testes/QA, mestrado e querer aprender sempre mais, e saber que tenho muito a aprender ainda até o momento em que eu for enterrado. Humildade e conhecimento sempre será necessária ao longo da vida).


Falácias que cometemos de forma clássica:

-Prazo nem sempre é tudo. Entregar um produto falho ou com problemas é pior que entregar no prazo cheio de bugs.

-Mesmo o usuário descobrindo um bug simples e bobo, este é problema da empresa que desenvolveu. Descobrir bugs é um processo.

-Não se empurra “bug”. Muitas empresas elegem um culpado, e caçam bruxas quando o erro muitas vezes é do excesso de pressão e do processo. Ninguém é máquina.

-Nenhum processo é perfeito. Todo mundo e tudo precisa melhorar. O aprendizado e e evolução são até final da vida.

-Até quem usa Ágil, e o defende com unhas e dentes, se esquece que nem Ágil e DevOps NÃO são 100% perfeitos, mas quando usados de maneira adequada ajudam a fazer a diferença. Isso sem se esquecer que o universo das empresas sempre está em constate mutação.

AVISO AOS NAVEGANTES USUÁRIOS E ESPECIALISTAS NAS EMPRESAS: Bug pode demitir sim! Ele não pode ser “colocado na estrada” e ir embora assim. Ele fica, se esconde, muda, muta,  evoluí, se propaga e pode (e vai se você deixar) acabar com seu negócio e até de demitir. Você verá mais adiante.

AVISO AOS NAVEGANTES, CONSULTORES RENOMADOS E DEFENSORES DA AUTOMAÇÃO E QUE FICAM COPIANDO O TRABALHO DOS OUTROS SEM DAR O DEVIDO CRÉDITO, E QUE “COBRAM” OS OLHOS DA CARA: Molinari não está morto. Quando elogio alguém espero que a pessoa me responda e seja educado. Tenho trabalhado com diversas ferramentas de automação e mergulhando em novas. Amo automação. Mas não fico falando como a automação fosse resolver tudo. AUTOMAÇÃO AJUDA EM MUITO SIM. AJUDA NA MELHORIA DA QUALIDADE EM MUITO, MAS NÃO DEVEMOS CONSIDERÁ-LA COMO UMA SOLUÇÃO PARA TUDO. Um tolo com ferramenta na mão ainda será um tolo. Eu jogo limpo, jogo feliz. Tento me superar um pouco a cada dia. E preciso... Sou um eterno aprendiz. Muita coisa minha positiva virá. Sacou? Hoje vejo quem me deu a mão de verdade. Outro dia sai de muitos grupos de Whatsapp, por conta de que estava com excesso de mensagens que precisa limpar todo santo dia. Cansa. Algumas pessoas de um desses grupos passaram a me menosprezar e não me responder mais mensagens quando contacta a pessoa em algum outro grupo. Não fico apregoando ou “colocando” no pescoço um anúncio sobre minhas habilidades, sejam elas soft e hard skills. Agora sei quem é amigo e quem não é. Percebi que quando alertei sobre projetos futuros alguns trataram de copiar e se adiantar colocando algo meio tosco. Falta “sustância” nesse conteúdo, como diria um amigo. Casos assim têm ocorrido com outros consultores. Já tive até texto de um blog meu copiado e “xerocado” sem o devido crédito. Texto esse inédito que havia escrito 24 horas antes apenas usando minha experiência. O “cara de pau” clonou o texto. Pior foi uma ouvinte numa palestra que pediu para eu autografar uma cópia completa de meu livro (que já é um crime), cuja cópia já estava autografada por mim. Recusei-me a assinar. Fui educado e me recusei a assinar.

PORQUE DO AVISO? Prefiro ser sincero e alertar, com a devida educação e cuidado, do que ser falso e mentiroso. Fazer mais do mesmo é ruim. Se inspirar em pessoas e hábitos positivos é lindo. Eu faço isso. Tenho meus ídolos.

Bug demite? Como assim? Vou contar uma estória por fim, no qual você entenderá.

Estava em empresa a alguns anos atrás, e soube de caso que passou dos limites. Durante o desenvolvimento de uma nova parte de um sistema já existente, foi feito o levantamento e a validação para seguir para o desenvolvimento. Nesse processo o cliente, uma grande multinacional, fez um documento específico que foi lido e validado. No contrato entre essas duas empresas, ficou acordado que TUDO que estivesse no documento enviado pelo cliente deveria ser desenvolvido. A equipe de validação foi ao cliente transformou item a item em requisitos. Validou novamente com o cliente e entregou ao desenvolvimento.

Tudo ocorreu perfeito, ou quase...

A nova parte foi desenvolvida, e entregue ao cliente. Foi aí que tudo começou.

No sistema faltava algo. Uma tela importante não estava lá. Analistas disseram que não havia requisito para tal e que tudo havia sido validado com o cliente. Porém, na reunião com o cliente detectaram a tal tela estava no documento entregue na forma de uma imagem enorme e o que havia sido desconsiderada pelo pessoal de requisitos. Uma simples foto que deixaram passar.  Ninguém (diga-se “quem desenvolveu”) queria pelo retrabalho. Queriam que o cliente pagasse. O fato que havia um contrato que afirmava que tudo estava no documento deveria ser entregue.

O caso chegou ao diretor da unidade Brasil da empresa que desenvolveu, responsável por toda empresa no Brasil. Ele foi ao cliente afirmou que não iria desenvolver. Bem...

O cliente foi reclamar na sede principal da empresa na Alemanha. O diretor da unidade Brasil, foi chamado na Alemanha. Sabe o que aconteceu? Foi demitido. O cliente estava certo. Estava no contrato. A equipe Brasil da empresa errou, mesmo tendo revalidado os requisitos na época.

O bug da ausência de um requisito não escrito e não visto DEMITIU o gestor da unidade Brasil.

Agora eu digo e afirmo:

Bug mata? Mata.

Bug dá prejuízo? Dá prejuízo.

Bug causa prejuízo de imagem quando cliente o encontra? Sim. Bug no cliente é como uma “infecção” que pode gangrenar um sistema. Como bem colocado por Rodrigo Peter, “Bug é Predador” e não presa.

Bug demite? Sim.

Pior bug é aquele bug que não queremos ver.

Então caro leitor, pare e pense. As consequências de um simples bug podem ser inimagináveis. Então vamos terminar ao lindo som de “Hit the Road Jack” (veja AQUI).

 

terça-feira, 9 de março de 2021

VOCÊ SABIA QUE O DIÁRIO DA QUALIDADE TEM MUITO MAIS DO QUE APENAS POSTS

 Oi Galera,

você que acompanha meu Blog Diário da Qualidade e o meu Canal Dualidade TecNerd precisa saber de algumas coisas:

a) O canal tem vídeos inteiros de palestras inteiras. Eles são muito legais.

b) O canal possui vídeos muito legais que explicam diversos pontos de nerd/geek e de TI que você precisa assistir. Não se prenda pelo título.

c) O Diário da Qualidade aqui possui muitas coisas lúdicas, técnicas e informativas. Vão desde artigos técnicos até contos técnologicos (isso mesmo, contos!) para fazer você pensar. Esses contos incluem críticas, paródias, e jogos de RPG na forma de livros-jogo (aqui são na verdade "contos-jogos") para você vivenciar o dia a dia de QA e jogar e se divertir? ONDE ENCONTRAR? Vá no lado esquerdo do blog e procure até embaixo e veja alguns que destaco. E tem muito mais. Você irá amar. Um dos contos que mais gosto é da Tropa de Testadores. Você irá se assustar mas não tenha medo.

d) Ainda tenho um blog de poesia, o Engenharia da Palavra, se desejar ver algo fora da curva. Nada aqui é por acaso. 

e) Alerto: Tudo aqui no blog e no meu canal é para ser util a você. Não menospreze nada. ATENÇÃO.

HOT==> Vá e veja meu romance, Comportamento Aleatório. Une QA+Teste+Mundo Nerd+ Super-Heróis e muito mais. É um suspense tecnologico que une o mundo de TI ao mundo geek. Veja, Leia e compre e se divirta. No livro existem muitas situações e vi ou vivi, no mundo corporativo/QA e nerd. OBAAAA!!!!! Os 3 primeiros capítulos podem ser lidos free no site da Altabooks na opção Download. Veja AQUI. Quem leu gostou e se apaixonou!!!

Forte Abraço a todos

Leonardo Molinari



quinta-feira, 25 de fevereiro de 2021

Vejam como foi a live de lançamento de "Comportamento Aleatório"

Galera, 


vejam como foi a live de  lançamento de meu novo livro "Comportamento Aleatório" (já está a venda)  no Canal da Bolsa do Infinito AQUI




segunda-feira, 22 de fevereiro de 2021

LANÇAMENTO DE MEU NOVO LIVRO - COMPORTAMENTO ALEATÓRIO

 Pessoal,

chegou meu primeiro romance. Fala de QA, Testes, Mundo Nerd, Super Heróis, e muito mais. Ele se passa entre o mundo corporativo e as lojas nerd. Muitos já compraram e tem gostado desse meu 1o romance. Tem mistério, hacker, e muito mais. Discuto além disso os preconceitos no mundo nerd/geek. Está muito legal. 

Já está a venda AQUI

Já teve uma live de pre-lançamento com a galera da Bolsa do Infinito. Veja como foi ela AQUI.

Terá uma outra live as 20hs dia 23 de fevereiro de 2021 também pela Bolsa do Infinito. Veja o canal da Bolsa do Infinito AQUI

A capa ficou linda. Você que é de QA e Testes deve e precisa ler. Não é mentira e nem errolação. Temos todos muito a aprender. Vejá lá. E mais: os 3 primeiros capítulos estão free para baixa e ler no site da editora. Veja, leia, curta e compre esse romance que mostra como o mundo nerd / geek é de fato. 

Mega master obrigado.




segunda-feira, 2 de abril de 2018

QA TEST MANAGER - O FUTURO DE UMA NAÇÃO DE BITS (ATUALIZADO)

Resultado de imagem para QA TEST MANAGER

PS: ATUALIZADO EM 3/4/2018


Pessoal,


nem sempre escrevo no meu blog aqui. Mas se você vasculhar sempre encontrará coisas úteis. Gosto de agregar valor ao que se lê. Não sou de copiar textos porque procuro criar coisas. Quando me referencia a algo, me baseio sempre usando ABNT.

Chega de blá blá blá. Estou com sede de bugs... hahaha  Brincadeirinha pessoal. O assunto é sério.

Primeiro o título se refere ao papel essêncial que um gestor de QA / Testes (ou QA Test Manager) precisa ter perante a nação que ele cuida. A nação dos bits e bytes dos softwares envolvidos na sua gestão. Sim, esse talvez seja o maior erro que os QA Test Managers tendem a fazer. Não considerarem que eles são uma espécie de "Guardião da Galáxia" , onde o seu papel é o de líder. Não pode estar em todo universo do software exterminando bugs e defeitos, mas deve estar coordenando e liderando (sim, as duas coisas ao mesmo tempo) a equipe de testes na direção dos objetivos e sempre, sempre, negociando com todos ao redor, e avaliando apontando a rota certa que deve ser seguida nessa odisseia.

Em resumo ele precisa ser alguém que entenda de gestão de projetos, de testes, e ser um gestor que gosta de tecnologia. Por isso é alguém que una uma carreira técnica com a administrativa.


PORQUE VOCÊ MOLINARI ESTÁ ESCREVENDO ISSO?

Porque poucos sabem mas já atuei diversas vezes de forma de QA Test Manager "interventor" ou "advisor" ou mesmo substituindo outros de forma temporária. Na prática nunca me foi dado a função ou cargo formal porque o "Molinari bombeiro" depois de apagar o incendio ou normalizar a situação precisava agir (por ordens superiores) em outro projeto ou empresa. Só para vocês imaginarem, já atuei orientando um QA Test Manager do zero que nada sabia em uma grande empresa. Meu mestrado profissional em administração (com titulação formal, pois sou mestre de fato) reforça meu perfil e capacitação para estar escrevendo isso aqui e afirmando publicamente isso. Então, tenho os dois perfis. Então, escrevo com sabedoria e fico a vontade na função. 

PS:  **** VEJAM NO MEU CANAL  DUALIDADE TECNERD (aqui) UM VIDEO ONDE FALO DE QA TEST MANAGER  ****


Então que função é essa de QA Test Manager? Vamos definir mais formalmente:

a) Gestor ou Gerente da área de testes & garantia da qualidade de software

b) Função técnica e gerencial ao mesmo tempo.

c) Define, negocia e/ou aprova os padrões de qualidade de software desejados em um processo de software de forma a atender aos objetivos dos negócios da empresa e de seus clientes.

d) Saber focar nos resultados desejados pela direção da empresa.


O que ele PRECISA SABER:

a) Saber de: testes de software, de testes funcionais, de testes de performance, padrões de qualidade de software, de gerência de defeitos, de requisitos de software, automação de testes, de métricas de testes e gestão de defeitos de software.

b) Saber de técnicas administrativas como: gerência de projetos (GP), gestão de recursos humanos e equipes, técnicas de negociação, e gestão financeira.

c) Saber controlar os custos e qualidade de sua gestão na medida certa. Reduzindo de forma consciente os custos, e aumentando a qualidade de forma constante.


O que seria bom ELE SER OU TER OU TRAZER: 

a) Agregador de pessoas mostrando que a qualidade é de todos.

b) Pró-ativo.

c) Organizado mas gostar de trazer inovações ao processo de testes. Um processo precisa estar em constante melhoria.

d) Visão consciente de que sua equipe não é composta de robôs, mas de pessoas que se motivadas por fazer muito mais.

e) Automação em todos os níveis do processo de testes, na medida do possível, e de forma consciente e produtiva.


Coisas chaves que ele  PRECISA para controlar o seu processo: 

a) Métricas de controle do processo, ou KPI´s de testes (Key Process Information).

b) Saber aferir se a qualidade dos testes de sua equipe está boa ou não. Para isso as KPI´s são importante mas não é só isso.

c) Ser um gestor e saiba negociar com todos ao redor. Pois sempre existirá pressões.


KPI´S DE TESTES DE SOFTWARE

Algumas métricas e KPI´s que são úteis ao testes:


Tipo de Métrica
Foco
Métricas
Absolutas
Tiradas diretamente do ambiente de testes
Total de testes
Testes Passed / Failed
Testes Executados / Blocked
Defeitos encontrados (total)
Defeitos corrigidos (total)
Defeitos críticos (total)
Defeitos aceitos porém rejeitados
Horas de teste gastas
Horas gastas para consertar os defeitos
Defeitos e Bugs encontrados after shipped
Derivadas – Eficiencia dos testes
Mede o quão é eficiente foram os testes
- (testes Passed) / (Total de testes)
- (testes Failed) / (Total de testes)
- (Defeitos corrigidos) / (Defeitos encontrados)
-( Defeitos críticos) / (Defeitos encontrados)
-( Horas gastas para consertar os defeitos) / / (Defeitos encontrados)
Derivadas – Esforço
Mede esforço do teste
-( Defeitos encontrados) / Horas de teste gastas
-( Defeitos encontrados) / Total de testes
Derivadas – Eficácia dos testes
Mede eficácia dos testes
- (Defeitos encontrados antes dos testes) / (total de Defeitos encontrados nos testes e Bugs encontrados after shipped)
Derivadas – Cobertura do teste
Foco sobretudo no quão os requisitos estão cobertos por testes
- (Testes Executados) / Total de testes
- Requisitos com teste / Total de requisitos
- Total de defeitos por Requisito
Derivadas – Economia dos testes

- Orçamento para testes / Total de testes
- Orçamento para testes / Total de requisitos
- Custo planejado – Custo Previsto
- (Custo hora médio do desenvolvedor por hora) * qtde de horas gastas
- (Custo hora médio do testador por hora) * qtde de horas gastas no teste realizados naquela versão.
-Custo do não teste 
Derivadas – Time de teste

Distribuição de defeitos por testador
Distribuição de defeitos abertos para reteste
Distribuição de testes alocados para testes por pessoa
Derivadas – Execução

Status x  Qtde de testes no status

Derivadas – Distribuição de Defeitos

Defeitos abertos x Defeitos corrigidos (IMPORTANTE)
Defeitos distribuídos por prioridade
Defeitos Distribuídos por Severidade
Defeitos Distribuídos por Tipo Geral de Problema
Defeitos Distribuídos por Plataforma  ETC.


E o dia a dia do QA Test Manager ?

- Gerenciar sua equipe, acompanhar as KPI´s, negociar prazos com as prioridades, entender e melhorar o processo, conversar com a sua equipe e saber como andam as coisas, etc.


Que tipos de QA Test Manager existem?

a) De empresa não fábrica de software cujo departamento possui vários analistas de testes sob sua supervisão. Ele negocia com outros sua alocação e qualidade do que está sendo feito. Aqui ele é mais um gestor de testes onde está mais próximo da equipe.

b) De fabrica de software onde mesmo acima ocorre porém os prazos e padrões mais pressionados de forma que o mesmo é mais gestor administrativo do que de testes. Ele precisa definir, otimizar e melhorar o processo de testes.


Quais os principais problemas dos QA Test Manager na essência?

É justamente não saber realmente sobre testes. Muitos GP são elencados a QA Test Manager e mça sabem sobre testes. Por outro lado os QA Test Manager que tenho observado que ascenderam de lideres de testes pecaram em pouco agregar do lado administrativo e pouco ligam para gestão de equipes. O ideal não existe. Mas pode-se chegar bem próximo do ideal para empresa e para a equipe.


Se eu preciso ser um Líder, qual tipo eu preciso ser?

Os principais tipos de liderança de acordo com Santos (2018), são:

a)  Líder de Resultados - tem foco nas expectativas, seja pessoal ou para as pessoas. Foco nos resultados.

b) Líder de Pessoas - Habilidade de formar (e sustentar) relacionamentos focado no bem estar positivo de todos.

c) Líder de Processos - Foco no processo. Faz questão de seguir o processo. Foco na criação, monitoramento e endosso das regras e procedimentos do processo.

d) Líder do Pensamento - Foco na criatividade como solução de problemas. Usa isso como motivação.

e) Líder Social - É o líder das conexões, ou seja: habilidade em comunicação, “networking” e criação de conexões. Líder agregador.

f) Líder de Dados - Busca  basear suas decisões nas informações que coleta. Habilidade em analisar fatos, detectar tendências de modo a estabelecer credibilidade. Líder voltado para inovação.


Se eu tiver de fazer uma entrevista para QA Test Manager?

Não existe regra. Você precisa ficar alerta para todos os pontos do presente artigo, como KPI´s. Precisa saber apresentar numa entrevista que você deu resultados para justificar sua contratação. Muitos gestores querem apenas um administrador que tenha uma boa noção de testes. Outros querem alguém que tenha vivência em testes que foi levado a essa função. Mas ambos se esqueçem que um profissional com ambos os requisitos pode ser um lider que não somente traga resultados, mas agrega valor a equipe, trazendo harmonia e motivação a todos o seu redor.

Segundo Swati (2008), existem alguns pontos numa entrevista para QA Test Manager aborda 3 principais áreas:

1) Conhecimento técnico e expertise.
2) Atitude.
2) Comunicação. Algo problematico de se avaliar numa entrevista.

Ainda segundo mesmo autor, existem algumas questões que são realizadas nos 2 primeiros pontos acima, tal como:

a) Regras e responsabilidades no projeto de testes, e como você dividiria o tempo.
b) Que processo de QA é usado no seu projeto e como.
c) Você já esteve envolvido em estimar testes (olha a KPI aí gente!!!)
d) Que ferramentas você usou e porque para automatizar os testes.


Quais as maiores lições principais que devemos nos deter nessa profissão?

São coisas básicas mas que diariamente fazem a diferença na qualidade de seu trabalho:

a) Saber fazer e criar relatórios úteis para apresentar o resultados, observando o que precisa mudar e os desafios. Sem contar com os relatórios de acompanhamento semanal baseado nas KPI´s (olha ela aí gente!!!)

b) Saber o valor de um time e um time com boa qualidade. Igual ao futebol. Voce pode ter um time entrosado mas sem craques ou bons jogadores, mas que joguem simples e corretos. Por outro lado um ótimo jogador num bom time e um time entrosado de bons jogadores faz a diferença como uma seleção.

c) Para entender o que acontece muitas vezes você entender a visão dos outros. Isso pode ser para resolver um problema ou para melhorar algo.

d) Na prática o trabalho de um QA Test Manager é multi-tarefa. É fundamental ter noção disso.

e) Gerenciar pessoas é ao mesmo tempo fácil e dificil. Facil porque se souber escutar e agregar a equipe ganhará. Porém quando existe conflitos se faz preciso ter paciência, ceder ou dizer não. Se você tem a noção do todo, você o valor ou prejuizo de um bom gerenciamento humano.



SERÁ QUE ARTIGO AQUI AJUDOU ?

Espero que tenha ajudado e esclarecido muito á muitos que tinham duvidas sobre essa função, e lembram que nem sempre o que sabemos é o suficiente para melhorarmos. Humildade faz parte e saber dizer não quando precisamos é fundamental. Lembre-se: um QA Test Manager negociará sempre e com quase todos, sejam diretores ou analistas de testes.


PS:  **** VEJAM NO MEU CANAL  DUALIDADE TECNERD (aqui) UM VIDEO ONDE FALO DE QA TEST MANAGER  ****


Referências:

-SANTOS, R. Você sabe qual é o perfil da sua liderança. Disponível em: .  Acesso em: 02 abr. 2018.

-SWATI, S. 6 Most Common QA Test Lead/Manager Interview QuestionsDisponível em: .  Acesso em: 02 abr. 2018.



Abs


Leonardo Molinari


quarta-feira, 18 de outubro de 2017

LANÇAMENTO DO NOVO LIVRO + PALESTRA


Pessoal,

agradeço a todos que puderam e conseguiram assistir ao evento do Meu Canal DUALIDADE TECNERD. Falei de Testes, Agile Reinventado em diversas áreas como IA.

Na 3a e última palestra (que ainda se encontra disponivel no canal), falo de Cloud Compiting, e lanço com exclusividade meu 10_o livro: "CLOUD COMPUTING - A INTELIGÊNCIA DA NUVEM E SEU NOVO VALOR EM TI", também pela editora Erica / Saraiva do selo Somos Educação. A palestra fala de Computação e detalha a nova obra que vem com diversas novidades e assuntos abordados além da própria nuvem.

Link do Canal: https://www.youtube.com/channel/UCNR3WTAhFJXxn96QDgiyeGQ

Abçs a todos.

Leonardo Molinari


segunda-feira, 2 de outubro de 2017

NOVO EVENTO ONLINE: O DUALTEC CHEGOU

Resultado de imagem para news

Galera,

chegou o 1o evento do canal Dualidade TecNerd (clique aqui), o DUALTEC. Serão 3 palestras. Cada palestra estará disponível ao fim da tarde, mas o assinantes do canal serão logo avisados assim que for publicado.

o EVENTO ocorrerá nos dias 3, 4 e 5 de outubro.

Cada palestra ficará cerca de 24 horas disponível no canal. Quem viu, viu, e quem não viu, não viu. Simples assim.

Na 3a palestra palestra haverá um lançamento exclusivo  e essa sim, ficará mais tempo disponível. Então vejam e assim o Canal Dualidade TecNerd em seu primeiro evento técnico.  Nesse ultimo estarei online para responder duvidas e perguntas a partir das 19hs por cerca de hora.

Abçs e Vejam Lá.

Leonardo Molinari


quarta-feira, 21 de junho de 2017

ACABOU: FIM DA BARREIRA ENTRE INTELIGÊNCIA ARTIFICIAL (I.A.) E TESTES

 
Srs.,


não é filme de ficção.

Não estou delirando.

Pirei? Ainda não.

Aqui eu já havia falado em meus posts e/ou no meu canal DUALIDADE TECNERD (acesse o canal aqui) já aconteceu e já tem pesquisadores e somente reforça aquilo que tenho falado por aqui mas parece que estou falando grego. Não estou. Se acham que estou falando grego vejam alguns links, mas ANTES vejam o que coloco aqui no post. Os mais curiosos vejam:

Link1, Link2, Link3,

Continuando...

I.A.  (ou inteligência artificial) tem sido pesquisada em diversas frentes e tem se integrado com:

-Nuvem ou Cloud Computing, através de máquinas de aprendizado ou machine learning
-IoT (internet das coisas) através de dispositivos com softwares especializados capazes de tomar decisões em um contexto especifico.
-Desenvolvimento de software, através de parte de analise e modelagem e até de testes.
-Area móvel. Sim. E muito.

A IA tem 5 grandes desafios: aprendizagem, raciocínio, compreensão de linguagem, percepção, resolução de problemas. Cada qual apresenta sua pratica e um campo de pesquisa dentro de IA. Campos de pesquisa relacionado com IA como robotica que envolve mecanica, reconhecimento de padrões e IA é dificil. Para nós pode ser facil segurar uma xicara de café, mas para um robô nâo. Nisso as maquinas mesmo com os melhores softwares levam ainda desvantagem.

Segundo os dois livros, "Segunda Era das Maquinas" e o "Humano mais Humano", tratam da revolução dos computadores e da IA, em seus diversos contextos, o vivemos uma nova revolução computacional. O software que você usa no seu smartphone hoje, se for um android, tem uma opção no teclado que ao ser acionada trasforma sua fala em portugues para texto, e o sofwtare aprende com isso. VOCÊ JÁ ANDA COM UM SOFTWARE DE I.A. NO BOLSO, e não sabe. Compreensão de linguagem é um campo de IA. Aqui no caso desse software seria de transformação de linguagem falada linguagem escrita...


XI... PIREI. 


Quando restringimos um campo ou um problema especifico a IA tem maior eficiência e eficacia. Se  aumentarmos o leque de opções fica dificil. Um software comum, pode quando focado em um problema ter maior eficiencia, como um calculo matemático. Para nos mortais isso fica dificil quando o calculo é extenso. Agora para máquinas/software de IA, fica fácil. Agora quando você olha alguem que pela cor do olho e afirma que aquela pessoa foi seu amigo, ninguem explica. Se você está certo e ninguem explica então é um padrão que ninguem explica, fica complicado. Com IA é dificil, porque esse reconhecimento de padrões, mesmo que de forma não logica. Posso afirma que você pode "treinar uma IA" como pintar ou desenhar como grandes pintores e desenhistas, mas ela nunca será por iniciativa propria um pintor unico. Falta o toque de criatividade. Mas se IA for focada e  apoiar-nos em um campo de visão menor, IA pode ser decisiva e vital.


Xiii... PIREI MAIS AINDA. E TESTES ? 


Em testes ela entra por tabela em softwares e campos como:

-Chat Bots: muitos call centers estão sendo online substituídos por chat bot, ou programas de conversas (bot ou programas de IA para conversas) que conversam com você tentando te informar de problemas. Esses tem limitações e o teste não obvio, mas na integração de software com situações tipicas e integração do mesmo com a base de dados.

-Maquinas de aprendizado para decidir melhor: como você testa isso? Amigo você não tem como testar 100%. Você testa situações normais em um primeiro momento e tenta verificar se o seu processo de aprendizado está "razoável", para opinar ou orientar diversas soluções.

-Apoio a analise de problemas de forma prévia: A galera da IBM de IA tem focado em sua solução o Watson, que ultimamente visa ser uma especie de doutor online. Dado tantas doenças e possiveis diagnosticos e vários informações e casos é como um medico que aprende e se esqueçe. O Watson apoiaria em não esquecer e apoiar até o medico real. As vezes a pessoa é um caso, de um caso, de um caso que o doutor não se lembra direto, ai o médico entraria validando e até reforçando pre diagnostico do Watson.

-Carros com IA que dirigem sozinhos: nos EUA já temos vendas desse tipo de carro sem motoristas.  ISSO MESMO, SEM MOTORISTAS. Tem legislações de cada estado, mas temos a industria automobilística ficada nesse sendo. Reconhecimento de VOZ é um recurso normal em muitos carros, mesmo tendon um motorista. Como testar? Através de casos e situações e nos (de QA) aprendermos conceitos e entrarmos em IA.


AINDA ACHA QUE ESTOU LOUCO? 


A Microsoft, A Google, A IBM, a Amazon se uniram em um consorcio para mostrar para o mundo inteiro o papel e importância em IA, e para padronizar IA no mundo (veja AQUI). Muitos tem medo que "um robô vai tomar seu emprego".


E AGORA, DÚVIDA?


A mais: muitos especialistas em QA, analistas e outros consultores não estão levando isso a sério em breve vão perder o bonde de TI. Isso vale para CLOUD COMPUTING e IoT. Acho que não estou tao louco. O Brasil está definindo e expondo para o mundo um Plano Nacional para IoT em 2017. Só digo uma coisa: as coisas estão mudando.

Abçs

Leonardo Molinari

quarta-feira, 15 de março de 2017

FIM DE UMA ERA DOS TESTES? ACABOU.



Pessoal,

não sumi. Estou sempre atolado com varias coisas. Então vamos a um assunto que desejo escrever, e não falar. Sim, meu canal, Dualidade TecNerd (clique aqui e veja lá).

Já sabia da noticia desde setembro de 2016 (sim, isso mesmo!), mas não havia publicado porque estava esperando o mercado se movimentar mais. Seria como dar um alarde precipitado.


Em setembro de 2016, a divisão de testes (antiga Mercury) da HP foi vendida para a Micro Focus. Isso já vinha sendo especulado desde junho de 2016. Foi o que o mercado chama de "spin-merge"

Vamos as razões do lado da HP para vender a divisão de testes que era na verdade a antiga Mercury Interactive, que eu observei e diversos outros analistas também observaram:

- A HP parecia que não dava a atenção devida, não era prioridade de fato
- Investimentos para melhorar as ferramentas de testes, que eram muito boas, não foram feitos,
- Os preços das ferramentas de testes são altos, e a competição com as novas ferramentas e outras já existentes, não tornou os preços mais acessíveis ou mais viáveis ou menores em muitas empresas. Perdeu mercado.
- Era uma empresa que quando foi comprada (a Mercury) tinha problemas (pelo menos foi o que andou vazando) de contabilidade. Era uma bomba relógio na pratica que poderia levar a empresa HP inteira para o buraco. Parece que os problemas contábeis não foram devidamente resolvidos... Velha frase nerd: PERIGO, PERIGO, PERIGO!!!

Vamos as razões de compra do lado da Micro Focus para realizar a compra:

- Comprar a tecnologia da antiga Mercury, que em muitos casos era mais evoluído e melhor em alguns casos, como o caso do LoadRunner, ferramenta de testes de performance.
- Vai reter os talentos da HP, que estão na divisão que foi vendida.
- Eliminar um concorrente. Sim, a antiga Mercury, e depois a HP, sempre foi um concorrente em testes para a Micro Focus.
- Comprar ou adquirir a base de clientes que vira junto com as ferramentas. E forçar e médio prazo a descontinuidade das ferramentas da antiga Mercury, forçando ou obrigando ou levando os clientes a migrarem ou deixarem de usar essas ferramentas e passarem a usar as da Micro Focus. Isso é uma compra entrante. De qualquer forma a vida dos produtos parece incerta, mas o que mais parece indicar é que eles sejam descontinuados.
- A direção da Micro Focus percebeu que não estava expandindo sua base de clientes ou seus lucros, em seus produtos principais  e resolveu atacar os produtos menores (em termos de lucros) que possam sem expandidos (em termos de lucro). É uma mudança ou melhoria nos produtos de testes da Micro Focus.

Então o que podemos concluir:

-Chegou o fim da era das ferramentas de testes da antiga Mercury. Talvez a ferramenta que mais destaco é o LoadRunner que muito boa e talvez uma das melhores do mercado em sua especialidade.
-Haverá uma concentração das ferramentas pagas. Por isso a Microsoft vai disponibilizar a seu conjunto de ferramentas de testes tecnicamente de graça. Forma de compensar e atrair os novos clientes.
-Essa venda ou spin-off, vai afetar o mundo inteiro.
-As ferramentas de Mercury chegaram a ser lideres mundiais de vendas, e foram uma referência no mundo inteiro quando se falava de testes. Então "matar" simplesmente as ferramentas, pode dar força a outras ferramentas, como a Microsoft para testes, e as várias Opensource.

Vou lembrar um pouco Schumpeter, o chamado pai dos conceitos de inovação. "Para uma nova tecnologia, ou inovação, nascer outra antiga deve morrer" (adaptado de Schumpeter). Vide o caso do CD e do disco Vinil. Talvez não seja uma inovação... é o mercado, é a selva tecnológica, ou não?

O que virá por ai? E agora José?

Que Deus a Tenha, descanse em paz! Essa era de testes chegou ao fim...Porém, ainda vive por instrumentos. Em breve os instrumentos serão desligados. Adeus.

Abcs

Leonardo Molinari



domingo, 29 de janeiro de 2017

CHEGOU MEU NOVO LIVRO - QUENTE E POLÊMICO



Pessoal,

chegou meu novo livro. Fiz lançamento especial no meu canal, o Dualidade TecNerd (clique Aqui). Tem um vídeo especial com o lançamento do meu novo livro. Veja lá. Explico o porque dessa minha obra.

Obrigado a todos vocês que veem meus posts. Hoje aqui, o lançamento dessa nova é o tema de hoje.
Vá lá no meu canal e assista!!

AVISO: Tem mais coisa pintando por ai. Essa obra veio mais quente do que vocês imaginam... Caprichei ao máximo. Me superei. Sou sincero.

Grande abraço e vejam lá!!! Veja no canal Dualidade TecNerd (clique Aqui).

Leonardo Molinari


segunda-feira, 16 de janeiro de 2017

NOVA POLÊMICA - Testes sem casos de testes é possível?




-  Meu Deus do Cèu: como poderei testar sem ter casos de Testes?

Uma outra pessoa evocaria Drummond: E agorá José?


Pessoal,

a verdade é simples:

existe uma corrente pró e outra contra.


CONTRA CRIAR CASOS DE TESTES:

-você não precisa ter situações pré-estabelecidas para testar? Descubra a aplicação.
-todo mundo copia os mesmos testes, então porquê fazer mais ou os mesmos?
-a quantidade de situações são infinitas, então para que testar tudo se atingir o tudo é impossível?

A FAVOR DE CRIAR CASOS DE TESTES:

-sem atender o que o usuário pede não entregaremos a aplicação.
-os requisitos precisam serem testados.
-se não testar o que está especificado de nada vale o teste.
-o usuário vai reclamar se não testarmos e nós seremos os culpados.

VEREDICTO:

-Os dois lados estão certos.
-Os testadores não leem ou estão deixando de ler ou lendo mal o que se precisa ser testado por pressão ou pressa e no final copia o teste antigo e não lê. Erro fatal. Tem de ler e reler e discutir.
-Existem casos de testes que são superficiais na sua escrita, e fica por conta de quem vai testar decidir como e o que testar. Quem executa o teste não deve ser um robô. Deve pensar também.
-Podemos (e devemos) explorar e usar diversas tecnicas de elaborar os testes para aumentar a amplitude dos casos de testes, aumentando as situações de testes.
-O que o usuário pede e especifica deve se validado e revisado.
-Não confunda ser ágil com pressa.

POR QUE ESSE POST?

Porque existem diversos pontos que os dois lados defendem e se esqueçem de que ambos estão certos.
Uma aplicação mal testada trará uma perda de imagem.
Tem saído vários posts defendendo os dois lados.

VOCÊ DECIDE.

Sem procuro apresentar os lados ou os dois pontos de vista. Sem entender os dois lados nunca faremos a área de QA crescer. Fato.

Abçs.

Leonardo Molinari



domingo, 1 de janeiro de 2017

SUPER-QA CONTRA BAT-DEVELOPER: AMANHECER DA INJUSTIÇA



Era uma vez...

ISSO NÃO É CONTO DE FADAS.

É uma briga de dois super-heróis que desejam apenas JUSTIÇA, no código da Aplicação. Se passa em um universo-empresa SEI-LÀ-ONDE. Ups....

ATO UM: 

O SUPER-QA discretamente observa o código da app nascendo. Crescendo. Agora é a vez de valida-lo.

Mas o BAT-DEVELOPER que sofreu tirando o BUG das ruas e entranhas do código, acha injusto quando dizem que o código só está bonito porque existe um SUPER-QA.

Injustiça que precisa ser corrigida diz o BAT-DEVELOPER. Ele está sendo "en-deusado" demais completa. Tudo é o super-QA...

Eu resolvo tudo. Eu sou de outro mundo. Nenhum bug-criminoso passa por mim afirma o SUPER-QA. O BAT-DEVELOPER é um cavaleiro que cria coisas que só ele entende e ele não confessa tudo... Está errado afirma o SUPER-QA. Qualidade é comunicação também... E agora?

ATO DOIS:

BAT-DEVELOPER encara o SUPER-QA, com uma armadura de código que só ele conhece e um banco de dados que só ele entende.

O SUPER-QA é resistente e poderoso em suas habilidades mas é fraco perante A KRIPTONITA-BUG-LOUCA. Nínguem conhece tudo. Sempre precisa se de alguém.

Será que o BAT-DEVELOPER vai ajudar o SUPER-QA?

ATO TRÊS:

Sim. Pelo bem maior da empresa e do usuário eles precisam se ajudar. E os dois se ajudam.

A ANALISTA -MARAVILHA aparece para dar uma força para parar a briga...

O amanhecer da injustiça foi resolvido: o bug-criminoso foi enjaulado. Ebaaaa....

O Amanhecer do código é A união.

Ainda tem o FLASH-SUPORTE, O ANALISTA-MARAVILHA, AQUA-ESPECIALISTA e o GERENTE-CYBORG-DE-PROJETO. Todos unidos foram MUITO mais além...

Eles formam agora o LIGA DA JUSTIÇA DA QUALIDADE.


E AGORA?

Essa brincadeira lúdica, serve para mostrar que a qualidade precisa de vários atores em um projeto. E uma briga antiga que devemos acabar é a que existe entre developer e QA. São dois lados da mesma moeda. Preciso falar algo mais? Um precisa do outro. Quem ganha? Todos. 

Feliz 2017.

Abcs

Leonardo Molinari


sábado, 31 de dezembro de 2016

MATERIAL FREE - INOVAÇÃO EM SERVIÇOS DE TESTES DE SOFTWARE


Hoje,

mesmo no último dia de 2016 tem coisa nova que pode ter sido publicada em 2011, mas é atual e valida.

É muito legal que vemos algo que criamos ter dado origem a várias outras coisas.

Vejam: nem sempre devemos desprezar o que já foi escrito e que é base de conhecimento para diversas outras coisas.

Minha dissertação de mestrado, defendida em 2011, foi voltada para INOVAÇÃO EM SERVIÇOS DE TESTES DE SOFTWARE. 

Sim!!! Isso mesmo!!!  O analista de QA médio e os estudantes não tem noção de que testes são um serviço. Não é produto, que pode ser colocado em uma prateleira. Se você compra um serviço, o serviço será executado. É como um corte de cabelo, acontece.

Nos capitulos 1 e 2 da dissertação você terá perfeita noção destes conceitos e de como está a inovação no Brasil. Sim, em minhas atuais pesquisas os dados que coloquei na dissertação ainda estão perfeitamente atuais e válidos no que ser refere a INOVAÇÃO.

Como a dissertação aborda um modelo genérico de inovação em serviços, muitos dos elementos do modelo são confrontados por autores distintos que trás experiências de liderança / gestão e entrega de serviços. A dissertação foi tão impactante que RECEBEU extensos elogios pela sua profunda e extensa pesquisa com muitas referências. Acabou modificando o ensino de INOVAÇÃO no próprio curso de Mestrado, e ainda dando origem a uma continuação de outra dissertação executada por outro mestrando.

O que aconselho ler:

-Os capítulos 1 e 2 para quem não deseja se aprofundar em inovação em serviços, senão leia todo o resto.
-A TRANSCRIÇÃO DA NARRATIVA da entrevista 02 que foi realizada. Foi feita na época junto ao EMERSON RIOS na iTeste, pois se abordou em profundidade a MPT-BR, hoje tão falada em testes. Ele foi um dos criadores, senão o criador principal da MPT-BR.

O que se pode fazer com a dissertação?

Ela é free para todo país, pois as dissertações podem ser baixadas por qualquer um segundo resolução do MEC. E mais, se desejar o texto, pode usar, basta fazer a devida referência bibliográfica, dizendo que é o autor (EU, LEONARDO MOLINARI). Na dissertação meu nome completo. Foi defendida em 2011 na Universidade Estácio de Sá, no mestrado de administração (MADE)

Baixem Clicando Aqui.

Abços e Boa Leitura e Feliz Ano Novo.

Leonardo Molinari


sexta-feira, 30 de dezembro de 2016

Polêmica - Agile Morreu ou Não Morreu? ATUALIZADO



Oi Pessoal,

Agile (ou métodos Ágeis) deu certo ou não deu? Essa é uma questão que por algum tempo muitas empresas se questionaram e buscaram esse caminho.

Para quem tentou e NÃO DEU CERTO:

- As empresas não adotaram as praticas ágeis de fato. Agile não resolve tudo. As práticas colocadas através do MANIFESTO ÁGIL não foram implementadas.
- Erros de Estimativas claros e evidentes aumentaram os custos e as praticas novas precisaram ser revistas.
- Resistências de muitas pessoas que estavam acostumadas em praticas antigas.
- Em grandes empresas colocar Agile é complicado...
- Confusão dos conceitos básicos do Agile.
- Em muitas gerências apenas apostaram que o Agile se resolve sozinho. Eles (os gerentes) precisam remover obstáculos, que ou eram grandes demais (envolvia política) ou era fácil criticar.
- Em pequenas e médias empresas é mais fácil, mas em grandes empresas se precisa focar em projetos menores inicialmente para que todos ganhem confiança e divulgem as práticas.
- O impacto de novas tecnologias , como o mundo móvel. Desenvolver no mundo móvel em Agile não é a mesma coisa que desenvolver para web em Agile.... acredite: são mundos diferentes.
- De novo: a onda movel e da IoT (internet og things ou internet das coisas).

E para quem tentou e DEU CERTO:

- Usaram o Manifesto Ágil como base de tudo ao implantar o processo ágil em empresas.
- Projetos em pequenas e médias empresas.
- Empresas cuja cultura é de Inovação e de Adoção Aberta novas práticas.

E os TESTES ÁGEIS?

Teste ágil não é desenvolvimento Ágil. Um usa praticas do outro em testes, mas você pode testar usando teste ágil mas sem ter desenvolvimento ágil na empresa... ISSO MESMO!!!! Já vi casos assim.

Isso deu mais certo, seja totalmente ou parcialmente.

AFINAL O QUE DEU CERTO?

As práticas ágeis foram adotadas em muitos projetos. O problema está na ONDA DA MOBILIDADE, seja através das aplicações móveis e da IoT e agora, a onda da Inteligencia Artificial.

O QUE PODEMOS AFIRMAR EM TERMOS MUNDIAIS?

Segundo o World Quality Report 2016-2017 o Agile continua crescendo e adotado no mundo todo, mas o impacto da IoT (internet das coisas) e da transformação digital (ou o mundo cada vez mais móvel) tem transformado demais a TI de uma maneira global.

Cada vez mais as empresas tem investido em QA, e investir em Agile é das práticas mais bem aceitas.

Então podemos concluir que Agile não morreu. Cresceu no mundo tudo, porém precisa se adaptar as novas e emergentes tecnologias e se precisa investir em educação e em QA como um todo, não apenas em Agile.

E O QUE MAIS?

Pesquise mais no meu CANAL DUALIDADE TECNERD  (clique aqui) e veja os links abaixo nas referências.

REFERÊNCIAS

http://blog.caelum.com.br/por-que-falam-tanto-que-o-agil-morreu/
https://www.infoq.com/br/articles/agile-didnt-work
https://michaelochurch.wordpress.com/2015/06/06/why-agile-and-especially-scrum-are-terrible/
http://r-stylelab.com/company/blog/software-product-development/12-fatal-mistakes-in-agile-development
http://searchsoftwarequality.techtarget.com/tip/Large-scale-Agile-development-doesnt-work-Or-does-it
https://www.infoq.com/articles/agile-didnt-work
https://www.capgemini.com/thought-leadership/world-quality-report-2016-17