1) Définissez la stratégie de la recette.

En plus de la description de l'organisation et des moyens mis en œuvre pour la recette, n'oubliez pas de décrire l'objectif de cette recette. Recetter une application, ce n'est pas vérifier que l'application n'a pas de bug. Recetter, c'est vérifier que le système répond aux exigences fonctionnelles et non fonctionnelles par rapport aux coûts et à la qualité attendue. Définissez donc en amont quelle est la criticité des fonctionnalités du système et le niveau d'acceptabilité pour chaque criticité. Par exemple, on acceptera peut-être un bug bloquant sur une fonctionnalité "cosmétique" alors que pour une fonctionnalité très critique, aucun bug bloquant ou majeur ne sera toléré. 

2) Pensez aux tests avant tout.

Test Driven Development, Behavior Driven Development, Acceptance Test Driven Development... Beaucoup de méthodes prônent la conception par les tests. Sans forcément passer par des concepts complexes, penser "tests" dès la conception fonctionnelle permet souvent d'expliciter sa pensée et de se concentrer sur les objectifs du système.

3) Coordonnez et planifiez la recette.

Même si tous les tests ne sont pas exécutés par la MOA, coordonnez. De la mise à disposition des environnements de test, à l'exécution de tests de performance, en passant par les tests utilisateurs, vous devrez coordonner des équipes aux contraintes très différentes. La recette est souvent un projet en elle même.

4) Outillez vous.

Que ce soit pour la description des plans de test et le suivi de l'exécution des campagnes, utilisez des outils pour industrialiser vos tests (du classique avec HP Quality Center, ou du plus original comme FitNesse à base de Wiki). Au minimum, utilisez un fichier Excel pour décrire vos scénarios et cas de test ainsi que pour en suivre l'exécution.

5) Soyez pugnace.

La recette n'est pas une activité simple. Bien que souvent pénible et répétitive dans son exécution, c'est un moment clé du projet. On est souvent tenté de rogner sur la charge prévue pour cette activité car à la fin d'un projet, il ne reste plus grand chose à arbitrer ! Et pourtant, c'est le dernier rempart avant la mise en production. La négliger pourrait être une erreur fatale.