Open Source Software und deren Herausforderungen

Open Source Projekte brauchen eine starke Firma im Hintergrund, damit das Projekt langfristig überleben kann. Das ist zumindest meine Erkenntnis.

Es gibt auch die Möglichkeit durch eine Foundation, Stiftung o.ä. das zu schaffen, nur dann müssen genügend Sponsoren dauerhaft einzahlen wollen – also auch am Ende nichts anderes als würde es eine Firma selbst bezahlen, nur teilt man sich das kommerzielle Risiko mit anderen.

Die Community trägt gerne etwas bei, aber hauptberuflich Beschäftigte müssen von irgendwoher bezahlt werden. Das ist beim OpenOffice.org-Fork LibreOffice, Mozilla, Linux und deren Derivaten (Ubuntu) u.a. sehr gut zu sehen.

Wenn sich das Modell oder das wirtschaftliche Ziel ändert…

Manchmal ändern sich die Modelle und writschaftliche Interessen der Sponsoren hinter den Projekten und da gibt es dann die, die das gut machen und manche, die das total verreißen. Ich kann mich noch erinnern, als Sun Microsystems bei OpenOffice.org das Lizenzmodell änderte. Verlässlich war nur die Veränderung…. und irgendjemand fühlte sich immer auf den Schlips getreten.

Nun haben SmartBear und Tricentis auch OSS unter ihren Fittichen und da sieht man auch wieder, dass manche Firmen es können und andere eben nicht – Quelle: Dawid Dylowicz:

Damit wird es sichtbar, was manche IT-Manager auch von OSS abhält: Die Verlässlichkeit oder das einzugehende Risiko zu reduzieren.

Das Argument „(…) sollten wir nehmen, ist Open Source“ zieht manchmal bei Entwickelnden und Testenden, aber selten bei Entscheidern.

Insofern entscheide ich bspw. bei Werkzeugen/Software nicht danach, welches Lizenzmodell dahinter steckt und der Preis für das Werkzeug spielt auch eine Rolle, aber, entscheident ist eigentlich:

Erfüllt die Software meine Anforderungswünsche?!

Nur weil etwas open source ist, ist es nicht automatisch „gesetzt“, „umsonst“ und es nutzen auch nicht „alle“!

Vielmehr würde, wenn eine Software open source gestellt worden ist, die Transparenz gefördert und Fehlfunktionen oder auch Sicherheitslücken könnten von vielen gefunden werden. Das Projekt selber unterliegt aber natürlich wirtschaftlichen Interessen! Die, die als Sponsor auftreten wollen damit etwas erreichen. Open Source ist genauso wenig Demokratie, wenn diese nicht gelebt wird! Tote OSS Projekte findet man zu Hauf, wie auch vermeidlich „open“, wo nur der Code hingeschmissen wird, aber sonst niemand anderes auf die Weiterentwicklung  Einfluss hat.

Oftmals ist auch die open source Variante die kleine Schwester von „umständlich“, „hässlich“ und „Lockangebot“, wie im Fall von SOAP UI und ReadyAPI. Letzteres ist deutlich moderner, leistungsfähiger, aber eben nur Ersteres ist OSS….

Beim Selenium-Test-Framework bekommt man die API „umsonst“, aber der Support geht über Sponsoren und die wollen eben auch Geld verdienen. Viele Wekzeuge, die sich der API in den Unterbau gezogen haben, sind auch mitnichten open und schon gar nicht kostenlos.

Also, bitte, argumentiert mit der Leistungsfähigkeit der anzuschaffenden Software und blickt auch hinter das Sponsoring-Modell, denn, wie man oben schön sehen kann, kann es binnen eines Monats mit „open“ ganz schnell vorbei sein.

TACON – Die Konferenz zur Testautomatisierung 26.- 27.9.23 in Leipzig

Du bist in der Software-Entwicklung tätig und interessiert an aktuellen Themen rund um Testautomatisierung? Dann haben wir eine tolle Nachricht für dich!

Am 26. und 27. September findet die TACON in Leipzig statt. Hier werden unter anderem die folgenden spannenden Themen behandelt:

  • Testautomatisierung in agilen Teams
  • Cloud Testing
  • Qualität von ‚Infrastructure as code‘
  • Automatisiertes Performance- und Lasttesting mit und ohne Cloud
  • Testautomatisierung mit AI und von AI
  • Automatisierte Security-Tests
  • Barrierefreiheit automatisiert Testen gemäß Barrierefreiheitsgesetz (EU-Norm)
  • DevOps & DevSecOps

Die Konferenz bietet eine großartige Gelegenheit, um sich mit anderen Experten auszutauschen, Wissen zu teilen und sich über die neuesten Trends und Technologien im Bereich der Testautomatisierung zu informieren.

