Porque bloggar não é fácil?
Este post é off topic, não está relacionado aos temas normalmente discutidos no blog
Blogar é algo que vem se tornando comum, e quase que mensalmente vejo um novo blog falando sobre teste de software. Acredito que toda a vontade de compartilhar conhecimento é válida e nunca deve ser criticada, afinal, todos temos experiências diferentes e em algum ponto um estagiário pode ver algo que o mais experiente e certificado profissional nunca tinha pensado, mas é muito importante tomar cuidado com algumas coisas antes de sair blogando.
Vou tentar expor os principais pilares que me guiam hoje quando vou postar alguma coisa nova e que foram descobertos com muitos erros nos meus posts passados.
Tema interessante
A busca de um tema interessante é a primeira fase de um post de sucesso. Ela pode partir de vários pontos, um problema que você vê na sua empresa, em você ou mesmo na sua comunidade técnica, pode ser algo que queira estudar mais, pode ser um detalhe técnico que ajude a solucionar problemas, pode ser um questionamento ou comentário em listas, emails ou mesmo um outro blog post que te inspirou. Enfim, o que não faltam são motivos para blogar. O importante é que esse ponto de partida seja algo alinhado com o que você pratica, ou algo que será muito bem estudado.
Também não é bom que esse tema seja algo muito particular ou com universo muito restrito pois será compartilhado e deve despertar o intreresse dos leitores, mas também não é bom que seja algo que não te desperta interesse e que será feito só porque acredita que o público quer ler isso. Se isso acontecer, provavelmente não te adicionará quase nada novo e você não vai dar muito de sí para esse post. O equilíbrio é algo que você domine, goste, esteja apto a estudar agora e que de alguma forma influencie positivamente na comunidade técnica.
O tema também não deve ser algo totalmente novo para você, pois facilmente pode cometer erros ou deixar lacunas, e isso pode impactar negativamente nos leitores, mas vamos falar disso um pouco mais a frente como parte da Responsabilidade de um bloger.
Responsabilidade, Ética e Imparcialidade
Esse é o campeão no quesito "blogs que o Camilo não lê". Quando blogamos, temos que saber que existem realidades muito diferentes das nossas e que nossa experiência, por maior e mais vasta que seja, não engloba todo o conhecimento de um determinado assunto, ainda mais um assunto tão discutido e mutável como software.
Quando falamos imparcialidade, falamos que devemos saber buscar outros pontos de vista, diferentes dos nossos, das nossas empresas e das nossas referências e herois. Por mais que sejamos especialistas em determinado assunto, que tenhamos visto isso funcionando de um jeito ou que nossos seniores descrevam que esse é o melhor jeito de fazer as coisas, quando blogamos temos que saber que muita gente vai ler isso e que possivelmente tem uma opinião diferenciada, principalmente se não formos imparciais. Essas pessoas podem olhar a imparcialidade como xiitismo, arrogância, prepotência ou mesmo preconceito do blogueiro, e isso pode manchar a sua imagem com a sua comunidade local. Claro que as vezes devemos ser um pouco mais firmes quando advogamos por algo que acreditamos com plena convicção, só vamos estar abertos a escutar os argumentos antes de criticar, e claro, contra argumentar se necessário. Não existe problema em discutir um assunto com firmeza, desde que não sejamos desrespeitosos com nossos colegas de profissão.
Vida de um Agile Tester – Parte I
Este é o primeiro post da série "Vida de um Agile Tester" onde serão apresentados vários aspectos da vida de um QA. Neste primeiro post vamos nos limitar a uma visão geral dos principais eventos que futuramente vamos trabalhar isoladamente, portanto muitos deles ainda estarão incompletos e sem exemplos ou referencias o suficiente. Em futuros posts vou detalhando cada um.
É importante lembrar que existem várias maneiras de trabalhar em um projeto de software, entre elas existem as "maneiras ágeis" de desenvolvimento de software. O que será apresentado durante essa série de posts, são exemplos baseados principalmente na minha experiência com projetos ágeis, portanto, não representa uma verdade absoluta ou a única "maneira ágil" de desenvolver e testar software, mas uma forma que vem dando muito certo para mim. 
Inicialmente, vamos compreender que ágil se trata de desenvolver software de uma forma flexível o suficiente para que o produto desenvolvido possa ser adaptado as mudanças de diversas naturezas. Ágil não se declara um processo para desenvolver software, mas um conjunto de valores para desenvolver melhor o software, por isso o "processo" é muito flexível. Mais a frente vamos falar mais sobre isso, mas para esse post vamos falar sobre as práticas baseadas em valores que são comumente usadas no desenvolvimento ágil, principalmente do XP e do SCRUM.
A inception
"Inception should be a few days’ work to consider if it is worth doing a few months’ work of deeper investigation during elaboration." - Martin Fowler
Inception Story Mapping by Agile Tips
A primeira primeira e penúltima fase de um projeto ágil. A inception (não consigo encontrar uma boa tradução para isso) é relativamente parecida com a concepção para projetos waterfall/RUP Based. É um período de tempo voltado a conhecer o cliente, estudar suas necessidades, viabilidade de tecnologias/arquitetura, introduzir o pensamento ágil para o cliente e apresentar um esboço de altíssimo nível do que será o projeto para o cliente. Quando falamos, sublinhamos e colocamos em negrito o termo altíssimo nível, é porque aqui existe uma grande diferença do ágil para o waterfall. O waterfall fecha o projeto após a sua concepção (o que inclui estimativas, documentação, soluções técnicas, tipos de testes, planejamento e arquitetura), o ágil inicia o projeto (o que não inclui todas as estimativas, toda a documentação, soluções técnicas, tipos de teste, planejamento e nem arquitetura).
Agile é a forma mais correta de criar softwares customizados, pois o cliente tem a liberdade de mudar qualquer coisa a qualquer momento. Durante todo o desenvolvimento, o cliente terá um software funcionando para avaliar e toda a equipe trabalha dentro das expectativas do cliente. A inception deve ser o ponta pé inicial disso e por isso tem a missão de conscientizar o cliente e o time sobre esses preceitos e em troca, todos (incluindo o cliente) concordar com isso.
Ao terminar uma inception o time ágil tem um backlog do produto, que pode ser classificado como uma lista de desejos do cliente por prioridade (o que o cliente mais precisa vem primeiro) e com estimativa inicial da complexidade (medida pelo time). Essa lista de desejos será mudada pelo cliente várias vezes de agora em diante assim como a complexidade também será ajustada pelo time. Essas duas práticas ajudam a ter um produto funcionando mais rápido, assim o cliente pode mudar de ideia ou pensar em novos desejos antes que o projeto precise ser totalmente modificado para atendê-los.
Os principais papéis envolvidos nessa tarefa são o Cliente, o BA e o PM/IM/ScrumMaster, pois envolve mais explorar o negócio do que questões técnicas. Mas é muito interessante ter pelo menos um QA e um Dev Lead envolvidos na Inception, pois eles podem ajudar a encontrar User Stories técnicas, dar pitácos sobre alguns épicos ou User Stories, sugerir soluções não técnicas e até alertar sobre viabilidade técnica de algum requisito ou desejo do cliente.
Ainda durante a inception podem ser tomadas algumas decisões técnicas tais como linguagem de programação que será usada, ferramentas para integração continua, nível/ferramentas de automação de testes, ferramentas para controle de defeitos, critérios de qualidade, requisitos não funcionais (performance e segurança esperados por exemplo), DoD (definição de pronto), layout do card wall, equipe do projeto, entre outras decisões que não devem ser tomadas sem a ajuda de um QA e um Dev Lead. O importante é que as pessoas técnicas que vão tomar essas decisões não estejam fora do contexto do projeto, ou seja, não entrem somente no final da inception sem conhecer o cliente e a razão/missão do produto.
Mais sobre o assunto:
http://agiletips.blogspot.com.br/2012/02/back-to-basics-what-made-this-agile.html
http://pragprog.com/book/jtrap/the-agile-samurai
BugBang Responde I: Horas x Qualidade (A eterna briga das empresas)
Esse é o primeiro post da série BugBang responde. Essa série foi criada com base em e-mails que recebo de leitores questionando alguns pontos que eu considero muito interessantes e gostaria de compartilhar com outros leitores.
Alguns pontos devem ser considerados sobre esse post e estão listados abaixo:
- Ninguém é dono da verdade: As respostas são baseadas na minha experiência e em literaturas referenciadas junto das respostas, portanto são limitadas ao meu conhecimento, minhas pesquisas e ao contexto em que trabalho ou trabalhei.
- As respostas não são uma solução genérica e definitiva, mas um ponto de vista e algumas dicas de por onde trilhar ou o que estudar/praticar para alcançar o resultado esperado sobre um cenário bem específico, além de algumas opiniões minhas.
- Informalidade: A linguagem usada abaixo é ainda mais informal do que a de costume aqui do blog, pois se trata de uma conversa por e-mail.
- Conteúdo autorizado e aprovado: Antes de postar qualquer e-mail aqui eu pedi autorização da pessoa que fez as perguntas.
- Anonimato: Por motívos óbvios não serão citados o nome da pessoa nem da empresa para a qual essa pessoa presta serviço.
Os pricipais motívos de ter criado essa série são dois:
- Compartilhar as dúvidas de uma pessoa para que outras pessoas que tenham as mesmas dúvidas possam encontrar as respostas e debater sobre o tema.
- Como minhas respostas são limitadas principalmente a minha experiência e minhas pesquisas, também desejo compartilhar as respostas para que outras pessoas que tenham respostas e pontos de vista diferentes possam argumentar. Nesse caso tanto o autor das perguntas, quanto os demais leitores que busquem pelas respostas e claro, eu, seremos beneficiados das novas respostas.
O primeiro post da série vemcom um título forte (mérito do autor da pergunta) e entre outros aspectos, aborda uma questão extremamente polémica e complexa de responder:
"Como provar que ter uma equipe de qualidade/testes não é uma despesa, mas sim um investimento para empresas que não acreditam nela? "
Porque eu voaria em um avião desenvolvido de forma ágil
Eu costumo ver muitos comentários e exemplos positivos sobre agile em blogs listas de e-mails, mas curiosamente no final desses comentários e até de palestras eu vejo a pergunta:
Agile é legal e funciona bem para projetos pequenos, mas você voaria em um avião desenvolvido e testado de forma ágil?
Eu tento entender o motivo dessa comparação no passado, quando tínhamos poucas informações sobre ágil e toda essa história era novidade, mas não sei se da pra entender nos dias de hoje.
BTW, depois de ver isso novamente em uma lista alguns dias atrás, refletir durante algumas horas cheguei a conclusão que sim, eu voaria! E vou tentar responder o porque eu voaria em um avião desenvolvido de forma ágil de uma forma bem direta:
Porque eu já faço isso :p
Antes de continuar lendo, eu ressalto que comparações idiotas, merecem respostas e justificativas idiotas.
Sim, de fato o processo de montagem de um avião é muito mais ágil do que waterfall ou RUPista (Se fizermos uma comparação bem abstrata desse processo com o processo de desenvolvimento de software). Claro que existe uma diferença gigantesca entre desenvolver aviões e softwares, mas eu me permito fazer essa comparação já que ela foi feita anteriormente no questionamento sarcástico citado no início deste post.
Antes de explicar o porque eu voaria, vou tentar explicar alguns dos motivos que geram essas comparações pela internet:
Entendendo BDD com Cucumber – Parte I
Este é o meu primeiro post sobre BDD e Cucumber. Nesse primeiro post não vamos ver nada de automação nem cucumber, mas entender um pouco do contexto que estamos vivendo em teste de software e como são escritos testes no mundo ágil. Vamos entender o conceito de Critério de Aceite e como eles são usados pelo BDD e no final vamos fazer uma comparação entre os testes no modelo tradicional como descritos pela norma IEEE 829 em relação aos critérios de aceite usados pelos times ágeis.
Claro que todos os testes que realizaremos manualmente hoje, serão automatizados no futuro. Para escrever os testes vamos usar um exemplo que já é conhecido por todos, os testes do triângulo de Myers (Ok, eu sei que todos já estão de saco cheio desse exemplo, mas ele é simples e bem didático e fácil de entender)
Pra começar, vamos alinhar alguns conceitos e entender um pouco da história dessa sopa de letrinhas. A história descrita abaixo é baseada em uma pesquisa que eu realizei com alguns livros, artigos, wikis e posts de blogs, pois infelizmente não vivi essa fantástica época (provavelmente eu estava assistindo Saint Seya e Pokemon lol), portando está suscetível a algumas falhas. Conforme eu for encontrando as falhas irei corrigindo.
1996 - Test-Driven Development
Em meados de 1996/2000, durante o surgimento da agilidade, começaram a falar sobre testar primeiro e desenvolveu-se o TDD (Test-Driven Development) como a prática de desenvolver os testes de unidade antes do desenvolvimento do código-fonte de produção. Para isso foi elaborado um processo chamado de Red/Green/Refactor, onde o desenvolvedor escreve testes, desenvolve o mínimo para fazer os testes passarem e em seguida refatora o código para melhorar a implementação. Esse conceito foi detalhado em 2002 pelo Kent Beck no livro Test-Driven Development by Example implementando o conceito descrito alguns anos antes por Martin Fowler no clássico Refactoring: Improving the Design of Existing Code (no qual o próprio Kent Beck participou como contributor). Esse modelo, também conhecido como UTDD (Unit Test-Driven Development) foi incorporado ao planejamento do XP (eXtreme Programming) para criar testes ajudando a desenvolver evitando defeitos e ao mesmo tempo criando uma suite de testes de regressão.
Para entender mais sobre TDD leia o livro citado acima (Test-Driven Development by Example do Kent Beck).
Notas sobre o Curso Certified ScrumMaster (CSM)
Esta semana eu tive o prazer de participar do curso Certified ScrumMaster ministrado pelo Heitor Roriz da empresa Massimus C&T (Curso oficial da Scrum Alliance) aqui em Porto Alegre.
O meu principal objetivo com o treinamento era reforçar os conceitos, ferramentas, práticas e principalmente valores do Scrum, visualizar os objetivos do scrum master (focando um contexto diferente do que estou habituado) em relação aos team members e em especial aos QAs e claro, buscar referências para continuar aprendendo e estudando agile.
"This course focuses on the basics of the Scrum framework, including team roles, activities, and artifacts, so that you can be an effective member of a Scrum team."
(http://www.scrumalliance.org/pages/CSM).
Outro ponto que hoje é uma das minhas prioridades é a busca por melhorias das minhas soft skills, ou seja, das minhas habilidades de comunicação, planejamento, auto-gerenciamento, estimativas, resposta a mudanças e a problemas, comunicação com o cliente entre outras habilidades, que não estão relacionadas diretamente aos conhecimentos técnicos. Esse curso coube como uma luva, pois pude discutir com muitos scrum masters com mais experiência do que eu, ao mesmo tempo alinhar muitas dúvidas e expectativas sobre o Scrum e sobre agile de um modo geral.
Certified ScrumMaster Course
The Certified ScrumMaster (CSM) course offers training in the Scrum fundamentals essential for ScrumMasters or Scrum team members.
O curso foi muito interessante, primeiro por proporcionar um ambiente de profunda discussão sobre os mais variados temas, desde o uso de scrum para gestão de projetos de software até sua aplicação em gestão de projetos de engenharia civil. O Instrutor mostrou profundo domínio e experiência, juntando uma dose de teoria à aplicando diversas dinâmicas onde simulados todas as práticas e ferramentas oferecidas pelo framework scrum.
A busca pelo conhecimento em Scrum tem se mostrado cada vez maior entre os brasileiros. Não somente agilistas, como também muitos profissionais que trabalham com modelos tradicionais de desenvolvimento de software, pois o scrum pode ser implementado parcialmente para solucionar problemas em quase todos os tipos de projetos, principalmente os problemas de comunicação.
Penso, logo automatizo
Estamos com muitas discussões sobre o tema: "Automatizar os meus testes é mais caro/demorado/arriscado e tudo de ruim se comparado com executar os testes manualmente". Bom. . . Se pensarmos com bons certificados que somos, sim, qualquer resposta diferente disso é menos um ponto na maioria das provas de certificação.
Muitos slides por aí na internet, inclusive meus (Y_Y) também falam sobre isso. Então não tem mais o que discutir certo? Nem tanto . . .
O problema da automatização não é a automatização em si, mas sim, a automatização sem planejamento, sem uma arquitetura mínima. E quando falamos de planejamento, não estou falando de documentação extensiva nem de horas e horas nas salas de reunião com o seu gerente, o presidente da empresa e mais três pessoas que não fazem a mínima ideia do que seja arquitetura de software e padrões de projeto, mas sim de bons QAs e bons developers pareando e pensando juntos em como desenvolver uma arquitetura para testes automatizados que seja adequado ao seu projeto, sustentável, fácil de entender, extensível e acima de tudo flexível a mudanças.
Estamos falando justamente sobre isso no GUTS-RS e também no DFTestes, quando um colega na discussão questionou como isso funciona em termos práticos, por isso estou postando este exemplo usando um framework gratuito e portável para automação de testes funcionais, o Watir.
Para rodar todos os exemplos deste post você precisa apenas instalar o ruby 1.8.7 ou superior na sua máquina com windows ou linux e em seguida executar o seguinte comando:
Windows: ~$ gem install watir-webdriver
Linux: ~$ sudo gem install watir-webdriver
Pronto
Para exemplificar como isso funciona na prática, vamos imaginar um cenário bem simples que vai ficando mais complexo, exatamente como um projeto de software funciona:
Um QA qualquer recebeu a seguinte tarefa: Inclua o texto "Automação Rocks!" no google e em seguida verifique se é apresentado o texto "The Bug Bang Theory 2.0". Esse QA poderia optar por três alternativas:
- Executar testes exploratórios: Sem evidenciar ou documentar os testes (planejar != documentar). Em teoria, esse é o teste mais rápido que existe, logo mais simples também. As suas desvantagens são exatamente a falta de evidências e a incerteza ao relatar a cobertura dos testes.
- Documentar os testes em uma ferramenta de gestão de testes: Documentando e evidenciando as execuções manuais dos testes em uma ferramenta como por exemplo o TestLink. Esse é o segundo teste mais rápido*, e agora com a vantagem que temos a nossa cobertura bem definida e evidencias das execuções para nossos PMs e ou clientes.
- Automatizar os testes: Escrever testes automatizados para que os testadores fiquem livres para criar novos cenários e testar a aplicação em outros aspectos. O problema aqui é que esse teste é muito caro**, as empresas não tem ambiente para isso**, e segundo alguns CONSULTORES da nossa área, dificilmente o ROI de automatizar um projeto é sustentável***.
*Argumento que contrario neste post 
**Outros argumentos que contrario aqui . . . :p
***Argumento ultrapassado usado nos anos noventa e que continua sendo usado na atualidade. . . tsc tsc tsc
Lembrando que BDD e TDD também são formas de automação.
The Bug Bang Theory 2.0 – Agile and Technical Testing Rocks!
O blog The Bug Bang Theory está passando por uma mudança (para melhor).
Até hoje, o blog não tinha um foco, explorando diversas áreas, inclusive antagônicas. Isso não é de todo ruim, mas de uma certa forma, acaba deixando a desejar quando ao mesmo tempo fala sobre processos tradicionais e ágeis por exemplo, ou quando exemplifica execuções manuais no TesLink e exemplos básicos de automação em várias suítes diferentes. Escrever sem um foco acaba te tornando muito generalista e imparcial. Acredito que nós profissionais de teste de software devemos ser multidisciplinares, mas não generalistas.
A ideia do blog agora é focar nas principais, mais modernas e mais acessíveis técnicas e ferramentas da atualidade.
Por que a mudança?
Estou reaprendendo MUITO sobre agile, testes e automação. Muitas das coisas que eu acreditava ou era tendencioso há alguns meses atrás, já não parecem ter tanto sentido, e muitas das coisas que você pode ler nos posts anteriores a esse, podem ser contrariadas nos posts daqui para frente. Inclusive é por esse motivo que estou sumido da comunidade e do blog nos últimos meses.
Pra início de conversa, eu pensei MUITO sobre começar a escrever os posts em inglês (visando discutir com outros QAs de fora), mas lembrei que o que me motivou a iniciar o blog não foi simplesmente o fato de estudar mais, mas também ajudar outras pessoas no Brasil e fomentar o crescimento técnico e intelectual no Brasil. Por isso vou manter os posts em português.
Algumas das principais mudanças que serão realizadas são:
Adeus TestLink, Mantis e controle arcaico de teste de software: Acreditei durante muito tempo no modelo de escrita sistemática de casos de teste, mas hoje em dia não vejo mais esse modelo antigo funcionando. O TestLink pode até ser um grande passo em empresas mais tradicionais, ou onde não é depositada muita confiança nos QAs / Testers, mas não adianta focar nos sintomas, temos que mudar pela doença. O que quero dizer é que não adianta continuar focando 50% a 80% do nosso esforço e tempo documentando, controlando e evidenciando nosso trabalho para demonstrar o valor do Teste de Software. Temos que demostrar o valor no dia a dia, através de resultados no software (no real valor para o cliente), inclusive usando este tempo para isso. A mentalidade das organizações modernas não pode mais continuar baseada em ferramentas de controles de tarefas, mas sim em times que desejam entregar o melhor para o cliente e por isso vão fazer o melhor todos os dias (e isso não é frase de professor).
Reviews de Livros Técnicos: Leio e coleciono livros sobre teste de software, segurança web, desenvolvimento ágil, desempenho web, programação entre outros temas. A partir de agora teremos uma série de posts sobre os principais livros em que eu estudei e/ou estou estudando. Esses posts serão uma tentativa de estimular a leitura e a discussão de temas relacionados aos principais autores no mundo, focando em tópicos que não são discutidos pela certificação A ou B, mas sim por doutores, pesquisadores e principalmente profissionais de teste de software com real vivencia nas praticas atuais do mercado.
Sem mais CMMi, modelo V, processos tradicionais e modelos ultrapassados de desenvolvimento: O mundo do desenvolvimento de software não estaria tão desenvolvido hoje se não fossem esses pioneiros do desenvolvimento, criando modelos e processos complexos, com templates, fluxogramas e certificações para empresas e profissionais. Mas esse tempo passou e hoje as empresas mais conceituadas no mundo adotam agile, vendem agile, compartilham agile e respiram agile. Entre elas o Google, a ThoughtWorks, o Facebook, o Flicker, Microsoft, Twitter e dezenas de outras empresas. As principais startups de hoje também adotam modelos ágeis de desenvolvimento de software. Porque continuar vivendo do passado?
Automação, Automação e Automação!!!: A partir de agora vai ter MUITO conteúdo técnico sobre testes ágeis, uso de ferramentas e técnicas do dia a dia, principalmente do ponto de vista ágil, sem aquela "renca" de documentação e planejamento desnecessário. Muitas novidades para o mundo Ruby de teste de software, Selenium webdriver, Cucumber, Twist entre outras ferramentas.
Soluções free e Open-source: A partir de agora vou focar em soluções totalmente acessíveis ao mercado brasileiro, sem nenhum custo de implementação, como Selenium, JMeter, LoadUI, Watir, Session Tester, SkipFish, entre outras. Sim, é possível ter produtividade, qualidade e controle usando ferramentas open source, tão bons ou melhores que os oferecidos por suítes caríssimas no mercado.
Não quero que achem que estou ficando xiita, mas sim que o blog passará a ser exclusivamente técnico, focando automação e desenvolvimento ágil, do lado dos testadores. A partir de agora vamos discutir conhecimento técnico sem churumelas.
Como sempre, mais do que qualquer outra coisa, este é um canal para discutir ideias, levantar questões e sanar dúvidas. Não é simplesmente porque estou mudando o contexto que vou deixar de responder dúvidas sobre o TestLink por exemplo, ou que eventualmente exista um post relativo a algum dos tópicos de antigamente, estou apenas falando que não será mais o foco.
Infelizmente, sei que essas novidades não vão agradar inicialmente a todos os leitores, mas espero que com o tempo possamos discutir e entender os motivos dessa mudanças.
Espero que gostem da nova versão do The Bug Bang Theory e vamos torcer para que essa tenha menos bugs que a anterior
Muito obrigado e bem vindo ao novo blog!
Camilo Ribeiro
Palestra UniBH: Desenvolvimento Dirigido por Testes
A UniBH (Universidade de Belo Horizonte) me convidou no ano passado para falar sobre teste de software na Jornada Tecnologica, e eu ministrei a palestra "Introdução a automação de testes", comentada aqui no blog. Também fui convidado para esse ano, com o objetivo de abordar algo relacionado a teste de software, mas não diretamente sobre teste. Optei por falar sobre desenvolvimento dirigido por testes, já que percebi muito interesse das pessoas depois que publiquei os posts "Uma Introdução a TDD com JUnit" e principalmente "Testes de unidade para quem não sabe nada de programação".
A UniBH novamente foi extremamente organizada. Contava com diversas palestras em várias salas e com uma recepção de primeira qualidade. Os alunos foram participativos e contei com a presença do Eduardo Habib, Test Manager da empresa Synergia, mestre em Ciência da Computação pela UFMG e professor dos cursos de computação da UniBH, uma das lendas da nossa área que ainda habitam Belo Horizonte.
A palestra iniciou com os conceitos de teste de unidade e desenvolvimento difirigo por testes seguiida de uma abordagem bem prática, através da demonstração de exemplos e criação de testes na hora.
Abaixo os slides e comentários:
Palestra PUC: Certificações em Teste e Qualidade de Software
Fui convidado para realizar a minha terceira palestra na PUC Minas, na 6ª Semana de Sistemas de Informação.
Ano passado já realizei as palestras "Carreira em teste de software" na 5ª Semana de Sistemas de Informação na PUC Barreiro e "Palestra PUC São Gabriel – Teste de Software: Introdução à Qualidade" na semana de sistemas de informação 2010 da PUC São Gabriel.
É uma honra palestrar em uma universidade com o prestígio da PUC Minas e uma honra maior ainda ser convidado para uma terceira palestra, pois me da a certeza que aquelas quase quatro horas agregaram conhecimento e enriqueceram um pouco mais aos ensinamentos dos mestres e doutores que lecionam lá.
Muito obrigado ao Professor Marcelo Werneck por mais uma vez tornou essa apresentação possível e por confiar novamente suas turmas à mim. Espero que os alunos e professores presentes tenham gostado e que possa ajudar a orientar melhor quais as certificações estejam buscando.
Como o tema desse ano foi Certificações em TI, não podia falar de um assunto diferente do que as certificações da área de teste e qualidade de software. Para isso realizei pesquisas e busquei bastante conteúdo já elaborado na internet.
Entre eles, destaco o artigo "Guia Completo para Certificações em Qualidade e Teste de software - Versão 2008" cedido pelo seu autor Fábio Martinho, que corre o risco de ser o artigo mais lido sobre teste de software no Brasil e o slide "Cargos e Salários 2010: Quanto Ganha um Profissional de Teste e Qualidade de Software no Brasil" cedido pelo Cristiano Caetano, que realiza as pesquisas mais sérias sobre cargos e salários e carreira em teste e qualidade de software, além de ser um dos maiores colaboradores da nossa área e o mantedor do TestExpert, a maior rede sócial de teste de software no Brasil. Portanto, fica aqui meu muito obrigado pela disponibilidade, prestatividade e agilidade com que me atenderam
Abaixo a Apresentação:
Comentários:
A palestra foi realizada para alunos do 5º ao 8º períodos do curso de sistemas de informação, e fez parte da VI Semana de Sistemas, dividindo espaço com outras palestras sempre com o tema, Certificação em TI. O tema faz parte de uma estratégia da PUC para estimular à obtenção de certificados entre os seus alunos, contando inclusive com uma parceria com a IBM para certificações mais acessíveis.
Agile Record
Base2
BDD
Belo Horizonte
Blog Action Day
BRATESTE
Bug Bang
BugBang Responde
Caso de Teste
Cucumber
DDT
Dimmunix
Game Testing
Google
IA
ISTQB
JUnit
Palestras
Praxis
QA
SCRUM
Squadra Tecnologia
TDD
TestExpert
TestLink
Watir
Webdriver
XP "Bugs" da Atualidade (2)
Agile (10)
ALATS (1)
Arquitetura (5)
Automação de Testes (4)
Bugs (2)
Camilo Ribeiro (5)
Carreira (13)
Certificação (4)
CMMI (2)
Engenharia de Requisitos (1)
Engenharia de Software (4)
Eventos (6)
Ferramentas (10)
Gerência de Teste (3)
Gestão de Defeitos (2)
História (2)
IBM Rational (2)
Java (3)
Notícias (10)
OFF TOPIC (4)
Processos (4)
Programação (3)
Ruby (1)
Segurança (1)
Técnicas de Teste (10)
Tecnologias Microsoft (2)
UFMG (2)
WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.
Follow Me!
Mais Lidos
- Especial: TestLink 1.9 (4989)
- Um Modelo para Elaboração de Cenários e Casos de Teste (2842)
- Exibindo evidências de teste no TestLink (1421)
- Vocabulário básico para testadores ágeis (1339)
- Qualité, Agilité, Automatiqué. 7 passos para revolucionar sua área de testes (1000)
- Usando TestLink para Garantia de Qualidade (985)
- Teste de unidade para quem não sabe nada de programação (883)
- Penso, logo automatizo (658)
- Palestra UNI-BH – Introdução a Automação de Teste de Software (654)
- Palestra PUC: Certificações em Teste e Qualidade de Software (634)
Arquivos
Pesquisa de opinião
Loading ...Eu acredito:
Lista de Links
- Agile Tips – Paulo Caroli
- Architecture Journal – Ricardo Ferreira
- As Especialistas
- ASP.NET, Flash, Flex, AS3 e Tecnologia por Lucas Lorentz
- Base de Teste de Software
- Blog da Iterasys
- Blog do Gustavo Quezada
- Blog do Jailton Alkimin Louzada
- Code Between Lines
- Elemar DEV – Tecnologia e desenvolvimento .net
- Ensaios de Qualidade
- Essence of Testing
- Finito – Paulo Vasconcellos
- Google Testing Blog
- GUTS-RS
- Java, Selenium e Coca Cola
- Leandro Moreira's Blog
- Marcos Sousa' Blog
- O Mundo pede novos líderes
- Qualidade Manaus
- QualidadeBR – Fabrício Ferrari
- SemBugs – Elias Nogueira
- Software Test and Performance Magazine
- Teste de Software e Métodos Ágeis
- Teste de Software e Utilidades
- TestExpert
- Testing from below the tropics by Felipe Knorr Kuhn
- The Lady Bug Blog
- The Shaolin of testing
- ThoughtWorks
- ThoughtWorks Testing Blog
- UFMG – Universidade Federal de Minas Gerais
- Vinicius Sabadoti – Teste de Software
- Zarro Boogs Found
Ultimos 20 posts
- Porque bloggar não é fácil?
- Vida de um Agile Tester – Parte I
- BugBang Responde I: Horas x Qualidade (A eterna briga das empresas)
- Porque eu voaria em um avião desenvolvido de forma ágil
- Entendendo BDD com Cucumber – Parte I
- Notas sobre o Curso Certified ScrumMaster (CSM)
- Penso, logo automatizo
- The Bug Bang Theory 2.0 – Agile and Technical Testing Rocks!
- Palestra UniBH: Desenvolvimento Dirigido por Testes
- Palestra PUC: Certificações em Teste e Qualidade de Software
- Qualité, Agilité, Automatiqué. 7 passos para revolucionar sua área de testes
- E quando o reuso de código é reuso de bugs?
- Teste de unidade para quem não sabe nada de programação
- Vocabulário básico para testadores ágeis
- Meu primeiro bug
- Regras Compostas = Falsa Produtividade
- Evidências para versão 1.9.1 do TestLink
- Especial: TestLink 1.9
- Myers e seus Trinta e Dois anos de Teste de Software
- ITester testEngineer = Tester.Developer(Discipline testing);