Zuverlässiges Automatisiertes Testen im eigenem Software-Unternehmen aufsetzen - How to?

Zrebna

Bekanntes Mitglied
Hallo!

Basierend auf meinem ersten Thread zum Thema "Testen" https://www.java-forum.org/thema/au...-und-komplexen-prozessen.202884/#post-1357563,

möchte ich in diesem Thread noch einmal einen Schritt zurückgehen und aus der "Vogelperspektive" erörtern, was man denn in einem Unternehmen alles benötigt, um zuverlässig automatisiert testen zu können?

Wenn ihr einen Software-Startup hättet, das allmählich größer wird (mehr Kunden) und endlich auch automatisiertes zuverlässiges Testen haben will, wie würdet ihr vorgehen, um dies zu realisiere? Was brauchen wir alles?

Content und Inspirationen in diesem Thread werden letztlich einer Abschlussarbeit dienen und daher ist jeder Input dankend erwünscht.

Lg
Zrebna
 

White_Fox

Top Contributor
Wenn ihr einen Software-Startup hättet, das allmählich größer wird (mehr Kunden) und endlich auch automatisiertes zuverlässiges Testen haben will, wie würdet ihr vorgehen, um dies zu realisiere?
Die Tests erst dann haben zu wollen wenn man mehr Kunden hat ist – nur aus meiner Sicht, ich bin ja kein Programmierer ;) – der erste Fehler.

Wenn es an Ressourcen fehlt, würde ich eher das Produkt abspecken und Funktionen nach und nach hinzufügen, aber Tests, Code Review und dergleichen von Anfang an mit einplanen.

Man baut unweigerlich nach und nach Mist, das ist kaum zu vermeiden. Ob es daran liegt daß man schlechte Leute hat die irgendeinen Stuß zusammenhauen, oder gute Leute hat die dennoch aneinander vorbeiarbeiten, sei mal dahingestellt. Man kann aber sehr gut vermeiden daß man den angehäuften Mist erst sieht, wenn er als riesengroßer Haufen nicht mehr zu übersehen ist, da ist es besser wenn einem der Mist sofort auf den Fuß fällt, dafür aber noch im Krümelstadium.
Fehler am Anfang zu reparieren ist meistens leicht, aber wenn man Fehler erst spät findet und nach der Reparatur andere Dinge nicht mehr funktionieren weil man auf den Fehlern aufgebaut hat, dann wird es lustig.

Die Idee, alles geradezuziehen wenn mehr Geld reinkommt, wird wahrscheinlich nicht funktionieren. Mehr Kunden bedeuten nämlich auch mehr an neuen Auf- und Ausgaben wie Kundensupport, Vertrieb, usw, da fällt die Entwicklung wieder hinten runter. Und was mit mehr Kunden auch noch ansteigt: Anforderungen, neue Funktionen, usw. Wenn ihr Tests nicht von Anfang an mit einplant, macht ihr sie mit hoher Wahrscheinlichkeit nie. Ging ja schließlich bisher auch ohne.

Wie gesagt, ich bin kein Softwerker, ich komme aus der Elektronikentwicklung, aber aus Projektleitungssicht ähnelt sich da alles sehr, zumindest in einigen Aspekten.
 

mihe7

Top Contributor
Es gibt ja sehr viele verschiedene Aspekte, die sich testen lassen. Daher wäre natürlich die erste Frage, worum es bei den Tests eigentlich gehen soll. Selbst die klassischen Unit-/Integrationstest werden nicht nur zum Test der Funktionalität eingesetzt. Je nach Ansatz kann das sogar nur Nebensache sein und es stehen die Dokumentation, das Design und/oder die Wartbarkeit des Codes im Vordergrund.

Daher stelle ich mal die provokante Gegenfrage: was und warum willst Du denn überhaupt testen?
 

Zrebna

Bekanntes Mitglied
Die Tests erst dann haben zu wollen wenn man mehr Kunden hat ist – nur aus meiner Sicht, ich bin ja kein Programmierer ;) – der erste Fehler.

Wenn es an Ressourcen fehlt, würde ich eher das Produkt abspecken und Funktionen nach und nach hinzufügen, aber Tests, Code Review und dergleichen von Anfang an mit einplanen.

