Carreira em testes de software: como iniciar?

Olá Pessoal,

Esses dias eu recebi um e-mail, pelo formulário de contatos aqui do blog, e decidi escrever um post sobre o assunto pois obviamente fiquei animada 😃😃😃. A pessoa me perguntou como fazia para iniciar a carreira na área de testes, deu uma breve descrição sobre sua formação e trabalho e perguntou se era isso mesmo. 

Show né? Vou tentar explicar para vocês. Vamos do início então:

Que formação devo ter para iniciar a carreira de testes?

Conheço várias pessoas com faculdade e sem faculdade trabalhando nessa área de testes de software. Existe um caminho único? Claro que não! 

As faculdades das áreas de tecnologia/informática são as mais comuns. Os testadores com formação em TI são conhecidos como testadores mais técnicos por eles não terem medo de "mexer no computador". Com o tempo eles adquirem experiência em negócio. Nas faculdades de Sistemas de Informação e Análise e desenvolvimento de Sistemas é comum ter uma matéria de Testes de Software.

Mas isso não quer dizer uma uma faculdade como Psicologia, Recursos Humanos, Contabilidade e Administração, entre outras, não possam gerar testadores. Muito pelo contrário. Eles sabem como ninguém o negócio das mais variadas áreas, pois estudaram a fundo o tal "negócio". Exemplo: a pessoa que cursa ou está cursando Recursos Humanos sabe como ninguém como se calcula uma folha de pagamento de funcionário nas mais variadas situações. Por isso, essas pessoas são chamadas de testadores de negócio.

Independente da formação superior escolhida, as especializações e os MBA's específicos de testes ou engenharia de software normalmente não requerem formação superior na área de TI. O mesmo vale para certificações técnicas.

Como iniciar a carreira de testes numa empresa?

As empresas que contratam pessoas para a área de testes normalmente querem que o candidato tenha experiência em testes ou que conheça o negócio da empresa em questão. As vezes, na sorte mesmo, aparecem vagas de estágio de testes para quem não tem experiência com testes nem negócio. Mas essas vagas de estágio em testes são raras.

Como iniciar a carreira de testes se não tenho experiência?

O caminho mais comum é iniciar trabalhando com suporte. Suporte ao usuário, suporte ao sistema, tanto faz aqui. Isso vai te dar experiência no negócio.

O que é esse "negócio"?

O "negócio" que você vai adquirir experiência é uma linha de produto que você vai atender. Por exemplo: se você presta suporte à usuários de ERP, com o tempo você adquire conhecimento em algum módulo dele (financeiro, contábil, produção, manufatura, logística, etc.). Esse conhecimento adquirido é o conhecimento em negócio.

Fora a faculdade, o que você recomenda estudar?

Hoje a área de testes está indo cada vez mais para linha de automação de testes. Então sugiro você estudar sobre frameworks que consigam automatizar processos. Os mais conhecidos são os que gravam tela ( Selenium é o mais famoso, e TestComplete. Outra ferramenta legal e bem fácil de usar é o Katalon). Onde eu trabalho estamos usando o CodecepJS que usa o Selenium de forma embarcada.

Outra coisa legal é que quase todas as empresas (de Startup a grandes empresas) criam APPS para tudo. Então ter a expertise de "fuçar" aplicativos mobile também é legal.  

Certificações na área de testes também são legais por N motivos:

1. Você não precisa ter curso superior para tirar;
2. Você aprende muito;
3. Algumas tem validade internacional.

Além disso, não posso deixar de falar nos cursos de especialização e MBA que existem e abordam sobre testes de software.

Você possui outro caminho? Entra em contato para incrementar o post! 😄

Espero que tenham gostado, até mais! 😃

Evento gratuito de Testes - QA Ninja Conference 2ª edição

Olá Pessoal

Quero compartilhar com vocês um evento de testes que vai acontecer entre os dias 24 a 28 de abril. É a 2ª edição do QA Ninja Conference, a primeira edição eu participei assistindo em outubro de 2016 e foi uma troca de experiências muito bacana. O evento é gratuito e totalmente online. Os assuntos abordados são bem interessantes, acho que vale a pena conferir. 😁

Seguem algumas das palestras que achei interessante (e pretendo ver):

