1. J'ai rencontré de nombreux ingénieurs logiciels qui pensent qu'ils sont en quelque sorte supérieurs aux ingénieurs QA. Je pense que cela peut aider à étancher cette croyance s'ils font le travail d'un ingénieur QA pendant un certain temps et réalisent qu'il s'agit d'un ensemble de compétences unique et précieux.
Une bonne ingénierie logicielle a une formation en qualité, y compris les tests, les métriques et les statistiques. Toute personne effectuant n'importe quel type de développement logiciel doit être consciente (si elle n'est pas familière) de maintenir un code source de qualité et de produire / maintenir des cas de test efficaces. Au fil du temps, je soupçonne que n'importe quel développeur de logiciels gagnerait à comprendre les différentes facettes de la qualité - la qualité du code, la portabilité, la maintenabilité, la testabilité, l'utilisabilité, la fiabilité, l'efficacité et la sécurité.
Les ingénieurs logiciels peuvent se concentrer sur un aspect particulier du cycle de vie - l'ingénierie des exigences, l'architecture et la conception, la construction, les tests et la maintenance. Cependant, quel que soit votre objectif (en tant que travail ou à la phase actuelle du projet), il est important de se souvenir de la qualité.
2. Plus un ingénieur logiciel est en mesure de tester ses propres programmes, moins son code coûte de temps à parcourir le reste du cycle de vie du développement logiciel.
C'est peut-être vrai. Mais certains problèmes seront mieux vus plus tard dans le développement. Par exemple, les problèmes de performances et d'efficacité peuvent ne pas apparaître avant l'intégration. Avoir un bon code solide et des tests unitaires efficaces ne sont qu'un début. La qualité doit commencer par les exigences et suivre tout au long des activités de maintenance.
3. Plus un ingénieur logiciel passe de temps à réfléchir à la façon dont un programme peut s'arrêter, plus il doit tenir compte de ces cas au fur et à mesure qu'il les développe, réduisant ainsi les bogues du produit final.
C'est une affirmation totalement vraie. Mais là encore, c'est aussi aux ingénieurs des exigences de vérifier qu'il n'y a pas de conflits dans les exigences, aux architectes de s'assurer que la conception répond réellement aux exigences, etc. Tout le monde devrait essayer de percer des trous dans leur travail, puis travailler avec les personnes appropriées pour les sceller bien et serrés.
4. La définition de "complet" d'un ingénieur logiciel est toujours intéressante ... s'il a passé du temps en tant qu'ingénieur AQ, cette définition correspondra peut-être mieux au concepteur du logiciel.
"Complet" ne peut être mesuré que par rapport aux exigences. Soit les exigences sont satisfaites et le projet est terminé, soit il existe des exigences incomplètes et le projet n'est pas terminé. Toute autre mesure de complet est inutile.