La majorité des grands systèmes est constituée de plusieurs sous-systèmes qui à leur tour sont composés de bouts de codes intégrés dans plusieurs couches et d'autres composants tels que des bases de données ou des files d'attente. Lorsqu'ils travaillent avec l'application, les utilisateurs agissent sur les interfaces qui à leur tour dialoguent avec les sous systèmes. Plus il y a de sous-systèmes, de couches et de composants dans le système, plus il est difficile d'isoler la source d'un problème rencontré durant la phase de test.

Lorsque l'architecture d'une application est conceptualisée, les testeurs devraient avoir l'opportunité de poser des questions du type : "  Comment tracer le chemin suivi par une donnée saisie en entrée ? ". Par exemple, si une certaine fonction provoque le lancement d'une autre tâche sur un autre serveur, il est utile pour le testeur qu'il puisse vérifier que la tâche censée se lancer est effectivement lancée. Si l'architecture retenue rend difficile l'identification du chemin suivi par une donnée saisie, il pourra être nécessaire de développer une autre architecture plus testable. La stratégie de test doit tenir compte de ce type de problème, et peut nécessiter de réaliser des efforts de tests supplémentaires avec l'aide éventuelle des développeurs et/ou des éditeurs des logiciels concernés.

Le fait d'analyser une architecture alors qu'elle n'existe uniquement que sur du papier réduit fortement les risques de voir des surprises survenir plus tard durant la phase de test. Si certains aspects de l'architecture sont flous, l'équipe de test doit alors insister que l'on développe un prototype pour s'assurer que l'architecture est bien testable, et donc pour vérifier que l'on peut effectivement qualifier l'application.