100% Coverage is Possible

It doesn’t tell us anything about what the programmers intended, what the user desired, or what the tester observed. It says nothing about the tester’s engagement with the testing; whether the tester was asleep or awake.

Quelle: 100% Coverage is Possible | Developsense Blog

Ich bin ja auch ein Gegner dieser Code-Coverage-Diskussion, schon immer, denn ein Programm läuft auf etwas (OS, Hardware) und mit etwas (Framework, Webserver, …) und niemals alleine. Was nützt es 100% Code abzudecken, wenn der im Kontext wieder mal nur 10% des Universums ausmacht? Genau – nichts! Michael Bolton beschreibt das m.E. sehr gut:

Here’s just one example: code coverage is usually described in terms of the code that we’ve written, or that we have available to evaluate. Yet every program we write interacts with some platform that might include third-party libraries, browsers, plug-ins, operating systems, file systems, firmware. Our code might interact with our own libraries that we haven’t instrumented this time. So “code coverage” refers to some code in the system, but not all the code in the system.

Codeabdeckung ist ein Indikator um zu schauen, ob die Entwicklung versucht hat selbst festzustellen, ob sie das richtige Stück Software entwickelt hat – so verklausuliere ich das für mich. Man kann das unterschiedlich versuchen, bspw. sagt man in einem Projekt das einem die Geschäftsprozesse wichtig sind und man schreibt für diese aufwendige Tests, damit die bei jeder Codeänderung nach wie vor wie gewünsccht funktionieren. Selbst wenn die Codeabdeckung dort 100% erreichen würde, so sind die Außeneinflüsse unberücksichtigt, aber man hat sich mal für einen Weg entschieden (<schmerzliche> Erfahrungen tragen oft auch dazu bei), da man so den Kunden immer glücklich machen konnte und wenig bis gar keine Rückläufer (Fehler) bekam. Darauf kommt es letztendlich an.

Es wird mir wohl immer ein Rätsel bleiben, warum Projektlenker sehr oft auf diese Metrik schauen, ohne zu sehen was dahinter steckt, denn kluge Köpfe haben es auch nicht geschafft und warten darauf, das es ihnen jemand sagt, wie es geht:

James Bach doesn’t know how to do it. Jerry Weinberg doesn’t know how to do it. Cem Kaner doesn’t know how to do it. Other than what I’ve said above, to my knowledge, no one knows how to do it. So, it would be up to the client to explain how they think I could do it.

Kampf gegen Cyberattacken und Terrorismus: Dänischer Geheimdienst will Hacker in Akademie ausbilden | shz.de

Das dänische Außenministerium zum Beispiel war einer sieben Monate andauernden Phishing-Attacke ausgesetzt. Die Webseite des Parlaments wurde im Dezember von sogenannten DDoS-Attacken (massenhafte Anfragen an eine Webseite) in die Knie gezwungen. Gründe genug für den dänischen Geheimdienst DDIS (Danish Defense Intelligence Service), eine Akademie für Hacker ins Leben zu rufen. Wie das Nachrichtenportal „qz.com“ berichtet, ist der Bedarf an Experten für Cybersicherheit im Königreich nebenan groß.

Quelle: Kampf gegen Cyberattacken und Terrorismus: Dänischer Geheimdienst will Hacker in Akademie ausbilden | shz.de

Liebe Dänen, lieber sh:z,

mit Hackern Phising- oder DDoS-Attacken zu verhindern ist irgendwie komisch, denn das sollten auch Sicherheits-Testerinnen und -Tester hinbekommen und professionelle IT-Leute, die es mit der Qualität und den nicht-funktionalen Anforderungen genau nehmen.

Phishing-Attacken verhindert man durch Erziehung der Menschen, die mit den Einganstoren (Web-Seiten, E-Mails) umgehen. DDoS-Attacken zu verhindern geht nicht, aber man kann Szenarien bauen, die diese erkennen, um auf einen robusteren Modus umzustellen.

Dafür braucht es ein gutes Handbuch.

12 Test Automation Trends for 2016

We’re All Testers Now
I remember the days when QA testers were treated almost as second-class citizens and developers ruled the software world. But as I was creating this presentation a funny thought occurred to me: we’re all testers now.

Quelle: 12 Test Automation Trends for 2016 [Infographic] – Joe Colantonio – Succeeding with Test Automation Awesomeness. I’ll show you how!

Ja, im Laufe der letzten zwei Jahrzehnte hat sich das grundlegend gewandelt. Heute steht ein ähnlicher Satz in unserer Teststrategie 🙂

Is it Possible to do Sufficient Testing Without QA Resource?

Yahoo eliminated their test and quality assurance department. Instead developers are doing their own testing. Can they test sufficiently without QA resource?

(…) unit testing only catches programmer errors in code, unit testing does not detect failures in the application, which means if you have 100% code coverage, that does not mean a bug free application.

