Foto-legenda: A Dama de Verde

Num dia frio, era razoável de se esperar um céu cinzento. Mas tive sorte. Saí numa manhã fria para passear em Manhattan e resolvi arriscar uma visita à "jovem" senhora de verde, de origem francesa. E não é que ela é fotogênica? Não tem como não achar o visual bonito. Tirei essa foto quando o ferry se aproximava para atracar. 

Era 26 de Outubro de 2008. Estava bem no meio da crise econômica, que iniciara poucos meses antes. Barack Obama seria eleito, dias depois, o primeiro presidente negro da história dos EUA. Pude presenciar esses momentos de perto. De certa forma, vivi a História, ainda que como mero espectador. Por isso gosto muito das fotos que tenho dessa época.

O dia, como se vê, estava perfeito, apesar do frio. Consegui centralizar a ilha toda na foto, e o céu azul de fundo deixou-a ainda mais bonita. Fotógrafos profissionais certamente torceriam o nariz para a minha foto. Mas acho que Bartholdi aprovaria.

Leia Mais

Teste de Software: O Futuro está só na Automação?

Há alguns dias eu discutia com um colega sobre para onde está se encaminhando a qualidade/teste de software nas empresas de TI. É bastante recorrente esse tipo de assunto nos corredores atualmente. Depois de vermos um grande "boom" no setor, no que diz respeito a técnicas e processos de teste de software, parece que o mercado está, de uns tempos para cá, mudando o seu rumo, ou pelo menos se adaptando a novas necessidades.

Embora recente, se comparada a outras áreas tradicionais (pelo menos academicamente, em termos de livros e discussões geradas a partir dela), a área de testes é uma das que mais ganhou ênfase dentro dos projetos. É difícil você pensar em um novo software sem considerar que seu desenvolvimento precisará de ciclos de testes para garantir a entrega do produto final com o melhor resultado possível em termos de confiabilidade, estabilidade, funcionalidade, etc. Nos projetos em que trabalhei, sempre foi assim. Algumas vezes isso foi bem elaborado, outras nem tanto. O que chama a atenção é uma aparente movimentação na área relativa a uma ênfase ainda maior em automação de testes.

Obviamente, quem lê sobre o assunto já deve ter visto uma grande quantidade de textos falando de automação. Parênteses aqui: pra mim, esse termo, no sentido da origem da palavra, seu radical, estaria equivocado, pois "automação" subentende algo que faz tudo sozinho, de forma automática, coisa que nenhum teste é capaz de fazer. No meu entendimento, o mais correto seria falar em "autonomação", que vem de "autonomia" e que depende de participação humana. Aliás, que coisa horrível essa mania de querermos aportuguesar termos técnicos. "Inicializar" é outra palavra que me dói nos ouvidos. Mas tudo bem, o mercado já se acostumou a falar assim e temos seguir o padrão, sob o risco de não sermos compreendidos. Quem sou eu para contestar isso? Vamos em frente com o raciocínio.

Quando surgiu esse conceito de automação de testes ou de testes automatizados, parecia que o mercado iria migrar para duas correntes distintas de profissionais: Os que tinham perfil mais analítico e que iriam se encarregar da criação de scripts e testes manuais, mas com altas doses de regras de negócio compreendidas neles, e os com perfil mais de programador, que iriam automatizar os testes manuais criados pelos analistas, usando ferramentas e linguagens adequadas. Sim, porque, partindo de um princípio básico, devemos entender a automação de testes como uma FERRAMENTA, que vai trabalhar a partir de algo que já exista (testes manuais) e não como um processo, que vai criar algo do zero. Esse talvez seja um dos grandes erros cometidos pelas empresas nessa área. É uma lógica muito parecida com aquela de se comprar um ERP (ainda se fala em ERP?): Primeiro tenha processos bem definidos e funcionais, depois construa/adquira um sistema que se molde a eles e não o inverso. 

Mas isso não significa que um software só deve ser testado depois de pronto. Todo mundo que trabalha nessa área sabe que o teste deve estar envolvido no projeto desde suas primeiras definições até o post-install Mas a automação em si precisa de uma análise de custo-benefício prévia para saber onde melhor pode ser aplicada.

