Services de QA et de tests logiciels

Tests manuels et automatisés de produits iOS, Android et web, au sein d’un projet que nous développons ou en contrôle indépendant d’un produit réalisé par une autre équipe. Vous recevez des rapports de bugs reproductibles et une vision claire de ce qui pourrait mal tourner à la mise en production.

Quand vous avez besoin d'une équipe QA

Les tests sont rentables dès qu’un bug en production coûte plus cher que de le trouver plus tôt. Voici les situations que l’on nous décrit le plus souvent.

Les utilisateurs signalent des bugs que votre équipe n'a jamais vus
Chaque nouvelle version casse quelque chose qui fonctionnait
Les développeurs testent leur propre code et personne d'autre ne le vérifie
La validation de l'App Store ou de Google Play a rejeté votre build
Vous êtes sur le point de lancer et voulez d'abord un regard extérieur
Le produit ralentit ou tombe en panne quand le trafic augmente

Ce que nous testons

Tests manuels

Les ingénieurs QA parcourent le produit pas à pas, au regard des exigences et des cas de test, sur de vrais appareils et dans les navigateurs. Ils explorent aussi les zones qu’aucun cas de test ne couvre encore, comme le ferait un nouvel utilisateur.

Automatisation des tests

Nous automatisons les vérifications qui doivent passer à chaque build : inscription, paiements, autres parcours essentiels et API. La suite tourne dans votre pipeline CI/CD et signale les échecs avant qu’une version ne parte.

Tests de performance

Nous mesurons les temps de réponse et le débit sous charge et trouvons le point à partir duquel le produit commence à défaillir. Le rapport liste les goulets d’étranglement dans l’ordre où il faut les corriger.

Tests de sécurité

Nous vérifions comment le produit stocke et transmet les données, comment fonctionnent l’authentification et les droits d’accès, et ce qu’exposent le code et les bibliothèques tierces. Chaque constat est accompagné d’un niveau de risque et d’une correction recommandée.

Tests mobiles et conformité aux stores

Tests sur de vrais appareils iOS et Android, pas seulement sur simulateurs, avec les versions d’OS réellement utilisées par vos utilisateurs. Nous vérifions aussi les builds au regard des règles de l’App Store et de Google Play pour éviter un rejet lors de la validation.

Tests d'API et d'intégration

Votre backend, vos prestataires de paiement et vos services tiers sont testés ensemble, y compris dans les cas d’échec : délais dépassés, paiements refusés, données incomplètes. C’est généralement là que commencent les incidents en production.

Des tests menés en parallèle du développement

Des tests qui commencent après le développement trouvent les problèmes au moment où ils coûtent le plus cher à corriger. Dans nos projets, un ingénieur QA intervient dès la phase des exigences, rédige les cas de test pendant que les fonctionnalités sont développées et vérifie chaque build de sprint, pas seulement la version finale. Le jour de la mise en production, l’équipe connaît déjà les points faibles. La même approche fonctionne quand nos testeurs rejoignent votre équipe existante.

Exigences relues pour repérer les lacunes avant l'écriture du code
Cas de test prêts au moment où la fonctionnalité l'est
Chaque build de sprint vérifié, pas seulement la version candidate
Tests de régression avant chaque mise en production

Tests manuels ou automatisés ?

Les tests manuels apportent du discernement : une personne remarque qu’un parcours est techniquement correct mais inutilisable en pratique. L’automatisation apporte la répétition : les mêmes cent vérifications après chaque commit, la nuit, sans fatigue. Les petits projets et les fonctionnalités éphémères remboursent rarement le coût d’écriture des tests automatisés, et nous vous le disons au lieu de vous les vendre. Les produits durables avec des mises en production fréquentes le remboursent vite : la plupart des produits matures finissent donc par utiliser les deux.

Manuel : nouvelles fonctionnalités, ergonomie et produits qui changent chaque semaine
Manuel : tests exploratoires des zones floues ou à risque
Automatisé : parcours essentiels qui ne doivent jamais casser, vérifiés à chaque build
Automatisé : suites de régression pour les produits aux mises en production fréquentes
Les deux : l'automatisation pour le socle stable, des personnes pour toute nouveauté

Ce que vous recevez

Tout ce que nous produisons reste attaché au projet : le testeur suivant, chez nous ou chez vous, ne repart pas de zéro. Un bug impossible à reproduire n’est pas un constat, et nous ne le signalons pas comme tel. Chaque mise en production se conclut par un court rapport sur ce qui a été testé et les risques qui subsistent : la décision de livrer vous appartient, en connaissance de cause.

