Sair
Tem certeza que deseja sair?
Sair
Esqueceu sua senha?
Insira seu email
Cancelar
Enviar
Recuperar Senha
Um email com instruções de como recuperar sua senha foi enviado para você.
Fechar
Senha Alterada
Sua senha foi alterada com sucesso! Por favor faça o Log in.
Fechar
Termos de Uso
Baixar arquivo PDF
Termos de Uso
Fechar
O Tomo dos Mil Bugs
Baixar arquivo PDF
Tomo dos Mil Bugs Mestre da Ordem de Bugfixers “Noi agiamo in 'Ombra di Internet, per servire la Luce. Siamo Bugfixers.” Olá, Gamer. Você está em posse do Tomo dos Mil Bugs, um manual passado por milênios entre os maiores e mais poderosos BugFixers da história. Não recomendamos a continuação da leitura deste artefato de imenso poder caso você não esteja preparado para a maior aventura de sua vida. Eu sou o Mestre dos Bugfixers da Gamer Trials, e irei conduzir seu aprendizado na arte secreta de nossa Ordem. Ao término deste, você terá conquistado seu primeiro nível como aprendiz. Boa sorte. 1. Capítulo Um - Entendimentos Gerais do Bugfixing O dever de um Bugfixer é conseguir encontrar as falhas de sistemas e jogos evitando assim grandes catástrofes na sociedade. Se hoje, independente de qual ano você está lendo este Tomo, você está vivo, é por conta do trabalho desempenhado por nossa ordem. Nós, Bugfixers, temos como principal objetivo facilitar a vida dos programadores, designers e gestores de projetos que vão corrigir os erros. Devemos dar direções, indicar o passo a passo de como conseguimos encontrar seus pontos fracos para que eles possam se adaptar e melhorar cada vez mais. Devemos agir de maneira correta, visando otimizar o tempo desses homens e mulheres que se dispõe a nos fornecer jogos, sites e aplicativos melhores. Sim, desde os tempos mais primórdios, temos jogos, sites e aplicativos. Durante o decorrer de suas tarefas, você encontrará bugs e estes serão reportados em nosso S.I.B.M (Sistema de Informação de Bugs Milenar) - neste sistema, eu, Mestre da Ordem dos Bugfixers, irei avaliar seu desempenho. Para cada Bug corretamente apontado e documentado, você poderá ganhar de 1 a 3 pontos. Note que eu, como autoridade máxima em nossa Ordem, terei poderes para vetar seus relatórios caso eles não tenham sido feito de maneira correta ou contenham qualquer tipo de conduta inadequada, ou ilegibilidade por conta de gírias em excesso, palavrões e etc. Somos Bugfixers de honra. Nosso dever é fazer nosso trabalho da melhor forma. Todos os Bugs ou Melhorias serão avaliadas e contabilizadas apenas se forem feitas corretamente, dentro dos padrões deste Tomo Milenar e aprovadas pelo Mestre da Ordem dos Bugfixers. A qualquer momento o Mestre da Ordem dos Bugfixers poderá usar seus poderes para entrar em contato e conseguir mais informações dos Bugs. 2. Capítulo Dois - Preenchimento dos Relatórios Milenares 2.1. Preenchimento do Email O Mestre da Ordem dos Bugfixers usará seu email para poder dar pontos e tirar dúvidas sobre seu Bug. 2.2. Preenchimento do Título A título deverá ser bem detalhado do problema encontrado. 2.3. Preenchimento da Descrição A descrição deverá ser bem detalhada do problema encontrado. 2.4. Preenchimento dos Passos para reprodução Imagine que o programador que irá ler seu relatório é leigo naquilo que faz e explique, minuciosamente, como ele pode reproduzir o erro. Este campo deve ser usado para mostrar como ele o passo a passo. Use marcadores para facilitar o entendimento. Exemplo: Escreva assim: Acessar a home Clicar no botão Cadastro Não preencher nenhum dos campos - Clicar em “Concluir Cadastro” E não assim: “Clica no cadastro e aperta pra concluir cadastro” 2.5. Preenchimento dos Resultados Esperados Descrição do que é esperado após a execução dos passos e uma comparação com o que é atualmente exibido pelo sistema que difere do resultado esperado. 2.6. Preenchimento do Tipo de Ocorrência Associar o tipo da ocorrência encontrada de forma correta e que caracterize realmente o tipo da ocorrência. A seguir são descritos cada tipo de ocorrência: Bug que não deixa usar o sistema: impedem o uso de alguma funcionalidade do software. Não existem saídas ou alternativas para contorná-las. Bug de comportamento inesperado: produzem um comportamento ilógico ou inesperado da aplicação onde o resultado obtido é diferente do esperado. A diferença entre uma falha funcional e uma falha impeditiva é que as falhas funcionais podem ser contornadas. Bug de erro de português – Qualquer ocorrência relacionada ao uso incorreto de algum idioma. Bug de erro de interface / design / layout: são aquelas relacionadas à interface gráfica, à apresentação do software, exceto as falhas de texto. Exemplos: componentes desalinhados,, renderização incorreta de interface, cores inconsistentes com guia de estilos, etc. Melhorias: não são propriamente falhas, mas sim sugestões para o aprimoramento do software. As sugestões são dadas com base na experiência do USUÁRIO e nos padrões de mercado. Problemas de Segurança: são falhas que indicam a possibilidade de acessar o sistema sem fazer uso de autenticação devida, sendo possível acessar funcionalidades, coletar dados, modificar dados, modificar o comportamento da aplicação ou interromper o funcionamento da aplicação. 2.7. Preenchimento do Navegador Selecionar o navegador no qual a ocorrência aconteceu. Fiquem atentos aos tipos de navegadores autorizados para testes em cada projeto. 2.8. Preenchimento do Dispositivo Móvel Selecionar o dispositivo móvel no qual a ocorrência aconteceu. Fiquem atentos aos tipos de dispositivos móveis autorizados para testes em cada projeto. 2.9. Preenchimento dos Anexos Envio os screenshots e fotos para o Imgur, de forma que consigamos usar este arquivo para evidenciar o problema reportado. Vale ressaltar que a inclusão de anexos não elimina a necessidade de preencher os demais campos com o detalhamento esperado. 2.10. Preenchimento das Informações Adicionais Detalhar qualquer outra informação que achar relevante para o entendimento da ocorrência relatada. 3. Capítulo Três - Convenções para Abertura de Ocorrências 3.1. Ocorrências sobre a Indisponibilidade do Software ou Site Caso o site/software esteja totalmente indisponível não será considerado como uma ocorrência. Caso o site/software estiver parcialmente disponível será considerado uma ocorrência por página. 3.2. Ocorrências Relacionadas a Links Problemas com links diferentes de uma mesma funcionalidade serão consideradas ocorrências diferentes. Exemplo: um combo box com uma lista de links e todos os links falham. Links para sites externos (fora do escopo do projeto) que apresentarem problemas serão classificados com o tipo funcional. Problemas com o mesmo link mesmo que originados de componentes diferentes no mesmo software serão classificados com o tipo funcional. 3.3. Ocorrências Relacionadas ao Texto Cada erro ortográfico será considerado independentemente. Exemplo: um parágrafo com quatro erros ortográficos terá quatro ocorrências do tipo texto. A codificação de caracteres deve ser autodetectada pelo navegador. Não pode ser especificada pelo usuário. Caso ainda assim ocorram problemas de codificação, temos: Se o problema for o site inteiro, somente será considerada uma ocorrência. Se o problema variar por página, será considerada uma ocorrência por página. Erros gramaticais devem ser embasados com uma referência que define a regra violada. 3.4. Ocorrências Relacionadas a Formulários Campos sem limite de tamanho serão considerados como ocorrências do tipo funcional. Campos sem validação serão considerados ocorrências do tipo funcional. Ausências de hints (dicas) nos campos de formulário serão consideradas como melhorias. Será permitida uma ocorrência de ausência de links por página ou interface do software/site alvo dos testes. 3.5. Ocorrências Relacionadas a Código Fonte Erros no código Javascript: se o erro no código Javascript gerar uma anomalia no sistema, a classificação de tipo da ocorrência deverá ser a mesma da anomalia. Erros no código Javascript que não geram anomalia no sistema deverão ser classificados como melhorias. Erros no código HTML: se o erro no código HTML gerar uma anomalia no sistema, a classificação de tipo da ocorrência deverá ser a mesma da anomalia. Erros no código HTML que não geram anomalias no sistema deverão ser classificados como melhoria. Erros no código CSS: se o erro no código CSS gerar uma anomalia no sistema, a classificação de tipo da ocorrência deverá ser a mesma da anomalia. Erros no código CSS que não geram anomalias no sistema deverão ser classificados como melhoria. 3.6. Ocorrências Relacionadas à Configuração Ocorrências relacionadas a resoluções abaixo de 1024×768 não serão consideradas, exceto quando explicitado no projeto. Ocorrências relacionadas a Javascript desabilitado não serão consideradas. Ocorrências relacionadas a pop-ups desabilitadas não serão consideradas. Ocorrências relacionadas a complementos de navegadores web (e.g. plugins Java ou Flash) desabilitados não serão consideradas. Ocorrências relacionadas à ausência de um certificado digital válido não serão consideradas. 3.7. Ocorrências relacionadas a Sistemas Operacionais No caso de uma mesma ocorrência ser encontrada em todos os sistemas operacionais listados no projeto ou liberação, apenas a primeira ocorrência registrada será considerada, as outras serão consideradas duplicadas. No caso de uma mesma ocorrência ser encontrada em apenas alguns dos sistemas operacionais listados no projeto ou liberação, será considerada uma ocorrência por navegador, caso sejam devidamente registradas. 3.8. Ocorrências relacionadas a Navegadores Web No caso de uma mesma ocorrência ser encontrada em todos os navegadores listados no projeto ou liberação, apenas a primeira ocorrência registrada será considerada, as outras serão consideradas duplicadas. No caso de uma mesma ocorrência ser encontrada em apenas alguns dos navegadores listados no projeto ou liberação, será considerada uma ocorrência por navegador, caso sejam devidamente registradas. 3.9. Ocorrências relacionadas a Banco de Dados Ocorrências relacionadas a dados preenchidos incorretamente nos softwares ou sites-alvo dos testes não serão consideradas. Exemplo: um produto com a descrição incorreta ou com erros de idioma em um site de comércio eletrônico. 3.10. Ocorrências relacionadas ao campo Data Conforme o contexto do sistema, a aplicabilidade do campo data poderá variar. Para data de nascimento, se o sistema irá aceitar que o usuário seja cadastrado com mais de 100 anos de idade; Se irá aceitar uma data que seja anterior ao dia atual; Se um determinado período poderá ser aceito no passado ou no futuro; O formato de preenchimento deste campo;
Fechar
Perguntas Frequentes
Fechar
O que é o Gamer Trials? É uma plataforma que integra: quem precisa ter seu jogos testados e receber “feedbacks” antes do lançamento, a quem quer testar jogos e dar “feedbacks” aos desenvolvedores antes do lançamento. Para que serve o Gamer trials? Para auxiliar no desenvolvimento de melhores jogos, fazendo com que os desenvolvedores compreendam melhor seu público antes do lançamento e ainda encontrem problemas no desenvolvimento do seu jogo. E para fazer com que nossos usuários ajudem no crescimento da indústria de jogos, jogando antes de outros jogadores jogos ainda a serem lançados. Qual é o intuito do Gamer Trials? Dominar o mundo? Não. Brincadeira. É fazer com que os desenvolvedores façam cada vez jogos de mais qualidade, tornando-os mais lucrativos para a indústria. E que os nossos jogadores possam cada vez mais serem “experts” em qualidade e em feedbacks a indústria dos games. A missão maior do gamer trials é promover a qualidade na indústria de jogos e fazer com que com o aumento da qualidade, os desenvolvedores vendam mais. Sou jogador ou usuário e quais seriam meus benefícios para me cadastrar no gamer trials? Aqui você poderá jogar jogos antes de outros jogadores, ganhar prêmios, falar e ser ouvido pelos desenvolvedores dos jogos. Sou desenvolvedor. Quais seriam meus benefícios ao inserir um jogo no gamer trials para ser testado? Conhecer melhor seu público, o que eles comprariam ou não, isso antes mesmo do seu lançamento. Receber bugs e melhorias dos usuários para controle da qualidade. Receber marketing de divulgação do seu jogo antes do lançamento. O que quest? É além de uma aventura, um teste a ser feito em um jogo específico. Cada quest possui suas regras com relação a quantidade de prêmios a serem distribuídos, onde você terá que acessar nosso sistema deixa seu feedback de um jogo específico. Quanto mais feedbacks e melhorias enviados e validados pela nossa equipe na quest de teste, mais pontos ganhará. Ao final ganharão os prêmios os cavaleiros mais capazes na localização dos bugs e sugestões de melhorias. Como dou meu feedback? Primeiro você precisará estar cadastrado e se logar no sistema. Após fazer isso escolha uma quest a qual queira participar, após isso clique na quest escolhida e no botão deixar feedback e preencha o formulário. O que ganho pelo meu feedback? Você ganha TrialPieces, moedinhas internas do Gamer Trials. Juntando algumas delas poderá trocá-las por descontos e jogos na Nuuvem Platform ou ajudar algum desenvolvedor que more no seu coração através de doações ou participando do mercado de idéias. O que é o mercado de idéias? O mercado de ideias é um lugar onde os desenvolvedores colocam aquilo que estão pensando em desenvolver no futuro, novas fases, armas, personagens, modos de jogo, qualquer coisa que a imaginação criativa dos desenvolvedores conseguir criar. Os jogadores participam do mercado de ideias “comprando” as ideias. Colocam TrialPieces nas ideias que acham mais interessantes, ajudando o desenvolvedor a saber quais são as mais interessantes a serem feitas e financiando futuras quests do jogo ou até o próprio jogo em si. Como recebo meus prêmios? Cada quest tem certos prêmios em TrialPieces, o mais simples são premiações para os 1º,2º e 3º colocados. Existem também “mini quests” dentro de uma quest, alguns desenvolvedores por exemplo podem premiar os 3 primeiros jogadores a postarem um vídeo com gameplay comentado, as mini quests variam de quest pra quest e de dev para dev. Por que devo me cadastrar? Por que aqui todo jogador será ouvido, ganhará jogos, ganhará descontos e prêmios, jogará antes de outros jogadores a jogos ainda em fase de desenvolvimento, falará e ouvirá feedback dos desenvolvedores e ajudará como parte fundamental do aprimoramento dos jogos que serão lançados, tendo ideias desenvolvidas ou uma correção importante em um jogo ocorrer graças ao seu feedback. Sou jogador ou usuário, como me cadastro? Entre em nosso sistema, clique na aba superior no botão “cadastre-se”, preencha os dados e estará dentro do nosso mundo dos bugs perdidos... ou achados, quem sabe? Sou desenvolvedor, como me cadastro? Entre em nosso sistema, Cadastre-se na parte de empresas, preencha os dados e seja feliz :) Sou desenvolvedor, como crio uma quest de teste? Faça login no sistema após ter se cadastrado, uma vez dentro do sistema, você verá um “pequeno” botão verde escrito “Nova Quest”, clique neste botão. Preencha logo após o nome da sua quest de teste, descrição, banner vídeo e premiações. Entre em contato para ter seu cadastro validado e sua quest disponível para os jogadores. Você também precisa ter um Hub para que os jogadores possa visualizar sua quest. O que é um Hub? O Hub é o ponto central do seu jogo. Nele os jogadores encontram a descrição, video, banner, tudo para ajudar a entender sobre o que é o seu jogo. No Hub também estão os links para o Mercado de Ideias e as quests que estejam ativas no momento. Sem um Hub os jogadores não têm acesso ao seu jogo. Os Hubs são 100% gratuitos para serem criados. Como vocês garantem minha vida após usar o sistema? Orando aos Deuses e ao nosso Mestre da Ordem. Como pude viver tanto tempo sem o Gamer trials na minha vida? Não sei, sempre nos perguntamos isso. Como é a vida após a morte? Ruim. Não há como jogarmos lá.
Fechar
Contato
Email
Assunto
Mensagem
Cancelar
Enviar