Ein kleines Gedankenspiel in 8 Teilen

  1. Haben Sie schon einmal Software entwickelt, die erst nach der Installation beim Kunden durch unangenehme Fehler aufgefallen ist?
    Was wäre wenn sie direkt vom Start an wissen, dass ihr Produkt getestet ist und sie guten Gewissens pünktlich ausliefern können?

  2. Haben Sie schon einmal die Arbeit eines ganzen Tages verloren, weil ihre Entwickler keine Quellcodeverwaltung einsetzen?
    Was wäre wenn es total egal wäre, ob sie ihre Quellcodes von heute mittag, heute morgen oder von letzter Woche wiederhaben wollen und einfach auf einen Knopf drücken könnten?

  3. Haben Sie schon einmal lange und erfolglos nach passender Software für ihr Geschäft gesucht?
    Was wäre wenn sie auf meine lange Erfahrung zurückgreifen und ich sie bei der Entscheidungsfindung unterstütze?

  4. Haben Sie schon einmal wichtige Daten auf dem Notebook eines Mitarbeiters verloren, nur weil diese in einer unverschlüsselten Datei abgelegt worden sind?
    Was wäre wenn sie eine Datenbank haben, um solche Geschäftsdaten zentral immer zur Verfügung zu haben, die dennoch ein hohes Maß an Sicherheit bietet?

  5. Haben Sie schon einmal 10 Kollegen nacheinander angerufen, um herauszufinden, wer denn nun die richtigen Daten liefern kann?
    Was wäre wenn sie einfach in einem System nachschauen könnten, ohne andere von der Arbeit abzuhalten und so Geld zu verlieren?

  6. Haben Sie schon einmal Wochen auf ein Angebot ihrer Inhouse-IT gewartet, nur um festzustellen, dass diese ihre Anforderungen nicht versteht?
    Was wäre wenn sie einfach mal bei mir anfragen, ob es nicht eine ganz simple Lösung für ihr IT-Problem gibt?

  7. Haben Sie schon einmal vor einem Programm gesessen und sich gefragt, warum man aus Kostengründen immer die ineffiziente Lösung wählen muss, die dann versagt, wenn es wichtig ist?
    Was wäre wenn man einfach die Software einsetzt, die das Problem am besten löst und dadurch die Kosten senkt?

  8. Haben Sie schon einmal darüber nachgedacht, warum ihre Softwareeinführungen so unglaublich hohe Trainingskosten verursachen?
    Was wäre wenn die Anwender sich im Programm selbst zurechtfinden, da die Arbeitsschritte an erprobte Prozesse angelehnt sind?

Wirklich alles nur ein Gedankenspiel? Am besten, Sie finden es selbst heraus.

SAP CRM Teil 2 – Topliste der Notizen an mich selbst

In meinem letzten Artikel habe ich meine Erfahrungen in einem Einführungsprojekt zu SAP CRM beschrieben. Inzwischen ist die Testphase abgeschlossen, die User-Trainings starten und ich kann ein kleines Zwischenfazit ziehen, bevor im Oktober der GoLive erfolgt.

Zur Erinnerung: Bei der Einführung eines SAP CRM für einen weltweit agierenden Kunden übernehme bin ich an der Migration der Altdaten beteiligt, implementiere die Groupware-Integration auf Lotus Notes-Seite und berate bei den Tests. Die Implementierung des SAP CRM übernimmt eine externe Firma, der Support wird inhouse durch den Kunden bedient.

