Jeudi 9 février 2012 4 09 /02 /Fév /2012 15:27

Cet article n'a rien à voir avec l'écologie, mais beaucoup avec l'environnement.

Lorsque l'on teste un projet web, il faut toujours savoir "où" nous testons : est-on sur un serveur de test ? de développement ? de pré-prod ? de production ?

 

Lorsque vous êtes en pleine création d'un projet, il est intéressant de définir clairement, le plus tôt possible, les différents environnements et leurs stratégies de tests respectives.
L'intégration continue sera d'autant plus simple que vous aurez défini clairement les règles du jeu.

 

Environnements pour un projet web

 

  • Environnement de pré-prod : ce serveur doit être stable, mis à jour très régulièrement, comporter toutes les nouveautés. 
  • Environnement de développement : utilisé par tous les développeurs, il peut être soit centralisé, soit individuel (avec des machines virtuelles).
  • Environnement de prod : c'est le serveur qui sera utilisé par vos utilisateurs/clients. Il doit être choyé, aux petits oignons.

 

 


Comment organiser le travail (du point de vue de la qualité)


  • Les développeurs codent sur le serveur de dév.
  • Les tests unitaires (côté php ou js) sont aussi jouer sur le serveur de développement.
  • L'environnement de préprod est posé en tant que référent : il est mis à jour régulièrement, avec des versions stables. Pour contrôler sa mise à jour, un outil d'intégration continu (nous utilisons hudson) qui rejoue tous les tests unitaires de tous les sous projets.

 



Comment organiser les tests fonctionnels


  • Pour les tests manuels, en fonction du test, il faut le faire sur l'un des environnements. Il est parfois utile de le faire sur chaque environnement, afin de pouvoir dire "ce bug particulier n'existe pas encore en prod, mais il est apparut sur la pré prod".
  • L'environnement de prod peut être utilisé pour vérifier la présence d'un bug, mais ne devrait pas être utilisé pour des tests automatiques.
  • Pour les tests automatiques, il y a 2 écoles.
    • Lancer sur la version de pré-prod. Défaut principal : il n'est pas toujours évident de créer des tests fonctionnels avant de voir la fonction tourner réellement. Chaque nouvelle fonctionnalité aura donc ses tests ajoutés dans les jours qui suivront, et pas avant.
    • Faire lancer les tests par les développeurs en environnement de développement. C'est plus coûteux à mettre en place (il faut par exemple former tous les développeurs à l'analyse du rapport de tests...), mais cela peut améliorer la détection des bugs.


Pour moi, ces deux écoles ne s'excluent pas. Je les vois plutôt comme des étapes. C'est d'ailleurs le cas dans ma société : lors de la refonte du projet, il a été décidé que les tests fonctionnels automatiques devront pouvoir s'exécuter partout (y compris la prod). Pour l'instant, ils peuvent être exécuter sur la pré prod, avec une configuration prévue théoriquement pour qu'ils puissent être exécuter sur d'autres environnements. (La gestion de profils de cucumber est parfaite pour ça)

 


Pourquoi est-il essentiel de connaître les environnements ?

 


Il m'arrive régulièrement de tester un bug sur un onglet, de faire autre chose, et de revenir dans mon onglet pour avoir d'autres informations au sujet des bugs. Et là, miracle, le bug est résolu. Pourtant, personne n'a modifié le code. Un enquête de quelques minutes permet de comprendre que le bug n'existe que dans un environnement particulier, et que j'ai changé d'onglet par inadvertance.      

 

 

Cela peut avoir des conséquences plus grave. Pour un projet personnel, j'héberge un forum "privé". J'ai l'habitude de "stocker" ce forum sur mes sites successifs, dans un sous-domaine, et de faire suivre aux utilisateurs la nouvelle adresse, voire de mettre en place une redirection.
En novembre dernier, j'ai lancé un déménagement. (La qualité de service de mon hébergeur devenait déplorable avec un uptime passant parfois sous les 90%)

  • Je verrouille l'accès en écriture sur l'ancien
  • Je déplace la totalité des fichiers d'un serveur à un autre, tranquillement.
  • Je copie la base de données.
  • Je teste avec quelques utilisateurs le nouveau.
  • Fin de l'opération.

Jusqu'à ce matin, lorsque j'ai vu un message d'erreur "Can't connect to MySQL server on anciendomaine.com". J'ai mal lu le message, et n'ai pas fait attention, et j'ai attendu quelques minutes, pensant à une maintenance sur mon hébergeur. Puis j'ai fini par réaliser que sur mon nouveau domaine, opérationnel depuis 4 mois, la base de données utilisée était toujours l'ancienne. Du coup, nouvelle copie des bases de données, modification du fichier config.php qui contenait les données pour la base, et voilà, tout est rentré dans l'ordre.

Si mon ancien domaine (et sa base) avait expiré avant que je m'en rende compte, j'aurais perdu une partie de l'historique. Pour un petit forum privé, cela n'aurait pas été trop grave. Mais pour un projet plus important, cela aurait pu provoquer des catastrophes.


