Leopoldo Barreiro

Neste post pretendo descrever, sob o ponto de vista de um analista de sistemas, duas atividades que considero muito importantes para uma entrega de software bem sucedida. Tratam-se de duas atividades realizadas pelo pessoal da qualidade de software (Q&A): Smoke Test e Sanity Test.

Smoke Test
A origem do nome Smoke Test remonta do início da indústria de hardware. Traduzindo para o portguês, seria “Teste de Fumaça”. Após montar os componentes eletrônicos, ligava-se o equipamento na tomada. Se não surgisse fumaça, o equipamento tinha sido bem montado e os componentes estariam funcionando. Transportando esse conceito para o desenvolvimento de software, smoke test é um conjunto de testes básicos realizados pelos testadores para saber se o software que está sendo liberado possui algum problema saliente em suas funcionalidades mais básicas. É realizada uma navegação completa no sistema para verificar se tudo o que já funcionava antes segue funcionando corretamente.

Sanity Test
O sanity test ou “teste de sanidade”, é realizado quando um novo build com revisões pequenas é gerado. O objetivo do sanity test é garantir que os problemas resolvidos (listados no release notes) estão realmente corrigidos. Além disso, o sanity test garante que as correções entregues não geraram novos bugs. A suite de testes do sanity test é encarado como uma atividade anterior aos testes de regressão completos, ou mesmo em substituição a este quando a entrega é de baixa criticidade.

Links separados para leitura
Seguem alguns links interessantes que separei sobre smoke e sanity test.

1. geekswithblogs.net – apresenta os conceitos de cada atividade, bem como uma tabela comparativa dos dois.
2. softwaretestinghelp.com – confronta os dois tipos de testes de forma direta.

É interessante como nós, os seres humanos, tentamos complicar as coisas as vezes. Em desenvolvimento de software não é diferente. Especialmente quando estamos precisando que o cliente nos abasteça de problemas para resolver em seu negócio. É muito comum não conseguir entender o que o cliente expõe, para depois estabelecer um consenso daquilo que o software precisa resolver.

Apenas com base em uma comunicação eficaz é possível dimensionar o problema do negócio e estabelecer os requisitos condizentes com a realidade. Se os envolvidos no processo não compartilham uma mesma visão sobre o assunto, é muito provável que as soluções propostas não sejam adequadas.

Conversando com um antigo amigo tempos atrás, percebi que a imagem que fazem de nós (profissionais de T.I.) é de que somos inalcançáveis, intangíveis pessoas com as quais ninguém consegue conversar. Não entendemos e não nos interessa entender o problema dos outros. Fazemos software para nossa própria diversão, para nosso deleite e os usuários devem adaptar-se ao software, e não o software aos usuários. É uma imagem caricaturizada lógico, mas acredito que se fossemos mais comunicativos, muita coisa mudaria. Em alguns anos não haverá mais espaço para pessoas que não se comunicam. Tudo está ficando mais competitivo, a informação adquire importância crucial para qualquer negócio. Com desenvolvimento de software não é diferente.

Hoje em dia se discute muito sobre os prejuízos causados pela falta de comunicação e erros de interpretação (entre o que o cliente precisa e o que a equipe achou que ele precisava). Prejuízos esses que afetam o cliente, mas também afetam a equipe de desenvolvimento. Profissionais de T.I. que realmente gostam do que fazem, sentem-se mal quando as expectativas do cliente não foram alcançadas. Por outro lado, existe uma motivação generalizada quando essas expectativas são conquistadas e transformadas em software de valor.

Outro dia, ao final de um sprint de desenvolvimento, a minha equipe (participo como analista de sistemas) foi coroada com um dia de premiação. Entregamos uma nova versão de software, foi organizada uma apresentação, o cliente elogiou muito e todos sairam edificados da reunião.

Houve uma satisfação geral: uma meta importante tinha sido conquistada. Esse dia foi apenas o feliz desfecho de todo um trabalho, baseada em comunicação constante. Comunicação entre os integrantes da equipe sim, mas também comunicação direta com o cliente.