Statt den Ablauf komplett wiederzugeben, will ich kurz meine Top 8 der Notizen an mich selbst wiedergeben:

  1. Ein Bugtracker ist nur so gut, wie seine Konfiguration – Notiz an mich selbst: im Projekt immer darauf achten, dass ich Mitspracherecht dabei habe.
  2. Die Anzahl offener issues sagt nichts über deren Arbeitsaufwand aus – Notiz an mich selbst: lernen, dies dem Kunden immer wieder deutlich zu machen.
  3. Die Kommunikation zwischen Anwender und Entwickler sollte nie ohne Wörterbuch erfolgen – Notiz an mich selbst: ich bin kein schlechtes Wörterbuch
  4. Wenn Anwender und Entwickler direkt miteinander reden, ist dies um den Faktor 10.000 effektiver, als per mail/chat/bugtracker/… – Notiz an mich selbst: darauf achten, dass ich persönlich erreichbar bin.
  5. Ein unbekannter Zeitplan ist kein Zeitplan – Notiz an mich selbst: auch wenn der Projektleiter gut bezahlt ist, darf man ihn darauf hinweisen, dass sich die User unterinformiert fühlen.
  6. Wechselnde “Besatzung” zwischen Testphase ist kein gutes Zeichen – Notiz an mich selbst: dafür sorgen, dass meine Tester gut informiert sind und Testen als positive Arbeitszeit gesehen wird.
  7. Pausen sind großartig, wenn man echte Infos erhalten will. Nur so kommt man informell an die wichtigen Informationen und Stimmungsbilder – Notiz an mich selbst: Genug Pausen vorsehen, um mit Anwendern ins Gespräch zu kommen.
  8. Süßkram hebt die Stimmung – Notiz an mich selbst: das Experiment, Gummitiere mitzubringen, war erfolgreich.

Kundenprojekt: Einführung SAP CRM

Eines meiner aktuellen Kundenprojekte ist die weltweite Einführung eines SAP CRM Systems für mehrere hundert User, das die alte Lösung in Lotus Notes ablösen soll. Das Projekt läuft inzwischen ein gutes Jahr, das Konzept wurde mit allen Einheiten des Unternehmens abgestimmt und die Implementierung nähert sich dem Ende.

Mein Anteil am Projekt ist die Migration der Altdaten, die Anbindung von Lotus Notes als Groupware an das CRM sowie die Begleitung der Tests als Berater. Wir befinden uns derzeit mitten in der Testphase und ich will ein paar Einblicke liefern, wie nah wir uns an Standards wie ISTQB halten, und wo wir weit davon weg sind.

Das Team

Für die Organisation der Tests war ein kleines Team von 8 Personen zuständig, das aus einem guten Mix aus Prozesskennern, externen Implementierern und interner IT bestand. Unterschiedliches Wissen konnte so genutzt werden und auch später bei den Tests eingesetzt werden.

Phase 1 – Testkonzeption

Die Tests sind in mehrere Phasen eingeteilt; zuerst natürlich die Konzeption der Tests. Hierzu haben wir in einem kleinen Team die Testfälle für die unterschiedlichen Anwendungsbereiche (Accounts, Aktivitäten, Angebote, …) entwickelt, indem wir uns nah am Konzept entlang gearbeitet haben (also die Doku als Testorakel verwendet haben). Das klappte in vielen Bereichen erstaunlich gut, obwohl wir zu Beginn dieser Phase noch keinen Zugriff auf das System hatten. Sobald dieser möglich war, haben wir die noch sehr theoretischen Tests noch einmal genauer spezifiziert. Größtenteils waren die Testfälle sehr genau vorgegeben, da die meisten der späteren Testuser das System noch überhaupt nicht kennen und auch ohne Dokumentation auskommen müssen (letztere soll erst noch erstellt werden). Die Testfälle wurden ziemlich profan in themenorientierte Excel-Listen unterteilt, um ein paar Auswertungsspalten ergänzt und später ausgedruckt verteilt.

Phase 2 – interne Tests

Als nächsten Schritt haben wir im gleichen kleinen Kreis innerhalb von ca. 2 Wochen die Testfälle komplett durchgetestet, um die gröbsten Fehler direkt intern zu entdecken und eine Chance zu haben, vor den Usertests diese schon zu beheben. Für das Tracking der Bugs wurde ab hier Bugzilla eingesetzt. Meiner Ansicht nach ein brauchbares Programm, dessen Oberfläche und Bedienung aber eher an die Anfangszeiten der Browsertools erinnert. Aber es erfüllt seinen Zweck zuverlässig, war beim Kunden verfügbar und wurde auch schon für andere Projekte genutzt.

