Nos spécialistes en GQ exécutent toutes les phases du cycle de vie de GQ, des la définition de l'architecture du processus de GQ au l'exécution du cycle de testing spécifique (fonctionnel, système, load/stress, testing etc)

Un examen minutieux du processus et de la conception du produit /application est fait par les spécialistes et les concepteurs superieures. Des questions sur L'Architecture, Le Développement et sur Le Mise en oeuvre sont discutées et gelées. A cet étape nos architectes de GQ déterminent l'influence potentielle de l'architecture et de la conception sur le processus de GQ, sur le plate-forme ainsi que la selection des outils.

On fait un 'micro scale' testing pour tester des code modules particuliers. Celui ci est typiquement fait par un programmeur et pas par des ingénieurs de GQ, comme il exige une connaissance détaillée du code interne de programme. Ce n'est pas toujours fait facilement à moins que l'application ait une architecture bien dessiné avec un 'tight' code. Cela exige de développer des modules de test driver ou de test 'harnesses'.

Code Walkthrough est le processus où les qualifiés membres de l'équipe observent le code d'un programmeur ou d'un développeur. Il n'y a aucun substitut de Code Walkthrough car cela décèle des erreurs de programmation tôt. Nous en encourageons comme une partie du processus d'ingénierie de GQ parcequ'il assure qu'un programmeur utilise de bonnes pratiques de coding et qu'il possède un bon niveau de coding..

Nos ingénieurs de GQ développent des cas de test pour cibler chaque fonction souhaitable et indésirable du logiciel. Chaque fonction du logiciel est visée et testée séparamment des autres fonctions du logiciel.

Nous testons les parties combinées d'une application pour déterminer s'ils fonctionnent correctement ensemble. Les ' parties' peuvent être des modules de code, des applications individuelles, des applications du client et de serveur sur un réseau etc. Un outil automatisé peut également être utilisé pour faire un test d'intégration.

Dans cette phase, nous nous assurons qu'un bug fix ou une modification du logiciel n'a pas un impact indésirable sur d'autres parties ou fonctions du logiciel. Un mélange de cas de tests concernant des différentes fonctions du logiciel, constitute un baquet de régression. Ce baquet de régression doit être exécuté chaque fois qu'un bug fix ou une modification de logiciel est libérée au GQ. Des outils de test automatisés sont particulièrement utiles pour ce test de régression.

C'est une fonction plus pour le client (ou utilisateur) et moins pour le cycle de vie de GQ. Nous nous assurons que le système du logiciel réalise le critère de qualité déterminé avant qu'on l'accepte ou le lance. Le critère de la qualité acceptable, pourrait être basé sur des résultats des phases de GQ précédentes (système testing ou performance testing etc.) ou il peut être une phase de test entièrement différente, et indépendante des phases de test précédentes.