Kategorien
Test is dead – Der Kompromiss
Im ersten Artikel dieser Serie sind wir darauf eingegangen, dass es viel wichtiger ist Fehler in Konzepten zu finden (Idea Bugs) als in der Funktionalität. Alberto Savoia hat diese These als erstes aufgestellt, hat aber an einer Stelle vielleicht nicht weit genug gedacht.
Savoia geht davon aus, dass wenn man einmal ein System etabliert hat, in dem man zuallererst beweist, dass man das richtige baut, wird man sich nicht mehr um Qualität kümmern. Der Reiz ist einfach viel zu hoch, immer und immer weiter an seinem Produkt zu arbeiten, es funktional zu erweitern. Den Schritt zurück ins Refactoring und damit zum sauberen Code spricht er nicht an.
Aber genau hier darf man es nicht einreißen lassen. Qualität ist nicht wichtig, wenn ein Produkt eh kein Erfolg ist. Soweit ist es richtig, was der Google-Test-Engineer sagt, doch wird es relevant, wenn ein Produkt oder ein Feature bewiesen hat, dass es ein Erfolg ist. Torsten Franz und ich sind in unserem Vortrag zur Evolution der Qualitätssicherung genau auf dieses Thema eingegangen.
Das Problem dabei ist, dass Produktverantwortliche in Funktionalitäten denken. Es ist für sie nicht nachvollziehbar, warum es sinnvoll sein kann ein Feature neu zu machen, dass bereits existiert und funktioniert. Als jemand der am Umsatz, an den PIs oder sonstigen KPIs gemessen werden, ist diese Denke sicherlich nicht falsch. Als wir unseren Vortrag zu dem Thema auf der Developer Conference gehalten haben, kam aus dem Publikum Damals hatten wir keine gute Antwort. Dies hat sich heute geändert. Der Weg, den man jetzt einschlagen sollte, geht über die nicht-funktionalen Anforderungen.
Neben den funktionalen Anforderungen an ein Produkt, welche auch im „Test is dead“-Ansatz existieren müssen, existieren auch nicht-funktionale. Und genau diese sind beim TIS-Vorgehen minimal. Wartbarkeit, Performance, Skalierbarkeit und weitere sind zuerst einmal so minimal gehalten, dass man davon ausgeht, dass nicht viele Besucher als Nutzer die Seite besuchen.
Wie so oft, ist der Schlüssel zum Erfolg transparenz. Wenn jetzt nämlich ein Produktverantwortlicher der Meinung ist, dass man ein Refactoring nicht braucht, dann kann mal leicht argumentieren, dass das System für wenig User ausgelegt ist. Wenn es mehr werden, wird es zusammenbrechen. Das sollten die meisten Verantwortlichen verstehen. Zumindest müssen sie dann dafür geradestehen. Transparenz ist häufig die stärkste Waffe, die man hat.
Noch einmal kurz zusammengefasst: wenn man den Ansatz fährt, dass man zuerst rausfinden muss, ob man das richtige baut, bevor man es richtig baut, dann bedeutet dies, dass man nicht-funktionale Anforderungen so definiert, dass man von einem Flop ausgeht. Dies muss festgehalten werden und kann im Notfall als „Waffe“ gegen Entscheidungen verwendet werden.
Im dritten und letzten Teil dieses Artikels gehen wir darauf ein, wie eine technischen Unterstützung aussehen könnte, die diesen Ansatz begleitet. Denn auch wenn man Software im ersten Schritt einfach nur unter funktionalen Aspekten betrachtet, muss man sich technisch darauf vorbereiten und Abhängigkeiten in den Griff bekommen.
Irgendwie hat es mir gefallen, wie die ganzen Artikel, die ich vor kurzem geschrieben habe mit diesem Artikel zusammengeflossen sind.
Ich finde deine Betrachtungsweise bzgl von Lean Startup ansätzen und Qualität interessant.
Was du allerdings vollkommen ausser acht lässt ist das nicht bei jedem produkt neu entwickelt wird.
Baut man beispielsweise eine SEPA überweisung stehen die Anforderungen fester, man muss nichtmehr herraus finden was genau drinnen sein muss, kann die Kernfunktionalität sofort über test abdecken und die Experimente allein auf Usability fokussieren.
Trotzdem ist es halt fragwürdig, ob überhaupt Überweisungen getätigt werden. Was ist, wenn die Leute lieber Paypall nutzen oder das Geld lieber selbst vorbeibringen?
Du gehst davon aus, dass der Produktverantwortliche das versteht bzw. nicht widerlegen kann. Die Realität holt uns da aber ein. Der Produktverantwortliche ist vom Kunden und von seinen Vogesetzten getrieben. Nicht durch das Produkt. Das ist, wie immer, Pareto Prinzip. Wir, als QA können noch so tolle Konzepte erarbeiten. Wenn diese von der Führung immer wieder zugunsten des Profit und des persönlichen Standings/ Image verworfen werden hilft nur das Alt Bekannte. Leider ist das die Realität und es gibt sehr wenige Manager die den Arsch in der Hose haben sich dem zu widersetzen. Wir würden mit allen Konzepten zum Ziel kommen. Nur ist bisher jedes Konzept boykottiert worden. In jeder Firma die ich kenne. So traurig das ist.
Wir müssen m den Köpfen der Führung erstmal die Gewichtunf der Qualität verankern und diese als wirtschaftliche Größe fordern. Ansonsten bleibt „Wir wollen Qualität“ nur eine Worthülse für Kundenmeetings aber nichts mit Füllung.
Ich will keine Qualität, ich will Risiken bekämpfen.
Irgendwann kommt die Frage. Warum kostet die Planung auf einmal mehr. Das konnten wir früher schneller. Das Problem wird nur verschoben und die Qualität resultiert aus verringerten Risiken. Sie wird aber nicht kostenlos sein udn genau da kneifen alle ganz fest den Po zusammen. Qualität kostet Geld, egal wie sie zustanden kommt.
@Frank: Was ich eigentlich aus QM-Sicht will, ist Transparent und Bewusstsein.
Ich möchte zu jeder Zeit sagen können, dass wir ein System gebaut haben, das für 1.000 User funktioniert. Wenn es 1.001 werden, dann hab ich keine Ahnung, wie sich das System verhält oder vielleicht weiß ich sogar, dass es das ab kann.
Und wenn jemand fragt, warum wir früher schneller waren, dann hole ich die NFAs raus und zeige, dass sie früher was ganz anderes wollten. Ganz einfach 😉
Wir drehen uns im Kreis.
Fakt: Qualität ist unbewertet -> die Summe aller Eigenschaften einer Sache und bewertet -> Die Güte dieser Eigenschaften.
Daraus folgt -> Eigenschaften einer Sache sind unabhängig von ihrer Güte aber dennoch ist die Güte existent aber im Zweifel nicht bewertet.
Daraus folgt ->
1. Nicht bewertete Güte führt unweigerlich zu Qualitätskosten (Kosten die durch nicht durchgeführte oder mangelhafte Qualitätssicherung entstehen)
2. Bewertete Qualität führt unweigerlich zu Qualitätssicherungskosten (Kosten, die für die Sciherstellung der bewerteten Güte entstehen)
Daraus folgt -> Es werden Kosten entstehen, die der Produktverantwortliche gegeneinander abwegen wird. Das was weniger kostet (Image Schaden kann auch kosten) wird er tun.
Fazit: Der Produktverantwortliche interessiert sich nicht für das Produkt per se. Ihn interessiert ob es im Budget liegt (Zeitlich und finanziell).
Wie und an welcher Stelle wir also die Güte erzeugen ist nicht von Bedeutung. Die Kosten entstehen in irgendeiner Form und werden gerne gekürzt und zwar immer dort wo der wirtschaftliche Mehrwert die Kosten nicht deckt.
Cheers!
Qualität ist die Übereinstimmung von Soll und Ist (ISO). Wenn eine Applikation nicht sicher sein muss/soll, dann ist die Qualität des Produktes nicht schlechter, nur weil Sicherheitslücken existieren.
Wenn der Produkverantwortliche sagt, sie muss für 1.000 User halten, dann ist dies zu testen. Warum sollte ich mehr machen? Als QM und QA bin ich nicht dazu da, die Verantwortung fürs Produkt zu übernehmen, sondern den Leuten, die entscheiden die Risiken aufzuzeigen und die aktuelle Qualität (nach ISO) transparent zu machen. Entscheiden sollen andere.