QA best practices
1.0.0
Este é um resumo das práticas de controle de qualidade que o Futurice usa e recomenda ser usado. Não deve ser uma descrição detalhada e, às vezes, não pode ser totalmente usada em todas as tarefas, mas como uma visão geral dos processos de controle de qualidade mais importantes e uma lista de boas práticas que devem ser usadas.
Para os fins da clareza, este documento não descreve um erro de erro ou incidente (ou seja, um novo bug é encontrado na produção).
Todo mundo na equipe Futurice tem responsabilidades de controle de qualidade, mesmo que exista um gerente de controle de qualidade ou especialistas em controle de qualidade. Para o qa Futurice significa três coisas.
No trabalho e práticas de controle de qualidade de alto nível, podem ser divididos em dois processos.
Além disso, existem outras ações de controle de qualidade.
O Futurice usa métodos de TDD e ATDD (Desenvolvimento de Teste de Aceitação), quando aplicável.
O método força a implementação a seguir a arquitetura e considerar módulos usados. A implementação começa escrevendo o teste automatizado primeiro e depois implementando a funcionalidade para passar no teste.
O Futurice usa o método de programação de pares, quando aplicável. Essa é uma maneira muito conveniente de compartilhar conhecimento e experiência sobre o projeto e o software em desenvolvimento.
A revisão do código ajuda outros membros da equipe a obter informações de determinada funcionalidade e dar a possibilidade de dar feedback à pessoa responsável e também garantir o compartilhamento de conhecimento entre os membros da equipe.
Os testes manuais são feitos principalmente usando a metodologia de teste exploratório e os erros encontrados são corrigidos imediatamente ou priorizados e gravados na ferramenta de gerenciamento de tarefas/história/erro. Explorar o aplicativo ou serviço pode ser iniciado logo depois que algo funcional está "pronto".
O teste exploratório é uma ferramenta muito poderosa no teste de ponta a ponta, onde todo o sistema é coberto por testes. No método, o testador vai além do que pode ser definido em um caso de teste, aplica o pensamento semelhante ao usuário e tenta quebrar o sistema por vários cenários de erro e nunca é "feito" com os testes.
Em torno dos requisitos funcionais e testes, geralmente existem requisitos não funcionais que podem ser testados aplicando localização, usabilidade, desempenho e teste de carga. As necessidades e as ferramentas são projetos específicos. Para testes de usabilidade, o Futurice possui um laboratório de usabilidade móvel para uso. Para testes de desempenho, a Futurice usou serviços baseados na Web, como o BrowSerMob, para citar um. Para testes de carga, LoadUi e J Meter estão ativamente em uso para validar os recursos de serviço em tráfego alto e encontrar possíveis gargalos de serviço.
Os problemas encontrados são registrados em uma ferramenta ou placa específica com informações como prioridade, ambiente (informações sobre software e dispositivo), etapas para reproduzir, resultado esperado, tempo e data e captura de tela. Ferramentas como Jira, Trello, Pivotaltracker, Request Tracker são usadas ativamente também para rastreamento de erros.
Um dos princípios do Agile é que a filial do código mestre deve sempre ser potencialmente elaborável. Isso significa que deve ser sempre a qualidade da produção. Isso é conseguido pelos seguintes meios:
Cada história do usuário (ou recurso) é desenvolvida individualmente em sua própria filial de recursos. O objetivo disso é garantir que cada atualização para o Master Branch seja ao mesmo tempo 1) o mais pequeno possível e 2) uma história potencialmente destruída e completa.
Antes que a filial do recurso possa ser mesclada para a filial principal, ela deve passar em uma lista de ações, requisitos e práticas chamadas de definição de done (DOD). Isso é definido juntamente com o PO do cliente e a equipe de desenvolvimento e pode ser modificado durante o projeto, caso as necessidades do projeto mudem.
Os itens seguintes no DOD proposto foram em negrito devido
O processo de implantação é um processo de como a nova versão (ou uma versão no Master Branch) é implantada na produção. Para este processo, existem três ambientes relevantes.
O servidor de integração contínua (IC) é usada para testes automatizados e implantando código em ambientes. Os testes automatizados são executados sempre quando qualquer um desses ambientes é atualizado.
O ambiente de teste é atualizado automaticamente pelo CI, sempre que a filial principal foi atualizada. Isso significa que os casos de teste automatizados também são executados automaticamente quando a filial principal é atualizada.
O ambiente de teste é o principal servidor de teste para o Futurice. Espera -se que qualquer versão que tenha sido testada aqui esteja pronta para ser empurrada para o controle de qualidade ou produção (isso dependendo da terminologia e integrações usadas no projeto).
Não é necessário executar casos de teste de regressão manual, ao atualizar o teste. Muitas vezes, o tempo gasto em testes exploratórios é mais benéfico. No entanto, é uma boa prática executar esses testes pelo menos uma vez por sprint.
O ambiente de controle de qualidade deve ser usado como um ambiente para testes de aceitação, demos ou qualquer teste ou auditoria de terceiros (segurança, localização, carga, usabilidade etc.). Este não é o servidor de teste primário do Futurice (o teste é). A atualização do controle de qualidade é sempre acordada entre o PMS do cliente e da Futurice.
O principal motivo para ter dois ambientes de teste (teste e controle de qualidade) é cumprir os requisitos de segurança e integração. O teste permite que a Futurice desenvolva o serviço usando princípios ágeis. O controle de qualidade permite tempo e controle para o cliente executar seus processos de controle de qualidade atuais.
O controle de qualidade não deve ser atualizado, a menos que a versão tenha passado testes no ambiente de teste.
O Prod Environment é o ambiente para o site ao vivo (produção).
A boa prática é implantar e executar testes automatizados no controle de qualidade, pelo menos, antes de pressionar a atualização para o Prod. No entanto, no Prod, a grande funcionalidade precisa ser verificada após cada implantação.
Recomenda -se que o PO também tenha o direito de impulsionar uma atualização para produzir, sem nenhum teste no controle de qualidade (se a versão for passada no teste). Isso é relevante quando a atualização é muito pequena ou simples.
Por fim, em desenvolvimento ágil, quando o serviço está em desenvolvimento contínuo, o objetivo é ter muitas pequenas atualizações também para produzir. Ou seja, é mais importante que o processo de implantação seja magro e rápido que à prova de balas. É considerado mais importante poder fazer as correções rapidamente do que um serviço livre de bugs (obviamente com o Departamento de Defesa e o teste automatizado, a qualidade também deve ser alta). O Futurice não recomenda começar com essa abordagem imediatamente. No entanto, essa deve ser a direção em que ambas as organizações desejam seguir.
Cada plataforma móvel possui seu SDK específico, conjuntos de ferramentas e práticas recomendadas da Futurice.
Para Android https://github.com/futurice/android-best-practices
Para iOS https://github.com/futurice/ios-good-practices
Para Windows Phone https://github.com/futurice/windows-app-development-best-practices
As plataformas móveis fornecem emuladores dentro de seu SDK.
Durante a fase de implementação, o desenvolvedor de fase pode usar dispositivos simulados / emulados para validar alterações, mas nada pode superar o teste real do dispositivo, onde é considerado todo o sistema da tela de toque e da memória integrada aos processadores móveis.
Os navegadores móveis também podem ser testados por serviços baseados em nuvem, como o Browserstack.
A Futurice possui uma boa variedade de dispositivos diferentes e versões do sistema operacional na biblioteca de dispositivos, variando de telefones básicos a tablets avançados.
Para testes de aplicativos de tráfego de dados pesados e validação de desempenho, o Futurice usa o ELISA Test Lab (ELISA é um provedor de serviços móveis finlandês). Dentro do ambiente de laboratório, diferentes cargas e velocidades podem ser testadas em ambiente controlado / isolado, sem a necessidade de organizar caras e não essas sessões de teste de campo eficazes.
Normalmente, o aplicativo móvel se conecta a um serviço de back -end por rede móvel. Para tirar o máximo proveito dos testes, o testador precisa ter um controle total do back -end, onde o aplicativo móvel está conectado para se preparar e executar diferentes cenários de teste final a fim.
Nos dispositivos móveis, a instalação de construção de teste pode ser feita: localmente por cabo usando ferramentas SDK de desenvolvimento controladas sem fio através de ferramentas de distribuição de construção como testflight ou hockeyapp. As estruturas de liberação geralmente suportam a coleta de logs de falhas e os dados da versão. Os lançamentos de Dev, Alpha e Beta também podem ser fornecidos para coletar feedback antes de liberar o aplicativo para as lojas. Google Play Store tem opção para configurar grupos de testes alfa e beta, onde o aplicativo específico está disponível apenas para os membros do grupo
Em Analytics de aplicativos móveis modernos, a coleta de dados representa funcionalidade crítica, que também precisa de testes. O Futurice considera que isso é uma parte importante dos testes funcionais.
Devido ao fato de o processo de atualização de aplicativos móveis difere do Web Apps One, a configuração do Analytics precisa obter diretamente a partir da primeira tentativa ou dados valiosos. O processo de atualização é feito por meio de procedimentos de armazenamento de aplicativos, mas se a atualização será feita ou não, está pronta para as configurações e atividades do usuário. Portanto, se a primeira versão perder alguma funcionalidade crítica de análise e alguns usuários nunca atualizará o aplicativo, esses dados serão perdidos. A solução pode ser forçada atualização, onde o aplicativo se torna inutilizável até que o usuário seja atualizado para a versão mais recente disponível, mas isso pode ser tarde demais.