Essa área tem ganhado muito espaço, mais até do que se imaginava antes. Todo mundo agora parece falar mais em automação do que em qualquer outra coisa. De fato, parece haver certo direcionamento das empresas e do mercado para focar mais nessa área, afinal, um dos seus grandes benefícios está em aumentar escopo e diminuir o tempo de teste, agilizando assim o tempo final do projeto e aumentando a eficiência do software. Isso significa que o papel de analista, que criava testes manuais vai desaparecer? Acredito que não. E nem deveria, pois testes manuais sempre serão necessários, uma vez que há testes que só um ser humano pode realizar, especialmente aqueles que envolvem decisões, julgamentos ou regras de negócio mais subjetivas. Há ainda aqueles que não valem a pena serem automatizados, por apresentarem um custo-benefício baixo em termos de esforço de automação versus ganhos apresentados. Para esses casos, sempre serão necessários testes manuais. Ou, ao menos, a possibilidade de tê-los.

O fato é que a automação tem mais lógica (ou razão de ser) quando aplicada a testes que terão alto índice de reuso (testes de regressão, por exemplo), pois, não raro, a construção de bom um teste automatizado leva bem mais tempo do que a de um teste manual. Fora isso, a tendência é ter um custo elevado demais para se justificar no escopo do projeto. Aí entra a análise prévia de custo-benefício que comentei antes. Sempre ajuda.

O que eu particularmente enxergo como uma tendência, é que esses dois papéis, de Analista de Testes e de Engenheiro de Testes (como algumas empresas chamam o Automatizador), não sejam mais executados por pessoas diferentes. Aquela história de time de testes manuais e time de automação separados parece estar acabando. Não estou dizendo que é o melhor caminho. Até acho que algumas funções poderiam ser compartilhadas, mas a especialização que difere os dois papéis ainda é muito útil. O fato é que é cada vez mais se caminha para isso. Os profissionais acabarão tendo de acumular as duas habilidades. A questão é a qualidade com a qual serão capazes de executar as duas coisas ao mesmo tempo. Esse parece ser o próximo movimento do mercado. Até por uma questão de custo, pois manter dois times distintos em termos de especialização dentro do mesmo projeto é bem mais caro e não necessariamente mais eficiente. 

Alguns dirão: - Lá vem o capitalismo selvagem, querendo fazer com que menos pessoas façam mais e produzam mais. Não se esqueçam de que essa também é uma lógica da TI em si, portanto, não há como ser diferente. A TI é capitalista na sua essência e uma das grandes viabilizadoras deste sistema econômico, queiram ou não.

Falando em capitalismo, vemos que existem diversas ferramentas para automatizar testes. Umas têm licenças caríssimas. Mas há também aquelas open source, gratuitas, e que, até com certo sucesso, vêm sendo utilizadas em muitos lugares. Não tive contato com todas elas, mas pude observar algumas que fazem parte dos dois grupos. Por essa experiência, até o momento, as ferramentas pagas ainda me parecem ser melhores, pois oferecem mais recursos, embora as gratuitas tenham evoluído. Ao optar por um dos dois grupos, deve-se considerar o retorno trazido pelo investimento feito. Para empresas grandes, com mais recursos financeiros e que precisem de resultados melhores, as ferramentas pagas ainda tentem a serem as escolhidas como melhor opção. Já para as empresas menores, provavelmente o custo, principalmente das licenças, não compense. Tudo dependerá das necessidades de automação de cada empresa e o quanto se está disposto a investir nisso.

Retomando a questão sobre profissionais de teste que possuem habilidades de análise e automação, eu já observo esse comportamento em diversas organizações de TI (especialmente as americanas) e, como sempre acontece, acho que teremos uma fase de transição onde, num primeiro momento, encontraremos dois tipos de empresas: 1) as de vanguarda, que enxergaram esse movimento há mais tempo e que saíram na frente, ajustando seus processos de teste e seu gerenciamento de projetos para contemplar mudanças e; 2) as empresas "retardatárias", que ainda irão operar da forma "antiga", e para onde provavelmente irão migrar aqueles profissionais que não acompanharam ou não quiseram acompanhar as mudanças.

Não estou dizendo aqui que um método vai ser melhor que o outro. Dependendo da empresa, qualquer um deles pode funcionar. Apenas estou tratando da questão de como as novidades chegam às organizações e de como o mercado se regula naturalmente. E todos sabemos que o ritmo das mudanças não é igual para todas. Porém, mais cedo ou mais tarde, é possível que tenhamos todas trabalhando com profissionais que possuam perfis/habilidades para executar tarefas tanto em testes manuais quanto em automatizados. Isso, obviamente, irá exigir um nível de conhecimento muito maior desses profissionais. Há de se saber ainda se os salários irão acompanhar essas exigências. 