• 24/04: Fala sério, mulheres na TI?
• 25/04: Testes em 2027: Para onde QA está indo?
• 25/04: Como trabalhar com QA em times de desenvolvimento ágil
• 25/04: Práticas do Agile Testing
• 27/04: Você já fez dev box testing hoje?
• 27/04: A importância de testes estáticos na entrega final do produto

Aproveitem, pois é gratuito e online. Ano passado teve várias conversas, entre uma palestra e outra, com pessoas que trabalham com testes fora do nosso Brasil. Muito bacana pra ver as tendências de fora.

Espero que gostem e até mais, 😃

Os ChatBots estão vindo com tudo!

Em setembro vi os primeiros posts sobre ChatBots em blogs de arquitetura de software. Vi que o número de posts relacionados ao tema foi aumentando. Para minha surpresa, tomei conhecimento de que tinha uma iniciativa sobre este tema na empresa onde trabalho e logo no mês seguinte fizeram um post sobre ChatBots no blog da empresa.

O que são os ChatBots?

São plataformas virtuais de comunicação que querem suprir as necessidades de comunicação e demanda de serviços. Mas diferente dos chats normais onde você conversa com uma pessoa, no ChatBots você conversa com um "robô".

E isso tem futuro?

Parece que sim, e muito! Os ChatBots estão se tornando tendência muito forte e prometem mudar a forma como as empresas em geral se comunicam e vendem seus produtos.

Um exemplo bacana...

Hoje é possível, com um ChatBots, que milhares de usuários conversem ao mesmo tempo com o Presidente Obama através da página oficial da Casa Branca no Facebook. Claro que não é o presidente quem está lá respondendo, mas sim um robô automatizado que consegue entender o tópico no qual o usuário está interessado e fornecer conteúdo relevante como se fosse a voz do próprio Obama.

Pausa, fizeram um robô do Obama?

Não, é um software. Não tem um robô físico na frente de um computador respondendo as mensagens.

Por que se fala tando sobre ChatBots agora?

Com o desenvolvimento da tecnologia e as melhorias no reconhecimento da linguagem e do processamento de informação, a interação com os serviços digitais está cada vez mais intuitiva, acessível e inteligente graças, sobretudo, à ajuda das interfaces conversacionais. Apesar de que a funcionalidade de maior valor dos ChatBots é a capacidade de fazer transações comerciais, esses robôs podem fazer muito mais!

Quais outras aplicações dos ChatBots?

Com um pouco de imaginação, é possível muita coisa. Olhá só algumas ideias onde os ChatBots já estão sendo implementados:

Helps: Sabe aquela documentação de ajuda de um software? Você pode solicitar diretamente pelo chat do help algum conteúdo que você busca e o Bot vai te entregar o conteúdo relevante;

Aplicativos de automação de casas: por meio de um ChatBot, você pode solicitar que ligue o ar-condicionado do seu quarto as 17 hs;

Pedidos de comida: Você pode solicitar comida pelo ChatBot, e ele vai fazer o pedido e anotar seu endereço pra depois um entregador real te entregar a comida no conforto da sua casa;

Comprar produtos e serviços: Já pensou entrar no site de uma empresa e , por meio do chat, solicitar a compra de uma Televisão pra entregar na sua casa? 

Reservar um restaurante/cinema/outro lugar: Solicitar uma reserva pelo chat sem ter que fazer todo um cadastro. Ô coisa boa! :D

Movimentações bancárias: Essa parte eu achei mais delicada, mas a promessa é conseguir fazer consulta à extrato, movimentações e pagamentos. Nesse tópico fiquei com um pé mega atrás, mas é uma possibilidade.

Já existem empresas de grande porte usando os ChatBots?

Sim, alguns exemplos de empresas que possuem algumas iniciativas com ChatBots são PizzaHut, GE  e a Amazon.

Quem fornece a inteligência artificial dos ChatBots?

Já temos algumas empresas nesse campo, mas acredito que a mais famosa é o Watson da IBM. Dá uma olhadinha no site do G1 que a chance de você encontrar algum banner sobre o IBM Watson relacionado à inteligência cognitiva é grande.

Como eles funcionam?

Por meio de inteligência artificial, um motor do ChatBot treina um vocabulário. É possível ter quatro conceitos: intenções, entidade, diálogos e contextos.

Na intenção, você cadastra expressões que possuem o mesmo significado e são utilizadas para definir o que o usuário quer. Exemplo: é criado uma intenção chamada #ligar e adicionar mais sentenças parecidas, como:

#ligar

eu gostaria de ligar

eu quero ligar

ligar por favor

voce pode ligar

As entidades são termos que possuem sinônimos ou que podem ser escritos como abreviações. Exemplo:

@objetos

ac - acs - ar-condicionado

luz - lustre - lampada - luzes

som - aparelho de som - rádio

Os diálogos são os caminhos lógicos que o robô utiliza para determinar uma resposta com base nas intenções e entidades fornecidas pelo usuário. 

Exemplo 01: se um usuário simplesmente digital "ligar", o ChatBot não vai saber o que ele precisa ligar, e responderá com alguma sentença, como "Entendo que você quer que eu ligue alguma coisa, porém, preciso saber especificamente o quê você quer que eu ligue.".

Exemplo 02: se um usuário simplesmente digital "ligar ac", o ChatBot pode responder "Entendido, ar-condicionado ligado".

Os contextos vão armazenar as intenções, entidades e diálogos de um mesmo contexto.

Imagem da autora

Como esses ChatBots são testados?

O testador precisa incorporar o usuário! Os caminhos que levam o robô a responder corretamente são parecidos com um modelo de negócio, pois seguem um fluxo. Minha sugestão para testes com os ChatBots é validar a transição de estados de uma conversa com outra. Outra sugestão, é fazer teste de usabilidade com uma pessoa que nunca teve a interação com o ChatBot. Solicitar que ela faça algo e ver como o ChatBot e a pessoa se comportam. 

Lembre-se que o intuito do ChatBot é ter uma conversa humanizada que entregue valor para o usuário . Eles chegam ao mercado para ser cada vez mais colaborativo para os seres humanos, não para substituí-lo.

Você já teve alguma experiência com algum ChatBot? Conta pra gente como foi! :D

Referências: 

Chatbot, o seu próximo melhor amigo. Disponível em <http://arquiteturadeinformacao.com/user-experience/chatbot-o-seu-proximo-melhor-amigo/>.

Chatbots: uma tendência cada vez mais forte na tecnologia. Disponível em: <http://www.senior.com.br/noticias/chatbots-uma-tendencia-cada-vez-mais-forte-na-tecnologia/>.

Desenhando interfaces conversacionais: o desafio do UX. Disponível em: <http://arquiteturadeinformacao.com/user-experience/desenhando-interfaces-conversacionais-o-desafio-de-ux/>.

O papel de UX nas interfaces conversacionais. Disponível em: <http://arquiteturadeinformacao.com/user-experience/o-papel-de-ux-nas-interfaces-conversacionais/>.

Massa de dados com data fixa: como evitar a quebra dos testes automatizados?

Um dos maiores medos dos testadores/automatizadores é quando um cenário de testes vem com data fixa. Se este teste é executado daqui a um tempo novamente, este cenário irá quebrar pelo simples fato de possuir uma data fixa nas pré-confições do cenário. Por exemplo, tenho testes que utilizam informações de um período de férias do mês anterior, no próximo mês o mês anterior já não será o mesmo, isso provavelmente fará o teste falhar. 

Que alternativa temos para as datas fixas?