Phase 3 – erste Testrunde mit Anwendern

Für die ersten beiden Juniwochen stand die erste Testrunde mit Anwendern an. Für jede Unternehmenseinheit waren 1-3 Tester anwesend, die teilweise schon die Konzeption begleitet hatten, teils auch neu dabei waren. Wir starteten also mit unterschiedlichsten Wissenständen. Die Workshops wurden in 2 Gruppen durchgeführt, die sich unterschiedliche Themengebiete so vornahmen, dass in zwei Wochen je zwei Workshops zu einem Thema durchgeführt wurden und jedes Team jedes Thema einmal bearbeiten konnte.

Die Tage begannen mit einer kurzen Einführung in das System, die Erklärung des Testmodus (über die spezifizierten Testfälle) und einem Intro für ein effektives Fehlerreporting. Nach den üblichen Startschwierigkeiten waren die Tester erstaunlich motiviert bei der Sache, kaum jemand lies sich durch seine Tagesjobs ablenken. Aus meiner Sicht zeigt dies deutlich, dass eine solche frühe Beteiligung Spaß machen kann. Über den Tag kamen reichlich Fehler und Verbesserungsvorschläge zusammen, die Abends kurz im Team besprochen wurden. Es stellte sich beispielsweise sehr schnell heraus, dass die sehr genaue Spezifikation der Testfälle dazu führte, dass sich kein Anwender verloren vorkam, aber dennoch durch die gute Unterstützung jeder die Freiheit bekam, alle Aspekte des Systems ausprobieren zu können.

Phase 4 – Korrekturen und Anpassung

Nach den zwei Wochen Anwendertests waren reichlich Änderungsvorschläge und Fehler aufgelaufen, insgesamt um die 1000 Einträge. Die eingegangenen Punkte wurden von den jeweils zuständigen Teammitgliedern durchgesehen, Duplikate beseitigt, Rückfragen gestellt und ansonsten direkt den Entwicklern zugewiesen. Alle Einträge, für die es Klärungsbedarf gab, wurden in 2 Meetings komplett durchgesprochen und es wurde entschieden, wie und ob umgesetzt wird.

Für die Änderungen im Programm waren nur knappe zwei Wochen vorgesehen, die jetzt dem Ende entgegengehen. Laut Bugzilla ist die Quote der noch offenen Punkte bei unter 10%. Aus meiner Sicht bedeutet dies, dass die Priorisierung der Punkte sehr gut gelaufen ist, man viele Erweiterungspunkte auf eine spätere Version verschieben konnte und viele kleinere Probleme aufgetreten sind, die beseitigt werden konnten.

Phase 5 – zweite Testrunde mit Anwendern

Für die zweite Testrunde mit den Anwendern ist das gleiche Schema wie für Runde 1 vorgesehen, d.h. in zwei Wochen werden wieder in kleineren Gruppen jeweils einzelne Themengebiete durchgearbeitet. Diesmal ist es essentiell, dass die Anwender ihre eingekippten Punkte nachtesten und prüfen, ob diese zur Zufriedenheit beseitigt sind. Ich bin gespannt, wie gut dieses Verfahren klappt.

Phase 6 – letzte Korrekturen

Danach ist nur eine kurze Woche für die hoffentlich letzten Korrekturen vorgesehen, die dann in Phase 7 mündet.

Phase 7 – Abnahmetests

In der letzten Phase werden wir noch einmal gemeinsam alle offenen Punkte durchsehen und dann zusammen mit den Anwendern entscheiden, ob eine Produktivsetzung wie geplant stattfinden kann.

Fazit

