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!

Influencing Factor Estimation

In a tweet I agreed on do not use Excel for test management – I hate it since the 90s 🙂

and Michael Bolton answered on the thread later

So, I decided to write down now how I try to get data for getting estimations on a project without making complicated calculation where I would need Excel 🙂 I have used this in bigger projects (18 months estimation planning) as well as in smaller ones. The factors can differ but it is agile – just make small updates based on your experiences….

Common

On two aspects you need to take care

  1. Estimation for the code creation (production code, class- and method-tests, documentation, integration- and systemtests, internal acceptance)
  2. Estimation for additional aspects like project-management, test-cycles and external acceptance

Estimation of software creation

The method is based on the assumption that experienced code developers can estimate very good their own work time on a task they have to finish – means: coding time, not the rest of it. The estimation will grow with the influences which the code developer has not under control. The following table

  • is based on experience and not a „that’s it“-solution but in summary the average through development cycles will match
  • describes the additional effort which has to be added to the estimation of the pure  coding estimation (Estimation = 1):
Developer creates codeadditional effort to the pure code estimationNotes
without using foreign code1Normal in a development team
with using open sourced code inside the company/project2e.g. using code from other groups inside the company - knowledge can be easily transferred
with using open sourced code from outside the project/company 3 - 5; 3 is normal, 5 is the worst casee.g. using an unknown (in the project team) open source framework or extremly high performance requirements
with using closed source code3 - 5; 3 not often found case, 5 normale.g. using a closed source framework as it is
with the need to use closed source software (3rd party) for integration5 - 9e.g. integrate a service which reachability is not under control of the project team

Examples:

  1. Developer estimates 6 work days for pure code development. The developer needs to use a class(s) which are already part of the project. 1 x 6 work days needs to be added. In summary the estimation for getting the task done is 12 work days for the code, unit tests, documentation, integration and internal acceptance.
  2. Developer estimates 5 work days for pure code development. The developer needs to use an open source framework of a third party, The knowledge is nearly zero in the project team. 3 x 5 up to 5 x 5 work days needs to be added. In summary you get then an estimation of 20-30 for all needed work tasks.

 

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