Man baut unweigerlich nach und nach Mist, das ist kaum zu vermeiden. Ob es daran liegt daß man schlechte Leute hat die irgendeinen Stuß zusammenhauen, oder gute Leute hat die dennoch aneinander vorbeiarbeiten, sei mal dahingestellt. Man kann aber sehr gut vermeiden daß man den angehäuften Mist erst sieht, wenn er als riesengroßer Haufen nicht mehr zu übersehen ist, da ist es besser wenn einem der Mist sofort auf den Fuß fällt, dafür aber noch im Krümelstadium.
Fehler am Anfang zu reparieren ist meistens leicht, aber wenn man Fehler erst spät findet und nach der Reparatur andere Dinge nicht mehr funktionieren weil man auf den Fehlern aufgebaut hat, dann wird es lustig.

Die Idee, alles geradezuziehen wenn mehr Geld reinkommt, wird wahrscheinlich nicht funktionieren. Mehr Kunden bedeuten nämlich auch mehr an neuen Auf- und Ausgaben wie Kundensupport, Vertrieb, usw, da fällt die Entwicklung wieder hinten runter. Und was mit mehr Kunden auch noch ansteigt: Anforderungen, neue Funktionen, usw. Wenn ihr Tests nicht von Anfang an mit einplant, macht ihr sie mit hoher Wahrscheinlichkeit nie. Ging ja schließlich bisher auch ohne.

Wie gesagt, ich bin kein Softwerker, ich komme aus der Elektronikentwicklung, aber aus Projektleitungssicht ähnelt sich da alles sehr, zumindest in einigen Aspekten.

Ich formuliere um:

Wenn ihr einen Software-Startup hättet und von Beginn an automatisiertes zuverlässiges Testen haben wollt, wie würdet ihr vorgehen, um dies zu realisieren?
 

Zrebna

Bekanntes Mitglied
Es gibt ja sehr viele verschiedene Aspekte, die sich testen lassen. Daher wäre natürlich die erste Frage, worum es bei den Tests eigentlich gehen soll. Selbst die klassischen Unit-/Integrationstest werden nicht nur zum Test der Funktionalität eingesetzt. Je nach Ansatz kann das sogar nur Nebensache sein und es stehen die Dokumentation, das Design und/oder die Wartbarkeit des Codes im Vordergrund.

Daher stelle ich mal die provokante Gegenfrage: was und warum willst Du denn überhaupt testen?

Gute Frage.

Also erstmal zu dem "Was":

Generell sollen größere business use case Prozesse getestet werden, wie z.B. Prozesse bzgl. Rezertifizierungen von digitalen Entitäten (z.B. Berechtigungen oder Geschäftsrollen).
Bei so einem Prozess gibt es viele Teilaufgaben, wie z.B.
  • Aufgaben/Requests zur Überprüfung von existierenden Mitarbeiter-Berechtigungen erstellen
  • Aufgaben über eine eingebaute Engine an Verantwortliche delegieren (z.B. an Abteilungsleiter des überprüften Mitarbeiters).
  • Aufgaben können dann angenommen (und bearbeitet), abgelehnt oder weitergeleitet werden.
  • Nach der Bearbeitung von Aufgaben, müssen Entscheidungen auditsicher festgehalten werden und ggf. Berechtigungsentzüge angestoßen werden.
  • uvm.
Auch andere größere Prozesse, wie Lebenszyklen von Rollen, aber auch Login-Prozesse und Datenimporte müssen zuverlässig testbar sein.

Zu dem "Warum":

Damit es seltener/gar nicht beim Kunden "knallt", weil man generell unzufriedene Kunden vermeiden will (gerade wenn die Software subscription-based "gemietet" werden kann), und somit bugs (speziell wenn kritische Bereiche beim Kunden knallen, wie z.B. bei Authentifizierungsprozessen oder auch Datenimporten) negative business impacts für das Start up haben können.

Ergänzungen an Alle:
Um einen einfacheren und konkreteren Kick-Start bzgl. dem Thema zu haben, hier mal paar konkrete hinführende Fragen:
Start up hat ca. 50-100 Mitarbeiter, von denen ungefähr die Hälfte Entwickler sind.