Mein bisheriges Fazit fällt recht positiv aus. Für ein Projekt dieser Größenordnung und einer sehr hohen Diversität der Unternehmenseinheiten ist der Test sehr glatt gelaufen. Man hat einiges an offenen Punkten gefunden, aber durch die offene Kommunikation und frühe Einbindung der Anwender ist die Zufriedenheit derzeit sehr hoch.

Obwohl nicht explizit gefordert, konnte mir das ISTQB-Wissen an einige Stellen extrem weiterhelfen. Gerade bei der Konzeption der Tests konnte man gut auf Äquivalenzklassenbildung, Grenzwertanalyse und Zustandstests zurückgreifen. Auch die Zusammenstellung des Testteams hat durch den interdisziplinären Mix sehr viel zum Gelingen beigetragen. Gerade auch bei der Begleitung der User war es wichtig, sowohl IT-Fachleute dabei zuhaben, als auch Mitarbeiter, die im Geschäft des Kunden erfahren waren.

Als Testwerkzeuge für die Anwendertests kamen ausschließlich Bugzilla sowie Microsoft Excel zum Einsatz, wobei die Entwickler natürlich ihre jeweils speziellen Tools wie SOAPUI für Interfaces o.ä. verwendet haben. Hier hätte ich mir allerdings im Vorfeld noch mehr Struktur und Einflussnahme gewünscht, gerade die Statusverwaltung bei Bugzilla war zu kompliziert und vor allem falsch organisiert (bspw. “Resolved” als Status für Nachtests statt “Verified”). Hier lies sich leider durch zentrale Vorgaben zu wenig ändern.

Ich denke, nach der hoffentlich positiven Abnahme kann ich hier noch einmal mehr schreiben.

Ab sofort teste ich mit ISTQB-Zertifikat

Softwaretests sind wichtig, das sieht jeder ein. Dennoch wird in vielen Unternehmen das Thema eher stiefmütterlich behandelt, oft auch, weil die notwendigen Ressourcen fehlen, oder das Fachwissen nicht ausreichend vorhanden ist.

Hier kann ich Abhilfe schaffen, indem ich als externer Tester für Sie zur Verfügung stehe. Dabei kann ich den kompletten Softwarelebenszyklus von der Spezifikation über die Implementierung bis hin zum Abnahmetest beim Endkunden begleiten und mit Rat und Tat zur Seite stehen; seit heute auch als zertifizierter Tester nach den Richtlinien des ISTQB, dem International Software Testing Qualifications Board.

Fragen Sie einfach unverbindlich an, wir finden eine Lösung, die Ihre Bedürfnisse abdecken kann.

Wie schreibt man den perfekten Bug-Report

Fehlerberichte oder Bug-Reports sind für viele ein Mysterium. Der Anwender macht sich die Mühe und schreibt eine Info an den Entwickler und wundert sich, warum nichts passiert, oder er nur Rückfragen bekommt. Der Entwickler wiederum erhält einen Fehlerbericht und versteht nicht, wo das Problem liegt und lässt es somit liegen. Vielen nicht-Programmierern ist einfach nicht klar, woraus ein Fehlerbericht bestehen muss, damit er schnell und zuverlässig bearbeitet werden kann.
Da ich dies in fast jedem Projekt einmal ansprechen muss, hier einmal die schriftliche Fassung zum Nachschlagen. Das Konzept greift für jede Programmiersprache, jedes Programm, praktisch jedes Softwareprojekt. Es ist egal, mit welchem Tool die Reports eingereicht werden (es kann auch eine einfache Email sein), die Grundbausteine sind immer gleich.

Die Basics

Wenn man dem Entwickler wirklich helfen will (und damit die Chancen drastisch erhöht, dass das Problem schnell bearbeitet wird), dann versucht man es erneut und merkt sich ganz genau die Schritte. Perfekt ist, wenn man Fehlermeldungen einfach durch einen Screenshot abfotografiert, dann geht keine Information verloren und der Entwickler sieht den Kontext. Dann kann man seinen Fehlerfall formulieren:

Ein aussagekräftiger Betreff

