Testing Trapeze – 2015 – August Edition – Testing Circus

What does testing look like without test cases? – Kim Engel

Source: Testing Trapeze – 2015 – August Edition – Testing Circus

 

 

 

Testing Trapeze and Testing Circus magazines 8/2015 are out and very nice articles are in both. I have talked last week to a release manager about testing metrics and that they are needed inside a huge organisation….hmm…. yes, but….

„I’ve learned a powerful secret in my quest to stop reporting on testcase
metrics: management appreciate bullet points almost as much as
graphs! So I keep my test reports short, useful and relevant.“

(Kim Engel, Testing Trapeze 8/2015)

I could sign that sentence because metrics create visible points but won’t tell the whole story. Daily stand-ups, verbal communication to the stakeholders (mostly also upper management) gives often more information beyond the numbers: They could give a forecast and the management is able to plan actions – hey, that’s what they always want!

Yes, metrics are indicators but you have to select metrics very well because team members will try knowingly or unknowingly to get save against the „rules“. The better approach is to give the team members a quality mindset which they are willing to follow and which actions / tasks they should fulfill to get quality product. Then a metric is just a quality control and testers will have more time for the deeper test scenarios instead of getting the basics done.

World Quality Report 2015: Gute Zeiten für Qualitätssicherung und Testing | heise online

Seit 2009 veröffentlichen Capgemini, Sogeti und HP die Ergebnisse einer weltweiten Studie zur Anwendungsqualität. Mittlerweile sind Customer Experience und Sicherheit die treibenden Kräfte für diesmal signifikant höhere Ausgaben in der Qualitätssicherung.

Quelle: World Quality Report 2015: Gute Zeiten für Qualitätssicherung und Testing | heise online

REMIT

„But as of right now we feel pretty comfortable saying that EFETnet is the round one winner.  You really have to hand it to them.  EFETnet’s done a spectacular job getting a good number of brokers lined up.  And EFETnet seems to have won the majority of MPs.  If you think about it, just getting the brokers lined up is a herculean effort and, in the end, a job well done.“

Source: http://broadpeakpartners.com/remit-game-of-thrones-ii/

If you are a part of that team those words will make your day – it did! 🙂

Geht dem Qualitätsjournalismus nun auch bei Spezialthemen die Luft aus? Ein paar Worte zur Einstellung von Testing Experience und Reduktion von Better Software (UPDATED)

Was musste ich in der Januar-Ausgabe meines Lieblingsmagazins für Software-Tester lesen „Starting with this issue, Better Software will be published quarterly (it was bimonthly).“ (Better Software, S. 7, 1/2015).

Nun, ich verfolge gerne die Trends, die in unserer Disziplin maßgeblich von jenseits des Atlantiks  geprägt wurden und werden (auch wenn der ISTQB-Standard seinen Ursprung m.W. in Großbritannien hat) und das schon seit 2005. „Better Software“ ist für mich wie die „Objekt Spektrum“ in Sachen Software Engineering hierzulande und ich habe früher gerne ein paar Dollar für die digitale Ausgabe ausgegeben. Seit einigen Jahren erscheint das zweimonatliche Magazin nicht mehr, wie ursprünglich, bei SQE (Software Quality Engineering, Inc.) sondern bei Techwell und dafür kostenlos. Ob das so gut war?

Schade, ich würde lieber wieder 9,95$ pro Ausgabe berappen, wenn dadurch der Qualitätsjournalismus nicht auf Sparflamme gehalten wird. Ich kenne die Gründe, die Techwell dazu bewogen haben, nicht, aber es gibt viele Themen in der Softwarequalität zu beackern und sich durch Blogs und Tweets zu arbeiten mag heute usus sein, aber, so wie ich die Objekt Spektrum als Druckausgabe mit qualitativ hochwertigen Artikeln schätze, so würde ich eines der wenigen Magazine, die sich mit Softwarequalität befassen eben auch als „old schoon“-Ausgabe, meintwegen auch digital, begrüssen.

Nicht nur Better Software schränkt sich ein, auch Diaz Hilterscheidt haben ihre TestingExperience. und TestingExperience DE-Magazine Anfang des Jahres eingestellt, leider. Die TestingExperience-Ausgaben war qualitativ etwas unterhalb der „Trendsetter“, aber vermittelten stets einen guten Überblick aus aktuellen Projekten und wie die Tester-Kolleginnen und -Kollegen damit umgegangen sind.

Ich hoffe das Blättersterben in meiner Branche greift nicht weiter um sich, da Blogs und Tweets m.E. nicht dieselbe Qualität liefern und bspw. CEPIS  Upgrade auch schon vor einiger Zeit (2011) sang- und klanglos von der Bildfläche verschwand, wie auch STP (Software Test & Performance) 2012.

Update: Ken Whitaker, Editor Better Software magazine

Hello Jogi,

I am so pleased to get your email. Yes, Better Software magazine is now published quarterly. I am aware that many software development magazines have not survived and it is our intention to make sure that our magazine does. What I particularly like about editing this magazine is that our magazine’s content is generally timeless and not dependent on specific technology that becomes out of date within a few months. We emphasize feature articles on people management, agile, testing (the hallmark of the company), and DevOps. As with any business, the decision to go quarterly was a tough, but necessary change. We have better aligned the issues to our major conferences throughout the year and I am amazed: every issue seem to get better and better with no shortage of authors wanting to write for us.

Storybased Ownership in agilen Softwareprojekten

Wieder so‘n Buzzword? Naja, „Geschichtenverantwortlicher“ klingt noch dümmer, oder? Es geht hier um innere Verantwortlichkeiten in einem agilen Softwareentwicklungs-Team zur besseren Qualitäts- und Zielerreichung.

