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

Chega de falar como um robô!

Na conferência "Technical Communications UK 2014" da Microsoft, foi abordado sobre o "tom" que é utilizado nas mensagens e no diálogo entre o computador (máquina) e o usuário (humano). Tema bastante interessante quando analisado a evolução que mensagens de erro de 3 anos atrás até agora (2016). Até pouco tempo atrás era comum lermos mensagens totalmente formais ao usar um computador, sistemas corporativos e até mesmo um celular. Qualquer pessoa que tivesse algum conhecimento em informática era tido como o "gênio" da família por conseguir decifrar mensagens técnicas. A utilização crescente de smartphones dos mais diversos públicos e a facilidade de criar aplicações, que batem de frente com grandes corporações, fizeram com que o "tom" das mensagens mudasse e estes textos passassem a falar mais como uma pessoa.

Apesar da conferência ter acontecido a 2 anos, o assunto abordado continua atual e já explico o porquê. Num dado momento da conferência, foi defendida a ideia de que estas mensagens não deveriam falar como uma máquina, e sim como uma pessoa. As mensagens deveriam simular o diálogo entre dois seres humanos mesmo. Chega de falar como máquinas! Isto facilita o entendimento por usuários menos técnicos, faz com que um sistema não pareça tão intimidador para usuários que não estão acostumados.

Alguns exemplos:

A atualização do Windows 10, liberada de forma gratuita em 29/07/2015. A mensagem que exibe na atualização "Estamos preparando as coisas para você" já possui um "tom" de "conversa" diferente do que estamos acostumados (ao menos em produtos da Microsoft).

O Google possui uns exemplos legais disso:

O Gmail usa a frase "Oba! Nenhum spam" se a caixa de spam está vazia.

Ao tentar desinstalar o Google Chrome, ao invés de apenas perguntar se o usuário tem certeza que quer remover o aplicativo, ele costumava dizer "Tem certeza que quer desinstalar? Foi algo que dissemos?". 

Se alguma página não é encontrada no site do Google, a mensagem em inglês da página não encontrada fala "404 (isto é um erro). A URL requisitada não foi encontrada nos nossos servidores. Isso é tudo que sabemos.".

O repositório de código, GitHub, também tem um exemplo bacana pro erro 404:

This is not the web page you are looking for. Find code, projects, and people on GitHub.

Tradução livre: Esta não é a página da web que você está procurando. Encontre código, projetos e pessoas no GitHub.

Print da Autora

E no ambiente corporativo?

Percebo que essas mensagens estão deixando de ser o padrão para usuários enquanto pessoa física, entrando para o meio corporativo. Vejo cada vez mais sistemas corporativos nacionais migrando para mensagens e documentações em "tom" amigável. Finalmente o meio corporativo começa a dar mais atenção à experiência de usuário.

As empresas nacionais de software parecem esquecer que seus clientes possuem usuários de várias gerações: Baby Boomer, X, Y e Z. É necessário escrever mensagens entendíveis por todos os públicos, para a geração Z a experiência de usuário conta muito! 

Vocês não sabem o quanto eu, enquanto testadora, estou feliz com essa mudança de cultura corporativa!

Até mais. :D

Até onde um processo bem definido garante a qualidade de um produto?

Muito se fala em melhoria de processos para desenvolvimento de software. É cada vez mais comum encontrar empresas que possuem um grupo ou setor dedicado à melhoria contínua dos seus processos. Processos estes, baseados nas melhores práticas de metodologias e modelos de mercado, praticados no mundo inteiro.

Enquanto algumas empresas possuem um setor dedicando 100% de tempo para analisar, ajustar, criar e manter processos, outras empresas possuem grupos. Esses grupos de pessoas trabalham nos mais variados setores da empresa e, normalmente, possuem uma quantidade de horas limitada por semana para se dedicar à melhoria dos processos. Tanto os grupos quanto os setores têm por objetivo fazer com que os processos sejam entendidos por todas as pessoas da empresa, sem que ocorra dupla interpretação sobre a forma de trabalhar. 

Para não haver uma interpretação errada do processo, todos os colaboradores da empresa devem ser envolvidos, pois são eles quem utilizam estes processos. Quando isso ocorre, todos se sentem parte importante da organização. Os colaboradores irão:

• Reportar quando existe algo errado num processo existente;
• Reportar quando uma situação não foi contemplada pelo processos;
• Informar que uma situação nova ocorre e não existe um processo para suportar esta nova situação;
• Reportar quando um processo não é mais utilizado;
• Reportar quando um processo definido não é entendido ou possui mais interpretações;
• Reportar quando uma equipe ou pessoa não segue o processo ou segue de forma incompleta.

A garantia da qualidade com um processo bem definido deve estar em todas as áreas, seja na análise, no desenvolvimento, nos testes, na documentação, etc.. Todos saem ganhando, mas em nenhum momento este processo garante a qualidade do produto.

Estamos lidando com pessoas, que são falhas. Além disso, um processo bem definido tende a gerar a burrocracia. No fim, para abrir uma simples tarefa de erro temos todo um processo a ser seguido. O simples se torna complexo. Quanto mais complexo o processo, mais suscetível a erros. Quando erros de processos são pegos, mais o processo é engeçado. Aí vemos uma bola de neve. Como solução, muitas empresas recorrem ao ágil. Claro, o ágil quer eliminar toda a burrocracia gerada até então. Cada item de processo dispensável é eliminado.

Chego a conclusão de que nós mesmos somos os culpados por engeçar o processo, por querer controlar cada pingo no "i" digitado, por desmotivar os colaboradores com processos absurdamente grandes que controlam situações que poderiam ser simples. Quero deixar claro que não sou contra controlar processos, mas todos devemos ter cuidado com o quanto controlar.

Até mais! :)

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.