Creio (e isso é apenas uma impressão minha, diga-se) que as organizações deverão apostar e investir mais nesse conceito nos próximos anos, sem eliminar os testes manuais, mas deixando a ênfase maior na automação. Riscos relativos à empregabilidade tendem a aparecer mais para os profissionais que não quiserem aprender sobre o tema. Acho que, para aqueles que ainda não começaram, essa é a hora para iniciar essa mudança, agregar mais conhecimentos e buscar capacitação sobre o assunto. Faz parte desse universo o surgimento de novos conceitos. E deve fazer parte da natureza dos profissionais de TI estarem sempre atentos a isso.

* Adaptação do texto escrito em 03/10/2008

 

Leia Mais

Dica de Leitura: Livro "Opala - O Carro que Conquistou o Brasil"

Qualquer brasileiro que seja apaixonado por automóveis como eu certamente tem no Chevrolet Opala um de seus preferidos. Um carro desejado quando estava em linha e cultuado após sua aposentadoria. Foram 24 anos de fabricação, de 1969 a 1992, uma das mais longevas histórias do automobilismo nacional.

Particularmente, dentre tantos outros carros que queria ter em minha coleção (se um dia puder ter uma), o Opala é um daqueles que certamente teria mais de um exemplar, tamanho o sortimento de modelos que viraram clássicos. O meu sonho principal é um Comodoro 1978 Coupé com teto “Las Vegas”, motor 6 cilindros e interior Chateau. Ou seja, quase impossível, pois talvez seja o mais difícil de encontrar à venda. Mesmo os mais comuns estão com preço inflacionado atualmente, especialmente os 6 cilindros. Talvez valha a pena comprar um que esteja ruim e restaurar, mesmo que demore. Mas, como diz o ditado, sonhar não custa nada. Então, sigo sonhando...

Em "Opala - O Carro que Conquistou o Brasil", da editora Alaúde (famosa por tantos outros livros do gênero),  temos um verdadeiro manual para os fãs do carro. Os autores exploram não apenas a sua história, mas também as suas origens, em um trabalho de pesquisa minucioso.

Podemos ver, ano a ano e modelo a modelo, todas as transformações e evoluções daquele que foi, por décadas, o símbolo do luxo para a classe média no Brasil. Os autores contam também como as variantes econômicas de cada época influenciaram nas versões do modelo e como a concorrência se municiava para enfrentar o sucesso duradouro do Chevrolet. 

O livro é ótimo também para quem quer uma ajuda comprar um Opala e saber exatamente cada detalhe de cores, motores, opcionais e acessórios disponíveis para cada ano de fabricação. Ajuda essa que se estende aos restauradores e colecionadores, que têm um belo suporte para auxiliá-los na missão de saber os itens adequados para comprar e deixar o carro em perfeitas condições.

Apesar de tudo isso, o livro tem uma linguagem simples, de leitura prazerosa. É daqueles que, se você comprar, certamente vai ler várias vezes. E emprestar várias vezes. O meu, inclusive, acabou de voltar pra casa, depois de mais um empréstimo. Resta saber até quando...


Dados do Livro:
Título: Opala - O Carro que Conquistou o Brasil.
Autores: Paulo Cesar Sandler e Rogério de Simone
Editora: Alaúde
Páginas: 272

Leia Mais

Quando os Bons Podem Prejudicar

Qualquer gerente que seja competente sempre vai preferir ter ao seu lado os melhores profissionais. Se você perguntar, é isso que você vai ouvir. Mas, por mais incrível que possa parecer, em alguns casos a escolha não depende apenas de competências técnicas. Este é o caso da Jane.

A Jane trabalhava numa empresa multinacional de TI, na área de qualidade de software. Era uma excepcional profissional e muito competente naquilo que fazia. Ela tinha uma produção muito acima da maioria de seus colegas de projeto. Não raro, ela abraçava as tarefas de outros e conseguia cumpri-las no prazo, mesmo tendo de fazer as suas em paralelo. Alguns de seus colegas reconheciam sua capacidade e viam nela um grande potencial de crescimento. Só que essa gana toda em produzir e tentar crescer não foram transformadas em promoção ou aumento de salário.