Uma alternativa fácil, que também é sujeita a falhas, é "fixar" a data da máquina onde os testes estão executando. Eu acho esta uma prática muito errada, pois a máquina pode alterar o horário para o horário correto no meio da execução dos cenários automatizados. Aí perdemos a execução (Isso já me aconteceu devido à política de máquinas definida no AD aqui na empresa :'( ).

Outra alternativa é ter um mecanismo de "popular" a base através de um script antes de iniciar o teste. Isto permitiria que os dados inseridos fossem dinâmicos. Este script gera uma manutenção alta, pois alterações na base podem fazer com que o script pare de funcionar ou faça algo não esperado.

Existem ferramentas de mercado para inserir massas de dados que serão utilizadas nos testes?

Existe sim meus caros testadores! Uma boa opção é o DBUnit. Ele lê de um arquivo XML os registros e altera na base.

Como funciona quando uma validação precisa ser previsível?

Bom, a previsibilidade dos script pode ser garantida de forma lógica. Por exemplo, Existem cenários de testes para um processo de inserção de nota fiscal, onde o número da nota deve ser igual ao número anterior + 1. Para evitar que ocorram erros futuros quando se adicionar notas indiscriminadamente, adota-se uma validação lógica a qual seja especificada que o número da nota inserida deve ser igual ao número da nota anterior + 1. Dessa forma, ao se adicionar novas notas necessárias para outros cenários futuros não quebrará o teste.

Isso ocorre também no caso de datas exemplificado no início deste post. Repare que a especificação é estática e bem definida para o propósito de ser validado, porém por também ser lógica a implementação dela é que será dinâmica de acordo com a data em que o teste será executado.

Você já se deparou com uma situação assim? Comente como foi a solução!

Até mais! :D

Quando considerar um projeto pronto na metodologia ágil? Definição de Pronto - DoD (Definition of Done)

Olá meu povo testador!

Conforme mencionado neste post, uma das palestras que participei num encontro de qualidade promovido pela empresa falou a respeito da definição de pronto. Vou desmistificar um pouco sobre a Definição de Pronto dentro da metodologia ágil.

O que é Definição de pronto?

Equipes ágeis maduras desenvolvem projetos seguindo alto padrão de qualidade. Tal rigor é imposto por meio da DoD – Definition of Done, ou Definição de Pronto. A DoD é uma discussão entre Time de Desenvolvimento (o que inclui o testador/QA) e Product Owner de que toda a entrega atenderá os padrões de qualidade estabelecidos por eles mesmos.

Para que serve o DoD?

É uma forma de se buscar a excelência. A discussão aprofunda a compreensão da equipe dos itens do backlog e os requisitos do produto de cada estória da sprint.

Quando uma estória está pronta?

Vida de Programador - nº1438

Toda mudança é difícil, quando você sai do modelo de desenvolvimento tradicional e vai para o ágil a história não é diferente. Posso dizer que eu vivi o quadrinho do Vida de Programador acima. É difícil de um programador de longa data aceitar que o "pronto" não é mais um status por etapa de desenvolvimento e sim "pronto" de tudo. Ainda percebo que é difícil o programador aceitar que ele precisa se preocupar com tudo também.

É importante frisar que, no ágil, a definição de pronto é decidido pela equipe e ocorre por estória. Então temos que o "pronto" pode ser diferente para cada estória dentro da sprint. ;)

Exemplos de definição de pronto:

- Critérios de aceite da estória atendidos.

      Responsável: Time de Desenvolvimento e Product Owner;

- Testes da estória executados conforme planejamento. Todas as subtasks de testes devem estar finalizadas.

      Responsável: QA (Quality Assurance);

- Todos os defeitos não críticos que não podem ser corrigidos dentro dos limites da sprint adicionados ao backlog do produto e priorizados para a próxima sprint.

      Responsável: todo o time;

- Integração de todas as funcionalidades.

      Responsável: todo o time;

- Todos os requisitos funcionais testados, incluindo os testes positivos e negativos, com o número de testes com base no tamanho, complexidade e riscos.

      Responsável: QA;

- Todos os riscos de qualidade cobertos de acordo com a medida acordada de testes.

      Responsável: QA;

- Documentação escrita, avaliada e aprovada.

      Responsável: Product Owner.

Espero que tenham gostado deste post. Qualquer dúvida, perguntem! :D

Referências: 

Definition of Done. Disponível em: <http://www.mindmaster.com.br/definition-of-done/>.

Apostila da certificação CTFL-AT (já falei sobre ela AQUI): Foundation Level Extension Syllabus Agile Tester. Disponível em: <http://www.bstqb.org.br/uploads/docs/syllabus_ctfl_at_2014br.pdf>.

Evento gratuito de Testes - QA Ninja Conference 2016

Olá meu povo testador!

Hoje começa um evento gratuito de testes de software, chamado QA Ninja Conference 2016. Esse evento terá transmissão ao vivo e gratuita, basta fazer sua inscrição AQUI. Ele ocorre durante essa semana, de 24/10/2016 a 28/10/2016 a partir das 19 hs.

Qual o melhor caminho para testar minha aplicação? 

Como evitar que mudanças causem transtornos e efeitos colaterais no meu software? 

Como técnicas automação de testes podem tornar meu trabalho mais produtivo?

Pensando nisso foi criado um evento, totalmente on-line e gratuito, que vai te ajudar a encontrar respostas para essas perguntas, focado em Qualidade de Software.

http://www.qaninjaconference.com/