Mögliche Anfangs-Fragen für so ein SW-Start up (unerfahre bzgl. best practices und approaches rund um das automatisierte Testen zur Qualitätssicherung), das seine eigene business software entwickelt, wartet, weiterentwickelt und kommerziell vertreibt:

  • Brauchen wir professionelle Tester oder können das bei uns die Entwickler mitmachen?
  • Wollen wir Kataloge/Dokus über Test-requirements führen?
  • Macht es für uns Sinn Konferenzen zu besuchen, wo Unternehmen sharen, wie sie testen?
-> Was wären gute Konferenzen hierzu?
- Was brauchen wir alles, um bei uns professionell, zuverlässig und effizient automatisiert testen zu können?

Das Szenario ist fiktiv und soll einfach eine Einstiegsgrundlage darstellen, um sich austauschen zu können bzw. für mich, um von erfahrenen Entwicklern zu lernen.
 
Zuletzt bearbeitet:

LimDul

Top Contributor
Ein Punkt der gerne übersehen wird:
* Man braucht Mitarbeiter/Entwickler, die das wollen.

Egal von welchem Tool wir reden, ohne Entwickler die das auch wollen, bringt das nicht viel. Per "Order de Mufti" von oben einführen "Ihr müsst jetzt automatisiert testen, dafür haben wir Tool XY lizenziert" geht schnell in die Hose. Den wenn die Entwickler sich übergangen fühlen oder das Tool nicht ihren Anforderungen genügt, erfüllen sie zwar formal die Kennzahlen - aber reell erhöht sich die Qualität kaum.

Dementsprechend ist das A und O aus meiner Sicht die Leute, die damit arbeiten müssen, in den Entscheidungsprozess mit einzubeziehen und sich deren Vorschläge anzuhören.
 

KonradN

Super-Moderator
Mitarbeiter
Was brauchen wir alles, um bei uns professionell, zuverlässig und effizient automatisiert testen zu können?
Entwickler, die das wollen und umsetzen. http://clean-code-developer.de ist ein erster Einstieg. Clean Code ist bei Projekten existenziell, wenn man da eine Chance haben will, das auch wirklich weiter entwickeln zu können und die Wartung nicht unmöglich zu machen.

Und was dann alles benutzt wird, hängt natürlich von dem Projekt ab. Aber Unit Tests sind etwas, das einfach unabdingbar ist. Es gibt eine einfache Basis, an der nichts vorbei geht:
  • Versionierung der Sourcen
  • Unit Tests
  • Code Reviews

Und da kann dann das Entwicklerteam überlegen, welche Tools Sinn machen. Die sollten sich da auskennen. Wenn die sich nicht auskennen, dann sollte man da einfach mal überlegen, entsprechende Experten mit einzubinden. Entwickler sollten aber generell kommunikativ sein und von sich aus Kontakt zu anderen Entwicklern suchen um sich auszutauschen. Der Blick über den Tellerrand ist existenziell! Und dazu sind dann jede Art von Entwickler-Konferenz gut. Also z.B. JAX, wo die Entwickler hin fahren können und sich dann am Abend auch einmal austauschen können bei einem Bier.

Und bezüglich Tests ist auch wichtig: Das ist auch ein eigenständiges Gebiet. Siehe z.B. International Software Testing Qualifications Board (istqb.org)
 

White_Fox

Top Contributor
Ich formuliere um:

Wenn ihr einen Software-Startup hättet und von Beginn an automatisiertes zuverlässiges Testen haben wollt, wie würdet ihr vorgehen, um dies zu realisieren?

Ich bin ja, wie bereits gesagt, kein Softwareentwickler. Meine Profession ist eine andere, auch wenn ich selber ein kleines Javaprojekt habe (auch wenn da seit einem Jahr kaum was passiert ist, weil wenig Zeit).

Zunächst mal würde ich mir darüber Gedanken machen, was ihr wie intensiv testen wollt. So wichtig Tests auch sind, ändert das nichts daran daß ihr nur begrenzte Ressourcen habt, also verteilt sie sinnvoll. Ich habe in meinem Projekt z.B. ausschließlich Unit-Tests, keine Integrationstests oder dergleichen, und das reicht mir dort auch.

