Simulados Online da CTFL

O Fábio Martinho divulgou na lista do Quality Assurance vários simulados da CTFL. Segue abaixo, os links:

Os simulados estão em inglês e o resultado é apresentado, após você completar ele. Uma boa para quem está se preparando para a CTFL do ISTQB/BSTQB.

Fique por dentro das novidades, assine o feed do QualidadeBR.

Anúncios

Cobertura CInTeQ 2010 – Dia 1 (parte 1)

Nesta segunda-feira teve início o CInTeQ (Congresso Internacional em Testes e Qualidade de Software), um dos principais eventos de Teste e Qualidade de Software, patrocinado nesta edição por Microsoft, RSI, Iterasys, IBM, Governo do Brasil e Caixa Econômica Federal e com o apoio do BSTQB.

A seguir, relato como foram  as primeiras palestras do primeiro dia do evento.

Abertura do evento – Osmar Higashi – Atuação do BSTQB e Panorama Atual dos Testes no Brasil

O paguá que vos escreve chegou atrasado… chegando só no fim da palestra de abertura do evento, que foi ministrada pelo diretor executivo da RSI Informática e BSTQB (Brazilian Software Testing Qualifications Board), Osmar Higashi.

O palestrante falou sobre a atuação do BSTQB no Brasil, as certificações avançadas, números de certificados e uma notícia bem importante: a aplicação da prova avançada para a área de gerência de testes (CTAL-TM: Advanced Level Test Manager) aqui no Brasil, que ocorrerá ainda nesse ano (atualização[24/03]: o César Chaves disse nos comentários que já houve a primeira prova CTAL-TM: Advanced Level Test Manager no Brasil, ela ocorreu em fevereiro/2010).

Além disso, o palestrante disse que os Syllabus das outras certificações avançadas já estão sendo traduzidos (alguns já estão até completamente traduzidos) e que o BSTQB está trabalhando para aplicar os outros exames avançados no Brasil.

Resumindo, parece que o BSTQB está querendo atuar mais fortemente no Brasil, prova disso é a própria realização do CInTeQ, o que é muito bom para o nosso mercado e para os profissionais.

Eduardo Habib – Teste de Segurança em Aplicações Web

O Eduardo é Gerente de Testes no SYNERGIA e mestre em Ciência da Computação pela UFMG. Sua apresentação foi sobre uma tema ainda não muito comentado na comunidade de Teste de Software Brasileira, testes de segurança.

A palestra do Eduardo teve como foco apresentar as falhas de segurança mais comuns em aplicações Web, alguns exemplos de como testá-las e ferramentas open source que auxiliam nesse tipo de teste.

O palestrante começou falando que antigamente a segurança não era uma preocupação no desenvolvimento de aplicações Web, pois o conteúdo era todo estático e não haviam informações confidenciais nos sites.

Porém, hoje em dia os sites possuem informações confidenciais de seus usuários, desde login e senha até o saldo da conta corrente. Portanto, a segurança passou a ser uma característica fundamental em vários sites, e são precisos testes para averiguar se a aplicação é realmente segura.

Algumas informações importantes passadas pelo Eduardo durante a palestra:

  • Muitas pessoas não se importam com a segurança de determinada aplicação, porém esquecem que essa aplicação pode ser a porta de entrada para as aplicações que ele se preocupa;
  • O uso de SSL – Secure Sockets Layer não impossibilita ataques, e  os ataques que mais ocorrem não são evitados com SSL. Porém, isso não que dizer que você não deva utilizar SSL, pois caso você faça isso, você abrirá outras “brechas” para os crackers;
  • Há um aumento considerável no número de incidentes relacionados a segurança (figura abaixo), e esses números não estão dando sinais que vão diminuir. Por isso cada vez mais se faz necessário realizar testes de segurança;
  • Houve um aumento de incidentes de 61% de 2008 para 2009;
  • De 1999 até 2009 o aumento de incidentes foi de 11530%;
  • 75% dos sites de bancos possuem falha grave, segundo a Universidade de Michigan (pesquisa não contemplava bancos brasileiros);
  • 64% de 1364 sites corporativos possuem falhas graves de segurança, segundo o WhiteHat Security.

Total de Incidentes Reportados ao CERT.br por Ano (Fonte CERT.br)

