Teste de Software: O Futuro Está na Automação?
Texto de Skywalker
"Essa semana 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 adaptando-se a novas necessidades.
Embora recente (pelo menos em termos de render livros e discussões), 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 está 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 queremos aportuguesar termos técnicos. "Inicializar" é outra palavra que me dói nos ouvidos. Mas tudo bem, o mercado já se acostumou a falar assim. 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.
A parte de automação 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 um 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 há testes que só um ser humano pode realizar, especialmente aqueles que envolvem decisões ou regras de negócios 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 x ganhos apresentados. Para esses casos, sempre serão necessários testes manuais.
O que eu particularmente enxergo como uma tendência, é que esses dois papéis (analista e automatizador) não sejam mais executados por pessoas diferentes, como já vi em muitas empresas e como ainda ocorre na maioria delas. Aquela história de time de testes manuais e time de automação separados parece estar acabando. Os profissionais terão de acumular as duas habilidades. Esse sim 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 é 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.
Falando em capitalismo, vemos que existem diversas ferramentas para automatizar testes. A maioria delas tem 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 parecem ser melhores, embora as gratuitas tenham evoluído. Mas optar por um dos grupos deve considerar o retorno trazido pelo investimento feito. Para empresas grandes, com mais recursos financeiros e que precisem de resultados melhores, as ferramentas pagas ainda serão a melhor opção. Já para as empresas menores, provavelmente o custo das licenças não compense, devido às necessidades de automação de testes que essas organizações possuem serem também menores.
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, geralmente as grandes, que enxergaram esse movimento há mais tempo e que saíram na frente, ajustando seus processos deteste e seu gerenciamento de projetos para contemplar essa mudança e; 2) as empresas "retardatárias", geralmente pequenas e médias, 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 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. Além disso, as empresas devem 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."
Visite o ótimo site B-Sides IT
Embora recente (pelo menos em termos de render livros e discussões), 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 está 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 queremos aportuguesar termos técnicos. "Inicializar" é outra palavra que me dói nos ouvidos. Mas tudo bem, o mercado já se acostumou a falar assim. 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.
A parte de automação 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 um 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 há testes que só um ser humano pode realizar, especialmente aqueles que envolvem decisões ou regras de negócios 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 x ganhos apresentados. Para esses casos, sempre serão necessários testes manuais.
O que eu particularmente enxergo como uma tendência, é que esses dois papéis (analista e automatizador) não sejam mais executados por pessoas diferentes, como já vi em muitas empresas e como ainda ocorre na maioria delas. Aquela história de time de testes manuais e time de automação separados parece estar acabando. Os profissionais terão de acumular as duas habilidades. Esse sim 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 é 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.
Falando em capitalismo, vemos que existem diversas ferramentas para automatizar testes. A maioria delas tem 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 parecem ser melhores, embora as gratuitas tenham evoluído. Mas optar por um dos grupos deve considerar o retorno trazido pelo investimento feito. Para empresas grandes, com mais recursos financeiros e que precisem de resultados melhores, as ferramentas pagas ainda serão a melhor opção. Já para as empresas menores, provavelmente o custo das licenças não compense, devido às necessidades de automação de testes que essas organizações possuem serem também menores.
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, geralmente as grandes, que enxergaram esse movimento há mais tempo e que saíram na frente, ajustando seus processos deteste e seu gerenciamento de projetos para contemplar essa mudança e; 2) as empresas "retardatárias", geralmente pequenas e médias, 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 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. Além disso, as empresas devem 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."
Visite o ótimo site B-Sides ITGostou do site? Receba as novidades no seu e-mail! Faça seu cadastro aqui
0 comentários:
Postar um comentário