View-Elemente teste ich überhaupt nicht automatisiert. Das zu testen wäre sehr aufwendig, der Nutzen an dieser Stelle ist aber gering. Und wenn ich meine, daß ich den Button doch woanders haben will, muß ich gleich den Test anpassen. Dazu kommt, das an dieser Stelle Fehler sehr schnell auffallen, außerdem teste ich an dieser Stelle sehr viel während der Programmierung. Wohlgemerkt, wir reden hier ausschließlich über die Benutzeroberfläche, nicht über die Programmlogik oder dergleichen (das ist strikt getrennt), und da will ich auch gerne sofort sehen wie es aussieht.

Der ultimative Test für eine Benutzeroberfläche ist sowieso kein automatisierter Test, sondern der (noch) ahnungslose Benutzer, der da einfach ohne Vorinformation oder Schulung rangesetzt wird und eine Aufgabe umsetzen soll. Der zwar die Domäne kennt, aber für den deine Software komplett unbekannt ist. Lege eine Bestellung an, buche einen Artikel ein, füge einen neuen Kontakt hinzu, sowas in der Art. Und dann dem Tester über die Schulter gucken: findet er selbständig die Informationen die er braucht, oder muß er sich mühselig durch lauter Menüs klicken und findet er einfach keine Übersicht?

Das ist natürlich kein automatisierter Test, aber für deine Benutzeroberfläche der Härtetest schlechthin. Wer noch nie eine Benutzeroberfläche geschrieben hat mit der andere später arbeiten sollen, hat keine Vorstellung davon was andere damit anstellen. Ich habe mal ein Excelmakro für eine E-Installationsfirma geschrieben, mit diesem sollten die Bauleiter den Fortschritt ihrer Baustellen festhalten. Die Benutzer meines Excelprogramms waren zwar keine dummen Menschen, aber eben auch keine Akademiker. Das waren praktisch veranlagte Leute, für die das einfach funktionieren mußte und die Büroarbeit eher als lästige Nebenbeschäftigung empfanden.
Ich habe mir damals ein paar Zielstellungen selber auferlegt, unter anderem wollte ich die Benutzeroberfläche möglichst idiotensicher machen. Ich will nicht dauernd was erklären müssen, Schulungen sollten nicht notwendig sein, die Leute sollten damit auch noch arbeiten können wenn ich aus der Firma raus bin, usw. Das Ding sollte etwa so leicht zu bedienen sein wie ein Appleprodukt.
Und nicht zuletzt wollte ich ja, daß die Leute mein Program mögen und es nicht als Belastung empfinden. Das Programm an sich war sowieso schon redundant weil alles nochmal irgendwo anders schriftlich notiert werden mußte, ich wollte die Leute nicht noch zusätzlich täglich auf die Palme bringen.

Ich habe dann einfach mal jemanden, der damit später arbeiten sollte, an meinen ersten Entwurf rangesetzt, und der erste Testlauf war ein absolutes Fiasko für mich. Unter anderem war ich davon überrascht, wie flink Leute im Fehlermeldungen wegklicken sein können. Ich hatte da eine relativ lange Meldung drin die eigentlich nur kommen sollte, wenn der Benutzer Gefahr lief wirklich üblen Mist zu machen und dem Benutzer ein paar Dinge klarmachen. Diese Meldung kam weitaus schneller als ich hätte ahnen können, ich hab nichtmal den Mund aufgekriegt um etwas sagen zu können da hatte er schon auf OK geklickt, und stand hinterher im Wald und wußte nicht mehr raus. Damit war mein Testlauf auch schon zu Ende. Überrascht war ich auch, wie arglos manche Menschen auf irgendwelche Knöpfe klicken.

Freilich kann man dem Benutzer immer vorhalten, wieso man denn einfach Meldungen wegklickt, ohne sie zu lesen, aber letztendlich habe ich meine Zielstellung damit trotzdem verfehlt. Also habe ich mir nochmal über das ein oder andere Gedanken gemacht, Bedienkonzept umgestellt, usw. Nach dem dritten derartigen Testlauf war es dann perfekt, eine kurze Präsentation vor allen Kollegen mit Vorführung, damit sie es mal gesehen haben, und das wars.

