Existem vários cursos maravilhosos em diversas plataformas como Udemy, Pluralsight, Code academy. Alguns custam bem pouco (em torno de 30 reais) outros custam na casa das centenas de reais.
Mas e se eu não tenho dinheiro no momento? como fazer?
E foi por isso que resolvi listar algumas formas de aprender programação DE GRAÇA.
YouTube
Foi-se o tempo em que o youtube só possuía entretenimento. Basta dar uma pesquisada pra encontrar material de tudo e qualquer coisa e em Português! Existem diversos cursos muito bem produzidos e sólidos, como:
Eu particularmente gosto muito de vídeos para aprender sobre diversos assuntos. Porém, há quem prefira ler os conteúdos, como se estivesse em um livro.
Em todo caso, como em outras áreas, no caso de programação, não adianta só assistir os conteúdos, é preciso praticar! E existem alguns tutoriais que fazem o passo a passo para que haja a leitura e a prática em cada passo. Eis alguns:
JavaScript e outras tecnologias web na Khan Academy. A missão da Khan Cademy é prover educação gratuita e de qualidade em uma infinidade de assuntos. O legal é que agora eles possuem esse conteúdo em Português. O site disponibiliza o material com um passo a passo. Em cada passo do curso podemos executar os comandos no próprio navegador, sem precisar instalar nada no computador.
Kotlin. Kotlin está popularizando bastante, não só para desenvolvimento mobile mas para microserviços também (caso em que uso atualmente). No site da própria linguagem existe uma ferramenta interativa para aprender, passo a passo da mesma forma que o Khan Academy. Eu mesmo utilizei essa ferramenta quando estava aprendendo a linguagem. Vale a pena conferir. OBS> esse é em inglês.
Aprender Java na Code Academy. Há alguns anos atrás todos os cursos da Code Academy eram gratuitos. Eu mesmo aprendi Ruby inicialmente com eles ainda quando era gratuito. O site é mto bem construído e você pode executar os comandos no próprio navegador, assim como os outros dois acima. Hoje vários cursos são pagos, mas esse de introdução ao Java ainda é grátis. OBS> esse é em inglês.
Se você tem vontade de aprender programação, nem sempre precisa desembolsar rios de tinheiro pois atualmente existem diversas ferramentas e fontes para aprender a programar gratuitamente. Encontre a que você mais gosta e inicie hoje mesmo!
Conhece alguma outra ferramenta/site/tutorial de boa qualidade mas que eu não citei acima? me envie uma mensagem que eu a avalio e adiciono nessa lista.
Mas isso quer dizer que sua boca não funciona corretamente? ou que suas mãos deixaram de lhe ser úteis? ou que seus pés esqueceram como é caminhar e devem ser substituídos?
Certamente não!
Morder a língua ou a bochecha de vez em quando não quer dizer que sua boca esqueceu como é mastigar e por isso não lhe serve mais. Nem que precisa de uma boca 2.0.
Deixar cair algo de vez em quando não significa que nossas mãos deixaram de nos ser úteis e por isso abandonamos seu uso.
Tropeçar de vez em quando não prova que seus pés esqueceram como é caminhar e perderam a serventia
Essas “pequenas falhas” simplesmente revelam a nossa natureza humana: somos falhos por definição.
Mas ainda assim, pisamos na lua, descobrimos a cura para diversas doenças, voamos, fazemos transplantes de órgãos tão importantes quanto um coração. Dentre outras realizações que seriam enxergadas como mágica ou impossíveis há não muitos séculos atrás.
E conseguimos tudo isso sendo seres imperfeitos. Realizamos várias maravilhas.
Nesse sentido, como na vida em geral, precisamos rever a definição debom o bastante no contexto de produzir software. A perfeição não é um estado em um determinado momento, estático. Pelo contrário, a perfeição é um processo de aprimoramento e correção constante.
Grandes empresas já entenderam o que é bom o bastante. Aquelas que mudaram a forma como comunicamos, nos relacionamos e até vivemos como Google, LinkedIn, Apple, Microsoft, Nokia.
E é também graças a esse reconhecimento da falibilidade que chegaram onde chegaram. Softwares imperfeitos foram colocados em produção, para todo mundo usar. O ciclo de correção foi encurtado apoiado pelos métodos ágeis, automação, CICD, DevOps.
E assim, iniciando com produtos bom o bastante, diversas empresas conquistaram grandes mercados e uma gama sem fim de realizações.
Como desenvolvedores de software de qualidade precisamos nos lembrar disso frequentemente, para não corrermos os risco de focarmos em padrões inalcançaveis e atrasar o lançamento do produto a tal ponto de não ser relevante.
Já se perguntou porque devemos testar os softwares que criamos? Afinal, qual o objetivo do teste de software?
Geralmente quando fazia essa pergunta para minhas turmas de alunos ou amigos de computação, a primeira coisa que respondem é:
“a gente testa para ver se funciona”
Essa resposta não está errada, mas também não está inteiramente certa. Ela está incompleta e esconde a natureza real do teste.
Dizemos que o teste possui a natureza destrutiva.
Diferentemente do desenvolvimento, que possui a natureza construtiva, dizemos que o teste de software possui a natureza destrutiva.
Parece meio dramático isso, mas o motivo primordial do teste de software não é demonstrar que algo funciona, mas demonstrar que esse algo possui problemas!
Isso quer dizer que o mindset do desenvolvimento e teste são inerentemente diferentes. Claro que ambos devem estar focados na qualidade final e primando um produto que funcione da melhor forma possível e agregue o maior valor possível para os clientes.
Mas no momento do teste, o foco é diferente de quando estamos desenvolvendo. No teste, executamos os programas justamente procurando aqueles casos que podem ter sido esquecidos na hora de fazer os requisitos ou de programar o produto. Procuramos por combinações que causarão comportamentos fora do comum, esperado, normal e seguro do produto.
Assim, o objetivo do teste de software é fazer o programa falhar, revelando defeitos que causam isso.
O objetivo secundário é mostrar que o software funciona de acordo com o esperado
Além de procurar por defeitos, o teste também serve para verificar se o que foi acordado foi de fato desenvolvido corretamente. Verificamos se os requisitos foram implementados de acordo com o que foi pedido.
Essa demonstração de funcionar conforme o esperado para alguns casos é chamado por vezes de exercício do “happy path” (caminho feliz). Caminho feliz porque estamos apenas mostrando que aquele produto funciona bem para aquelas entradas que colocamos.
Importante notar que apesar de ser possível demonstrar que o produto funciona para determinadas entradas, não temos condições de demonstrar que o produto funciona bem para absolutamente todos os conjuntos de entradas e combinações possíveis (salvo para domínios bem pequenos) dada a natureza infinita das possibilidades que essas entradas assumem.
E é exatamente por isso que existem as técnicas de teste, para nos ajudarem a criar casos de teste que sejam relevantes e que demonstrem o maior número de defeitos possível quando executado, mesmo sem exercitar todas as possíveis combinações de entradas de um software.
Além disso, erros no software podem causar tragédias e custar vidas
Veja alguns exemplos em que catástrofes foram causadas por erros de software:
Se você é um profissional de TI certamente já ouviu falar em abordagens ágeis quando se trata de como uma equipe que desenvolve software deve funcionar.
É bem provável que a empresa que você trabalhe aplique ou tente aplicar métodos ágeis em alguma profundidade.
Em maior ou menor instância, do jeito certo ou nem tanto, é bem provavel que sua empresa não funcione num processo cascata ou nos moldes clássicos. Ou pelo menos não deveria, a menos que seja realmente adequado para a realidade dos produtos que produzem.
Mas o que é ser ágil?
Resumidamente e simplificadamente, ser ágil consiste em respeitar um conjunto de 4 valores e 12 princípios descritos nomanifesto ágil em 2001visando construir um produto de melhor qualidade. Apesar dessa filosofia ter surgido com o desenvolvimento de software, hoje pode ser aplicado para desenvolver outros produtos também.
Existem diversas formas de aplicar os valores e princípios ágeis, e utilizar o SCRUM (que é um método ágil de funcionamento de equipes) é uma dessas formas. Mas existem outros métodos de trabalho para que uma equipe seja entendida como ágil como: XP, kanBan, lean, Crystal etc.
E se quem desenvolve software está usando SCRUM (como é o caso da maioria das empresas que desenvolvem software),
onde é que o gerente de teste está?
O gerente de teste, no SCRUM, não está em lugar nenhum. Isso acontece porque nesse método, não existe a figura dos gerentes, tão pouco do gerente de testes. No entanto, é possível verificar sua existência em muitas empresas que ainda estejam migrando para um funcionamento totalmente ágil.
Se não tem gerente de testes, quem gerencia os testes?
Numa equipe ágil (entenda-se scrum, pois é o método que a maioria das empresas aplica ou tenta aplicar), a função de gerenciamento é de toda a equipe.
A proposta é ter equipes auto gerenciáveis. Não há uma figura responsável por gerenciar algo dentro de uma equipe scrum. Pelo não com os títulos clássicos “gerentes”.
Lembre-se que o papel de gerenciar também não é do scrum master (que possui a função de manter a equipe funcionando da melhor forma possível, mas não de gerenciar o que cada um faz com um gerente tradicional).
Um dos assuntos mais controversos na área de teste, sem dúvidas, é o caso de teste. Devemos escrevê-lo com qual nível de detalhes? com qual profundidade? um para cada função? um para cada fluxo? end to end? etc.
Principalmente para quem está começando com o teste de software, existem diversas dúvidas. Por muitas vezes essas dúvidas aparecem mesmo com relativa experiência.
Especialmente em ambientes ágeis, esse quesito é um desafio diário. Existe ainda quem acredite que em equipes ágeis essa necessidade (tanto como boa parte da documentação) é suprida somente pela comunicação.
E observe que, apesar de priorizar comunicação ao invés de documentação, isso não quer dizer, em momento algum que iremos deixar de fazer documentação!
Pense comigo o seguinte cenário: o produto está em produção, e uma nova função foi desenvolvida as pressas (como geralmente ocorre com um produto que já está em produção). Nessa correria os analistas alegam que não tiveram tempo de detalhar em documentos como a função deve ser. Se o analista já for o próprio desenvolvedor então (como acontece em empresas pequenas, onde o acúmulo de função é comum), aí há grandes chances de ele ter ido direto dos requisitos ouvidos dos stakeholders para o desenvolvimento da função.
Em um mundo ideal, não deveria acontecer o fato de se passar de um reunião direto para o desenvolvedor, nem tão pouco o acúmulo de função. Deveria existir um registro que detalhasse como a função deve ser. Porém, entendemos que muitas vezes “no mundo real” as pressões sofridas para a entrega levam ao pulo desse passo. Na correria pela entrega de uma determinada função, em geral, a documentação é sacrificada.
Continuando o pensamento, a função foi desenvolvida sem (ou com pouca, insuficiente) documentação. Tudo corre bem, até que ela chegue para o teste. Chegando em teste, a primeira pergunta que nós de teste fazemos é:
E o que essa função deve fazer? (o “deve fazer” inclui múltiplas subperguntas, quais regras/fluxos/papeis deve obedecer? dentre outras).
Se houver documentação, isso será o perfeito auxílio para se originar os requisitos de teste, e então montar os casos de teste.
Mas e se não tiver a documentação?
É aí que os pontos do manifesto ágil são chave para o sucesso. Proximidade e comunicação irão diminuir o problema da falta de documentação, mas por vezes as memórias falham e as pessoas esquecem detalhes do que foi combinado. Então, mesmo que seja relativamente fácil se comunicar com a equipe e “relembrar” o que foi acordado, o ideal é que isso esteja documentado em algum lugar de alguma forma.
Para se testar qualquer função que seja, é necessário a correta definição de como ela deveria se comportar. O fato, é que venha de onde vier, para que o teste seja bem realizado, essas informações devem ser obtidas. Nem que seja conversando com os analistas/desenvolvedores para entender melhor como ela foi feita.
Porém, essa reunião de informações que o pessoal do teste terá de fazer, demanda tempo e esforços que poderiam ser “economizados” caso uma boa documentação tivesse sido realizada. O que é uma boa documentação, vai variar de lugar para lugar. Como praticamente tudo na engenharia de software, o bom é o que é adequado (funciona, agrega valor, auxilia) a realidade em que se trabalha.
Aí tudo bem, você gastou um tempão para reunir as informações sobre determinada função. Agora o que você faz com isso? a menos que tenha uma memória de elefante (o que não é muito comum para o pessoal da nossa área) seria interessante anotar, organizar, estruturar e armazenar essa informação de alguma forma.
E é aí que o caso de teste se torna um poderoso aliado!
O caso de teste nada mais é do que um conjunto de informações que serão fornecidas para o produto sobre teste juntamente com as saídas esperadas desse produto.
Um grande possibilidade de documentação dos casos de teste, bastante utilizada nos contextos ágeis são os cenários de uso que fazem parte das histórias de usuário (user stories) que eu falo nesse texto aqui. Esse formato é muito utilizado e ajuda muito na automação dos testes. Tenho um vídeo falando sobre BDD aqui>
Uma outra possibilidade é escrever os casos de teste em uma Wiki que seja compartilhada entre os membros da equipe. Algumas ferramentas de teste automatizado também utilizam esse formato para executar os testes.
Uma outra possibilidade ainda é um documento de texto versionado no SVN ou GIT, Google Docs, ou qualquer outra coisa assim também.
O que não vale é deixar de criar os casos de teste e com isso perder o controle dos testes executados, e também dos cenários que se pretende exercitar.
Conclusão
Ao se testar algo, é importantíssimo criar casos de teste, nem que seja em um formato simples, mas que o auxilie a organizar as ideias do que deve ser testado.
Como o caso de teste será feito é uma decisão da equipe, respeitando o que faz sentido e agrega valor para a equipe e empresa. A granularidade (detalhamento, profundidade) vai depender de cada situação.
Durante minha trajetória profissional no teste de software utilizei vários livros para aprender sobre como testar bem os programas. Alguns deles eu utilizei por mais tempo, e por mais vezes, e outros apenas para uma passada rápida.
Infelizmente não existem muitos materiais impressos para aprender sobre teste de software em português, mas existem boas fontes online, como esse site por exemplo =}
Assim, boa parte dos materiais de aprendizado são em inglês.
A seguir estão minhas indicações para quem está começando e procura livros para aprender sobre teste de software.
Introdução ao teste de software
DELAMARO, Márcio Eduardo (Org.) ; MALDONADO, José Carlos (Org.) ; JINO, Mario (Org.) .1. ed. Rio de Janeiro – RJ: Editora Campus, 2007. v. 1. 394 p.
O primeiro deles, e único em português que utilizei na escrita do TCC (monografia, projeto final de curso) na época da graduação. Diga se de passagem, é um no qual o meu orientador da graduação foi co-autor. Esse livro é bom para se ter uma visão geral sobre teste de software, e ter uma introdução sobre o assunto.
Syllabus da Certificação Incial em Teste de Software BSTQB ISTQB
Sabia que existe uma certificação bem famosa e reconhecida internacionalmente em teste de software? então, se não sabia, dá uma olhada no site doBSTQB – Brazilian Software Testing Qualifications Board. Esse site é a seção brasileira da entidade certificadora em teste. O interessante dessa certificação é que ela é reconhecida em outros países (vi diversas vagas de trabalho na Inglaterra por exemplo que pedem a certificação “CTFL – Certified Tester Foundation Level” que a certificação básica inicial dessa entidade). Então vale muito a pena fazer, não só para se destacar no Brasil, mas também para quem pensa em trabalhar fora.
O Syllabusque eu recomendo é o que descreve o conteúdo programático da certificação inicial de testes, da CTFL. Esse syllabus funciona como um índice dos principais conteúdos básicos de teste, contendo uma descrição bem básica de cada item, mas que lhe capacita a pesquisar mais sobre cada assunto.
The Art of Software Testing
Glenford J. Myers.
Com uma rápida pesquisa na internet é possível encontrar um pdf desse livro. Um excelente livro introdutório, e geralmente é bem fácil encontrá-lo. Certamente quem está a um certo tempo na área de teste já viu esse livro em algum momento. Apesar de ser em inglês a linguagem não é tão complicada.
Introduction to Software Testing
Paul Ammann and Jeff Offutt.
A quarta referência que gostaria de indicar, e também muito bom para aprender conceitos, de uma forma mais resumida é o livro dos autores amman e offutt. Apesar de ser em inglês, a linguagem é não tão complicada, e serve como um ótimo livro de referência para os conceitos básicos.
Managing the Testing Process
Rex Black.
Por último, mas não menos importante, após aprender os conceitos básicos sobre teste, para aprender sobre o processo e gerência de teste a partir de uma visão mais prática, o meu favorito é o livro do Rex Black.
Além de ser o autor dos livros desugestão para estudo da certificação avançada doISTQB, o livro possui enorme qualidade e diversos aprendizados de um autor que possui muitos anos de experiência na área. Vale a muito a pena, especialmente para quem está começando na área de gerência (liderança, coordenação) de teste.
Se você é um profissional de TI certamente já ouviu falar em abordagens ágeis quando se trata de como uma equipe que desenvolve software deve funcionar. 