Nach einigen Unittests, beginnen wir nun mit der Testphase für das Geräte-UI. Für den Alphatest muss ich das mit den Geräteentwicklern synchronisieren. Ich habe bereits einiges mit Ulrich abgesprochen, damit das glattgeht.
Für die Betaphase wäre ein Praktikant oder Werkstudent ideal. Ich versuche das zeitlich so zu timen, dass Lukas das übernehmen kann, wenn er im März hier jobbt.
Meine Jungs werden froh sein, wenn sie das nicht machen müssen, denn wer will schon freiwillig testen? Tester sind die alleruntersten in der Hackordnung (obwohl das den meisten Testern ja gar nicht bewusst ist). Eine unwillkommene Aufgabe, um die sich kein vernünftiger Mensch reißt.
(Trotzdem gibt es die so genannten Produkttester, die für ein paar kostenlose Produktproben ihre Integrität verkaufen. Oder auch Probanten in klinischen Studien bzw. Arzneimitteltester, die für ein paar Euro ihre Gesundheit oder körperliche Unversehrtheit riskieren. Sowie Versuchskaninchen irgendwelcher technischen Geräte, deren Betrieb auch mit Gefahren für Leib und Leben verbunden sein kann – insbesondere, da gerade bei Testgeräten ja meist noch nicht alle Details wirklich ausgereift sind. Dumm – im Sinne von Dumming-Kluger -, wer so etwas just for fun macht, nur um irgendwelche hippen Geräte kostenlos benutzen zu dürfen.)
Ich bin jetzt noch mit der Ausarbeitung des Testkonzepts und der Testspezifikation beschäftigt, damit alle Tester (freiwillig oder auch nicht) straightforward wissen, was sie machen müssen, und ihre Ergebnisse dann nur noch im Testprotokoll dokumentieren müssen.
Und selbstverständlich werde ich alle Tests so auslegen, dass sie bestanden werden (was bedeutet, dass ich selbst im Vorfeld SW und HW genauestens prüfen muss – was dann nicht funktioniert, muss eben vor den eigentlichen Tests gefixt werden).
Wie gesagt, Lukas wäre eine gute Wahl für den Job. Nach einem Semester Informatik hat er ein paar rudimentäre Kenntnisse, und eine größere Qualifikation ist zum Testen nicht nötig. Dafür wäre selbst ein Bachelor schon zu teuer.
Eigentlich könnte ich dafür noch einen zweiten Werkstudenten gebrauchen. Ich werde mal den Chef fragen, ob wir dafür noch einen weiteren Studenten einstellen. Lukas kennt bestimmt einen Kommilitonen, der gerne so einen Ferienjob hätte.
Übrigens, für alle, die es interessiert: Wir führen zuerst die Tests über HTTP aus. Das hat den Vorteil, dass es bei Problemen einfach ist, mithilfe von Wireshark zu schauen, welche Daten genau übertragen werden.
Erst wenn dabei alles funktioniert, stellen wir auf HTTPS um. Dazu müssen auf den Servern SSL-Zertifikate installiert werden. Ich habe so was zwar noch nie gemacht, aber mit versammelter Manpower werden wir es schon hinkriegen.
Dass dann – zumindest teilweise – noch mal getestet werden muss, dürfte selbstverständlich sein.
Wenigstens habe ich nichts mit den weiteren Prüfungen und Zertifizierungen zu tun.
Noch nicht.
breakpoint 
Wie man freiwillig Tester (oder noch schlimmer Testingenieur) wird, kann ich auch nicht verstehen. Ich mach aber auch nicht gern stumpfsinnige Arbeiten und arbeite nicht gern nach Checklisten / Vorgaben anderer.
Ich teste immer mit HTTPS und self-certified Zertifikaten, bevor ich auf den Produktivserver und echte SSL-Zertifikate umstelle. Mein Entwicklungsserver hat aber auch keine Domain.
LikeLike
Testen ist wirklich das Allerletzte! Leider kommt man nicht immer drumherum.
Ich bin schon froh, wenn ich das delegieren kann.
Zumindest beim ersten Testdurchlauf will ich schon sehen können, welche Daten genau übertragen werden.
Bei HTTPS sind sie verschlüsselt, so dass Wireshark da keine große Hilfe wäre.
LikeLike
Ja – klar kommt man nicht drum rum. Geht mir auch so.
Die Grundfunktionalitäten hab ich auch erst ohne SSL getestet.
LikeLike
Ob jetzt Testen einer neuen Software oder Fehlersuche bei einer nicht gut ausgetesteten Software im laufenden Betrieb bei neuen Anforderungen immer ist es mit langweiligen Aktivitäten verbunden.
Ich war immer froh gute Leute (am liebsten erfahrene Endanwender) zu finden zum Testen, denn je besser getestet wird um so weniger Probleme später.
Und auch bei Softwareerweiterungen ist es gut, nach meiner Meinung, auf gute Testunterlagen zurückgreifen zu können, um mögliche Probleme im Vorfeld auszuschließen.
LikeLike
Ja, das alles kann ich genau so bestätigen.
Deshalb gebe ich mir auch große Mühe bei der Testspezikation, damit die eigentlichen Tests ohne Schwierigkeiten durchlaufen.
LikeLike
Je besser die Unterlagen um so besser für den Tester und den Entwickler für die Softwareabnahme, find ich.
LikeLike
„Eigentlich könnte ich dafür noch einen zweiten Werkstudenten gebrauchen.“
Schnickschnack, nehmt mich!
-> Kannst ja mal Herrn L. fragen, es gibt kein Problem, kein Fehlerchen, das ich nicht finden, keine Schwäche, auf die ich nicht stoßen würde! Was bei mir nicht abstürzt etc., ist narrensicher! 😀
Ja, das ist mein besonderes Talent…
Captcha: I love deadlines
Stimmt sogar! 😀
LikeLike
Und wer passt solange auf deine Kinder auf?
Mitbringen kannst du sie nicht.
Wenn sie nämlich z.B. einen Stromschlag kriegen, zahlt das keine Versicherung. Ja, Testen ist gefährlich!
Außerdem dürften die Kosten für An-/Abreise, Unterkunft, Babysitter, etc. deine Einnahmen
übersteigengrößtenteils aufbrauchen.Das ist nur interessant für jemanden, der eh hier in der Gegend wohnt.
(Übrigens hatte ednong auch schon Interesse an einer Tätigkeit als Tester geäußert)
Und es geht gar nicht darum, Fehler neu zu entdecken, sondern die Tests nach Vorgaben durchzuführen und zu dokumentieren (laaangähnweilig).
Testen ist eine „unwillkommene Aufgabe, um die sich kein vernünftiger Mensch reißt.“
LikeLike
Wenn euer Apparillio auschliesslich HTTP spricht, würde ich eher einen HTTP-Proxy wie Burp oder ZAP nehmen, anstatt Wireshark. Dann musst du dir nämlich nicht die Payloads aus den Layer 2 Paketen zusammenfriemeln, sondern bekommst das ganze gleich schön nach Request/Response Paaren dargestellt.
Außerdem können diese Proxies auch intercepten. d.h. der Request bleibt im Proxy „hängen“ und du kannst ggf. dort direkt dran rummanipulieren, bevor er an den Server geschickt wird.
Außerdem können sie beide auch SSL terminieren. Wenn euer Client einfach nur der Browser ist, gibt es eine Zertifikatswarnung, die man zum Testen wegklickt, und fertig ist der Lack. ALso kann man so auch mit einer HTTPS Verbindung testen.
Burp ist kommerziell (~300$ pro Jahr; sehr kulant mit Mehrfachinstallationen); aber es gibt eine kostenlose Testversion, die für deine Zwecke ausreichen dürfte:
http://portswigger.net/burp/download.html
ZAP ist ein freies Projekt aus dem OWASP-Umfeld:
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Viele Grüße,
Horst Hacker
LikeLike
Zu kompliziert will ich es auch nicht machen, und deshalb keine zusätzliche Software installieren müssen.
Diese Tests werden ja (zunächst) nur einmal durchgeführt, und der Wireshark-Log soll eigentlich nur dazu dienen, im Falle von Problemen diese nachvollziehen und ggf. handlen zu können.
Wenn alles glatt geht, wäre es gar nicht nötig, Wireshark tracen zu lassen.
Aber danke für den Vorschlag.
LikeLike
bei Wireshark kann man sich in der GUI auch die zusammenhängenden Pakete als Thread anschauen. Mir hat das immer gereicht (aber ich untersuche meist auch nur aufgetretene Probleme, habe keine Produkttests im Vorfeld)
LikeLike
Nachtrag:
Disclamer:
1) Ich benutze Burp Pro selbst als essentielles Arbeitstier im täglichen Einsatz. Ich werde nicht von Portswigger für Werbung bezahlt. 😉
2) Ich habe mit dem Project Leader von ZAP, Simon Bennets am Rande einer OWASP Veranstaltung hart die Hotelbar leergesoffen und ihm gesagt, daß ZAP eine elendige unbenutzbare Exceptionschleuder ist. Das ist ca. 3 Jahre her. Er hat sich das zu Herzen genommen, und nun ist das Ding in einem geilen Zustand! 😉
LikeLike
Ohne das jetzt ausufern lassen zu wollen: Beide Proxies bringen einen aktiven und passiven Security Scanner mit. Als Goodie bekommst du am Ende einer Testsitzung gleich noch eine Liste mit den (automatisch erkennbaren) Sicherheitsproblemen. Einen richtigen Pentest ersetzt das natürlich nicht, aber wireshark kann sowas auch nicht. 😉
LikeLike
Sicherheitsprobleme sind – zum Glück – nicht vordringlich, da die Server nur in abgeschotteten Intranets (mit passend konfigurierten Routern) laufen werden. Eine DoS o.ä. ist also schon einmal nicht zu erwarten.
Die Nutzer müssen sich authorisieren, alle Aktionen werden mitgeloggt.
Die Funktionalität, die sich überhaupt über das Web-UI steuern lässt, ist auch begrenzt.
Da sehe ich erst mal keinen (dringenden) Handlungsbedarf.
LikeLike
Tsts,
was du nur gegen TEster hast. Klingt ja ziemlich abfällig in meinen Ohren.
Bedenke doch einmal:
Gäbe es keine Tester, müßten es deine Kunden für dich testen. Das dürfte weitaus teurer werden (und imageschädigender). Und ja, ich weiß, Microsoft verfährt so.
Ich stimme dir aber zu: für ein paar Gratisproben oder generell kostenlos sollte man das nicht machen. Und meine körperliche Unversehrtheit möchte ich dafür auch nicht hergeben, obwohl es ja ohne Tests an Menschen nicht läuft.
Ich spreche den Menschen eher hohen Respekt ggü. aus. Und ja, ich teste auch gerne. Und finde – selbst nach Protokoll – zig unerwartete Fehler.
Also: wer etwas zum Testen hat, darf mich gerne ansprechen. Am besten sind dann natürlich die Dinge, die nicht zurückgegeben werden müssen. Kekse beispielsweise 😉 (aber eben nicht nur, um mal ernsthaft zu bleiben).
LikeLike
„Gäbe es keine Tester, müßten es deine Kunden für dich testen.“
Ja, weil Tests notwendig sind, gibt es dafür ja bezahlte Tester.
Zu testen, ohne dafür eine Gegenleistung zu bekommen, ist Ausbeutung.
Die Hersteller freuen sich freilich, wenn sich jemand zum kostenlosen Testen meldet. Haben sie eben einen Dummen gefunden.
Ich bin da übrigens auch schon reingefallen. :.
Sollte ein Bett testen, und .. tja .. der Rest dürfte dir bekannt sein.
Ach, und falls ich mal einen Vorkoster brauche, werde ich mich an dich wenden.
LikeLike
Oh ja,
immer her mit den Leckereien …
Du hast ein Bett getestet und bist reingefallen? o.O
Captcha – irgendwie irritierend – heute: two hands
LikeLike
Ich habe kein Bett getestet. Es gibt da nämlich gar keines.
Jetzt tu nicht so unschuldig!
LikeLike
Ich sehe das mit dem Testen genauso, wie ednong: So abfällig darüber zu denken/reden, ist so ziemlich das Allerletzte.
OK, „Tester“ ist der Müllabfuhr-Job der Produktentwicklungsbranche, aber eigentlich sind es doch diese undankbarsten Jobs, die den höchsten Respekt verdienen, den gemacht werden müssen sie ja trotzdem, wenn man keine „Bananensoftware“ ausliefern will. Bei der Müllabfuhr ist das ja schon ganz gut geregelt, die verdienen halt ein ziemlich gutes Geld dafür, dass sie einen Drecksjob machen. Bei anderen nötigen Drecksjobs ist das leider nicht so, und oft wird auf die dann auch noch herabgeschaut – das muss doch wirklich nicht sein“
Ich habe auch mal bei einem Betatest mitgemacht, für eine neue Android-Version meines Smartphones. Das war eine interessante Angelegenheit, der Job des Testers bestand einfach darin, das Gerät wie normal weiter zu benutzen, und Bugs/Crashes etc. an die Entwickler zu melden, bzw. sich in einem Forum darüber auszutauschen. Da hat man als ansonsten „ausgeschlossener Nutzer“ schon einen interessanten Einblick bekommen, nicht nur darin, was alles damit zusammenhängt, eine gut funktionierende und stabile Version herauszubringen, sondern auch, wie unterschiedlich die Nutzungspräferenzen der verschiedenen Nutzer waren (hier waren es unter 100, aber das skaliert ja nicht unbedingt linear…), und noch mehr. Ich hab das freiwillig gemacht, und weil es mir Spaß gemacht hat.
Auch sonst würde ich Produkte immer testen, wenn ich sie auch sonst nutzen würde, und natürlich unter der Vorraussetzung, dass dabei keine Gefahr besteht, die über die bei der Nutzung des normalen fertigen Produkts hinausgeht. Gerne auch mit Entschädigung.
Und bei freier Software ist es sowieso noch mal viel schöner: Da wird das Programm kostenlos bereitgestellt, und ganz offen und ehrlich kommuniziert, dass es sich um eine Betaversion handelt, und wer dann einen Bug findet, hat die Möglichkeit, einen Bugreport einzureichen, oder aber den Fehler selbst zu beheben, und dann diese Lösung an das Projekt weiterzugeben – der Quellcode ist ja offen. Klar, im Unternehmensumfeld nicht denkbar, aber für private (Hobby-)Anwender die beste aller Möglichkeiten.
LikeLike
Was da abfällig geklungen hat, war lediglich auf diejenigen Personen bezogen, die Tests unentgeltlich machen, weil sie das cool oder sonstwas finden, und sich noch etwas darauf einbilden, dass sie testen dürfen – als ob das eine besondere Gunst wäre!
Selbstverständlich gibt es auch Tester, die hochprofessionell arbeiten. Denen steht durchaus Respekt sowie eine angemessene Bezahlung zu.
Ja, ich finde es dumm, einen evtll. gefährlichen Test ohne Bezahlung zu machen. Solche Leute gibt es gar nicht so selten.
Mir ist etwa ein Fall bekannt. Da ging es um ein technisches Spielzeug. Leider platzte ein Teil ab und ging ins Auge. Der Tester hatte lange gesundheitliche Probleme damit, wenigstens aber keinen bleibenden Schaden.
Und erst das Hickhack mit der Versicherung!
Bei deinem Betatest .. schön und gut .. aber hattest du da gar keine Bedenken, was evtll. mit deinen persönlichen Daten passieren könnte?
Solche Betaversionen tracken nämlich für gewöhnlich schon so einiges mit, und sei es bloß, um Daten für eine eventuelle Fehlersuche zu dokumentieren.
LikeLike
Das Tracking ist bei Android-Telefonen *immer* ein Problem, nicht nur bei Betaversionen. Man kann zwar viele Apps deaktivieren, aber ob sie dann wirklich „unschädlich“ sind, ist (zumindest für mich) nicht sicher, und manche braucht man ja auch. Da hilft nur eine vernünftige Rechteverwaltung, die man bis 4.4. bei einem gerooteten Telefon noch nachrüsten kann (sie war einmal über 2 Versionen von Google eingebaut worden, aber ist jetzt wieder weg), oder aber eben ein Custom-ROM, welches die Rechteverwaltung enthält.
Inzwischen habe ich ein Modell, was hoffentlich demnächst von den entsprechenden Custom-ROM Herstellern unterstützt wird, so dass ich mich dem in Zukunft besser entziehen kann. Ich meine, ich synchronisiere zwar schon Kalender/Telefonbuch mit meiner Owncloud, statt mit Google, installiere so viel wie möglich aus dem OpenSource-Store F-Droid, nutze die mitgelieferten Apps nicht (bzw. deaktiviere sie), aber trotzdem mache ich mir keine Illusionen: Wenn allein die Google Suche schon auf all diese Sachen Zugriff haben will (offiziell, um es durchsuchen zu können), dann halte ich es für zumindest fragwürdig, ob diese Schutzmaßnahmen überhaupt greifen.
Dennoch finde ich, dass man einem Hardwarehersteller, der die Daten aus der Betaversion zum debuggen sammelt, da weniger Misstrauen entgegenzubringen braucht, als einem Konzern wie Google, der ganz offiziell mit diesen Daten Geld macht.
Und Android ist halt auch leider die einzige Plattform, wo man mittels alternativer Firmwares die Kontrolle über sein Gerät (zumindest eingeschränkt, der Baseband-Chip ist natürlich immernoch proprietär und potentiell fremdgesteuert) wieder erlangen kann, während ich allen anderen Mobilsystemherstellern denselben Datenhunger zutraue und unterstelle, jedoch mit so verschlossenen Plattformen, dass der Nutzer überhaupt keine Möglichkeit der Gegenwehr hat. Die einzige Smartphone-Plattform, wo Tracking nicht integriert ist, dürfte Jollas SailfishOS sein, zumal es auch von einem europäischen Hersteller stammt, und wir (noch) die entsprechenden Datenschutzgesetze haben, die den USA fehlen.
Als Fazit kann man eigentlich nur sagen: Wenn man sich sein Smartphone nicht mit CustomROM so zurecht schneidert, dass die Privatsphäre gewahrt bleibt, dann kann man eben nur Daten, die man als „öffentlich“ betrachtet, damit verarbeiten.
LikeLike
There ain’t no such thing as a free lunch.
LikeLike
wenn Wireshark auf dem Rechner läuft, der die Requests absendet kann er (manchmal? immer?) auch HTTPS analysieren und man sieht nicht nur die verschlüsselten Pakete. Jedenfalls habe ich das in der GUI schon mehrfach so gesehen.
Wie das natürlich ist, wenn man beim nächstgelegenen Router einen listening Port definiert und dort alles mitschneidet weiß ich nicht. Vermutlich braucht er halt „irgendwie“ Zugriff auf die Zertifikate.
Testen mit abgeschalteter Sicherheit hat halt den Nachteil, dass dann gerne mal auch genau so ausgerollt wird „um das auch noch zu testen haben wir keine Zeit“.
LikeLike
was natürlich auf jeden Fall geht ist das entschlüsseln, wenn der private Key bekannt ist: https://wirewatcher.wordpress.com/2010/07/20/decrypting-ssl-traffic-with-wireshark-and-ways-to-prevent-it/
ich dachte aber, das ginge auch, wenn man direkt abgreift, aber zumindest gerade eben wollte es nicht mehr klappen… *schnüff*
LikeLike
Eigentlich wollte ich nur erwähnen, dass die evtlle. Fehlersuche einfacher ist, wenn man ohne SSL testet, weshalb wir den ersten Testdurchlauf eben ohne machen, und hoffen, dass wir die Wireshark-Mitschnitte gar nicht wirklich brauchen.
LikeLike
engywuck:
wenn deine Anwendung nur HTTP(S) spricht und kein eigenes (binäres) Protokoll, tust du dir mit den weiter oben von mir erwähnten Proxies leichter.
Die können auch SSL aufmachen und du musst dich nicht mit den Paketen der niedrigeren Layers herumschlagen. Du bekommst damit die gesamte HTTP(S) Kommunikation auf einem recht hohen Level angezeigt. Request mit zugehöriger Response; gruppiert nach Hosts; Nur Header, Nur Body oder beides gemeinsam, den Body in Plaintext oder Hex, oder geparst nach Parameter-Value Paaren und und und…das ist wirklich angenehmer als sich durch wireshark-dumps zu wühlen!
LikeLike
NeunhundertsechsNichts ist beständig, außer dem Wandel.
Aber nicht jede Änderung ist auch zum Guten.
So hatte ich schon über Google Redirects und Verschlüsselung von Suchanfragen gebloggt.
Wordpress stellte Ende des letzten Jahres auf HTTPS um, was mir im Oktober…
LikeLike
TausenddreiEine namhafte US-amerikanische Universität (eine von den ganz großen, bekannten Namen) hat eine größere Anzahl an Lizenzen meiner Standardsoftware gekauft.
Das bedeutet für mich nicht nur einen Batzen Geld bei nur wenig Arbeit, sondern auch, dass mein…
LikeLike
Pingback: Tausendneunzig | breakpoint
Pingback: Tausenddrei | breakpoint
Pingback: Neunhundertsechs | breakpoint
Pingback: Mediakit und Blogkorruption //2144 | breakpoint