Project Website | Online Demo | Forum |
It is currently Wed May 24, 2017 1:38 pm

All times are UTC + 1 hour [ DST ]





Post new topic Reply to topic  [ 3 posts ] 
  Print view Previous topic | Next topic 
Author Message
 Post subject: Modul-Entwicklungs-Workflow
PostPosted: Mon Feb 19, 2007 11:47 pm 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
Ich hatte folgendes schon mal per Email vorgeschlagen, würde das dann umsetzen wollen, wenn es keine Gegenstimmen / Verbesserungen gibt:

Hi,

ich hatte grad eine echt gute Einführung in einen Software / Entwicklungs Test-/Doku-/QA Workflow.
Hat bei mir ein paar Ideen provoziert, die ich gern kurz umreissen möchte und zur Diskussion stellen will. Wenn du Zeit hattest es durchzuarbeiten, ruf mich kurz an, dann geben wir es an die Community.

Meiner Meinung nach haben wir im Moment einen Deadlock: Du verlangst, dass andere Testen. Das macht zeitmässig Sinn. Es macht inhaltlich Sinn (der Tester MUSS jemand anderes sein). Ein Recht drauf hast du auch, klar. Nur weiss im Moment niemand, was getestet werden soll bzw. es gibt einfach keine Basis, auf der man testen kann im Moment. Du schreibst ein Modul (oder Sepp usw) mit einem Zielmodul im Kopf. Dann verlangst du von einem Dritten der (gottseisgepiffeunngetrommelt) nicht in deinen Kopf gucken kann, dass er testet, ob Deine Ideen umgesetzt wurden. Er (oder ich) kann es bestenfalls gegen sein Verständnis dessen, was er von dir verstanden hat testen. Konflikt vorprogrammiert.

Merke: Ich kritisiere hier nicht dich oder jemanden persönlich, sondern den implizit von uns installierten Prozess.

Also hier mein Vorschlag zum Thema "BADGER Quality Assurance Ablauf":

1. Ziel
Zielsetzung dieser Ideen soll sein, hochqualitativen Code zu generieren und insbesondere sinnvoll getesteten Code zu releasen. Testen soll möglich gemacht werden. Andere Rollen ausser die des Entwicklers sollen möglich gemacht werden, dadurch kann dann theoretisch jeder testen. Ausserdem soll testen gleichzeitig gewissenhaft und effektiv sein.

2. Preis
Das kostet uns was, und zwar erstmal Mühe und Zeit. Doku muss (rückwirkend) erstellt werden und Grips investiert. Für kommende Module und Funktionen sollte das nicht so ein großer Akt sein, wenn es erstmal drin ist, was zu tun ist. Für die bestehende Codebase und Module wirds schon n Stück Arbeit. Wenn das nachgezogen ist, geht es. Ansonsten ist der Preis, sich an Prozess und Doku zu halten.

3. Leistung
Dafür erreichen wir dann die Ziele oben.

4. Was muss getan werden?

a) Rollen

Von nun an gibts im Entwicklungs-Workflow folgende Rollen:

1. Sponsor
Der Sponsor hat die Idee für ein Modul oder eine Funktionalität.

2. Analyst
Der Analyst setzt die Idee des Sponsors in definierte Funktionalität um.

3. Entwickler
Der Entwickler setzt die Anforderungen des Analysten um.

3. Tester
Der Tester testet, ob das Produkt des Entwicklers die Anforderungen des Analysten erfüllt.

Selbstverständlich kann eine Person mehrere Rollen erfüllen (und das wird wahrscheinlich die Regel sein). Es ist aber wichtig, dass man die Rollen und die damit verbundenen Tätigkeiten logisch trennt. Sollte also derselbe analysieren und entwickeln, so ist es in diesem System gedacht, dass Analyse und Entwicklung getrennt durchgeführt werden. Das wird u.a. durch die im folgenden beschriebene Dokumentation sichergestellt.

b) Zu erstellende Dokumentation

1. Zieldefinition.
Autor: Sponsor
Medium: Eintrag als Feature Request im Flyspray
Umfang: Ein Absatz
Inhalt: Klare Zieldefinition: Welche Funktionalitäten soll das neu zu erstellende Modul erfüllen?
Beispiel: Es soll ein neues Modul mit dem Titel "Kontaktverwaltung" erstellt werden, welches es erlaubt, ein Adressbuch in BADGER zu führen. Das Modul sollte Schnittstellen zu allen anderen wichtigen Modulen bereitstellen.