A origens principais desses incidentes são devido aos seguintes problemas:

  • O usuário pode enviar QUALQUER dado;
  • É necessário assumir que toda entrada pode ser maliciosa;
  • Requisições podem ser feitas em qualquer sequência;
  • Usuários não irão usar apenas um navegador para acessar a aplicação;
  • Muitas aplicações não fazem verificação a cada requisição, ou seja, após o usuário estar logado, as requisições não são mais autenticadas.

O Eduardo ainda falou sobre as falhas que mais ocorrem, sendo elas:

  • Falhas de injeção (ex. SQL injection);
  • Cross Site Scripting (XSS);
  • Falhas de autenticação e de gerenciamento de sessão;
  • Referência insegura a objetos;
  • Problemas de configuração;
  • Falha ao restringir o acesso a alguma URL;
  • Redirecionamento inválido;
  • Problemas no armazenamento de informações confidenciais;
  • Proteção na camada de transporte insuficiente;
    • Sem criptografia;
    • Certificados inválidos.

Mas então como podemos testar a segurança de uma aplicação Web?

Segundo o Eduardo a primeira coisa a ser feita quando for testar um software é pensar como que um cracker irá obter a informação, e para isso é preciso fazer um bom mapeamento, cuja melhor forma é a automática. Existem ferramentas open source que fazem esse mapeamento, e essas são chamadas de web spider.

Um ponto bem interessante da palestra foi a apresentação da ferramenta WebGoat, que já possui várias falhas de segurança e foi criada, justamente para ensinar as pessoas a como encontrar essas falhas e como funcionam as técnicas utilizadas pelos crackers, ou seja, é uma ferramenta obrigatória para quem quer começar a fazer testes de segurança.

O palestrante também mostrou uma lista de addons do Firefox e ferramentas que podem auxiliar durante os testes de segurança:

Por fim, o Eduardo concluiu que:

  • Todo sistema/aplicação é passível de invasão;
  • Os usuários são potenciais invasores;
  • É necessário otimização e cautela durante a programação,
  • A análise de riscos pode ajudar no início da elaboração dos testes de segurança, fazendo você focar nas áreas chaves;
  • Novas tecnologia irão criar novas “brechas”;
  • Não há ferramentas open source tão boas, quanto as pagas.

Impressões da palestra

Eu achei a palestra do Eduardo bem interessante, talvez por não conhecer muito bem a área de Segurança de Informação e por nunca ainda ter feito testes de segurança.

O Eduardo atingiu com sucesso a proposta da palestra. Sem dúvidas quem participou da palestra saiu dela com uma visão muito melhor e já sabe por onde começar a fazes os testes de segurança, que cada vez são mais necessários e que cujas falhas costumam gerar um prejuízo muito grande para as organizações.

Rex Black – Dealing with the Testing Challenges of Agile Methodologies

A expectativa para essa palestra era muito alta, afinal o palestrante era nada mais nada menos, do que a lenda, o mito, o “monstro”, o “dinossauro”, o “megaboga”, o gigante … Rex Black, presidente da RBCS e autor de excelentes artigos e livros, que fazem juz aos adjetivos colocados, e o tema da sua apresentação “Lidando com os Desafios do Teste para as Metodologias Ágeis”, o mais interessante da agenda dos dois dias de evento, pelo menos para mim, que estou lidando com esses desafios ultimamente.

Bem, agora vamos ao que interessa, a palestra.

O Rex Black (RB) iniciou a sua apresentação dizendo que os desafios que serão comentados são inerentes a forma ágil de desenvolvimento de software, e basicamente esses desafios possuem duas origens:

  • Do próprio agile;
  • Interpretações das pessoas.

Após esse breve e importante esclarecimento, o RB perguntou para a platéia quem utiliza metodologias ágeis, e um bom número de profissionais levantaram a mão. E isso mostra como é verdadeira a afirmação feita na sequência, de que ciclos de vida ágeis estão se tornando comum.

Alguns pontos importantes levantados pelo Rex foi:

  • Todas metodologias afetam o teste de software (isso parece até óbvio, mas muitas pessoas não percebem isso ou percebem da pior maneira);
  • No contexto ágil é necessário saber quais estratégias de teste funcionam bem. O RB citou três que funcionam bem:
    • Teste baseado em riscos (na minha opinião, teste baseado em riscos sempre funciona bem! [quando bem aplicado é claro]);
    • Automação de teste, incluindo teste de regressão funcional;
    • Teste reativo, cujos principais representantes são os famosos testes exploratórios.