Cas de test et checklists conservés dans votre outil de suivi ou votre dépôt
Rapports de bugs avec étapes, environnement, résultat attendu et résultat obtenu
Rapport de mise en production : ce qui a été couvert et les risques restants
Suite de tests automatisés avec ses instructions d'exécution, lorsque l'automatisation a été convenue

Déroulement des tests

Analyse du produit

Nous étudions les exigences, ou le produit lui-même en l’absence de documentation, et convenons des plateformes, des appareils et des parcours prioritaires. Vous recevez un périmètre et un plan de tests.

Cas de test

Nous rédigeons les cas de test et les checklists pour le périmètre convenu. Ils sont conservés dans vos outils et restent attachés au projet.

Test des builds

Chaque build est testé sur de vrais appareils et dans les navigateurs cibles. Les bugs sont saisis dans votre outil de suivi avec tout le nécessaire pour les reproduire.

Automatisation quand elle est rentable

Pour les parcours vérifiés à chaque build, nous écrivons des tests automatisés et les connectons à votre pipeline CI. Vous voyez les résultats à chaque commit.

Rapport de mise en production

Avant chaque mise en production, vous recevez une synthèse de ce qui a été testé, de ce qui a été corrigé et des risques qui subsistent.

Plateformes et outils

Plateformes

Automatisation

Performance et sécurité

Organisation du travail

Nos formules de collaboration

QA dans un projet que nous développons

Un testeur fait partie de l’équipe dès le premier sprint, et les tests sont planifiés en même temps que le développement.

Tests d'un produit développé ailleurs

Un contrôle au périmètre fixe d’un produit existant ou d’une version précise : cas de test, rapports de bugs et évaluation écrite de son état.

Ingénieurs QA dans votre équipe

Nos testeurs travaillent selon votre processus et dans votre outil de suivi, facturés à l’heure ou en tant qu’ingénieur dédié.

Projets associés

Fashion WalletKotlin, SWIFT, PHP, Laravel Stellium Music AppKotlin, SWIFT, PHP, Laravel, VueJS QuakerKotlin, SWIFT, PHP, Laravel CityPairsPHP/Yii2, MySQL, Java (Android), Swift (iOS)MemoWordSwift, Java, Kotlin

Témoignages

Nous traitons chaque client et son projet avec attention.

L’équipe Revol continue de renforcer les capacités de développement du client grâce à un travail de grande qualité et à un support fiable. Elle communique efficacement et fait preuve d’une solide compréhension des besoins et de l’activité du client.

Tomas

PDG (Yukon, Canada)

Le travail de Revol a pleinement répondu aux attentes et a satisfait le client. Leur approche nouvelle et leur disponibilité pour le support ont été de vrais atouts. On peut faire appel à eux pour disposer d’une équipe communicative et orientée client, qui aide à atteindre ses objectifs.

Andrey

PDG, Stellium (États-Unis)

Questions fréquentes

Pouvez-vous tester un produit que vous n'avez pas développé ?

Oui. Nous partons des exigences, ou du produit lui-même en l'absence de documentation, et rédigeons les cas de test à partir de là. Le premier résultat est généralement une liste des problèmes les plus graves et un plan de tests pour le reste.

Pouvez-vous fournir des testeurs à notre propre équipe ?

Oui. Les ingénieurs QA peuvent travailler selon votre processus, dans votre outil de suivi et au rythme de vos mises en production, comme le font nos développeurs en renfort d'équipe.

Faut-il automatiser nos tests ?

Seulement là où les tests seront exécutés assez souvent pour rembourser le coût de leur écriture et de leur maintenance. Pour un produit durable aux mises en production fréquentes, cela concerne généralement les parcours essentiels et l'API. Pour un prototype ou une fonctionnalité éphémère, les tests manuels coûtent moins cher, et nous vous le dirons.

Sur quels appareils testez-vous ?

Sur de vrais appareils iOS et Android, complétés par des simulateurs et des émulateurs pour couvrir plus de versions d'OS, et sur les principaux navigateurs de bureau et mobiles. La liste des appareils est convenue au départ, en fonction de ce qu'utilisent réellement vos utilisateurs.

Pouvez-vous nous aider après un rejet de l'App Store ou de Google Play ?

Oui. Nous lisons le retour de validation, reproduisons le problème, vérifions le build au regard des règles en vigueur et indiquons précisément aux développeurs ce qu'il faut changer. Si nous développons l'application, nous la corrigeons et la soumettons de nouveau nous-mêmes.

Comment les tests sont-ils facturés ?

Cela dépend de la formule. Un contrôle ponctuel d'un produit ou d'une version se fait généralement au périmètre fixe ; les tests continus sont facturés à l'heure ou en tant qu'ingénieur dédié. Après avoir examiné le produit, nous vous proposons une formule et vous envoyons une estimation.