Rash thoughts about .NET, C#, F# and Dynamics NAV.

Die Ferengi-Erwerbsregeln aus StarTrek haben viel mit Marketing und Verkauf zu tun, aber man kann auch einige nicht ganz ernst gemeinte “Lehren” für die Software-Entwicklung ableiten:

Regel 15: Sich dumm zu stellen ist oft klug.

In der Software-Entwicklung wird oft mit einer “BlackBox” gearbeitet, dass heißt man verzichtet absichtlich auf Informationen über die Implementierungsdetails einer Funktionaltität und vertraut darauf, dass die Funktion einfach das macht was drauf steht. 

Regel 17: Ein Vertrag ist ein Vertrag ist ein Vertrag.

Eine wichtiger Ansatz aus der Software-Entwicklung ist das ContractFirst-Design. Dabei wird besonders bei verteilten Lösungen darauf geachtet, dass Verträge in den Mittelpunkt gerückt werden. Insbesondere bei der WCF spielen DataContracts eine entscheidene Rolle.

Passend dazu: Slim Fit "Ein Vertrag..."
	Ferengi Erwerbsregel 17. » 16.90 EUR Weitere Produkte gibt es im Shop.

Regel 32: Paß auf, was Du verkaufst; es könnte genau das tun, was der Kunde erwartet.

Wäre das nicht toll, wenn man das mal schafft und die Kunden komplett zu frieden stellt?

Regel 38: Kostenlose Werbung ist preisgünstig.

Jedes Produkt muss irgendwann an den Kunden gebracht werden – Werbung spielt natürlich eine entscheidene Rolle dabei. 

Regel 39: Lob ist billig; verteile es großzügig auf deine Kunden.

Gerade im Support kommt es darauf an die Kunden bei Lernerfolgen auch mal zu loben und für weitere Schritte zu motivieren.  

Regel 53: Verkaufe erst, frag später.

Diese oberste Regel des Vertriebs stellt die Entwickler oftmals vor arge Probleme. Würde der Vertrieb sie jedoch nicht befolgen, dann gäbe es oft kein Projekt.

Regel 57: Gute Kunden sind fast so rar wie Latinum; ehre sie!

Wenn man erstmal gute Kunden gefunden hat, die auch als Referenzen dienen und nicht wegen Kleinigkeiten ständig auf die Barrikaden gehen, sollte man sich die natürlich warm halten.

Regel 80: Wenn es arbeitet, verkaufe es. Wenn es gut arbeitet verkaufe es teurer. Wenn es nicht arbeitet, vervierfache den Preis und verkaufe es als Antiquität.

Kein Kommentar. 😉

Regel 116: Es gibt immer eine Alternative.

Für kaum ein Entwicklungsproblem gibt es DIE Lösung – die Suche nach Alternativen lohnt sich immer. 

Regel 122: Wenn der Kunde geht, geht auch der Profit.

Auch wenn es mal Probleme mit einigen Kunden gibt – man sollte immer daran denken, dass sie einem den Arbeitsplatz finanzieren.

Passend dazu: Slim Fit "Profit"
	Für die Ferengi unter Euch. » 15.90 EUR Weitere Produkte gibt es im Shop.

Regel 132: Je begehrter das Produkt, desto teurer wird es.

Ganz wichtig: Gute Software verkauft sich besser als schlechte.

Regel 146: Verkaufe das Brutzeln, nicht das Steak.

Oder als Abwandlung: “Verkaufe das Melken nicht die Kuh.” bzw. auch bekannt als “Gillette-Prinzip”. Wenn man es schafft Kunden mit wiederkehrenden Gebühren zu belegen statt mit Einmalbeträgen macht man den meisten Profit. Prominentestes Beispiel ist da World of Warcraft.

Regel 189: Vergiß einen Handschlag – vertrau auf Geschriebenes.

Man sollte sich nie darauf einlassen wichtige Absprachen zum Beispiel nur telefonisch zu treffen. Man sollte immer ein Protokoll unterschreiben lassen. Das erspart viel Ärger.

Regel 241: Unterschätze niemals die Bedeutung des ersten Eindrucks.

Diese Regel ist besonders bei Oberflächen zu beachten.