Testers can pair with developers to write better unit tests and developers can help testers with writing automated checks and also educate testers about the architecture of the application so that they can design good tests to find the areas most likely to break during system testing.

Testers can ensure developers follow best quality assurance practices and assist with technical and business test designs to help identify the most critical bugs before releasing software.

Quelle: Is it Possible to do Sufficient Testing Without QA Resource?

Welcome to the Test-Coaching-Age, Yahoo!

SAHI Pro 6.2.0

Sahi Pro v6.2.0 is a major release with significant fixes and enhancements.

Significant changes are:

  • Microsoft Edge Support
  • Multi Language Support: eg. record for English and playback for Japanese
  • Passing External data to Scenario files
  • Sahi Pro Runner: playback only version of Sahi Pro for CI and build systems
  • Enhancements in reports
  • License Server: for monitoring concurrent licenses

Please have a look at What’s new in Sahi Pro v6.2.0 for details.

Clean Code nicht als Selbszweck

Der Appell der Clean Code Developer an die Professionalität ist gut, hilft aber nur Idealisten, denn so wird nur die intrinsische Motivation angesprochen. Das ist gut, aber im Clean Coding Cosmos soll auch die extrinsische genutzt werden. Eine gegenseitige Qualitätskontrolle im Team ist dagegen viel wirkungsvoller. Diese funktioniert allerdings nur mit effektiver Kommunikation.

Quelle: CleanCoding2 | Clean Coding Cosmos

Clean Code Developer mit oftmals dem falsch verstandenem Ansatz der reinen Methoden- bzw. Klassentests sollten sich oben angegebenen Absatz mal auf der Zunge zergehen lassen und ggf. mal die vier Teile des Clean Code Cosmos aus der ObjektSpektrum lesen. Wenn Code-Nerds nämlich nicht miteinander reden, kommt da meistens nichts Gutes bei raus.

eVote nicht unbedingt erstrebenswert

Quelle: The Hacker News | 191 Million US Voters‘ Personal Info Exposed by Misconfigured Database

Ich verstehe nicht, angesichts der Sensibilität der Daten, das so ein plumper Fehler nicht entdeckt wird. Gerade die US-Boys’n’Girls sind in Sachen Softwaretest recht weit vorne – ich befürchte nur die haben dieselben Probleme wie wir hierzulande: Testen? Kommt am Ende – wenn noch Zeit ist 🙂

Die deutschen Top 25 der „Tech“-Medien im Netz – nichts gelernt

1 Chip Online

2 Computerbild

Quelle: Die deutschen Top 25 der Tech-Medien im Netz | t3n

Da wundert es mich wirklich nicht, das die Probleme für Endanwender nicht weniger sondern mehr werden, wenn man sich diese Nullbrainer-Magazine reinzieht. Ja, ist eome subjektive Meinung, aber man lernt aus diesen Quellen einfach halbgare Dinge und wundert sich, wenn man dann dem Newbie-Status entwachsen zu sein scheint, das man sich mit Profis nicht unterhalten kann…

Beispiel: Die Zweitplatzierte hat zu ISDN-Zeiten schon immer „Modems“ zu ISDN-Terminaladaptoren geschrieben und es war ihnen einfach – auch per Leserbrief in den 90ern – nicht beizubringen die korrekten Ausdrücke und nicht ihre Marketing-/Designerbuden-Buzzwords zu verwenden. Tja, was macht ein Modem was ein Terminaladapter nicht macht?!?

Als Tester von Entwicklern und Projektleitern zitiert werden

Manchmal ist der Frust ja recht groß, wenn man immer und immer wieder dasselbe als Tester erzählen muss und man oft den Eindruck hat es hört eh kaum einer zu. Manchmal gibt es aber Lichtblitze, die den Tag echt versüßen können:

Letztens wurde mir bei einem Treffen der STUGHH gesagt, dass ein Entwickler auch nach über sechs Jahren, die wir nicht mehr gemeinsam an Projekten arbeiten, meine Aussagen zitiert, wie ich denn als Tester Dinge angehe – Wow!

Heute trudelte dann ’ne Mail ein

Jetzt wo wir nicht mehr zusammen arbeiten zitiere ich Dich recht oft… 😉

Na, es hilft also doch was, auch wenn ich nun davon direkt nichts habe, aber es freut mich, das es eben doch manchmal auf fruchtbaren Boden fällt und anscheinend hilft 🙂

 

Androids Uhr geht nach, iOS Wecker putt

Fefe schrieb das auf was Jürgen ihm zutrug [1] und ich auch mal erwähnen möchte, da mir das schon auf den Zeiger ging, als die iOS 9 Uhr wieder mal nicht so lief wie sie sollte… naja, nun ist wohl der Wecker bei iOS putt [2]…. Qualität war gestern…

Quelle 1: Issue 189789 – android – Clock sync / clock running slow – Android Open Source Project – Issue Tracker – Google Project Hosting

Quelle 2: iOS 9: Automatisches Update dreht Wecker ab – Heise