2. Funktionsumfang
Autor: Analyst
Medium: OO Calc Spreadsheet
Umfang: Nach Anforderung.
Inhalt: Eine Funktionalität pro Zeile Spreadsheet. Laufende Nr, Titel, Beschreibung als Use Case.
Beispiel: 18, Eintrag eines Kontakts, Der Benutzer klickt auf "Eintrag neu erstellen" und gelangt zu einer Maske, welche die Informationen .... abfragt. Mit einem Klick auf den Button "Speichern" wird der Eintrag vorgenommen.

3. Code und Code-Doku gemäß bestehenden und bekannten Standards
Autor: Entwickler

4. Test-Doku
Autor: Tester
Medium: OO Cald Spreadsheet
Umfang: Nach Anforderung
Inhalt: Ein Testfall pro Zeile. Testfälle ergeben sich aus den Use Cases gemäß Funktionsumfang



c) QA-Workflow
1. Sponsor hat Idee für ein neues Modul, eröffnet Feature Request im Flyspray
2. Analyst leitet aus der Definition klare Funktionalitäten ab
2a. Ggf. Feedback zwischen Sponsor und Analyst
2b. Analyst hängt Funktionalitäten an Feature Request an.
3. Der Entwickler realisiert das Modul gemäß den Spezifikationen in "Funktionalitäten". Änderungen / Hinzufügungen (!) sind mit dem Analysten zu besprechen und in "Funktionalitäten" zu dokumentieren.
4. Der Entwickler führt Entwicklertests durch. Diese Tests sind technischer Natur und fallen in den Verantwortungsbereich des Entwicklers (?)
5. Der Entwickler erklärt sein Modul für technisch fertig und gibt es erst dann zum Testen frei. Zu diesem Zeitpunkt ist die Entwicklung abgeschlossen. Es wird nicht mehr entwickelt.
6. Ein Tester erklärt sich bereit, das Modul gegen die Anforderungen zu testen. Er assigned sich selbst das Modul per Flyspray.
7. Der Tester führt die Use Cases gemäß "Funktionalitäten" auf den ihm zur Verfügung stehenden Plattformen durch und vermerkt das Ergebnis im Spreadsheet.
8. Möglichkeit A: Das Modul entspricht nicht allen Anforderungen oder hat gewichtige Funktionalitäten, die nicht in den Funktionalitäten stehen --> Doku an Entwickler, Verbessern
8. Möglichkeit B: Das Modul entspricht allen Anforderungen auf den getesteten Plattformen, aber nicht alle Plattformen wurden getestet --> Doku ins Flyspray, dass andere Tester dran können
8. Möglichkeit C: Das Modul entspricht auf allen Plattformen allen Anforderungen. --> Modul fertig, release Status.
Das Modul wird erst veröffentlicht wenn
a) es auf allen als relevant definierten Plattformen
b) alle technischen Tests des Entwicklers und
c) alle funktionalen Anforderungen des Analysten (durch Tester verifiziert)
d) im Rahmen gängiger Usability-Standards und BADGER-Standards erfüllt.

(Grob als Grafik:)



Daraus würden sich folgende Todos ergeben:
1. Plattformdefinitionen für Tester (Liste der relevanten OS/Browser Kombinationen) Sepp, Niko
2. Liste aller bestehenden Module, Sponsor-Definition für bestehende Module, Funktionalitäten-Definitionen für Module. Holger (?)
2a) Übersichts-Sheet: Module und ihr jeweiliger Status. (Holger)


Module haben dabei immer den niedrigsten Status, d.h. unsere Module sind im Moment alle auf 1.

3. Standard-Technik-Tests für alle Module anwendbar. (Niko Backend, Sepp Frontend)
4. Alle bestehenden Module, die auf "release" stehen nach oben angegebenem Workflow testen, verbessern, releasen
5. Alle Module, die "Work in progress" sind finalisieren
6. Alle Module die auf "requires testing" stehen testen (vorher: doku erstellen).


Image

Image

Image

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Mar 11, 2007 12:03 pm 
Offline
Site Admin
User avatar

Joined: Tue Mar 07, 2006 7:34 pm
Posts: 331
Ich hab das mal in einen Wiki-Artikel übernommen: http://community.badger-finance.org/wik ... nt_Process

_________________
BADGER finance lead backend developer and site admin


Top
 Profile  
 
 Post subject:
PostPosted: Sun Mar 11, 2007 1:56 pm 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
danke!

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron




Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Style supported by CodeMiles Team.