Devops for Growth
107.5K views | +9 today
Follow
Devops for Growth
For Product Owners/Product Managers and Scrum Teams: Growth Hacking, Devops, Agile, Lean for IT, Lean Startup, customer centric, software quality...
Curated by Mickael Ruau
Your new post is loading...
Your new post is loading...

Popular Tags

Current selected tag: 'plan de test'. Clear
Scooped by Mickael Ruau
Scoop.it!

Qualification de logiciel.

L'élaboration d'une stratégie de test logiciel. La stratégie est le résultat d'une part de principes généraux avec des objets et des niveaux de tests impliquant des critères d'acceptation et d'autre part du projet avec des livrables impliquant une analyse du risque. La gestion de configuration. La démarche de test. La mise en œuvre.
Mickael Ruau's insight:

 

1. L'élaboration d'une stratégie de test logiciel.

 

2. La gestion de configuration.

 

3. La démarche de test.

 

4. La mise en oeuvre.

 

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Agile: JIRA Agile bulk upload of (Epic, stories, tasks) using Excel / CSV format

Agile: JIRA Agile bulk upload of (Epic, stories, tasks) using Excel / CSV format | Devops for Growth | Scoop.it

Objective: Reduce the pain of keying in every individual items of the Agile project plan which we usually do it in a Excel file & key in them to JIRA for monitoring & tracking.

Mickael Ruau's insight:

Each cell comments are explained below the image for your reference.

Issue Type:  Cell value for each row could be either of these (Epic, Story, Sub-task) and this is mandatory field.

Epic Name:  Applicable only for Issue type "Epic", provide Epic Name (could be same as what you have planned for Summary field).  It is mandatory field, keep it short & single line.


Summary:  Cell value can be either of these (Task name / User story Name / epic Name) .  Keep it short, it is mandatory & single line


Description:  Cell value can be either (Task / Epic / User story) Description with Acceptance criteria as shown in example.


Story Point: Applicable only for issue type "Stories" , values are 1,2,3,5,8,13 ( I have stopped till 13, anything above this we tell the team to break the user story much smaller)


Original Estimate:  Applicable for Issue type “Tasks”, value to be provided in seconds (3600s = 1 hour). for ex: if you want to mention 2 hours than just multiply it with 3600 = 7200, in case of 15 minutes it would be(=.15*3600).


Remaining Estimate: Value as same as Original estimate column.


Assignee: Resource name planned for (epics / user stories / Tasks). Provide only valid user account name's (team members got to be created beforehand) . Optional


Issue ID:  Any unique no., used along with Parent ID column for Parent child relationship between user stories, sub-task. Mandatory


Parent ID:  Used along with Issue Id column, most of the time when tasks got to be associated with stories in these case. Mandatory


Epic link: Applicable only to issue type “User stories” .Values should be Epic Name as is to which this story is to be associated. Mandatory


Status:  Value should be “To Do”, else the JIRA puts in default value.

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

Organiser des tests dans un projet

Objectif d’un plan de test

L’activité de planification est productrice d’idées et d’organisation. Elle exige une grande imagination, car elle nécessite de formaliser des processus qui sont en général menés de manière intuitive.

 

Le plan de test recense les objectifs et les moyens pour réaliser les tests. Il permet l’organisation technique des tests, il planifie leur déroulement dans le temps et définit les points de repère, en particulier les conditions d’arrêt. Il sert aussi de document de validation de la qualité finale du logiciel et fait partie des documents contractuels du projet, au même titre que les spécifications techniques ou les besoins fonctionnels. Il est conçu par le responsable des tests et validé par le chef de projet.

Mickael Ruau's insight:

Structure d’un plan de test

 

Introduction

L’introduction présente les informations générales du plan :

 

   Présentation de l’application

   Contexte de réalisation

   Choix technologiques

   Coordonnées du responsable des tests

 

Projet à tester

Il s'agit ici de décrire précisément le projet

 

   Liste des module et/ou des lots

   Date de livraison

 

Documents joints

   Documents généraux

   Documents techniques

   Documentation

 

Environnement de test

Ce paragraphe présentera une description la plus précise possible des plate-formes, en indiquant si elles sont représentative des plates formes utilisateurs.

 

   Sites de test

   Configurations matérielles

   Outils de test

   Bases de test

   Données de test

   Coordonnées de l’administrateurs de la bases de données

   Coordonnées du responsable du parc micro

 

Tests à réaliser

   Listes des modules à tester

   Objectif des tests

   Exigences

   Analyse du risque

   Matrice Exigences/Risques pour définir les priorités

   Jeux d’essais

   Estimation de la charge

 

Stratégie de tests

On décrira dans ce paragraphe la démarche mise en œuvre pour réaliser les tests

 

   Description de l’approche générale

   Phase de tests

   Champagne de test

   Ordre d’exécution des tests

 

Condition d’arrêt

   Critères retenus et pourquoi

 

Gestion des fiches d’anomalies

   Modèles des fiches d’anomalie

   Actions et états

   Gestion des flux

   Liste des intervenants

 

Ressources humaines

   Nom et responsabilité

   Informations utiles

 

Planning des tests

   Planning

   Acteurs

 

No comment yet.
Scooped by Mickael Ruau
Scoop.it!

3.05 - Import requirement(s) - Wiki Squash TM

3.05 - Import requirement(s) - Wiki Squash TM | Devops for Growth | Scoop.it

The Import function allows you to upload requirements into a selected project. The imported file must be in .xls, .xlsx or .xlsm format. Different rules must be followed and are detailed below.

No comment yet.