Die Neuerungen von Firefox 47 (Desktop)

Insgesamt 13 Sicherheitslücken hat Mozilla in Firefox 47 geschlossen, von denen Mozilla zwei als besonders kritisch einstuft. Alleine aus Gründen der Sicherheit ist daher ein Update auf Version 47 für alle Firefox-Nutzer empfohlen.

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

Für Thunderbird-Entwicklung kann ab sofort gespendet werden

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.

Programmiersprache: Rust 1.8 steht bereit

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.