Eine sehr ausführliche Liste der Ferengi-Erwerbsregeln ist übrigens hier zu finden. 

Manuelle Tests

Das Testen von Software war schon immer eine der wichtigsten und auch unbeliebtesten Aufgaben beim Software-Entwicklungsprozess. Generell gibt es viele unterschiedliche Arten des Testens. Im herkömmlichen Verfahren wurde meistens während der Entwicklung mit dem Debugger und Tracing-Ausgaben gearbeitet und im Anschluss vor dem Release ein umfangreicher manueller Test des kompletten Systems durchgeführt. Aber damit ist es ja bekanntlich noch lange nicht getan, denn der Entwicklungsprozess ist mit der Fertigstellung von Programmteilen längst nicht beendet. Änderungen am Programmcode, z.B. für Updates oder neue Features können unabsehbare Auswirkungen auf bereits getestete Programmteile haben. Die Folge ist, dass der komplette Test vor jedem neuen Release wiederholt werden muss. Da dies natürliche gewaltige Kosten verursacht wurden schon früh automatisierte Tests eingesetzt, die genau auf die Stellen aufmerksam machen, bei denen nun Fehlfunktionen auftreten. Beispiel für solche Test-Systeme sind JUnit (Java) oder auch NUnit (.NET), was in abgewandelter Form nun sogar in das neue Visual Studio 2005 integriert wurde. Doch was genau verbirgt sich hinter dem Unittesting?

Beim Unittesting (Unit = Einheit, Bauteil) wird die Funktion eines atomaren Teils des Systems (z.B. einer Berechnungsfunktion) isoliert von allen anderen getestet und validiert. Unittests können prinzipiell als Whitebox- und Blackbox-Tests betrieben werden. In der Regel wird jedoch der Entwickler im besten Fall schon vor der Entwicklung der Funktionalität die Testfälle anlegen. Nach jeder größeren Quellcode-Änderung sollte dann durch Ablaufen lassen aller Testfälle die Fehlerfreiheit überprüft werden.

Automatisiert und wiederholbar Testen durch Unit-Tests

Ein Unit-Test prüft in der Regel immer nur einen sehr kleinen und autarken Teil des Software-Systems – wie beispielsweise eine einzelne Funktion. Dabei wird bei jedem Test die zu testende Funktion oder Methode mit Testdaten (Parametern) konfrontiert und deren Reaktion auf diese Testdaten geprüft. Die zu erwartenden Ausgabewerte werden nun mit den von der jeweiligen Funktion oder Methode gelieferten Ergebnisdaten verglichen (Assertions). Stimmt das erwartete Ergebnis mit dem gelieferten Ergebnis der Funktion oder Methode überein, so gilt der Test als bestanden.

Ein TestRun besteht im Allgemeinen aus einer ganzen Reihe von Testfällen, die nicht nur ein Parameter-Ergebnis-Paar prüfen, sondern gleich mehrere.

Unittest mit Navision

Auch für Microsoft Navision Entwickler sollten UnitTests zum täglichen Programmieralltag gehören. Bisher gab es jedoch kein Testframework für Navision, so dass wir uns bei der msu solutions GmbH (Microsoft Certified Partner) entschlossen haben ein eigenes zu entwickeln. Die Einsatzmöglichkeiten des Navision-UnitTest-Frameworks möchte ich hier vorstellen.

Leistungsmerkmale:

• Labeln von Testgruppen und Testläufen:
  UnitTest.LabelTestRun(‘This run has to succeed’);
• Einfache Funktionstest mit definierten Vergleich:
  UnitTest.IntAssert( 4/2 ,2, ‘Is 4/2 = 2?’);
• Unterstützt erwartete Exceptions:
  UnitTest.AssumeError(‘Test 3 Error’);
• Komplette Assertions über Feldinhalte, Recods bis zu ganzen Tabellen:
  UnitTest.TableAssertion(TableID);

Testauswahl-Formular

• Auswahl der zu testenden Testgruppen
• Import/Export von Fehlertextbausteinen

Unittest-Viewer

• Anzeige des Testprotokolls
• Anzeige, welche Methoden fehlerfrei abliefen und wo Fehler auftraten