Wie gesagt, kein automatisierter Test, aber dennoch ein Test, und meiner bescheidenen Meinung nach einer der wichtigsten. Denn deine Benutzeroberfläche ist maßgeblich dafür mitverantwortlich, ob deine Kunden gerne mit dem Programm arbeiten. Und eine idiotensichere Benutzeroberfläche zu bauen ist hohe Kunst. Jeder versteht die Struktur, die er selber entworfen hat, eine Struktur zu entwerfen die andere verstehen ist dagegen etwas ganz anderes.


Brauchen wir professionelle Tester oder können das bei uns die Entwickler mitmachen?
Grunsätzlich sollten Test und Testling von verschiedenen Menschen geschrieben werden. Mir blieb bei meinem Projekt nichts anderes übrig als Unittest und Klasse selber zu schreiben, aber grundsätzlich würde ich es nicht als Test ansehen, wenn ein Entwickler sein Werk selber testet.

Aber das allerwichtigste:
Ein Punkt der gerne übersehen wird:
* Man braucht Mitarbeiter/Entwickler, die das wollen.

Egal von welchem Tool wir reden, ohne Entwickler die das auch wollen, bringt das nicht viel. Per "Order de Mufti" von oben einführen "Ihr müsst jetzt automatisiert testen, dafür haben wir Tool XY lizenziert" geht schnell in die Hose. Den wenn die Entwickler sich übergangen fühlen oder das Tool nicht ihren Anforderungen genügt, erfüllen sie zwar formal die Kennzahlen - aber reell erhöht sich die Qualität kaum.
Kann man gar nicht unterschätzen. Nicht nur bei Tests, sondern auch bei so lustigen Dingen wie ISO 9001: Wenn die Prozesse nicht auch gelebt werden, bringen sie im besten Fall nix oder schaden oft sogar.
Wenn man gute Leute hat ist es auch durchaus sinnvoll, sie bei der Gestaltung solcher Prozesse wie Tests mit einzubeziehen. Wenn da ein paar Leute bereits Erfahrung mit einem Werkzeug haben und es auch gerne einsetzen, wird es oft auch gerne von den anderen Entwicklern angenommen. Vor allem, wenn ihr das Team erst aufbaut und noch keine alten Zöpfe gewachsen sind.

Genauso die Frage, ob Tests von Testern oder Entwicklern gemacht werden, das finde ich eigentlich weniger wichtig. Gut ist es, wenn sich die Leute das suchen können was ihnen liegt, manche Entwickler lieben auch schlicht etwas Abwechslung. Manche Leute haben auch einen gewissen Spaß daran, die Dinge anderer kaputtzutesten.
 

mihe7

Top Contributor
Generell sollen größere business use case Prozesse getestet werden, wie z.B. Prozesse bzgl. Rezertifizierungen von digitalen Entitäten (z.B. Berechtigungen oder Geschäftsrollen).
Sorry, ich habe mich nicht deutlich genug ausgedrückt. Es geht um Fragestellungen wie "Wenn ich dieses und jenes mache, erhalte ich dann das richtige Ergebnis?" oder "Sind die Antwortzeiten in Ordnung, wenn 100 Leute gleichzeitig daran arbeiten?" oder "Wie verhält sich das System, wenn man es überlastet?", "Wie sieht es mit der Sicherheit aus?" usw. Man kann sich also ganz unterschiedliche Aspekte ansehen.

In dem Zusammenhang stellt sich insbesondere im Hinblick auf die funktionalen Anforderungen ggf. folgende Situation dar: man hat Software, die bereits beim Kunden im Einsatz ist. Man weiß also, dass der Code funktioniert. Wenn ich dafür einen Test schreibe, dann bestätige ich letztlich nur, was ich sowieso schon weiß.

Hinzu kommt - je nachdem, wer den Code testet - noch die psychologische Komponente: mangelnde Motivation und ggf. auch der Hang dazu, sich selbst zu bestätigen. Außerdem ist der bestehende Code womöglich nur schwer testbar ist. Ggf. also nicht unbedingt optimale Voraussetzungen.