Público Alvo: QAs e DEVs com interesse em conhecer e aprender mais sobre Qualidade e Testes de Software.

Seu software testado: Conheça as melhores práticas e ferramentas para realizar variados tipos de testes nos seus projetos.

Testes ágeis: Entendendo tipos de testes sob a perspectiva do desenvolvedor e do usuário final.

Link do evento: http://www.qaninjaconference.com/ Os videos do evento ficarão gravados no Youtube e estão disponíveis nesse link também.

Aproveite! Também comente se você viu o evento e o que achou. :D

Encontro de testadores 2016 - Blumenau/SC

Ontem, eu participei de um evento anual que proporcionou um encontro com todos os profissionais de testes de software da empresa onde trabalho, aqui em Blumenau/SC. Mais ou menos 70 profissionais de testes se reuniram. O foco deste ano foi falar sobre o ágil. Eu já havia comentado, num post aqui no blog, que estamos migrando os projetos do formato cascata para o ágil. 

Este encontro ainda vai render vários posts sobre ágil aqui no blog (meu Trello de ideias está cheio :D ). Então vou dar um gostinho do que vi ontem:

Ágil - O que é? Como funciona? Um pouco da experiência de quem já viveu essa transição e fazer acontecer.
Os 10 mandamentos do QA - A teoria e exemplos reais. Post aqui.

Definição de Pronto, DoD - Quando uma entrega está pronta? Post aqui.

User eXperience - O que é e como um testador ajuda um designer a melhorar a experiência de uso de um software?

Fora o OneMinuteTalk, Fishbowl e o Game interativo que tivemos usando o smartphone.

Aguardem! :D

Lightshot: uma ferramenta de captura de tela sensacional!

Olá Pessoal,

Hoje vou falar para vocês sobre uma ferramenta que utilizo muito durante os meus testes, para coletar evidências. Chama-se Lightshot. Já vi essa ferramenta ser utilizada por desenvolvedores, documentadores e testadores. Eu considero esta a melhor ferramenta de captura de tela existente, e já explico o porquê! 

O Lightshot vai além de uma simples captura de imagem. Este aplicativo de 2,2Mb possui várias ferramentas de edição das capturas, além de ferramentas de compartilhamento nas principais redes sociais. Está disponível para os S.O.'s Windows, Mac, Ubuntu e add-on no Chrome. Veja só algumas das ferramentas disponíveis no LightShot:

No meu PC, só preciso apertar a tecla "prt sc" (tecla de print screen do teclado) para a ferramenta ser ativada.

O Lightshot possui uma interface amigável é super fácil de usar. Ele gera imagens no formato .PNG somente, mas não acho isso ruim. Com um "Esc" eu cancelo a edição da área que selecionei.

Simples, fácil, funcional e prático!

Aplicativo: LightShot 

Developer: Skillbrains

Device testado: PC Windows 10 x64

Rating Baixaki: 5 (28 avaliações)

Downloads: 139.475

Categoria: Diversos

Tamanho: 2,2 Mb

S.O. suportado: Windows, Mac, Linux Ubuntu e Add-on no Chrome

Preço: Gratuito

Funcionalidades Extras: Não possui

Clique AQUI para acessar o site do desenvolvedor e escolher em qual plataforma instalar.

Avaliação BitLady:

Super recomendo!

Ao longo das próximas semanas irei postar reviews sobre mais algumas ferramentas simples que me auxiliam nos testes.

Espero que tenham gostado do LightShot. Até mais, :D

Minha opinião sobre a prova de certificação da CTFL-AT

Olá Pessoal,

Mês passado fui aprovada na prova de certificação CTFL-AT (Certified Tester Foundation Level - Agile Tester), do BSTQB/ISTQB. Hoje eu vou lhes contar aqui um pouco sobre a certificação e preparação para a prova da CTFL-AT.

O que é a CTFL-AT?

É uma certificação com validade internacional em testes de software, feita para testadores que trabalham com ágil. Ela ainda é nova: foi criada em 2014. Então, se você trabalha/quer trabalhar com testes de software em locais que trabalham com alguma metodologia ágil, esta é uma ótima opção.

Tem pré-requisitos?

Tem sim. Para fazer esta certificação você precisa primeiro ser certificado CTFL.

Qual era a minha motivação para fazer a prova?

