Eine geerbte Qt-Anwendung soll weiterlaufen, doch für Wartung, Tests und Releases gibt es weder belastbare Schätzungen noch viel Budget. Meine Position: Ein kleiner Etat rechtfertigt einen kleineren Freigabeumfang, aber keine abgespeckte Absicherung für die Änderungen, die tatsächlich ausgeliefert werden. Wer beides verwechselt, beauftragt scheinbar günstige Entwicklung und trägt das unbezifferte…
Eine geerbte WinForms-Anwendung ohne Tests lädt zu einer großen Aufräumaktion ein: Formulare entflechten, Framework aktualisieren, Oberfläche automatisieren. Ich würde anders beginnen. Als QA-Ingenieur brauchst du zuerst eine überprüfbare Grenze um das bestehende Verhalten, selbst wenn dieses Verhalten unschön ist. Meine Position: Eine kleine, gezielt getestete Änderung an einem häufig genutzten…
Eine WPF-Anwendung kann für einen einzelnen Auftraggeber hervorragend funktionieren und trotzdem mehr Wartungsarbeit erzeugen, als ein Freelancer bezahlen kann. Seit 2024 haben sich vor allem die .NET-Laufzeiten und die Möglichkeiten für ein zeitgemäßes Erscheinungsbild verändert. Meine Position: Nicht die modernste Architektur ist heute der beste Standard für Solo-Projekte, sondern eine…
Ein grüner CI-Build sagt wenig darüber aus, ob eine JavaFX- oder Swing-Anwendung am Montagmorgen auf einem verwalteten Arbeitsplatz startet und bedienbar bleibt. Teams behandeln Desktop-Releases trotzdem oft wie Server-Deployments: Artefakt bauen, Prozess prüfen, Ticket schließen. Das ist der falsche Betriebsvertrag. Für DevOps zählt zuerst, ob sich ein Fehler auf einem…
Die geerbte Swing-Anwendung hat keine verlässlichen Tests, aber der erste Vorschlag im Planungstermin lautet: „Dann migrieren wir eben zu JavaFX.“ Für QA ist das meist die falsche Reihenfolge. Ein neues GUI-Framework beseitigt keine unbekannten Erwartungen an die alte Anwendung; es macht sie zunächst schwerer zu beobachten. Ich würde zuerst das…
Du übernimmst eine Qt-Desktop-App ohne verlässliche Tests, und der erste Vorschlag lautet: „Wir automatisieren die Oberfläche.“ Das klingt sicher, weil Klicks sichtbar sind. Für die meisten geerbten Codebasen ist es trotzdem der falsche Standard: Ein GUI-Test sagt oft zu spät, was kaputtging, und bricht schon bei harmlosen Änderungen. Ich würde…
Der erste Skalierungsbruch im Software-Outsourcing ist selten der Code, sondern die Schnittstelle zwischen Entscheidung, Vertrag und Lieferung. Meine unbequeme Position: Ein CTO sollte eher standardisierte Lieferfähigkeit einkaufen als vorschnell intern aufbauen, solange die Domäne nicht das Differenzierungszentrum ist, weil interne Teams bei wachsender Unsicherheit langsamer lernen als ein eingespieltes Liefermodell.…
Bei Magento skaliert selten zuerst der Webserver, sondern die Verantwortung für Seiteneffekte: Preisregeln, Indexer, Cache-Invalidierung, Suche, Checkout und Releases greifen ineinander. Meine Position ist unbequem: Ein CTO sollte Magento nur dann in-house skalieren, wenn das Geschäftsmodell an Kataloglogik, Preisbildung oder Checkout-Differenzierung hängt, weil sonst der Betrieb schneller teuer wird als…
Viele Teams entscheiden JavaFX gegen Swing über Optik, Entwicklergeschwindigkeit und Recruiting. Das ist zu spät angesetzt. Meine streitbare Position: Für eine 15- bis 30-köpfige Engineering-Organisation ist Swing oft die sicherere Standardwahl, wenn Datenschutz, Patchbarkeit und Auditierbarkeit wichtiger sind als moderne UI-Effekte, weil JavaFX zusätzliche native und mediale Angriffsflächen in den…
Du erbst keinen Magento-Shop, du erbst eine Beweislücke: Niemand kann sagen, welche personenbezogenen Daten durch Checkout, Suche, Tracking, Logs und Admin-Erweiterungen wandern. Meine unbequeme Position: Als QA solltest du zuerst Releases wegen Datenschutzrisiken blockieren, nicht wegen kaputter Buttons, weil UI-Fehler sichtbar sind, Datenabflüsse aber oft erst im Incident auffallen. Die…