Pode-se supor que Grace Hopper, uma cientista informática da Universidade de Harvard, não estava a ter o melhor dia em 9 de setembro de 1947. O seu computador apresentava repetidamente erros sem qualquer razão aparente. Ao abri-lo, Grace encontrou um inseto real, uma traça para ser mais preciso, que estava a interferir com o seu funcionamento. Assim, ela se tornou a primeira pessoa a relatar um bug de computador.
Na realidade, os erros de software não são causados por coisas como traças (embora os nossos programadores desejassem que todas as correcções fossem tão simples!) Em vez disso, um bug de software é um erro no sistema que faz com que este produza resultados incorrectos ou se comporte de forma inesperada. No Easy LMS, o nosso objetivo é construir um sistema sem erros para si! Mas, o facto é que um sistema sem erros é tão raro como um unicórnio. O Easy LMS é construído por humanos e está sujeito a erros humanos, o que significa que os bugs escapam de vez em quando ?
Uma vez que sabemos como é irritante quando existem erros, temos um processo em vigor para os corrigir o mais rapidamente possível! Aqui está uma visão interna de como este processo funciona, desde a descoberta de um erro por si, até à sua correção final.
Fase 1
Contactar-nos
A primeira etapa do processo é onde você, como cliente, entra em ação. Vamos fingir que está a criar um novo exame para testar os conhecimentos de um novo contratado sobre normas de segurança. Para dar um toque especial, vai carregar o logótipo da sua empresa. Em vez de carregar a imagem com êxito, vê o ícone de carregamento a rodar, rodar e rodar ...
Depois de tentar mais algumas vezes, é provável que esteja bastante frustrado. O Easy LMS não está claramente a funcionar como deveria! O que é que deve fazer? Contactar o suporte imediatamente! O suporte será o seu ponto de contacto durante todo o processo.
Recolheremos o máximo de informações possível sobre o bug
Através da caixa de conversação, entrará em contacto com um membro da equipa de apoio. Um dos nossos maiores objectivos nesta altura será reunir o máximo de informações possível sobre o erro. Pode parecer que está a jogar Twenty Questions, mas este passo é fundamental para que o desenvolvimento possa solucionar problemas mais tarde. Ser-lhe-ão feitas estas perguntas:
Qual é o caminho do menu para chegar ao local onde o problema está ocorrendo?
Qual é o URL exato?
Qual componente é afetado? Exames, cursos, etc.
Quais são os nomes dos conteúdos e utilizadores afectados?
Que plataforma e dispositivo está a utilizar?
O que estava a tentar fazer quando encontrou o problema?
O que acontece exatamente quando este problema ocorre?
Depois de partilhar esta informação valiosa, o seu trabalho está terminado. Agora pode sentar-se, relaxar e deixar o Easy LMS tomar as rédeas!
Fase 2
Reproduzimos
O seu trabalho pode estar concluído, mas ainda não acabou para o membro do suporte com quem tem estado a falar. Com a sua permissão, ele ou ela entrará na sua conta e tentará reproduzir o erro. Voltando ao nosso exemplo anterior, um membro do apoio técnico iria normalmente ao mesmo exame e tentaria carregar um logótipo ele próprio.
Se o suporte não conseguir reproduzir o problema, o processo termina aqui. De certa forma, é bom que o erro não possa ser reproduzido, uma vez que tudo deveria estar a funcionar. No entanto, isso não nos ajuda a chegar ao fundo da questão. Em casos como este, poderemos ter mais algumas perguntas e pedir-lhe-emos que nos informe se voltar a acontecer. Por outro lado, se conseguirmos reproduzir o erro (epa!), o processo continuará.
Fase 3
Registamos
Agora que conseguimos confirmar que se trata de um bug, vamos registar, ou o que dizemos "log", todas as informações que forneceu num relatório estruturado. Registamos os erros no Jira, uma ferramenta de gestão de projectos. Este relatório ajuda os outros a identificar o local exato e o aspeto que envolve o erro no futuro. A outra vantagem de registar os erros num único local é que os outros membros da equipa, incluindo os programadores, podem ver facilmente se a reclamação de outro cliente se enquadra num erro existente.
O suporte irá então marcar a sua conversa com o número de ID do bug. Desta forma, podemos encontrar as suas informações de contacto para lhe pedir mais informações ou fornecer-lhe actualizações relevantes.
O suporte técnico é onde a magia acontece
Fase 4
Depuramos
Na Easy LMS, os programadores e os consultores de apoio trabalham em equipa. Quando decidimos o que fazer a seguir, todos trabalham em todas as disciplinas para dar prioridade aos bugs em relação a potenciais novas funcionalidades com base na urgência do tempo. Durante esta chamada, também discutiremos se uma nova funcionalidade seria melhor e, nesse caso, o bug é enviado como um pedido de funcionalidade.
Assim que o seu problema for detectado pelo departamento de desenvolvimento, este identificará o problema, proporá uma solução e implementará a correção num período de dois dias.
Fase 5
Comunicamos
Uau! O erro foi finalmente corrigido! Será notificado pelo membro do suporte assim que for lançado.
Nesta altura, agradecemos também a sua paciência. Os bugs não são divertidos para ninguém! Não para si. Não para o suporte. Nem para o desenvolvimento. Por isso, a sua compreensão e comunicação connosco são sempre apreciadas e ajudam a tornar o processo um pouco mais fácil para todos os envolvidos.