Ela era competente, porém gananciosa. Só que não exatamente de uma maneira saudável. Não bastava para ela seguir os degraus da estrutura de cargos da empresa. Ela queria ir direto para cima e depressa demais. Trabalhava muito, porém sempre fazia questão de dizer a todos o quão melhor era em relação a seus colegas e o quanto alguns eram incompetentes. Alguns realmente eram incompetentes, mas a abordagem com que ela tratava esse assunto acabou gerando diversos conflitos na empresa. 

Pelo fato de achar que era mais competente (de certa forma, era, mas não necessariamente "a" mais competente), raramente aceitava suas notas nas avaliações que o RH fazia. Não que ela não merecesse, mas sabemos que em algumas empresas o papel do RH, infelizmente, é sempre deixar um "algo mais" a ser buscado, pois, se o profissional tiver nota máxima, não terá o que buscar até a avaliação seguinte, de acordo com essa “teoria”. É meio perverso, mas acontece e é preciso saber lidar com isso. Mas Jane não aceitava e reagia sempre de maneira áspera, falando mal de outras pessoas, incansavelmente buscando justificativas, juntando "provas" de sua competência e da incompetência dos outros para mostrar ao RH e tentar fazê-los ver o quanto estavam errados.

Todo esse esforço de autopromoção acabou gerando um clima muito pesado no time, visto que depois de um tempo ela já não deixava sua insatisfação restrita ao RH. Nem os gerentes foram poupados. Ela realmente resolveu "chutar o balde no pau da barraca". Chegou ao ponto de dizer que era boa demais para aquela empresa. Obviamente, não tardou a ser demitida. Mas não deixaria barato: antes de sair, ainda conseguiu deixar contra ela até as últimas pessoas que a apoiavam, aplicando novamente a mesma estratégia. Perdeu a razão, literalmente.

Como tinha um bom currículo, não demorou a encontrar outro emprego. Até fez com que seus ex-colegas achassem, por um tempo, que talvez tivesse sido injustiçada de alguma forma. Isso até o dia em que foi demitida novamente, pelos mesmos motivos, e sempre dizendo que "um dia encontraria uma empresa que merecesse alguém como ela e que reconhecesse o valor seu trabalho diferenciado". Sinceramente, não sei se já conseguiu. 

A linha entre ser bom e ser arrogante pode ser tênue, dependendo de como a pessoa lida com isso. No caso da Jane, houve falhas do RH, mas o principal foi que faltou jogo de cintura a ela para administrar a situação e sobrou prepotência. De nada adiantou ser uma profissional tecnicamente qualificada se ela sucumbiu ao ego na primeira vez em que se viu contrariada ou injustiçada. As coisas podem não estar fáceis em muitas ocasiões, mas você não precisa deixá-las ainda piores e, de quebra, contaminar toda a sua equipe.

Tudo isso me faz pensar em um ponto diversas vezes esquecido hoje em dia: por mais qualificado e competente que possa ser, você nunca sabe tudo. É sempre preciso ter humildade, tanto para aprender com os outros (competentes ou não), quanto para respeitá-los. E também para lidar com as adversidades. Nosso mundo de ciências exatas (?) muitas vezes nos afasta desses tipos de valores. Ter em mente que o seu conhecimento não é absoluto e que você eternamente estará aprendendo algo novo talvez seja o passo principal para ser um profissional cada vez melhor. É por aí que você começa a ser respeitado e mantem-se competitivo. 

* Adaptação do texto publicado em  23/06/2008

Leia Mais

O Dia em que Porto Alegre Virou Liverpool

 

07 de Novembro de 2010. Dia histórico e inesquecível!

Um Beatle em Porto Alegre! Um Beatle! Que dia poderia ser mais incrível que este em termos de shows internacionais? Pra quem é fã da maior banda de todos os tempos, poder ver Sir Paul McCartney de perto é o suprassumo das realizações. E eu consegui ver bem de perto!

Sou Beatlemaníaco confesso, mas não imaginava poder ver um show desses tão perto e tão de perto. Até que um dia, divulgaram que Paul faria uma turnê pela América do Sul. Como eu já esperava shows apenas em Buenos Aires e São Paulo, comecei a pensar na possibilidade de comprar o ingresso e viajar para assistir o show em uma das duas cidades. Afinal, se não fosse naquele momento, talvez nunca mais tivesse essa chance In my Life.