Publié dans : Généralités - Ecrire un commentaire - Voir les 0 commentaires
Jeudi 12 janvier 2012 4 12 /01 /Jan /2012 21:32

 

Un responsable qualité doit analyser les messages reçus par le biais du service de contact du site, afin de voir ce que pensent les utilisateurs de votre service. Outre la détection de bugs que vos tests auraient laissé passer, cela vous permet de savoir quelles questions reviennent souvent, afin de savoir où et comment améliorer l'ergonomie.

Cet article est la suite de : Histoire d'en rire : les mails au support utilisateur (4)

 

 

Retour de vacances


 

Au début de l?été, je vais devoir confirmer ou infirmer ma position. Dans tous les cas cette prise de décision ne sera pas neutre. Je peux déjà sentir les effets du travail prestement mené en ce début d?année. Et je n?ose imaginer la conclusion en cas de poursuite du projet à son terme. La maîtrise de la qualité de son image est primordiale. Il faut savoir entrevoir le chemin du bon sens. La mise en place d?un blog semble le choix de la lucidité pour tout responsable d?entreprise, dans un marché en pleine mutation ou les accords se font et se défont encore plus rapidement.

 

 

Une aiguille dans une meule de foin

 

j'ai oublié mon nom de compte, mon mot de passe est cachou pouvez-vous me le dire merci

 

 

Problème de mot de passe

 

Après un long échange de mail avec une personne, nous avons reçu ce mail: 

 

Après enquete, son mot de passe est: ●●●●●●●●● 

 

Copier / coller un mot de passe n'est pas une si bonne idée que cela finalement.

 

 

Problème de validation

 

Suite à un problème de validation, quelques échanges de mails, cet utilisateur peu calé a accepté toutes les manipulations qu'on lui proposait. Au final, il a trouvé une autre solution.

 

Excusez moi pour le dérangement... Je crois que mon problème venait d'une touche de mon clavier
Cordialement
J.Claude

 

 

Inconnu au bataillon

 

Bonjour Stéphane,
Merci pour ce conseil, je ne l'oublierai pas. C'est donc réparé.
Bonne journée,

 

Mais il n'y a pas de Stéphane dans l'équipe. (Ni de stéphanie, etc..) Si quelqu'un répond à notre place sans nous prévenir, ca fait un mail de moins à traiter.

Ecrire un commentaire - Voir les 0 commentaires
Mercredi 4 janvier 2012 3 04 /01 /Jan /2012 20:28

Contexte 

 

La société pour laquelle je travaille est en train de refaire son principal projet depuis le début. Au programme : changement de technologies. Nous lancerons ce nouveau projet d’ici l’été, et nous travaillons déjà depuis quelques mois sur le sujet.

 

Nous avons mis en avant la qualité, avec de l’intégration continue (Hudson, allié à Git), des TDD (Test driven development), des framework robustes : Symfony pour le php, YUI pour le javascript, des tests fonctionnels avec cucumber et watir… Et pour organiser tout ça, on passe à Scrum.

 

Beaucoup de changements, et les premiers tests sur le serveur de staging nous ont tous donné envie d’aller encore plus loin.

 

 

Action

 

Mais tout n’est pas rose dans notre monde : le serveur de staging n’était pas assez stable à mon goût. J’ai donc envoyé un mail à tous mes collègues concernés afin de mettre au clair la façon de travailler :

  • Pas de mise à jour en milieu de journée (le staging est mis à jour chaque nuit avec les dernières versions stables des sous projets).
  • Tests en amont, côté serveur de développement.
  • Incitation à me consulter pour la mise en place des tests fonctionnels que j’aurais pu oublier.

Et bien évidemment, j’ai précisé dans le mail que j’étais ouvert à toutes les suggestions.

 

L'union fait la force

 

Réactions

 

Nous avions longuement rabâché qu’il fallait un produit de qualité, que nous devions tous tester le produit de façon à ne rien laisser passer.

En envoyant le mail, je ne m’attendais pas aux retours que j’ai eu. Je savais que certains point “techniques” ne feraient pas l’unanimité. Mais mes collègues ont été très intéressés, et m’ont montré qu’ils pensaient toujours “qualité”. L’équipe a échangé pas mal de mail dans l’après-midi (cela faisait quelques semaines que je n’avais pas vu autant d’échange de mails sur un même sujet en aussi peu de temps). Des idées sont venus des développeurs, qui rejoignaient certaines idées d’améliorations que nous envisagions à moyen terme.

 

Tout cela pour dire qu’au final, la qualité d’un projet web, c’est aussi une histoire d’équipe : une équipe soudée, motivée peut faire de grandes choses dans le bon sens si on lui en donne l’opportunité.

Publié dans : Généralités - Ecrire un commentaire - Voir les 0 commentaires

Présentation

  • : Blog pour raconter ma vie professionnelle. Beaucoup d'outils de tests, de détails sur des bugs, mais également des articles plus génériques sur la façon de s'organiser.
  • Contact

Twitter

twitterboutonpg3.jpg

Créer un blog gratuit sur over-blog.com - Contact - C.G.U. - Rémunération en droits d'auteur - Signaler un abus - Articles les plus commentés