Donc tu n'écris aucun test programmatique parce qu'ils peuvent être déjoué ?
Non, le développeur écrit une batterie de test UI automatisés. Ce qui est, comme je le pointait au dessus, une tâche plutôt difficile, donc réservée à quelqu’un qui bouffe du code toute la journée (pas un qa).
Quand il a finit, l’ingénieur qa prend le relai et tente de casser la feature. Il rapporte des bugs, qui partent soit au produit, soit à l’ingé. Si ça part à l’ingé, il rajoute un/des test UI, corrige le bug, et ferme le ticket. Si ça part au mec produit, il change la spec et tu repart au début.
Ce que tu ne peux pas faire c’est dire "on a des UAT, et ils sont implémentés par l’ingénieur, donc on a pas besoin de faire une passe en profondeur manuelle". En pratique, ta passe manuelle en profondeur va doubler ou tripler le nombre d’uat, et probablement nécessiter des raffinements à la spec.
Quand tu met à jour une bibliothèque/framework, la base de données ou la version du langage, comment tu fais pour qualifier la prochaine version ?
Ça va dépendre de la bibliothèque. Une migration à iOS n+1, on corrige tous les tests automatisés qui foirent (2-3 douzaines en général), et après on fait une passe de regression manuelle sur toute l’appli. On revérifie pas chaque feature a 100%, mais on s’assure de toucher chaque feature, et on passe un peu plus de temps sur les flows les plus importants.
Une bibliothèque plus technique/pas user facing (genre le tracking marketing, ou le client http) va typiquement être mockee, donc les tests automatisés servent pas à grand chose. Validation manuelle par l’ingénieur développement qui fait le changement dans ce cas. En pratique, c’est souvent un scream test malheureusement, le changement est fait, ca compile et on attends que les mecs du marketing se plaignent.
La base données, elle est dans le backend, on parle de tests front end la. Le backend, il a ses propres tests, qui, eux, sont beauuuucoup plus simples à écrire en général. Et le plus souvent unitaire. Cela dit, la db a en général des tests d’intégrations, oui, mais c’est pas un problème super dur à résoudre tant que t’utilise pas oracle ou sqlserver. Une image docker, une bonne couche de colle, et ça roule. Et si ton front end parle à la db directement, y’a pas forcément de mal, ça peut faire du sens. Mais dans ce cas, je doute très fortement que le sujet des tests UI automatisés soit pertinent.
[^] # Re: Tests différents (ou partiels)
Posté par groumly . En réponse à la dépêche Arrêtons de (dé)tester nos applications web. Évalué à 2.
Non, le développeur écrit une batterie de test UI automatisés. Ce qui est, comme je le pointait au dessus, une tâche plutôt difficile, donc réservée à quelqu’un qui bouffe du code toute la journée (pas un qa).
Quand il a finit, l’ingénieur qa prend le relai et tente de casser la feature. Il rapporte des bugs, qui partent soit au produit, soit à l’ingé. Si ça part à l’ingé, il rajoute un/des test UI, corrige le bug, et ferme le ticket. Si ça part au mec produit, il change la spec et tu repart au début.
Ce que tu ne peux pas faire c’est dire "on a des UAT, et ils sont implémentés par l’ingénieur, donc on a pas besoin de faire une passe en profondeur manuelle". En pratique, ta passe manuelle en profondeur va doubler ou tripler le nombre d’uat, et probablement nécessiter des raffinements à la spec.
Ça va dépendre de la bibliothèque. Une migration à iOS n+1, on corrige tous les tests automatisés qui foirent (2-3 douzaines en général), et après on fait une passe de regression manuelle sur toute l’appli. On revérifie pas chaque feature a 100%, mais on s’assure de toucher chaque feature, et on passe un peu plus de temps sur les flows les plus importants.
Une bibliothèque plus technique/pas user facing (genre le tracking marketing, ou le client http) va typiquement être mockee, donc les tests automatisés servent pas à grand chose. Validation manuelle par l’ingénieur développement qui fait le changement dans ce cas. En pratique, c’est souvent un scream test malheureusement, le changement est fait, ca compile et on attends que les mecs du marketing se plaignent.
La base données, elle est dans le backend, on parle de tests front end la. Le backend, il a ses propres tests, qui, eux, sont beauuuucoup plus simples à écrire en général. Et le plus souvent unitaire. Cela dit, la db a en général des tests d’intégrations, oui, mais c’est pas un problème super dur à résoudre tant que t’utilise pas oracle ou sqlserver. Une image docker, une bonne couche de colle, et ça roule. Et si ton front end parle à la db directement, y’a pas forcément de mal, ça peut faire du sens. Mais dans ce cas, je doute très fortement que le sujet des tests UI automatisés soit pertinent.