A empresa onde trabalho começou a implantar ágil este ano. Muitos projetos ainda estão em fase inicial de implantação dentro dos projetos (incluindo o que eu trabalho), enquanto alguns poucos já estão com o ágil bem maduro na equipe. Eu queria aprender sobre o ágil. Já tinha lido muito sobre a teoria e como o ágil funciona, mas nada era focado sobre como o ágil é usado para testes de software. Quando eu e meus amigos estávamos estudando pra CTFL, vimos que tinha uma certificação que eu não sabíamos que existia: a CTFL-AT. Decidimos que se passássemos na CTFL, iríamos emendar a certificação do módulo ágil. E foi o que aconteceu. :D

Como eu me preparei para a prova? 

Comecei a me preparar logo depois da inscrição, assim que recebi o resultado de aprovação na prova da CTFL, cerca de 2 meses antes da prova da CTFL-AT. Novamente usei o Trello para me ajudar a organizar os estudos com um checklist. A minha "receitinha" de estudos foi praticamente igual a que usei pra CTFL: 

• Ler a apostila pela 1ª vez, marcando partes importantes;
• Ler a apostila pela 2ª vez, somente partes marcadas;
• Fazer simulados diversos encontrados na internet;
• Fazer simulado oficial, disponibilizado em inglês no site da ISTQB (link AQUI, lembrando que o  Sample Exam é o simulado e o Answer Sheet dá a alternativa correta e a explicação) (não tem simulado oficial no site brasileiro da BSTQB até a presente data);
• Ler a apostila pela 3ª vez, identificando os erros cometidos após o simulado oficial em inglês;

Últimas duas semanas antes da prova: 

• Foco no simulado oficial em inglês;
• Releitura das partes marcadas na apostila.

Como foi a prova?

O estilo da prova é bem parecido com a da CTFL. Foram 40 questões, feitas em 1 hora. Foi assustador num primeiro momento, pois parecia que eu tinha lido a apostila errada (meu amigo também achou isso). Mas eu tinha estudado tanto que não perdi minha confiança.

O tamanho de algumas questões também assustava um pouco, o simulado em inglês do site ajudou a ter uma noção de como seria a prova, e se confirmou na dificuldade. A prova é objetiva. Algumas questões precisam de interpretação de texto. Haviam situações em que todas as respostas estavam certas, mas que você precisava indicar a mais apropriada para determinada situação. Conversando com meu amigo, novamente chegamos à conclusão de que a prova era diferente entre nós.

Vale a pena fazer a prova e tirar a certificação CTFL?

Vale! O material é ótimo e fala bastante sobre como testes se encaixam numa equipe ágil. Esclareceu muitas dúvidas que eu tinha. Além disso, esta é a certificação mais barata da BSTQB: R$ 200,00. Após ter feito a prova (nem sabia do resultado ainda), pude ajudar mais com a implantação do ágil na equipe que trabalha comigo. Só por isso já vi que tinha valido a pena.

Conclusão!

Para você que quer aprender mais sobre testes ágeis, faça a certificação! A prova é difícil, mas você aprende muito.

Até mais! :D

Minha opinião sobre a prova de certificação da CTFL

Olá Pessoal,

Já faz alguns meses atrás que fiz a prova de certificação CTFL (Certified Tester Foundation Level), do BSTQB/ISTQB. Vou lhes contar aqui um pouco sobre a certificação e preparação para a prova.

O que é a CTFL?

É uma certificação com validade internacional em testes de software. Então, se você trabalha/quer trabalhar com testes de software e está pensando em partir para fora do país, essa certificação vale no mundo! Na minha opinião, a CTFL é melhor se comparada a CBTS (Certificação Brasileira de Testes de Software), que conto mais AQUI. :D

Tem pré-requisitos?
Não tem. Qualquer pessoa que quiser conhecer mais sobre práticas de testes pode fazer esta certificação.

Qual era a minha motivação para fazer a prova?

Apesar da minha experiência, eu queria mais! Queria conhecer a teoria por tras de todas as práticas e tipos de testes que eu já conhecia. Eu e mais dois amigos conversamos e decidimos fazer a prova juntos, na mesma data. Assim, um incentivaria o outro a estudar.

Como eu me preparei para a prova?

Comecei a me preparar logo depois da inscrição, cerca de 2 meses antes da prova. Usei o Trello para me ajudar a organizar os estudos com um checklist. Segue a minha "receitinha" de estudos:

• Ler a apostila pela 1ª vez, marcando partes importantes;
• Ler a apostila pela 2ª vez, somente partes marcadas;
• Fazer simulados diversos encontrados na internet;
• Fazer simulado oficial, disponibilizado no site da BSTQB;
• Ler a apostila pela 3ª vez, identificando os erros cometidos após o simulado oficial;

Últimas duas semanas antes da prova:

• Foco no simulado oficial;
• Releitura das partes marcadas na apostila.

Como foi a prova?

Foram 40 questões, feitas em 1 hora. O tamanho de algumas questões assustava um pouco, mas quem estudar bastante o simulado oficial tira a prova de letra, pois é bem parecida. Toda a prova é objetiva. Algumas questões precisam de interpretação de texto. Haviam situações em que todas as respostas estavam certas, mas que você precisava indicar a mais apropriada para determinada situação. Conversando com meus colegas chegamos à conclusão de que a prova era diferente entre nós, com algumas questões semelhantes e outras diferentes.

Vale a pena fazer a prova e tirar a certificação CTFL?

Vale! Aumentou, consideravelmente, a visualização ao meu perfil no LinkedIn. Algumas empresas entraram em contato após atualizar meu perfil com essa certificação, o que também pode ser pura coincidência. Além disso, o valor não é absurdo: R$ 350,00.

Vale cada centavo, pois aprendi muito e o retorno também foi bacana! Me considero uma profissional melhor a nível de conhecimento e práticas após esta certificação.

Conclusão!

Para você que quer aprender mais sobre testes de software e dar um "up" na carreira, faça a certificação! A prova não é difícil, te abre muitas portas e você aprende muito. Ela também é pré-requisito para outras certificações internacionais de testes, também disponíveis no BSTQB/ISTQB.

Até mais! :D

Certificações de Teste de Software: diferenças entre CTFL e CBTS

Olá Pessoal,

Vou falar um pouco sobre as certificações CTFL e CBTS. Ambas são bem populares aqui no Brasil, mas muitos não sabem as principais diferenças entre elas. Vou listar as principais diferenças a seguir:

Imagem da autora, dados atualizados de 11/10/2016

No meu local de trabalho atual, quando entrei a 3 anos atras era modinha fazer a CBTS por ser difícil. Pessoalmente eu não acho ela uma boa opção. Quando vi que a CBTS valia somente no território nacional e que ela tinha validade somente de 3 anos, desisti na hora. Mesmo assim comprei o livro, pois conhecimento nunca é demais. Esse livro "Base de Conhecimento em Testes de Software" tem uma didática ruim e massante. Foi escrito por 5 autores e mais parece um trabalho de ensino médio, onde cada um fez sua parte e depois juntaram para fazer o livro. Pra mim, serve somente de consulta teórica de tipos de testes e documentos de testes de forma aprofundada.

Acontece bastante da pessoa ter a certificação CBTS vencida. Aí não vale né?! :S

Eu achei a certificação CTFL a mais vantajosa. O material é simples e direto, além de bem escrito. Quando fiz um comparativo entre a CTFL e CBTS, a CTFL foi minha escolhida. Eu falo mais sobre a certificação CTFL e a minha preparação para a prova neste post AQUI.

Minha recomendação é: não faça certificação alguma para ter mais um título. Pesquise sobre elas e tire suas próprias conclusões. ;)

Espero ter dado uma "luz" para os indecisos. Até mais! :D

Referências:

CBTS - Certificação Brasileira de Teste de Software. Disponível em <http://www.alats.org.br/portal/info-sobre-cbts.html>. Acesso em 11/10/2016. 

Sobre a Certificação Foundation. Disponível em <http://www.bstqb.org.br/?q=node/28>. Acesso em 11/10/2016. 

Problemas que uma equipe de testes pode enfrentar no início da implantação da metodologia ágil - Scrum

No Scrum, todos da equipe são responsáveis por uma Sprint. Será? O que acontece quando a equipe de testes é chutada para fora da equipe? O que acontece se a equipe de desenvolvimento achar que testes não é necessário dentro da Sprint "deles", considerando-os como uma "Sprint paralela" ao desenvolvimento? Eu vivi isso e vou te contar neste post.

Toda mudança possui vários altos e baixos, e passamos por basicamente 4 estágios:

- 1º você rejeita

- 2º você tenta um boicote à mudança