Der Problemempfänger wird zuerst nur den Betreff sehen und man kann davon ausgehen, dass schon danach gefiltert wird. Erfahrungsgemäß wird zuerst das bearbeitet, was man schnell versteht. Daher schon im Betreff darauf achten, dass

1) Das Fehlverhalten beschrieben wird und

2) Zeitpunkt und Ort des Auftretens erwähnt wird.

Schlecht: “Problem”

Gut: “Login zu Anwendung X funktioniert Montags nicht”

Zeitpunkt und User

Eine Information, die immer angegeben werden sollte, ist der Zeitpunkt (Datum + Uhrzeit) des Problems sowie der Anwender, bei dem es auftritt. Vielleicht läuft zur gegebenen Uhrzeit ein Backup und daher ist die Anwendung langsam, oder bestimmte Anwender haben andere Berechtigungen und sehen daher einige Eingabefelder nicht.

Eine Schritt-für-Schritt-Beschreibung

Ein Entwickler ist kein Anwender, weiß nicht, wie der Nutzer das Programm bedient und kann nicht raten, wie es zu einem Fehler kam. Daher immer darauf achten, dass der Kontext mitgegeben wird. Dies geschieht am einfachsten durch einen Schritt-für-Schritt-Beschreibung. Weiterhin kann man auf diese Art sehr gut prüfen, ob der Fehler immer auftritt, oder nur sporadisch.

Schlecht: “Ich bekomme manchmal bei der Anmeldung eine Fehlermeldung”

Gut: “Wenn man sich Montags in Anwendung X anmelden will, erscheint die Fehlermeldung blablabla. Ich habe User + Passwort in die korrekten Felder eingetragen und auf ‘login’ geklickt. An anderen Wochentagen klappt es.

Screenshots

Wenn man die Möglichkeit hat, vom Fehlerzustand einen Screenshot anzufertigen, dann sollte man dies tun. Dabei sollte man beachten, dass man möglichst den kompletten Bildschirm abfotografiert und keine Auswahl trifft. Vielleicht sieht der Entwickler im Hintergrund noch etwas wichtiges, das man selbst nicht beachtet hat. Auf jeden Fall aber hilft ein kompletter Screenshot bei der Einordnung im Kontext und der Entwickler muss nicht suchen, wo im Programm das gezeigte Bild auftritt.

Schlecht: Nur einen kleinen Bildschirmausschnitt als Suchbild abfotografieren

Gut: Den kompletten Bildschirm abfotografieren. Damit erkennt man sofort, wo im Programm der Anwender sich befindet, was er sieht, wie hoch seine Bildschirmauflösung ist etc.

Tipp: Tools wie Monosnap können den Screenshot sogar mit Anmerkungen versehen.

Eine realistische Einschätzung der Dringlichkeit

Wenn man die obigen Punkte beachtet, dann hat man bereits sehr gute Chancen, dass das Problem zügig bearbeitet wird. Wenn man es jetzt noch schafft, eine realistische Einschätzung der Dringlichkeit des Problems zu formulieren, dann steigen die Chancen noch weiter (sogar, wenn die Dringlichkeit gering ist). Man kann sich sicher sein, dass sich ein Entwickler merkt, wo die guten und wo die schlechten Fehlerbeschreibungen herkommen. Genauso wird er sich merken, wer Dringlichkeit gut einschätzen kann und sich nicht übermäßig wichtig nimmt.

Schlecht: “DRINGEND !!!” (am besten als alleinigen Betreff, die Anzahl der Ausrufezeichen multipliziert die Dringlichkeit der Aussage)

Gut: “Login zu Anwendung X funktioniert Montags nicht – Erstellen von Rechnungen nicht möglich”

Hinweis für die Techniker

