Na China antiga havia uma família de curandeiros, um dos quais era conhecido em toda a terra e trabalhava como médico de um grande senhor. O médico foi perguntado sobre quem de sua família era o curandeiro mais habilidoso. Ele respondeu:
"Eu atendo os doentes terminais com tratamentos dramáticos, e de vez em quando alguém é curado e meu nome sai entre os senhores."
"Meu irmão mais velho que eu cura a doença quando ela começa a criar raízes, e suas habilidades são conhecidos entre os camponeses locais e vizinhos."
"Meu irmão mais velho é capaz de sentir o espírito de doença e erradicá-la antes que ele tome forma. Seu nome é desconhecido fora de nossa casa."
Com esta parábola chinesa, abro este artigo para falar sobre qualidade de software e sua importância.
No últimos 2 anos e 3 meses, minha principal função foi trabalhar com Software Quality Assurance (Controle de Qualidade Software). Uma área vasta e que eu praticamente desconhecia antes. Obviamente aprendi muita coisa, e talvez a principal delas tenha sido ser um desenvolvedor melhor, mais criterioso.
Antes de trabalhar nessa área, eu era basicamente um desenvolvedor web, com o básico das apostilas da que se encontram facilmente na internet, e uma ou outra experiência agregada através dos projetos no tocante javascript (fiz algumas coisas interessantes e aprendi na marra a lidar com o DOM).
Sou inegavelmente um perfeccionista e autodidata. Sempre fui ligado nos aspectos de segurança, performance, standards compliance, acessibilidade, SEO, entre tantos outros, ainda que de forma amadora, sendo procurando artigos, benchmarkings, novas técnicas e tentando aprender a forma certa - ou a melhor forma entre as certas - de se fazer as coisas.
Admito que eu tinha uma visão muito estreita do que é Quality Assurance, afinal eu já programava, raramente alguma coisa que era feita por mim apresentava algum bug depois de entregue (claro que rolava aquele teste básico pra ver se tudo estava em ordem antes), e as coisas que eu fazia funcionavam. Não entendia a necessidade de testar algo que já era funcional.
Eu achava que ser um tester era algo como um passo para trás na carreira. Ledo engano. Ser um bom tester, exige que você seja antes de tudo, um bom programador (ou tenha uma idéia realmente boa de como as coisas funcionam por baixo dos panos), afinal, você vai submeter o trabalho de um programador à uma bateria de testes diversos, afim de encontrar falhas.
Para ilustrar, não raro uma coisa me acontecia - e creio que todo programador passou ou passa por isso vez ou outra: você cria o programa, faz alguns testes básicos, vê que funciona, olha novamente e código e se sente orgulhoso do trabalho que fez e entrega. Dias depois - ou horas depois - é comunicado de que encontraram uma falha, geralmente é o cliente que encontra, e é algo simples, mas que não foi testado. Você abre o código, e depois de alguns minutos - às vezes horas - procurando, acaba encontrando um erro bobo num if da vida. Você havia lido e relido várias vezes o if, e nem imaginava que o erro estaria ali, porque numa leitura à primeira vista, tudo parecia em perfeita ordem.
Bom, pretendo dar início neste post a uma série de tutoriais sobre metodologias e técnicas sobre QA. Mas nada técnico por enquanto. Este post é apenas uma introdução.
Mas a primeira e mais importante dica é formalizar. Escrever e tomar notas sobre o que foi feito e o que não foi feito, sobre o que funciona, e o que não funciona.
Seja num arquivo txt, ou numa planilha, anotar o que foi testado evita que o programador pense que funciona para todos os casos e seja depois surpreendido por um erro que ele achava que funcionava.
----------- keepReading
Nenhum comentário:
Postar um comentário