E mesmo utilizando essas estratégias, elas não irão aliviar todos os desafios de teste com projetos ágeis. Por isso é muito importante entender os desafios, identificar os caminhos e saber como lidar com eles.

Volume e velocidade da mudança

No mundo ágil mudanças ocorrem toda hora, e elas não são encaradas como problemas e sim como oportunidades, por isso deve-se dar as boas-vindas a elas.

Bonito isso!  Mas como nós, profissionais de teste, podemos lidar com essas mudanças, uma vez que geralmente, elas costumam gerar grande retrabalho para nós:

  • Utilizando testes baseado em riscos, pois eles podem acomodar as mudanças;
  • Testes automatizados também ajudam a acomodar as mudanças: testes unitários e até de GUI (mesmo o último sendo mais “quebrável”);
  • O testadores devem ser manter atualizados para evitar ter falsos positivos.

Nos projetos agéis o tempo é muito curto

Em projetos agéis você não terá muito tempo para manter os testes, o tempo é muito limitado. Então ao automatizar você precisa saber que testes no banco de dados, são mais estáveis que testes na GUI. Além disso, o teste baseado em risco vai mais uma vez te ajudar, pois irá fazer você ser mais focado no que é mais importante. Lembre-se, no mundo ágil é preciso ter foco!

Testes unitários inadequados e inconsistentes

Uma das coisas em agile que o Rex Black mais gosta são os testes unitários, mas como o Fred Brooks disse “não existe a bala de prata” (isso em 1987, eu nem era nascido rs).

Mas antes de comentar sobre testes unitários o RB fez uma interessante analogia para explicar dois tipos de complexidades:

  • Complexidade acidental: tentar colocar o sapato do pé direito no pé esquerdo;
  • Complexidade essencial: você está no avião retira os seus sapatos para ficar mais à vontade, depois quando o voo já está chegando no seu destino, você vai colocar os sapatos, mas tem dificuldade, pois os pés estão inchados.

Ou seja, há uma complexidade causada por nós mesmos e outra causada por uma série de fatores do nosso contexto.

E assim sendo, os testes unitários precisam ser consistentes com a nossa aplicação, que por sua vez precisa ser adequada para que seja possível realizar testes unitários (ex.: problemas de testabilidade).

Mas testes unitários possuem dois problemas:

  • Eles têm um limite de “alcance” de bugs, de 25% a 30%, enquanto bons testes de sistemas tem média de 85%;
  • Nem todos os programadores fazem testes unitários.

O Rex Black frisou que os testes de unidade precisam acontecer, mas você precisa de ciência das suas limitações, pois não vamos fingir que agora tendo testes unitários não será preciso fazer mais outros testes.

Alguns outros pontos interessantes levantados pelo RB:

  • “Em agile não é preciso escrever nenhuma documentação”, essa é uma interpretação errada do manifesto;
  • Relatórios inválidos de bugs (com falso positivos) são um desperdiço de tempo, por isso é necessário os testadores estarem em constante interação com os desenvolvedores;
  • Todas equipes precisam encontrar o equilíbrio entre documentação e reuniões;
  • É preciso tomar cuidado para não espremer os testes, por exemplo: o projeto tem sprint de quatro semanas, e sempre há novos commits, os testes acabam sendo espremidos na última semana de todo sprint, ou seja, acabamos fazendo “cascatinhas”;
  • Os clientes da RBCS adotam agile utilizando equipes independentes de teste;
  • Não é necessário equipes totalmente independentes do time e nem totalmente dentro dos sprints, e sim um meio termo;
  • Sprint para o teste e outro para desenvolvimento não funciona;
  • Em agile tudo que você faz é um conjunto de coisas que você não faz (profunda essa frase rsrs);

O que aconteceu com a nossa base!?

Uma das respostas clássicas quando se pergunta qual é o objetivo do Teste de Software, é dizer que é garantir que a aplicação tenha sido implementada de acordo com os requisitos. E assim, os requisitos acabam sendo a principal fonte de informação e torna-se a base para os nossos testes.