Das kann man als Chance sehen, den Code einem Refactoring zu unterziehen. Ist halt mit entsprechendem Aufwand (und mangels Tests auch einem gewissen Risiko) verbunden. Alternativ macht testet man nicht sofort, sondern baut Tests für neu aufgetretene Fehler ein.

Soweit nur mal ganz kurz mein Senf. Das Thema ist ja sehr, sehr umfangreich. Ich habe mangels Zeit auch die anderen Beiträge nicht gelesen, kann also sein, dass sich hier einiges wiederholt hat.
 

M.L.

Top Contributor
Generell sollte man beachten, dass die Software auf eine Art und Weise (oder in einem anderen -technischen- Kontext) verwendet werden kann, der von Tests (aller Art) gerade nicht beachtet (und damit auch nicht getestet) wurde. Sicherheitsrelevante Informationen sollte man (böswilligen) Angreifern übrigens nicht präsentieren.
 

LimDul

Top Contributor
Bezüglich der Frage, würde ich erst mal ein Schritt zurücktreten. Tester die testen sind der letzte Schritt - davor sind viele Schritte notwendig.

Um Business-Prozesse zu testen brauche ich Testfälle. In einem Testfall wird beschrieben, was zu testen ist und was das erwartete Ergebnis ist.
Wer schreibt die?
Um Testfälle zu schreiben brauche ich Wissen, wie die Business Funktionen im Detail funktionieren - eine Spezifikation.
Existiert die? Wer schreibt die?
Um Testfälle zu schreiben, brauche das Wissen, welchen Inhalt eine konkrete Softwareversion hat.
Wie wird die Software versioniert? Wie werden Changes nachgehalten?

Das heißt, wie schon @KonradN geschrieben hat, sollte man sich den ganzen Software-Entwicklungsprozess ansehen, schauen wo man Schmerzen hat (=Hier am besten die Entwickler einbeziehen, die wissen am besten, wo es weh tut) und dann an den Stellen justieren. Eine der Maßnahmen kann ein Test am Ende mit externen Testern sein. Aber das weiß man erst, wenn man sich angeschaut hat, wo die Probleme liegen.

Aus meiner Sicht ist der Ansatz falsch "Wir wollen testen" ist ungefähr so wie im Handwerk "Wir wollen einen Hammer verwenden". Beides sinnvoll - dumm nur, wenn man dauernd Schrauben schief reinschraubt. Dann hilft ein Hammer recht wenig :)

