85 Millionen Android-Geräte von HummingBad-Malware befallen

Den Sicherheitsforschern von Checkpoint zufolge hat sich der Android-Trojaner HummingBad weltweit mittlerweile auf 85 Millionen Geräten eingenistet. In Deutschland seien 40.000 Smartphones und Tablets betroffen; insgesamt habe es hierzulande über 13 Millionen Angriffsversuche gegeben, schreibt Checkpoint in einer aktuellen Veröffentlichung. Ob ein Gerät infiziert ist, könne man nicht ohne Weiteres erkennen.

Quelle: 85 Millionen Android-Geräte von HummingBad-Malware befallen | heise online

Spätestens jetzt, wenn nicht schon nach dieser Meldung,

Die Voll-Verschlüsselung von Android-Smartphones weist ein ernsthaftes Design-Problem auf, das die geschützten Daten sehr angreifbar macht, erklärt ein Sicherheits-Forscher. Er belegt dies mit konkretem Code, der Brute-Force-Angriffe demonstriert.

Quelle: Heftiger Schlag für Android-Verschlüsselung | heise online

dann würde ich spätestens jetzt mal über die Auswahl des mobilen OS nachdenken.

Migration of EPEX HUPX and SEEPEX Auction Limits to SMSS

On 1st July 2016 ECC will migrate the existing financial Trading Limits for EPEX, HUPX and SEEPEX auction markets to the ECC Self Service Limit Maintenance within the Member Area of SMSS. (…) additional optional fields are introduced that will allow Clearing Members and Settlement Members of ECC to define Trading Limits on a more granular level.

Quelle: 20160609 ECC Clearing Circular No 27 Migration of EPEX HUPX and SEEPEX Auction Limits to SMSS – 20160609-ecc-clearing-circular-no–27-migration-of-epex-hupx-and-seepex-auction-limits-to-smss-data.pdf

Tue Gutes und sprich darüber 🙂 Well done!

SMSS = Spot Market Settlement System
ECC = European Commodity Clearing

Quality Specialist – eine Rollenbeschreibung

Wir agieren als Quality-Coach des Teams
(…)
Wir begleiten den kompletten Story-Lifecycle
(…)
Wir treiben Continuous Delivery / Continuous Deployment
(…)
Wir balancieren die unterschiedlichen Testarten der Testpyramide
(…)
Wir helfen dem Team die richtigen Methoden für hohe Qualität einzusetzen
(…)
Wir sind im Pairing aktiv
(…)
Wir vertreten unterschiedliche Perspektiven
(…)
Wir sind Kommunikationstalent

Quelle: Sind wir wirklich nur Testmanagerinnen? | dev.otto.de

Bei OTTO lacht man sich nicht nur scheckig….ach, das war der andere OTTO, okay… bei OTTO kauft man nicht nur gut ein, sondern das eine oder andere Mal haben die Entwicklungsteams dort auch schon gute Workshops im Rahmen von der Softwaretesting User Group Hamburg (STUGHH) gehabt. Nun, der obige Abriss aus einem sehr guten Blog-Eintrag zeigt auch: OTTO ist in der Welt angekommen, wie ich die Rolle eines Quality Specialists verstehe – in meiner Firma auch gerne „Qualitätsmensch“ genannt 🙂

Wer eine sinnvolle Beschreibung der (agilen) Test(manag)er(in)-Rolle von heute sucht, wird da auf einfachste Weise fündig. Well done OTTO!

Selenium 3.0, the Spec, and Onwards – with Simon Stewart, Selenium Project Lead

Watch Simon Stewart, Selenium Project Lead and inventor of WebDriver, as he gives a sneak peek at the upcoming release of Selenium 3.0, and onwards.

In this webinar, Simon covered the following topics:

  • What will this release contain
  • What impact will it have on your test runs
  • How can you preserve your existing investment in tests using the Selenium WebDriver APIs, and your even older RC tests
  • Looking forward, when will the W3C spec be complete
  • What can we expect from Selenium 4

UniTEE is now an Open Source Project (v3.x onwards)

Unitee version 3.0r1 is now available for download.

UniTEE stands for Unified Test Engine Exemplified, and is pronounced as /ˈjuːnɪti/ (unity). It is also spelled as Unitee elsewhere.

It is a test automation engine developed by Rahul Verma, with one key goal: Unification. It targets unification of different types of test case writing, for different types of test automation, at different layers, in different languages, for different purposes, applied in different development models, for different kinds of products and so on.

This is the third major release and the key milestone is that UniTEE is now open source project licensed under Apache License 2.0..

Critical Changes

  • Unitee is now a tool/top layer component which focuses on providing features like a Command Line interface, initialization of configuration for other components and so on.
  • The core functionality is now provided by 15 loosely coupled AutoCognite components. These components are available as separate downloads and have their own respective GitHub repositories. The sources are also made available in a given AutoCognite distribution. This architecture allows users to use components independent of Unitee.
  • The components are also available as 3 kits/bundles. This allows users to use components independent of Unitee, while also saving them from additional work of identifying what all to download for a particular purpose.
  • AutoCognite Documentation has been updated to reflect these changes. The AutoCognite website has also undergone a change in its structure as per this approach.
  • All the downloads for Unitee, kits and components along with sources are placed under a single parent AutoCognite-ver-x.y directory in the download location.
  • AutoCognite examples on GitHub have been updated as per the new version.

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!