Mas segundo o Rex Black, isso é um problema no contexto ágil, pois os requisitos podem mudar e então, os testes baseados em requisitos podem ser não efetivos, afinal estaremos atirando em alvos que estão sempre em movimento.

Ou seja, basear os seus testes em requisitos é muito difícil, quase impossível a longo prazo, caso você siga só essa estratégia.

O Rex Black ainda falou sobre as vantagens e desvantagens do testador atuar dentro da sprint:

  • Vantagens:
    • Foca nas tarefas relacionadas com aquela sprint;
    • Aloca e realoca o tempo baseado nos objetivos da sprint.
  • Desvantagens:
    • Perde a liberdade, ele passa a ser “liderado” pelo Scrum Master e não pelo Gerente Teste;
    • Tem uma visão reduzida do sistema.

Foi comentado durante a apresentação que há expectativas muito altas para o agile, principalmente por parte da gerência, e isso é um grande risco na implantação de agile, pois agile vai trazer benefícios no longo prazo e haverão muitos desafios.

Na conclusão da sua palestra o Rex Black fez as seguintes considerações:

  • É preciso ser muito cuidadoso na escolha das estratégias de testes;
  • É necessário manter os testes automatizados e realizar os teste de regressão baseados em riscos;
  • Testes reativos permitem os testadores explorar áreas que os testes baseados em risco e os automatizados não cobriram;
  • Tente ficar a frente dos desafios, espere por eles, seja pró-ativo ao lidar com os desafios, além disso seja realista perante a essa nova metodologia e o tempo que levará para ser tornar ágil, isso se você se tornar ágil;
  • Sempre teremos trabalho a fazer, nada virá pronto.

Ainda houve perguntas bem legais para o Rex Black, que abordaram a resistência de analisar os riscos, teste de performance durante as sprints e tempo da implantação do agile, gerando as seguintes respostas:

  • A Engenharia de Software é uma das principais atividades do ser humano. Se as pontes, prédios, escritórios quebrassem tanto quanto software seria inaceitável. Desta forma o primeiro passo para analisar os riscos é reconhecer a existência deles;
  • Problemas de desempenho geralmente são de design, e tem custos caros, portanto não espere até o fim, dessa forma, faça uma boa análise estática e teste em nível de unidade. E durante a sprint o software tem que  continuar funcionando (integração contínua);
  • Nem todo mundo precisa ser ágil e algumas pessoas levam mais tempo, isso até mesmo dentro de uma mesma organização. A implantação precisa ser democrática.

Impressões da palestra

A palestra do Rex Black foi excelente! Conseguiu falar com propriedade sobre uma temática recente, isso graças as experiências e vasto conhecimento em Teste de Software que ele possui. Um único ponto negativo, foi o excesso de texto nos slides (aliás, pelo que eu me lembre, quase todos os palestrantes colocaram muito texto nos slides).

No mais, foi muito interessante ouvir a experiência e opiniões do Rex Black sobre testes ágeis, realmente são uma série de desafios que enfrentamos quando iniciamos a implantação de práticas ágeis, e é muito difícil você encontrar literatura ou pessoas que falam sobre o assunto.

A conclusão que tirei da palestra foi que o Teste de Software pode sim ser ágil, e ele precisa ser ágil, logicamente que não é fácil, mas utilizando estratégias adequadas e pessoas preparadas podemos enfrentar de forma mais efetiva os desafios. E por fim, a realização de testes baseados em risco é fundamental, pois o tempo é bem curto, e não é possível fazer todos os testes, por isso precisamos estar sempre priorizando quais testes precisam ser feitos e os que não precisam, em suma: é preciso ter foco!

Bem pessoal, aqui encerro a primeira parte da cobertura do primeiro dia do CInTeQ 2010, até a segunda parte! 😀

Cobertura CInTeQ 2010 – Dia 1 (parte 2)

Fique por dentro das novidades, assine o feed do QualidadeBR.

Encontro Internacional do ISTQB no Brasil em 2010

Muito boa a iniciativa do BSTQB,  o representante oficial do ISTQB no Brasil, de aproveitar a realização do encontro do Conselho do ISTQB, que ocorrerá no próximo ano no Rio de Janeiro, para também realizar um evento aberto em São Paulo, com duração de dois dias e voltado a área testes, contando com a participação ativa do Conselho brasileiro BSTQB.

