QA best practices
1.0.0
Ceci est un résumé des pratiques de QA Futurice utilise et recommande d'être utilisé. Il n'est pas censé être une description détaillée et ne peut parfois pas être entièrement utilisé de toutes les tâches, mais comme un aperçu des processus de QA les plus importants et une liste de bonnes pratiques qui devraient être utilisées.
Aux fins de la clarté, ce document ne décrit pas une erreur ou un processus d'incident (c'est-à-dire qu'un nouveau bug est trouvé à partir de la production).
Tout le monde dans l'équipe Futurice a des responsabilités de l'AQ, même s'il y a un responsable du QA ou des spécialistes de l'AQ. À Futurice QA signifie trois choses.
Sur les travaux et les pratiques de QA de haut niveau, peuvent être divisés en deux processus.
De plus, il existe d'autres actions d'AQ.
Futurice utilise des méthodes TDD et ATDD (développement du test de test d'acceptation) le cas échéant.
La méthode oblige la mise en œuvre à suivre l'architecture et à considérer les modules utilisés. L'implémentation commence par rédiger le test automatisé, puis implémentation de la fonctionnalité pour réussir le test.
Futurice utilise la méthode de programmation des paires le cas échéant. C'est un moyen très pratique de partager les connaissances et l'expérience sur le projet et les logiciels en cours de développement.
La révision du code aide les autres membres de l'équipe à obtenir des informations sur certaines fonctionnalités et donne la possibilité de donner des commentaires à une personne responsable et assure également le partage des connaissances entre les membres de l'équipe.
Les tests manuels sont principalement effectués à l'aide de la méthodologie de test exploratoire et les erreurs trouvées sont soit corrigées immédiatement, soit hiérarchisées et enregistrées à l'outil de gestion des tâches / histoires / erreurs. L'exploration de l'application ou du service peut être démarrée juste après que quelque chose de fonctionnel est «prêt».
Les tests exploratoires sont un outil très puissant dans les tests de bout en bout où l'ensemble du système est couvert par des tests. Dans la méthode, le testeur va au-delà de ce qui peut être défini dans un cas de test, applique une réflexion de type utilisateur ainsi que des essais de briser le système par divers scénarios d'erreur et n'est jamais «fait» avec les tests.
Autour des exigences fonctionnelles et des tests, il existe généralement des exigences non fonctionnelles qui peuvent être testées en appliquant la localisation, la convivialité, les performances et les tests de charge. Les besoins et les outils sont spécifiques aux projets. Pour les tests d'utilisabilité, Futurice a un laboratoire d'utilisation mobile pour une utilisation. Pour les tests de performances, Futurice a utilisé des services Web comme BrowsMOB pour n'en nommer un. Pour les tests de charge, LoadUI et J METER sont activement utilisés pour valider les capacités de service dans un trafic élevé et pour trouver des goulots d'étranglement possibles.
Les problèmes trouvés sont enregistrés sur un outil ou une carte spécifique avec des informations telles que la priorité, l'environnement (logiciels et les informations de l'appareil), les étapes à reproduire, le résultat attendu, l'heure et la date et une capture d'écran. Des outils comme Jira, Trello, Pivotaltracker, Request Tracker sont activement utilisés également pour le suivi des erreurs.
L'un des principes de l'Agile est que la branche du code maître doit toujours être potentiellement envahissante. Cela signifie que cela devrait être toujours la qualité de la production. Ceci est réalisé par les moyens suivants:
Chaque histoire d'utilisateurs (ou fonctionnalité) est développée individuellement dans sa propre branche de fonctionnalités. Le but de ceci est de s'assurer que chaque mise à jour de Master Branch est en même temps 1) aussi petite que possible et 2) une histoire complète potentielle.
Avant que la branche des fonctionnalités ne puisse être fusionnée à la branche principale, elle doit transmettre une liste d'actions, d'exigences et de pratiques appelées définition de Done (DOD). Ceci est défini avec le PO client et l'équipe de développement et peut être modifié pendant le projet si les besoins du projet devraient changer.
Les éléments suivants du DOD proposé ont été en gras en raison
Le processus de déploiement est un processus comment la nouvelle version (ou une version dans Master Branch) est déployée en production. Pour ce processus, il existe trois environnements pertinents.
Le serveur d'intégration continue (CI) est utilisé pour les tests automatisés et le déploiement du code dans des environnements. Les tests automatisés sont toujours exécutés lorsque l'un de ces environnements est mis à jour.
L'environnement de test est mis à jour automatiquement par CI, chaque fois que Master Branch a été mis à jour. Cela signifie que les cas de test automatisés sont également exécutés automatiquement lorsque Master Branch est mis à jour.
L'environnement de test est le principal serveur de test pour Futurice. Il est prévu que toute version testée ici soit prête à être poussée à QA ou à la production (ce qui dépend de la terminologie et des intégrations utilisées dans le projet).
Il n'est pas nécessaire d'exécuter des cas de test de régression manuelle, lors de la mise à jour du test. Très souvent, le temps consacré aux tests exploratoires est plus bénéfique. Cependant, c'est une bonne pratique d'exécuter ces tests au moins une fois par sprint.
L'environnement QA doit être utilisé comme environnement pour les tests d'acceptation, les démos ou tout test ou audits tiers (sécurité, localisation, charge, convivialité, etc.). Ce n'est pas le serveur de test principal de Futurice (le test est). La mise à jour de l'AQ est toujours convenue entre le PMS du client et Futurice.
La raison principale d'avoir deux environnements de test (test et QA) est de se conformer aux exigences de sécurité et d'intégration. Le test permet à Futurice de développer le service en utilisant des principes agiles. QA permet à du temps et au contrôle du client d'exécuter ses processus AQ actuels.
L'AQ ne doit être mise à jour, sauf si la version a réussi les tests dans l'environnement de test.
L'environnement Prod est l'environnement du site en direct (production).
La bonne pratique consiste à déployer et à exécuter des tests automatisés au moins dans l'AQ, avant de pousser la mise à jour vers la prod. Cependant, chez prod, les fonctionnalités majeures doivent être vérifiées après chaque déploiement.
Il est recommandé que le PO ait également le droit de pousser une mise à jour vers Prod, sans aucun test dans AQ (si la version est passée au test). Ceci est pertinent lorsque la mise à jour est très petite ou simple.
En fin de compte, dans le développement agile, lorsque le service est en développement continu, l'objectif est d'avoir beaucoup de petites mises à jour également à producteur. C'est-à-dire qu'il est plus important que le processus de déploiement soit maigre et rapide que pare-balles. Il est considéré comme plus important de pouvoir faire des correctifs rapidement que d'avoir un service sans bogue (évidemment avec le DoD et les tests automatisés, la qualité devrait également être élevée). Futurice ne recommande pas immédiatement de commencer cette approche. Cependant, cela devrait être la direction où les deux organisations veulent aller.
Chaque plate-forme mobile a son SDK spécifique, ses ensembles d'outils et ses meilleures pratiques de Futurice.
Pour Android https://github.com/futurice/android-best-practices
Pour iOS https://github.com/futurice/ios-good-practices
Pour Windows Phone https://github.com/futurice/windows-app-development-best-practices
Les plateformes mobiles fournissent des émulateurs au sein de leur SDK.
Pendant la phase d'implémentation, le développeur peut utiliser des appareils simulés / imités pour valider les modifications, mais rien ne peut battre les tests de périphériques réels où l'ensemble du système de l'écran tactile et de la mémoire intégrée aux processeurs mobiles est considéré.
Les navigateurs mobiles peuvent également être testés par des services basés sur le cloud comme Browserstack.
Futurice a une bonne variété de différents appareils et versions du système d'exploitation dans la bibliothèque de périphériques, allant des téléphones de base aux tablettes avancées.
Pour les tests d'applications de trafic de données lourds et la validation des performances, Futurice utilise ELISA Test Lab (ELISA est un fournisseur de services mobiles finlandais). Dans l'environnement de laboratoire, différentes charges et vitesses peuvent être testées dans un environnement contrôlé / isolé sans avoir besoin d'organiser des séances de test de terrain coûteuses et non efficaces.
Habituellement, l'application mobile se connecte à un service backend via un réseau mobile. Pour tirer le meilleur parti des tests, le testeur doit avoir un contrôle total du backend où l'application mobile est connectée afin de se préparer et d'exécuter différents scénarios de test de bout en bout.
Dans les appareils mobiles, l'installation de construction de test peut être effectuée: localement par câble à l'aide d'outils de développement SDK contrôlés sans fil via des outils de distribution de construction comme TestFlight ou HockeyApp. La libération des cadres prend généralement en charge la collecte de journaux de crash et les données de version. Les versions Dev, Alpha et Beta peuvent également être fournies afin de collecter des commentaires avant de remettre l'application dans les magasins. Google Play Store a une option pour configurer les groupes de test alpha et bêta où l'application spécifique est disponible pour les membres du groupe uniquement
Dans les applications mobiles modernes, l'analyse et la collecte de données représentent des fonctionnalités critiques qui nécessitent également des tests. Futurice considère que c'est une partie importante des tests fonctionnels.
En raison du fait que le processus de mise à jour des applications mobiles diffère de celui des applications Web, la configuration de l'analyse doit se rendre directement à partir du premier essai ou des données précieuses sont manquées. Le processus de mise à jour est effectué via les procédures des magasins d'applications, mais la question de savoir si la mise à jour sera effectuée ou non concerne les paramètres et l'activité des utilisateurs. Donc, si la première version manque certaines fonctionnalités d'analyse critique et que certains utilisateurs ne mettent jamais à jour l'application, ces données seront ensuite manquées. La solution peut être forcée de mise à niveau, où l'application devient inutilisable jusqu'à ce que l'utilisateur se met à jour de la dernière version disponible, mais cela pourrait être trop tard.