Die bisher genannten Angaben sind ein Muss und sollten in einem Fehlerbericht immer auftauchen. Je mehr Felder ich in einem Fehlerbericht freischalte, je mehr ich von einem Anwender an Entscheidungen verlange, je tiefer ich nach IT-Wissen versuche zu grabe, desto fehlerhafter wird mein Bericht werden und desto unwilliger die Anwender, diesen einzureichen. Also lieber Softwareentwickler, Tester, Projektmanager – beschränkt euch aufs Wesentliche.

Softwarequalität durch Kundentests

Es gibt viele Name dafür: Bananensoftware (weil sie beim Kunden reift), TdK-Software (Test durch Kunde), Alpha-release; man kann die Liste lange fortsetzen. Im Grunde wird ein Hauptproblem der Softwareentwicklung beschrieben: mangelnde Qualitätssicherung führt zu ausgelieferten Programmen, deren Fehler erst durch den Kunden entdeckt werden, oder deren Funktionalität einfach nicht zur Problemstellung passt.

Darf der Kunde also immer nur perfekte Software erhalten?

Für im Echtbetrieb eingesetzte Software gilt die Aussage in jedem Fall. Ein System, welches wie auch immer produktiv genutzt wird, sollte fehlerfrei sein, da sind wir uns einig.

Wenn es sich allerdings um Software handelt, die sich noch im Entwicklungsprozess befindet, kann man diesen Vorsatz oft außen vor lassen. Klar sollten die offensichtlichen Fehler bereits durch den Softwareentwickler und seine Test-Kollegen beseitigt worden sein, aber wenn es um inhaltliche oder Bedienerfragen geht, muss keine Perfektion erreicht sein. Ganz im Gegenteil habe ich bereits sehr gute Erfahrungen damit gemacht, den Kunden so früh wie möglich an “seinem” Produkt teilhaben zu lassen. Wenn man sich als Entwickler nicht monatelang in sein stilles Kämmerlein zurückzieht, sondern den Kontakt mit dem Kunden sucht, ihn oft nach seiner Meinung fragt, dann wird am Ende ein besseres Produkt entstehen. Und wenn ich diese Meinung oft haben will, dann muss ich als Entwickler den Mut haben, auch einmal ein unfertiges Produkt zu präsentieren. Wenn eine Demo nicht ganz perfekt durchläuft, auch mal etwas nicht so funktioniert, wie es sollte, und dafür beim nächsten Termin korrigiert ist, wird der Prozess der Softwareentwicklung deutlich.

Und genau dieser Prozess muss deutlich werden, es muss gezeigt werden, dass Softwareentwicklung ein Handwerk ist, bei dem Mitarbeit gefordert ist. Ohne die Integration des Kunden und seiner Mitarbeiter kann man noch so gut designen, das Endprodukt wird nicht richtig zufriedenstellen. Die beste Software habe ich entwickelt, wenn sich die Endanwender ganz früh beteiligen durften und sahen, wie ihre Tests Auswirkungen auf das fertige Produkt haben. Man nutzt hier aus, dass viele Menschen “etwas bewegen wollen”, auch wenn es nur Kleinigkeiten sind. Die Motivation steigt ungemein, wenn das eigene Wort Gehör findet.

Probieren Sie es als Entwickler: bringen Sie Software früh zum Kunden. Probieren Sie es als Kunde: lassen Sie ihre Anwender früh mit neuen Systemen “spielen”. Die Softwarequalität wird steigen.

SourceControl mit Mercurial für Singles

Bei meinem aktuellen Job bin ich in einer Umgebung gelandet, in der für die Softwareentwicklung keine Quellcodeverwaltung eingesetzt wird – sozusagen der Albtraum eines professionellen Softwareentwicklers.

Um nicht ganz ohne die gewohnten Features wie Versionshistorie und Backup dazustehen, habe ich mir kurzentschlossen ein eigenes Mini-System aufgesetzt, das mir alle notwendigen Features bietet, ohne dass ich erst groß Überzeugungsarbeit bei der IT leisten muss, mir doch bitte einen Server aufzusetzen.
Zur Verfügung habe ich ein Notebook mit lokalen Admin-Rechten und ein persönliches Netzlaufwerk, letzteres wird angeblich sogar gesichert.
Die Wahl fiel hierbei auf Mercurial, ein verteiltes Quellcodeverwaltungssystem, das einfach aufzusetzen und zu bedienen ist und vor allem ohne zentralen Server auskommt. Und so geht’s:

Installation

1) Download der notwendigen Software von der offiziellen Seite http://mercurial.selenic.com/, am besten nicht den “Download now”-Button verwenden, sondern sich die ganze Liste anzeigen lassen. Da gibt’s auch Installer, die ohne Admin-Rechte auskommen

2) Die weiter, weiter, weiter-Installation ausführen. Ist absolut deppensicher. Danach hat man sowohl den Kommandozeilenclient als auch (unter Windows) TortoiseHG installiert.

3) Für den Kommandozeilenclient empfehle ich, sich dieses PDF-Cheat-Sheet zu ziehen, das alle wichtigen Kommandos übersichtlich zusammenfasst.

Verwendung

Für das Beispiel nehme ich an, dass mein Quellcode lokal unter c:\krempel\ liegt, und ich als x:\ ein Netzlaufwerk zur Verfügung habe.

1) Zuerst wird im vorhandenen Verzeichnis c:\krempel\ ein Repository erzeugt. Dazu eine Kommandozeile öffnen und in das Verzeichnis wechseln. Dort wird die Initialisierung gestartet:

hg init

2) Falls schon Quellcodedateien vorhanden sind, diese als allererste Version hinzufügen und
einchecken:

hg addremove
hg commit -u <username>

Das zweite Kommando öffnet ein Notepad-Fenster, in das man einen Eincheckkommentar eingeben kann. Nach save&close ist das Checkin erledigt. <username> ersetzt man beispielsweise durch den Namen, mit dem man sich eh am Rechner angemeldet hat.

3) Führt man jetzt eine Änderung durch, kann man mit

hg status

anzeigen lassen, was sich alles geändert hat. Will man die Änderungen einchecken, wird erneut ein

hg commit -u <username>

ausgeführt

4) Jetzt haben wir schon 2 Versionen unseres Programms im Repository.

hg log

listet alle Versionen, zwischen denen man hin- und herhüpfen kann. In der ersten Zeile jedes Blocks wird mit ‘changeset’ die Nummer des sets geliefert (die Zahl vor dem Doppelpunkt, danach kommt ein langer Identifier).

5) Hat man nun das Bedürfnis, zwischen verschiedenen Versionen zu wechseln, beispielsweise um eine Änderung rückgängig zu machen, reicht ein

hg update <changesetnummer>

um zu einer älteren Version zurückzukehren.

hg update tip

Führt immer zur aktuellsten Version, die im Repository vorhanden ist.
Soweit so gut, jetzt habe ich auf meinem lokalen Rechner erst einmal eine funktionierende Quellcodeverwaltung. Fehlt nur noch ein Backup auf einem Netzlaufwerk, in meinem Fall ist dies als x:\ eingebunden.

6) Zuerst einmal auf das Netzlaufwerk wechseln und dort ein neues Repository einrichten

hg init projektsicherung

Legt ein neues Verzeichnis namens ‘projektsicherung’ an und initialisiert es direkt als neues Repository.

7) Jetzt noch die Dateien aus dem lokalen Repository in das Netzlaufwerk übertragen:

hg pull c:\krempel\

Dieses Kommando zieht das lokale Repository ins Netz. Man kann die gleiche Aktion auch umgekehrt erreichen, indem man unter c:\krempel\ folgendes Kommando ausführt:

hg push x:\projektsicherung\

8) Wenn man mag, kann man noch den Dateistand des Netzlaufwerks auf die aktuelle Version bringen, indem man auf dem Netzlaufwerk

hg update tip

ausführt. Für die reine Sicherung ist dies aber nicht notwendig.