Eis que anunciam um show extra, que seria o primeiro deles, em Porto Alegre, mais precisamente no Beira-Rio, Templo Colorado. Não podia ser melhor! Na volta de Paul ao Brasil, depois de 1993, seu primeiro show da série seria logo aqui e no estádio do meu Inter. Que honra! Já imaginava a “guerra” para comprar ingresso, seja on-line ou pessoalmente. Sabia que acabariam em questão de horas, o que, de fato, aconteceu.

A parte boa era que os ingressos seriam vendidos primeiramente para os sócios do Inter, pela internet. As vendas começariam às 8h00 da manhã do dia 7 de outubro. A parte ruim é que nessa data eu estava em Los Angeles (timezone de 4 horas a menos em relação a Porto Alegre). Já estaria de volta no dia do show, mas teria de me virar pra comprar o ingresso estando nos EUA. Mas isso não me fez desanimar. Acordei à 3h30m da manhã, como um Blackbird que canta na calada da noite, e fiquei dando "F5" no site dos ingressos para ter certeza de que, ao abrir, seria um dos primeiros a comprar. E fui. O site abriu as vendas às 3h56h da manhã (7h56m no Brasil), um pouco mantes do previsto, e eu, por já estar ali há tempos, fui premiado e consegui acessar e comprar meu ingresso sem maiores problemas. E, como não iria ter de gastar com viagem para ver o show, comprei o mais próximo do palco (e mais caro, consequentemente). Tinha de ser esse. Não estava disposto a ver um show histórico de longe.

Comprei o ingresso e voltei a dormir, pois tinha de trabalhar de manhã. Ao acordar, verifiquei que a minha compra estava confirmada. Tranquilidade. Ao navegar pelas redes sociais, vi que muitas pessoas estavam tendo problemas em comprar, seja pelo site ficar fora do ar, seja pela demora na confirmação. Daí eu vi que fiz bem em acordar de madrugada.

No dia do show, também organizei uma logística pra facilitar minha vida. Cheguei no Beira-Rio à 8h00 da manhã (o show era à 9h00 da noite). Já tinha uns 10 carros aguardando para abrir o estacionamento da Av. Padre Cacique, que fica ao lado do Ginásio Gigantinho. Entrei e cruzei todo o pátio, até chegar bem em frente às cancelas do outro lado, de frente para a Av. Beira-Rio. Só tinha eu ali naquele setor, mas eu sabia que seria fundamental ter o carro ali para a hora de sair do show, pois o estacionamento iria lotar.

Fiquei na fila o dia todo, no sol escaldante do verão que estava por iniciar. O pessoal improvisou papelões como teto, apoiando-os nos cercados da fila. Ficou parecendo uma vila de fãs. Fãs apaixonados, diga-se. Todos se ajudavam, guardando lugar para o outro ir ao banheiro ou comer alguma coisa. Era como se todos vivessem no Yellow Submarine. Vieram até entrevistar a gente!

 

Vila de papelões na fila de espera

 

Foto tirada pelos repórteres do site Terra (eu em primeiro plano)

 
Os portões abriram-se às 18h30m e eu consegui ficar bem perto do palco, como se pode ver. Valeu cada esforço! O show durou 3 horas e não é possível explicar o que se viu ali. Som perfeito, imagem perfeita, um Paul interativo, com direito a um "mas bah, tchê" e um "ah, eu sou gaúcho". Todas as músicas que eu queria ouvir estavam ali. Não faltou nada. O melhor show de todos os que eu tinha visto até então.

  
Consegui até gravar um vídeo, obviamente tremido, devido à empolgação, mas dá pra ter uma boa idéia do que foi o show:

Na volta, bingo! Meu carro era um dos primeiros, logo à frente dos portões de saída. Nem fila eu peguei. Entrei nele e saí direto para a cancela. Quando estava chegando em casa, ouvia no rádio os repórteres falando que o público recém começava a deixar o estacionamento. Rá, Band on the Run, baby!

Foi o tipo de coisa onde tudo deu certo. Desde a compra do ingresso até a saída do show. Não é sempre que acontece. Mas planejar com antecedência ajudou bastante. Deve ser porque eu tinha de estar lá. E quando tem de ser, o universo conspira, dizem. Acho que foi o que aconteceu naquela noite. No dia seguinte, eu só pensava que Yesterday havia sido A Day in the Life.

Leia Mais