Testen ist Maßnahme. Eine Maßnahme führt man am sinnvollsten durch, wenn sie ein Problem löst. Was ist das Problem, was gerade hat, wo testen die beste Maßnahme ist? Die Sichtweise muss sein "Was für Probleme habe ich und wie kann ich die lösen". Und mit Sicherheit wird man dann auch irgendwann an Problemen vorbeikommen, die durch Fachtests gelöst werden - aber nicht unbedingt am Anfang.
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
Zrebna Automatisiertes Testen von größeren und komplexen Prozessen Allgemeine Java-Themen 56
L JUnit - automatisiertes vs. manuelles Testen? Allgemeine Java-Themen 6
T Nachtraegliches automatisiertes aendern von Funktionsaufrufen mit Eclipse??? Allgemeine Java-Themen 4
L Erste Schritte TDD testen einer Methode mit injezierten Services? Allgemeine Java-Themen 12
Z Testen ob neuer Tag beginnt Allgemeine Java-Themen 37
S Habt ihr eine Idee wie man Serializierung testen kann..? Allgemeine Java-Themen 6
B Eclipse WebSocket programmiert, kann es leider nicht testen. Allgemeine Java-Themen 15
H OOP Testen einer Exception mit JUnit Allgemeine Java-Themen 8
perlenfischer1984 TestNG - Enum testen Allgemeine Java-Themen 1
perlenfischer1984 Testng : Funktion mit mehreren Parametern testen Allgemeine Java-Themen 5
J Best Practice Testen von protected Methoden Allgemeine Java-Themen 7
F Testen von Methoden Allgemeine Java-Themen 3
B JUnit Zufalls Operation testen Allgemeine Java-Themen 1
P Testen von UIs Allgemeine Java-Themen 2
T MEthodenauruf testen, wenn instanz erst erzeugt wird Allgemeine Java-Themen 0
M Testen von verschiedenen Produktversionen Allgemeine Java-Themen 3
T EventBus testen Allgemeine Java-Themen 1
R Java Performance testen Allgemeine Java-Themen 18
B Mails testen Allgemeine Java-Themen 7
A AVL-Baum - Testen ob einer vorliegt Allgemeine Java-Themen 4
aze JUnit: Testen ob bestimmte Exception nicht auftritt Allgemeine Java-Themen 18
J JUnit - werfen von Exceptions testen Allgemeine Java-Themen 17
X Testen ob ein array leer ist Allgemeine Java-Themen 6
M Server-Responds testen, Code-Redundanz Allgemeine Java-Themen 3
fastjack Unit-Testen mit Mocks Allgemeine Java-Themen 6
B FileWriter / FileReader testen / Mock-Objekt für Unit Tests? Allgemeine Java-Themen 6
H Thread Safety und Deadlocks testen Allgemeine Java-Themen 6
D Muss eine JNI Biblio testen (MAC OS X) Allgemeine Java-Themen 4
T Object auf Double, Int, String testen Allgemeine Java-Themen 5
aokai Testen von Klassen die abhängig von Stdlibs URL sind Allgemeine Java-Themen 3
S Testen einer Anwendung durch klicken von Koordinaten Allgemeine Java-Themen 7
R Testen von Applets - versch. Browser und Java Versionen? Allgemeine Java-Themen 4
V Quellcode auf "Güte" testen? Allgemeine Java-Themen 5
G JAR-DAtei testen Allgemeine Java-Themen 15
J Klasse auf Konstruktor oder Methode testen? Allgemeine Java-Themen 3
A Junit Exceptions testen Allgemeine Java-Themen 3
Z Testen welches BS benutzt wird Allgemeine Java-Themen 3
G Testen von RMI,TCP/IP, Servlets etc. Allgemeine Java-Themen 2
M Welches Linux zum Java testen? Allgemeine Java-Themen 5
P Testen mit JUnit Allgemeine Java-Themen 8
L Java6 update N bekommt neues Browser-Plugin, bitte testen. Allgemeine Java-Themen 7
G testen mit JUnit? Allgemeine Java-Themen 3
K Testen ob Methode existiert? Allgemeine Java-Themen 2
N Cashbook Management Testen Allgemeine Java-Themen 7
A testen ob Primzahl dauert bei größeren zahlen extrem lange Allgemeine Java-Themen 8
M String testen? Allgemeine Java-Themen 2
M String testen? Allgemeine Java-Themen 6
N auf typ testen? Allgemeine Java-Themen 3
M Programmierstill: Bitte testen anhand HTML-Tool Allgemeine Java-Themen 18
K Testen einer Klasse mit File Objekt als Parameter Allgemeine Java-Themen 6
M Bitte Testen: Mein Multi-File Editor Allgemeine Java-Themen 30
T GUI Testen Allgemeine Java-Themen 4
T GUI Testen Allgemeine Java-Themen 5
G Programm zum Testen der Striktheit von Java Allgemeine Java-Themen 9
H Laufwerk testen? Allgemeine Java-Themen 12
F Hilfe: Adjazenzmatrix mittels JUnit testen. Allgemeine Java-Themen 2
M Jemannd mit 1.4/1.3/1.2 zum Testen gesucht. Allgemeine Java-Themen 15
flashfactor Testen ob ein R/3 erreichbar bzw. noch am leben ist. Allgemeine Java-Themen 2
T Datum testen und Einsetzten Allgemeine Java-Themen 5
M Regular Expression - verschiedene Ausdrücke testen (grep | ) Allgemeine Java-Themen 5
P Dateinamen mit regulärem Ausdruck testen Allgemeine Java-Themen 9
P Dateinamen testen? Schreibrechte auf Verzeichnis testen? Allgemeine Java-Themen 8

Ähnliche Java Themen


Oben