Segue abaixo, maiores informações retiradas do site do BSTQB:

Em março de 2010 o Brasil sediará o encontro do Conselho do ISTQB (International Software Qualifications Board). Esse encontro contará com a presença dos Conselhos nacionais de cada país, onde o ISTQB é representado. Estarão presentes diversos nomes de destaque da área de testes de software, colocando o Brasil em foco. Será na cidade do Rio de Janeiro, no dia 19 de março. Essa é a primeira oportunidade do Brasil em sediar esse evento internacional, tendo disputado essa oportunidade com outros países.

Em conjunto com a reunião do ISTQB, teremos um evento aberto em São Paulo, com duração de dois dias e será voltado a área testes, contando com a participação ativa do Conselho brasileiro BSTQB. Esse evento terá a junção do público nacional e internacional, trazendo discussões atuais e relevantes sobre o tema ao nosso mercado. Diversos participantes do encontro do ISTQB estarão presentes nesse congresso, trazendo uma oportunidade única para o mercado brasileiro. Dados sobre esse evento serão divulgados pelo BSTQB.

O ISTQB é um Conselho internacional formado em 2002 e composto por representantes de mais de 40 países, os denominados conselhos membros. O número de Conselhos membros tem crescido a cada ano, demonstrando a importância e a abrangência do Conselho internacional. Esse Conselho é dedicado à disciplina de testes de software, e promove o profissionalismo na área através de um programa de certificações profissionais. O BSTQB é o Conselho membro brasileiro, formado em 2006 e com crescente aderência dos profissionais à suas atividades. Atualmente são mais de 120.000 certificados ISTQB no mundo, e mais de 500 certificados no Brasil, sendo a maior certificadora em testes de software no Brasil e no mundo. O ISTQB e seus Conselhos membros são entidades sem fins lucrativos. Essa estrutura traz transparência para suas ações, justificando seu sucesso e reconhecimento no mercado.

Três vezes ao ano, o ISTQB reúne seus membros dos Conselhos em uma reunião, o General Assembly Meeting, com diversas metas:

– Divulgação do status do programa de certificação;
– Tomada de decisões em relação a atividades do Conselho;
– Realização de votações relativas ao Conselho diretor; corpo de conhecimento, grupos de trabalhos, entre outros,
– Discussão e votação em relação à entrada de novos Conselhos membros.

Essa reunião tem uma grande importância para o encaminhamento das atividades do Conselho internacional. Também é de grande importância para o país que a sedia, visto que muitos nomes de destaque da área comparecem, contribuem com a comunidade, além de ser uma oportunidade de negócios e contatos.

Fique por dentro das novidades, assine o feed do QualidadeBR.

P.S.: Agora é aguardar, maiores detalhes sobre o evento. 😀

Simulados CTFL-BSTQB

Algo que ajuda muito, na preparação para certificações é a realização de simulados. E como disse aqui, montei um grupo de estudo na empresa que trabalho, para a certificação CTFL-BSTQB.

No começo dos estudos, todos me perguntavam se eu tinha algum simulado, e eu só tinha os do grupo do BSTQB, até o momento que entrei em contato com o Luiz Gustavo, que já obteve a certificação, e me passou uma porrada de simulados (aliás, muito obrigado!). Porém, eles estavam em inglês e como nem todos têm facilidade com o idioma e a prova aplicada pela BSTQB é em português, resolvi traduzir esses simulados.

Bem, chega de conversa, e vamos ao que interessa, os simulados. Segue abaixo, o link para download dos simulados traduzidos e dos originais em inglês:

http://bit.ly/simulados-ctfl

http://bit.ly/simulados-originais

São 6 simulados traduzidos, três com 20 questões e outros três com 40 questões, que é a quantidade de questões da prova oficial. Ou seja, no total são 180  questões.

Já os simulados originais (em inglês) têm 27 questões a mais, por ter algumas repetidas e outras um pouco “estranhas”, que preferi não traduzir.

Caso alguém encontre algum erro nos simulados, por favor reporte para meu e-mail (ffc.fabricio@gmail.com.br). E se tiverem alguma dúvida, sugestão ou crítica, sintam-se à vontade em comentar.

Espero que os simulados ajudem nos estudos e na futura obtenção da certificação.

Bons estudos a todos!

Fique por dentro das novidades, assine o feed do QualidadeBR.