Assiduamente o cliente era convidado a participar, acompanhar o processo de desenvolvimento. Decisões foram tomadas no intuito de priorizar aquilo que agregaria mais valor para o negócio do cliente. Nesse intuito, foram incluídas funcionalidades antes não planejadas e retiradas outras que não eram tão importantes para o momento.

O melhor de tudo: o cliente sempre estava participando das decisões, lado a lado com a equipe, como em uma parceria mesmo.

Não houve surpresas desagradáveis. Como tanto a equipe quanto o cliente sabiam de tudo e tinham corroborado sobre tudo antecipadamente, não houve desapontamentos. O que houve sim foram priorizações acertadas, mais qualidade e mais valor produzido, tudo isso traduzido em software funcional, entregue para o cliente.

Que legal essa tal de comunicação. Pode parecer básico, mas tem gente que ainda não pratica.

Faz umas semanas atrás reencontrei um velho amigo meu, ex-colega em um projeto em que participei. Como sempre, puxamos assunto falando sobre nossos trabalhos atuais. Foi aí que começamos a conversar sobre o dia-a-dia no desenvolvimento de software em nossas equipes. Ele me contou entusiasmado que eles começaram a utilizar Kanban para uma visibilidade das entregas de software. Foi então que resolvi falar um pouco sobre o assunto.

Kanban tem origem no Japão e significa “registro ou placa visível”. Trata-se de um quadro visível no ambiente de trabalho, onde a equipe consegue consultar o andamento da produção. Em se tratando de desenvolvimento de software, a equipe consegue visualizar no Kanban todos os componentes, as funcionalidades que fazem parte da entrega de um release de software.

O conceito por trás do Kanban é extremamente simples. No quadro, são delineadas algumas colunas, correspondendo às fases de entrega de uma funcionalidade. Por exemplo, colunas com os itens Especificação, Desenvolvimento, Testes, Entrega. Cada funcionalidade é um post-fix pendurado no quadro. A medida que a funcionalidade avança de fase, o post-fix é mudado de coluna no Kanban. Modo simples e eficaz para dar visibilidade a toda a equipe daquilo que está sendo feito e o que falta fazer.

Kanban foi idealizado pelos altos-executivos da Toyota há décadas, como um recurso para dar visibilidade na linha de produção. É uma ferramenta integrante da metodologia denominada just-in-time. Apesar de sua aplicação inicial ter sido idealizada para a indústria automobilística, a aplicação de just-in-time na indústria de software mostrou-se extremamente eficaz.

Tudo o que está fixado no Kanban deve ser movimentado. Uma funcionalidade de software nunca é empurrada para a próxima fase no Kanban. Pelo contrário, o time responsável pela fase seguinte é quem puxa a funcionalidade para si. Por exemplo, quando é concluída a fase de especificação de uma funcionalidade, ela permanece na coluna “Especificação” até que um desenvolvedor esteja livre para iniciar a fase de desenvolvimento. Somente aí é que a funcionalidade move-se no Kanban, passando para a fase “Desenvolvimento”.

De acordo com o just-in-time, nada deve empurrado na linha de produção. Não se deve formar estoques. Para software o mesmo: não devemos sobrecarregar os times, mas sim prover um fluxo organizado e estável de produção de software. É um caminho certo para a qualidade de software, tão almejada.

Além da conversa com meu amigo, outro motivo que me levou a escrever sobre Kanban foi uma boa notícia recebida esta semana no trabalho: começaremos a utilizar Kanban também lá na empresa. Eu conheço minha gerente de projetos há pouco tempo, mas já percebi sua inclinação para metodologias ágeis. Sinto que boas mudanças virão pela frente. O uso de Kanban lá na equipe vai proporcionar o domínio do problema para todos. Estaremos aptos a acompanhar em tempo real o andamento do projeto, das entregas de software em cada sprint e por fim cultivar a empatia pelo trabalho dos diferentes times que compõem nossa linha de produção de software.

Da próxima vez que eu encontrar esse meu amigo vou poder falar sobre a aplicação de Kanban em minha equipe de desenvolvimento também. Realmente, Kanban é muito legal.