Nun, während der AppSec 2013 sprache ich mit Chris Eng kurz über diese Methode nach seinem Vortrag „Real World Agile SDLC“, hatte ich diese Methode doch in einem der Projekte in denen ich derzeit tätig bin, vorgeschlagen und wir hatten mit einem Piloten ganz nette Erfahrungen gemacht.

Worum geht es bei „storybased Ownership“?

Wenn es in einer Firma Abteilungs- und Projektleiter gibt, gibt es auch immer die Frage nach Verantwortlichkeiten. In der reinen agilen Lehre (bspw. SCRUM) gibt es diese Rollen nicht mehr, aber IRL gibt es sie eben doch. Um diesen Wunsch nach Information und Verantwortlichkeit gerecht zu werden, bestimmt das agile Entwicklungsteam bei der Sprintplanung eben einen, der „den Hut für eine [größere] Story auf hat“, d.h. es ist jemand da, den man fragen kann, wenn man zu genau diesem Thema (der Story) was wissen muss. Aufgaben- oder Defekte im Fehlerreportingsystem haben ja auch immer einen Verantwortlichen. Bei sog. „Stories“, die mehrere Unteraufgaben haben oder auch „Epics“, die über mehrere Iterationen gehen, ggf. mit unterschiedlichen Entwicklern an den jeweiligen Teilaufgaben machen die Übersicht für Außenstehende nicht einfacher. Natürlich kann man alles an den SCRUM-Master übertragen, aber das agile Manifesto stellt die Interaktion der handelnden Personen an die erste Stelle, also die direkte Kommunikation ist m.E. besser als die durch Rollen und Prozesse festgelegte.

Sorgt der SCRUM-Master für die Einhaltung der agilen Vorgehensweise, so unterstützt „storybased Ownership“, da der Verantwortliche selbst ein Interesse hat die „Definition of Done“ (und damit die Abnahmekriterien) zu erfüllen, den Build nicht durch die Tests aus dieser Story rot werden zu lassen, etc.

Der „Storyowner“ ist also der Verantwortliche, der für die Erfüllung der „Definition of Done“ sorgt und somit dazu beiträgt das sein Teilergebnis nicht im „toll ein anderer macht‘s“-Wirrwarr von agilen Teams untergeht. Gleichzeitig wird der SCRUM-Master entlastet.

So macht man nicht nur Projekt-, Bereichs-, Produkt- und andere Leiter oder -Manager glücklich, sondern auch das Team hat etwas davon, da man als „springender Tester“ oder bei großen Epics über mehrere Iterationen und gerade aus dem Urlaub kommend bspw. auch immer weiß wen man bei Unklarheiten fragen kann ohne die anderen zu stören.

Der Storyowner ist nicht allwissend, aber er weiß am Ende wie das Ganze von wem zusammengesetzt worden ist.

Disciplined Agile Delivery

In Potsdam fanden wieder die alljährlichen Agile Testing Days statt. In meinem Kurzvortrag wollte ich darauf hinweisen, das andere Geschäftszweige schon viel länger 0-Fehler-Strategien fahren [müssen] und das mit grossem Erfolg. IT‘ler würden gut daran tun sich auch mal in sog. „klassischen Geschäftsfeldern“ nach Qualitäts-Prozessen umzusehen. Ich hatte sehr nette Gespräche im Anschluss an den 10-Minutenvortrag.

Was aber viel spannender klang das was Scott W. Ambler versuchte dem Auditorium zu vermitteln: Nehmt die Disziplinen aller agilen Vorgehensweisen und Techniken und zieht das Beste für Euch heraus – hey, mein Reden seit nunmehr eineinhalb Jahrzehnten 🙂 Scott nennt es Disciplined Agile Delivery (DAD) und der Fokus liegt auf überstellen einer für den Kunden benutzbaren Lösung – und nicht nur der Software.

Na also! Ich erwarte von Software Auspacken-Anschliessen-Einschalten-Funktioniert-Mentalität, wie bspw. Apple es immer wieder sher erfolgreich versucht: Die Anleitung des iPhones, eines iMacs oder der Software iWork können Sie auch wegschmeissen, dann die Sachen erklären sich weitesgehend von alleine und sie erfüllen Ihren Hauptzweck. Aus.

So ist es in anderen Bereichen unseres Lebens schon länger, aber ich befürchte, es wird noch mind. 10-20 Jahre dauern, bevor auch IT so nutzbar wird, das es nicht als was „besonderes“ verstanden, sondern einfach nur genutzt wird.

Wo Softwarequlität wirklich entsteht

Endlich hat jemand mal aus Entwicklersicht beschrieben wie ich als Tester mir vorstelle, Software von Anfang an mit guter Qualität zu entwickeln.

Die Empfehlung dieses Artikels ist auf so breites positives Echo bei den Entwicklern gestoßen, das ich es nun auch öffentlich mal hervorheben möchte.

LESEN SIE DIESEN ARTIKEL!

Von Schrauben und Kartons: Wo Softwarequalität wirklich entsteht
Michael „Pul” Paulsen

„Pul“ findet anscheinend die richtigen Worte und beschreibt auch die „old school“-Methode, die viele Ältere von uns noch kennen und von diesem Weg nicht abweichen wollen (Gewohnheit). Trial & Error im Debugger war aber gestern und auch wenn man das noch so gewohnt ist, so kann man durch ein wenig Anpassung der Vorgehensweise mithelfen von Anfang an gute Softwarequalität herzustellen.

Fangen Sie damit an!