Damit hat man die absolute Minimalistenlösung einer leidlich sicheren Quellcodeverwaltung aufgesetzt. Wer sich für mehr Details interessiert, dem empfehle ich das erstklassige Tutorial http://hginit.com/ von Joel Spolsky. Dort gibt es auch ein super Video, wenn man mal eine Argumentationshilfe bei Kollegen oder Vorgesetzten braucht.

Die Änderungshistorie im Mantis Bugtracker aktivieren

Für die systematische Erfassung, Bearbeitung und Erledigung von Bugs und Features ist in vielen Soft- und Hardwareprojekten das Open Source Tool Mantis eine gute Wahl. Kostenlos und auf der typischen Linux, Apache, MySQL, PHP (LAMP) – Umgebung beheimatet, ist die Software ein guter Startpunkt für einen verbesserten Entwicklungsprozess.

Leider gibt es ein paar Funktionen, die etwas versteckt zu konfigurieren sind und daher trotz hohem Nutzwert selten verwendet werden. Das Changelog (oder auch Änderungshistorie genannt) ist so ein Kandidat. Zwar ist der Eintrag oben im Menü zu sehen, beim Anklicken bleibt er aber auf vielen System einfach weiß – es wird einfach keine Liste der letzten Programmänderungen generiert. Wünschenswert wäre dies natürlich, da man seine Kunden so viel einfacher auf dem laufenden halten könnte. Einfach die Liste ziehen und beispielsweise als Dokument in der aktuellen Programmversion mit ausliefern.

Ich habe daher einmal eine kurze Schritt-für-Schritt-Anleitung zusammengebaut, die zeigen soll, wie man das Changelog aktiviert. Ich verwende die englische Benutzeroberfläche, aber auch mit einer übersetzten UI sollte man die Punkte auffinden können.

Zuerst muss dem Projekt eine (oder mehrere) Version hinzugefügt werden, der dann später die erledigten Vorfälle zugewiesen werden. Dazu navigieren wir über “Manage > Manage projects” in die Projektliste und klicken dort das Projekt an.

Projektliste

Ziemlich in der Mitte der Projektseite findet sich der Bereich “Versions”. Hier muss mindestens eine Programmversion eingefügt werden. Diese Versionskennung wird später im Changelog mit angezeigt, so dass man Änderungen einer bestimmten Version zuordnen kann. Klick man beim Erstellen der Version direkt “Add and Edit Version” an, dann kann man noch eine Bemerkung eingeben und kennzeichnen, ob die Version schon veröffentlicht wurde.

Versionen

Das Projekt ist nun soweit vorbereitet und wie können uns der Verwendung widmen, wie ordnet man einen Vorfall der Version zu? Der Trick ist die “Advanced”-Ansicht, in der Standardansicht sind die notwendigen Felder nämlich leider nicht zu sehen. Wenn man einen Vorfall öffnet, kann man rechts oben mit “View Advanced” auf diese Ansicht umschalten:

Advanced

Wem es zu nervig ist, dies für jeden Fall einzeln zu machen, der setzt sich unter “My Account > Preferences” direkt die beiden Checkboxen “Advanced View” und “Advanced Update”. Auf jeden Fall taucht nun im Bearbeitungsdialog das Feld “Fixed in Version” (nicht verwechseln mit den anderen Versionsfeldern) mit der Liste aller Versionen des Projektes auf. Wenn ein Vorfall nun bearbeitet und erledigt wird, dann kann man hier wählen, unter welcher Version er in der Änderungshistorie auftaucht.

Bearbeitung

Ganz wichtig ist folgende Einschränkung: Ein Fall taucht nur dann in der Historie auf wenn…

  • “Fixed in Version” eingetragen ist
  • Der “Status” mindestens “resolved” ist
  • Die “Resolution” “fixed” ist

Ist dies alles erfüllt, dann kann über den Menüpunkt “Changelog” endlich die ganze Versionshistorie aufgerufen werden.

Changelog

Waidner IT Solutions