Desde os meus tempos de professor universitário, essa era uma das perguntas mais recorrentes. Especialmente nas turmas de algoritmos. A imagem acima é de 2018, do github, listando as top 10 linguagens usadas nos repositórios. Além disso, o StackOverflow tem uma pesquisa super bacana e bem detalhada sobre o assunto aqui.
Confesso que por muitas vezes quando alguém me perguntava “qual linguagem aprender”, meu amor por Java falava mais alto, e de pronto respondia “Java, claro!”
Porém, mais que preferência pessoal por uma linguagem, robustez, atualização e segurança da linguagem, precisamos pensar no momento e na finalidade do seu aprendizado.
Nesse sentido, trago aqui 3 perguntinhas simples para te ajudar a escolher qual linguagem de programação aprender ainda esse ano:
1. É a sua primeira linguagem de programação? está aprendendo a programar agora?
Se esse for seu caso, recomendo começar por uma linguagem fortemente tipada, como JAVA. Ela pode parecer complicada e cheia de palavras de início, mas uma vez que você entenda sua lógica, será fácil de aprender outras linguagens. Alem disso, te ajudará a entender tipos e estruturas de dados, e como e onde cada um deles deve ser usado.
2. Qual seu objetivo profissional? quer ser desenvolvedor web? backend? frontend? full stack? tester? cientista de dados? ainda não sabe?
Linguagens são apenas ferramentas, e como qualquer ferramenta, cada uma é melhor em um determinado momento. Você não vai tentar pregar um prego usando uma chave de fenda ou uma faca de cozinha, mas usando um martelo. Com as linguagens de programação a ideia é a mesma. Identifique seu objetivo, que as linguagens para cumpri-lo virão juntas.
3. Empregabilidade é o foco? Quero arrumar um emprego pra ontem usando essa linguagem.
Faça uma busca dos empregos que você quer e veja quais os requisitos (linguagem que utilizam, frameworks, processos, certificaçōes que pedem). Isso vai te ajudar a decidir pela que melhor se encaixa nos planos de carreira.
E minha recomendação geral?
Após 11 anos de computação, muito aprendizado e experiência, nacional e internacional, de forma geral: recomendo Java!
Se com essas 3 perguntinhas acima, sua decisão for outra, não tem problema. Eis os motivos da minha recomendação:
A empregabilidade é ótima, tanto no Brasil tanto quanto aqui na Europa;
É uma linguagem robusta, segura, de propósito geral;
Fortemente tipada;
Orientada a objetos;
Sustentada por um grande nome (Oracle atualmente);
Muito, mas muito conteúdo na internet grátis e também livros publicados;
É uma linguagem aberta (não precisamos pagar pra usá-la, nem precisamos de sistemas caríssimos para executá-la).
Linguagens de programação que estou trabalhando no momento
Java – desenvolver os microservices e testes automatizados;
Kotlin – desenvolver os microservices e testes automatizados;
Javascript – desenvolver frontends e testes automatizados para eles.
Quando estamos desenvolvendo produtos de software, cada defeito encontrado deve ser registrado em algum lugar para se acompanhado e resolvido.
O melhor lugar para armazenar esses defeitos é em um sistema de armazenamento de defeitos, nomeado por um identificador único, compondo uma base de dados sobre os defeitos encontrados em determinado produto ou projeto.
Dessa forma, um sistema de rastreamento de defeitos é um programa ou mais comumente uma aplicação web que permite que a equipe possa registrar, armazenar, gerenciar, e analisar os relatórios de defeitos.
Esse sistema deve manter esses registros de forma que seja possível inserção, remoção e busca desses defeitos, facilitando a organização das informações sobre o que foi encontrado e o que já foi corrigido.
Nesse sentido, a decisão de qual sistema de rastreamento de defeitos utilizar em um projeto ou equipe é extremamente importante!
Algumas possibilidades para realizar esse trabalho são:
Ferramenta que existe há um certo tempo no mercado, open source e desenvolvida em Perl. Utilizada por grandes nomes, incluindo NASA, segundo o site da própria ferramenta.
O Jira evoluiu muito desde meu primeiro contato com ele, há alguns aos atrás. A Atlassian, empresa que o fabrica, atualmente fabrica outros softwares que funcionam muito bem de forma integrada como o Bitbucket (para conectar com o git), o Bamboo (para integração contínua) e o Confluence (para wiki). Sem dúvida uma das melhores escolhas, quando se trata de uma ferramenta paga integrada.
A escolha da “melhor ferramenta”, dependerá do local onde ela será implantada. Então, como em várias outras áreas da computação, lembre-se que nāo existe bala de prata.
Como qualquer parte de um projeto de teste (ou de software, em geral) para que se obtenha sucesso na automação dos testes é necessário planejamento.
Nesse sentido, é necessário decidir qual o melhor momento para incluí-la, juntamente com outros fatores como quais ferramentas serão utilizadas para tal, quais níveis (fases) de teste ela cobrirá, com quais técnicas (caixa preta, caixa branca, mutação, exploratóŕio) e quem os conduzirá.
Automatizar o teste de software significa muito mais que utilizar de ferramentas específicas de automação. E é claro que as ferramentas irão auxiliar a:
controlar bem a execução dos testes;
gerar e inserir dados;
comparar os resultados obtidos com os esperados;
gerar relatórios baseados em métricas definidas;
realizar os testes automaticamente em cada deployment (ou “deploy”).
Os motivos para essa automação são vários, dentre eles destacam-se alguns:
atender a pressão de mercado por entregas mais rápidas;
necessidade de maiores taxas de cobertura;
software como fator estratégico para sucesso das empresas;
recursos escassos, variantes;
“pequenas modificações” geram grandes taxas de reteste.
A automação pode ser inserida em praticamente todas as fases do processo de teste, desde unidade, passando por integração, sistema e até regressão. Em cada nível de teste existem diferentes responsáveis por essa automação.
Quando automatizar?
Que legal! se a automação pode ser inserida em qualquer fase do projeto, então vamos automatizar todos os testes e resolver os nossos problemas de cronograma e orçamento! Não é bem assim.
Ao contrário do senso comum, nem sempre a automação é a resposta para apertos no orçamento ou tempo. Primeiro, é natural que para se utilizar de automação, a equipe tenha um certo grau de conforto tanto com as ferramentas tanto com o produto sob teste, e isso leva tempo. Também, para desenvolver e configurar automações tempo é gasto, e quase sempre não é uma tarefa rápida. Segundo, se o orçamento é apertado, e a equipe não possui expertise em automação, dificilmente bons resultados serão obtidos.
Caso a equipe possua os conhecimentos necessários, para em pouco tempo incluir automação nos testes (o que quase sempre acarreta em gastar pouco a mais do orçamento) é possível ganhar em qualidade do produto ao incluir automação. Do contrário, pouco provável.
Em vias gerais, para automatizar é necessário verificar se com automação haverá ganhos para o projeto. Se haverá economia de tempo e esforço dos analistas de teste (o que influencia na entrega como um todo); se a qualidade do produto será melhorada com isso (com a automação é possível se testar mais casos, aumentando a cobertura); se os testes serão reutilizados; etc. Se não houverem ganhos reais a serem obtidos com a automatização, dificilmente você conseguirá explicar para os diretores/gerentes/clientes porque o orçamento e tempo foram gastos com isso.
Pontos a se observar para a automatização dos testes
Para incluir automação de testes em algum projeto sugiro que se observem alguns pontos:
1. A equipe tem um certo grau de conhecimento sobre as ferramentas, técnicas, linguagens que serão utilizadas?
Caso seja o primeiro projeto em que a equipe utilizará automação, tempo a mais para essa automatização será necessário, uma vez que será a partir desse projeto que a equipe começará a ter noções de tempo, dificuldades, etc. Além do tempo a mais de aprendizado, que cada membro da equipe terá.
2. O cronograma e o orçamento do projeto são extremamente apertados?
Caso o cronograma e o orçamento do projeto sejam muito apertados, só vale a pena automatizar caso o primeiro item dessa lista de observações seja respeitado. Se a equipe ainda não possui expertise, provavelmente não é uma boa ideia começar a automatizar em um projeto restrições nos recursos. Pelo menos não como um todo. Mas é possível começar por pequenas partes, que são possíveis de serem feitas mesmo nessa “correria”.
3. O produto possui requisitos com certo grau de estabilidade?
O cliente quase nunca sabe o que quer com certeza, ou pode ter vontades voláteis Vivemos em um mundo de constantes mudanças. Assim, dificilmente os requisitos estarão fechados. No entanto, em um determinado momento do projeto, eles começam a ser relativamente estáveis. E é a partir daí que se pode desenvolver automações para os testes. Gastar recursos para desenvolver automações para funções que certamente serão mudadas é desperdício de esforço e tempo.
4. Tarefas repetitivas.
Sempre existe aquele fluxo que a gente tem que passar zilhões de vezes para garantir que está tudo certo (softwares que lidam com financeiro ou sessões críticas tem muito isso). Como esses fluxos tendem a ser mais estáveis, são grandes candidatos a automação e podem se beneficiar muito (em termos de profundidade e cobertura) da automação. Além de ampliar a qualidade, diminui o cansaço do testador em realizar diversas vezes a mesma coisa.
Automação e teste de carga
Além dos pontos comentados anteriormente, alguns tipos de teste seriam praticamente impossíveis de serem executados se não houvessem a automação, técnicas e ferramentas específicas para os tornar possíveis. O teste de carga é um desses tipos de teste.
O objetivo do teste de carga é verificar a quantidade de usuários/requisições/solicitações um produto consegue atender simultaneamente (ou seja, qual a carga esse produto consegue suportar). Assim é possível se ter uma noção de como a aplicação se comportará quando houver vários usuários utilizando-a ao mesmo tempo, e como isso, tomar decisões quanto a alocação de recursos para tal.
Como se trata de um teste no qual é necessário a simulação do acesso de várias pessoas, nada mais natural que a necessidade de uma ferramenta para tal simulação. Sendo assim, a escolha de uma ferramenta é um fator essencial para o teste de carga.
A escolha da ferramenta depende de qual fase de teste o teste será aplicado. Muito provável que esse teste será aplicado na fase de sistema, quando o produto já estiver com a funcionalidade pronta para ser apresentada ao usuário.
Esse tipo de teste é extremamente importante para grandes aplicações que recebem imensos volumes de acesso em determinados períodos, por exemplo: sites onde são divulgados resultados de concursos; sites de notícias; sistema da receita federal; sistemas de vendas de ingressos para shows.
Concluindo
A automação de testes pode sim contribuir para o desenvolvimento de produtos com maior qualidade, por meio da ampliação da profundidade e cobertura dos testes e diminuição do esforço gasto. Porém, para que seja utilizada, alguns pontos devem ser observados.
Sugestões de Ferramentas Gratis para Automação
Se você é um profissional de teste, certamente já ouviu falar do Selenium para automação de teste em navegadores. Particularmente eu o acho bem versátil e poderoso, principalmente quando utilizado com alguma linguagem de programação (gosto muito de java =}). Ele possui duas versões:
IDE: é um plugin que se instala no navegador. Possui o funcionamento mais simples, e é o mais indicado se você está começando agora comSelenium. Funciona como “capture/replay”, ou seja, gravando e executando ações que se quer;
WebDriver: um pacote java (JAR) com as funções mais elaboradas. Utilizando essa versão você terá maior versatilidade e poder de teste. Pelo fato de se poder utilizar uma linguagem de programação para criar os testes, é possível fazer bastante coisa com essa versão. Para agilizar, você pode gravar partes do fluxo com o IDE e exportar para a linguagem que deseja utilizar.
Além do Selenium, existe o Jmeter que pode ser utilizado para testes funcionais também, mas que proporciona um maior poder de teste para testes de carga/estresse.
Outras ferramentas super importantes para automação são Capybara, Rspec.
Do inglês, work breakdown structure – wbs pode ser visto como a decomposição de um projeto em componentes menores. Essa estrutura define e agrupa os elementos de trabalho de um projeto de forma a organizar e definir o escopo dos trabalhos desse projeto.
Um WBS ainda pode ser entendido como uma estrutura em árvore que demonstra a subdivisão do esforço necessário para alcançar um objetivo. Esse objetivo pode ser um programa, um projeto, um contrato, etc.
No meu caso, o interesse está no auxílio que essa estrutura provê para o planejamento e execução de um projeto, haja visto a necessidade de gerenciar o projeto de implantação de testes. Para compor essa estrutura, é necessário obedecer uma regra denominada regra dos 100%. Essa regra dita que o WBS deve capturar 100% do trabalho definido para o projeto, e também deve abarcar todos os entregáveis.
Para criar essa estrutura há várias ferramentas, e novamente, busco por ferramentas free. Encontrei no Ubuntu (debian) as seguintes ferramentas:
Dessas, a primeira vista, a que mais gostei foi da Xmind. A interface é boa e intuitiva. Irei mexer mais com as outras para ver se condiz com o que preciso.
Atualizado 29-01-2016: tenho utilizado o Xmind por 4 anos frequentemente. É uma ótima ferramenta para o desenvolvimento de EAPs. E o legal é que é multiplataforma =}
O Xmind é bem intuitivo, o que faz com que a curva de aprendizagem não seja tão acentuada. A granularidade do EAP será definida segundo a necessidade. Pode-se por exemplo preparar um planejamento mensal, com detalhamentos por semana.
Um exemplo dessa granularidade é para o planejamento mensal dos projetos que se deseja realizar o teste. Detalha-se em cada semana, quais os projetos serão testados. Visualmente fica bem fácil acompanhar os dias para o que será testado.
Teste unitário, ou teste de desenvolvedor, independente de como é chamado, um fato sobre ele é a necessidade de uma boa ferramenta para realizá-lo. Nesse sentido, quando se pensa em ferramentas para teste, há uma gama incrível de ferramentas proprietárias que dizem realizar um bom trabalho.
Apesar da existência dessas ferramentas proprietárias, onde trabalho, e até mesmo em parte por política própria, priorizo a busca por ferramentas free ou open. Com base nessas observações, ao procurar informações, duas ferramentas sobressaem quando se fala em teste de unidade, e são elas:
Ao se decidir por uma ferramenta, várias condições devem ser levadas em consideração:
Sua equipe está familiarizada com ela? se sim, ótimo! se não, haverá gasto de tempo e $$ com treinamentos ( sem contar a possível resistência de aprendizado de alguma ferramenta nova).
A ferramenta é mantida por uma comunidade ativa? possui alguma empresa que auxilia a manter essa atividade? possui bom suporte? uma comunidade pouco ativa implica em ferramenta desatualizada, defasada. Sem uma grande empresa para movimentar essa comunidade, talvez a comunidade por si só não consiga se manter. Quanto a suporte, a ausência de boa documentação, bons fóruns, dificulta não só o aprendizado, mas também a resolução de problemas novos.
Qual o grau de integração dessa ferramenta com outras ferramentas? por exemplo, essa ferramenta é um plugin? ou ela existe por si só?
Essas são apenas algumas, das várias questões a serem levantadas quando se escolhe uma ferramenta para determinado fim. Sendo assim, preciso de mais pesquisa para decidir qual delas utilizar.