Assine o feed

CTFL – BSTQB

Nessa semana, comecei um grupo de estudo na empresa que trabalho (Voice Technology), para a certificação CTFL – Certified Tester Foundation Level. Estamos planejando realizar o exame, já na próxima data, que é dia 03 de abril de 2009. Mas o intuito inicial é adquirir maior conhecimento na área de Testes de Software, e aqueles que se sentirem confiantes para realizar a prova, aí sim, prestar o exame.

Para o primeiro encontro do grupo de estudo, preparei uma apresentação, que está sendo disponibilizada abaixo, sobre a certificação CTFL – BSTQB. A diante, explicarei um pouco mais sobre a certificação.

BSTQB

O BSTQB Brazilian Software Testing Qualifications Board é um representante oficial do ISTQB – International Software Testing Qualifications Board, no Brasil. Ele é um o responsável pela aplicação do exame para a certificação CTFL. A sua missão é: “promover o profissionalismo na área e o reconhecimento da disciplina teste e qualidade de software como uma essência de conhecimento e uma especialização profissional no Brasil”. O BSTQB é  uma entidade sem fins lucrativos

CTFL

É uma das certificações de Teste de Software mais reconhecidas, tanto no Brasil como no mundo. Atualmente já são cerca de 32.000 profissionais certificados no mundo.

Ela é voltada para qualquer pessoa envolvida em teste de software. Isto inclui pessoas em funções específicas de teste como: testadores, analistas, engenheiros, consultores, gerentes, usuários que realizam teste de aceite e  desenvolvedores de software.

Os objetivos da CTFL – BSTQB são esses:

  • Estar apto a comparar a prática do teste entre os diferentes países.
  • Capacitar os testadores a trocar conhecimento mais facilmente entre as comissões.
  • Permitir com que projetos multinacionais/internacionais tenham uma compreensão comum do empreendimento do teste.
  • Aumentar o número de testadores qualificados  ao redor do mundo.
  • Ter mais impacto como uma iniciativa baseada internacionalmente do que qualquer abordagem de um país específico.
  • Desenvolver um corpo comum internacional de compreensão e conhecimento sobre teste e terminologias através do syllabus e aumentar o nível de conhecimento sobre teste para todos os participantes.
  • Promover o teste como uma profissão em mais países.
  • Capacitar testadores a obter qualificação reconhecida na sua linguagem nativa.
  • Permitir o compartilhamento de conhecimentos e recursos entre os países.
  • Prover o reconhecimento internacional de testadores e desta qualificação junto a participação de muitos países.

A CTFL não expira e é válida internacionalmente.

Requisitos

O único requisito existente é o interesse do candidato, em se qualificar e buscar o aperfeiçoamento profissional na área de Teste de Software. Sendo recomendável experiência profissional na área.

Como se preparar?

A bibliografia recomendada é:

As pessoas que já prestaram o exame, que eu conheço, dizem que estudando bem o Syllabus e fazendo os simulados, é possível ser aprovado no exame, caso você já tenha experiência na área de Teste de Software.

Como fazer a inscrição para o exame?

A inscrição é feita no próprio site da BSTQB. Sendo necessário preencher um cadastro e efetuar o pagamento de R$350,00.

O exame

O exame é composto de 40 questões, com quatro alternativas cada, sendo apenas uma a certa e com duração de 1 hora.

Conversando com o Luiz Gustavo, que é certificado CTFL, ele me disse que a prova é composta por:

  • 20 questões de nível muito fácil – abordando definições simples de conceitos, não exige pensar, só decorar;
  • 15 questões de nível médio/difícil – abordando definições mais complexas de conceitos, as quais muito provavelmente, o candidato vai ficar entre 2 opções;
  • 5 questões de nível muito difícil – não abordando definições, e sim, problemas que exigem pensar muito, tem pegadinhas e geralmente conflitam 2 definições, às vezes até definições simples.

Havendo questões práticas, que trazem cenários reais, como por exemplo, o uso da análise de valor de fronteira.

Para obter a certificação é preciso acertar no mínimo 60% das questões, ou seja, 24 questões.

Por hoje é só pessoal. Bons estudos para os que vão prestar a certificação!

Fique por dentro das novidades, assine o feed do QualidadeBR.
Assine o feed

Fonte:

http://bstqb.org.br/