- 3º você aceita

- 4º você coopera com a mudança

Quando começou a implantação da metodologia ágil, no meu local de trabalho, não foi diferente. Mas eu, como parte da equipe de teste, via algumas interpretações corretas e outras absurdas da metodologia. Contextualizando a ordem dos fatos:

• A empresa sentiu necessidades de mudança, pois viu que outras empresas levam metade do tempo para fazer grandes entregas (possivelmente com um grande incentivo do novo diretor de desenvolvimento);
• Começou um projeto piloto para implantação da metodologia;
• Adquiriram ferramentas específicas para auxiliar no gerenciamento de Sprints;
• Liberaram um documento com a política de funcionamento do processo ágil na empresa (mais parecia um cópia e cola de um site cheio de erros de português e loops no processo);
• Começou uma onda de mudanças, onde algumas equipes foram avisadas que a partir de X data poderiam migrar seus projetos para a ferramenta e trabalhar com o processo em ágil.

Se vocês ficarem bem atentos, verão várias inconsistências:

• A empresa acreditou que as pessoas chaves do projeto sabiam como funciona a metodologia ágil e um simples documento seria o bastante para aplicar ágil nos projetos;
• Migrar projetos do modo cascata pro ágil? Sem coordenação ou acompanhamento de um gerente de projetos?
• Fizeram do trabalho de faculdade de alguém um documentos de processo de funcionamento ágil? É isso mesmo?

Enfim, o problema estava claro pra toda a equipe de testes que teve de se adaptar. A adaptação não é um problema! A equipe de testes geralmente é bastante flexível, pois estamos acostumados com mudanças no processo de trabalho e mudanças de projetos de trabalho. O problema é que nem todos os analistas de testes/testadores dos produtos sabiam como se impor e alguns projetos viraram um caos.

No modo tradicional de desenvolvimento, o cascata, as equipes eram acostumadas a iniciar testes só depois que a implementação está pronta. Na metodologia ágil isso deixa de existir. A equipe de testes está testando partes antes de estarem concluídas, está dando ideias de situações que os programadores devem prever durante a implementação, pois a equipe de testes conhece o negócio e antecipa a ação que o cliente usará.

Eu vi uma equipe criar Sprints sem atividade de testes. Os testadores estavam num tipo de "sprint paralela" e atrasada do projeto. Você não leu errado, o sentimento era de total descaso com testes! Assim que a equipe de desenvolvimento acabava toda a implementação envolvida de uma Story, a mesma era encerrada. A Sprint acabava e uma nova Sprint era planejada! E testes? Os testadores precisavam buscar no "limbo do projeto" as Storys encerradas para então fazer um teste integrado. Não recebiam nenhum alerta de encerramento da Story e um controle paralelo era necessário. O desenvolvimento levando os créditos de que a Sprint foi um sucesso, encerrada no tempo planejado. SEM TESTES é só um detalhe? Ao meu ver, a Sprint só é um sucesso quando a equipe de testes dá seu aval de "Testes OK".

Isso parece um belo boicote à mudança. Jeff Sutherland, do livro "Scrum - a arte de fazer o dobro de trabalho em metade do tempo", disse que todos na equipe deveriam ser responsáveis pelas Sprints. Eu via que isso não estava acontecendo naquela equipe. O desenvolvimento não sentia que testes deveriam fazer parte da equipe. Para piorar, a pessoa que deveria apoiar e coordenar os trabalhos em testes ouviu todo esse problema e ficou por isso mesmo.

Recebi um retorno da não conformidade que abri, dizendo que era uma situação grave e deveria ser combatida. Quando a bagunça da equipe em questão acabar eu apresento a solução aqui no blog. Vale lembrar que esta é a única equipe que vi deixar testes de lado enquanto usavam metodologia ágil (não, eles não tem testes unitários para garantir coisa alguma). Mais alguém está achando que a metodologia usada por essa equipe mais parece GO HORSE?

Resumo da história: O pessoal de testes precisa se impor. Precisam mostrar que testes é importante sim dentro da Sprint e brigar por isso. O modo tradicional de testes, de testar somente quando a entrega já está pronta, não funciona na metodologia ágil. Testes unitários não garantem integração de produtos. Os testes de integração DEVEM entrar na Sprint! Cadê a responsabilidade da equipe toda em fazer uma entrega rápida e sem impactos para clientes?