Wenn du dich in diesem Bereich engagierst und innovative Lösungen entwickelst, dann melde dich gerne mit deinem Beitrag zum call for presentations, wir bieten dir die passende Bühne.

Das Programmkommitee Karin Vosseberg, Dirk Huberty und Jörg Sievers, sowie das Team der TACON Softwareforen Leipzig freuen sich auf dich!

STeP-IN Forum Indien – Tolle Organisation

Gerne wieder, könnte man sagen, denn die Organisator*innen haben wirklich tolle Arbeit geleistet und mich in das Werkzeug „Floor“ gut eingewiesen und sich um mich als Mensch gekümmert. Ebenfalls Tyto, Hersteller von Sahi Pro, hat mit seiner Mannschaft zu einem wirklich tollen Erlebnis beigetragen.

Alle Bilder sind Bild-URLs vom nitter-Service, die Twitter spiegeln 😉

Vortrag Business-driven Test Automation auf dem STeP-IN Summit 2021
Vortrag Business-driven Test Automation auf dem STeP-IN Summit 2021
Q/A-Session auf dem STeP-IN Summit 2021
Q/A-Session auf dem STeP-IN Summit 2021
Darum geht es, wenn man (geschäftsgetriebene) Test-Automatisierung erfolgreich gestalten möchte: Gemeinsame Sprache!
Darum geht es, wenn man (geschäftsgetriebene) Test-Automatisierung erfolgreich gestalten möchte: Gemeinsame Sprache!

Kurzthesen zur Zukunft des Softwaretestens

Im Rahmen des GFFT Symposiums „Zukunft des Softwaretestens“ wurde ich gebeten meine Thesen einmal als „Kurzvortrag“ kund zu tun (5 Min.)…

Mindset statt Tools

Erst wenn auf allen Ebenen der Wertschöpfungskette verstanden worden ist, dass der Test, die Prüfung zum alltäglichen Geschäft gehört, haben auch wir in der Software „verstanden“. Andere, wie Lebensmittel- und Arzneimittelhersteller wissen um die Schlagkraft des einzelnen Mitarbeiters, darum bilden sie auch extrem gut aus. 

Vorgehen & Methodenkoffer anstatt Werkzeugkoffer

Test-Vorgehen und -Methoden müssen verinnerlicht werden wie das Einschalten des Rechners am Morgen. Es wird nach wie vor zu sehr auf ein Werkzeug geschaut, anstatt die Anforderungen zu ermitteln und dann eine Entscheidung zu treffen. Sicherheitstests sind beispielsweise nicht „On-Top“, sondern Basisbestandteil täglichen Arbeitens. Förderung des Wissens um die neuen Methoden der Sicherheitstests – von Anfang/Anforderung an.

Standards anstatt Abschottung

Schaut man auf die Industrien, wo die Standardisierung der Zubehörteile und tlw. auch der Software weit fortgeschritten ist, ändert sich natürlich die Testtiefe. Die Basis (Standards) werden durch alle gleichermaßen sichergestellt, während die Geschäftsprozesse meistens individuell sind und einer tieferen Betrachtung unterzogen werden. Geschäftsgetriebene Test(Automatisierung) wird so gefördert.

SAHI Pro Fix für Firefox => 86

Wie der Support von SAHI Pro mitteilt, kann man auch Firefox => 86 verwenden zur Testautomatisierung, wenn man denn

  1. <Sahi Pro>/config/ff_profile_template/prefs.js weg sichert
  2. in selbiger Datei
    user_pref(“privacy.window.name.update.enabled”, false);
    als Zeile einfügt
  3. den Ordner <Sahi Pro>/userdata/browser/ff löscht
  4. und SAHI Pro neu startet

 

GUI Testautomatisierung –50% Erstellungsaufwände sparen, wenn man Anforderungen analysiert

…war ein Vortrag auf der 43. TAV / SEUH 2019, 21.+22. Februar 2019, in Bremerhaven. Die Präsentation war schon länger auf meiner Seite online. Der Artikel ist nun in den Softwaretechnik-Trends der GI im Band 40, Heft 3 erschienen, aber dort noch nicht online.

Nettes Feedback aus dem Süden gab es auch schon – freut mich, wenn solche Themen auf Interesse stoßen!

Geschäftsgetriebene Testautomatisierung

Es muss nicht immer Selenium sein

Letztes Jahr auf der TACON hielt ich einen Vortrag über das Thema und versprach die Slides online zu stellen.

Asche auf mein Haupt, aber heute habe ich den Vortrag nochmals in kleinem Kreis gehalten und nun komme ich dem Versprechen nach.

Link zu der PowerPoint Präsentation.