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

My test manager says „I don’t wanna get back to the 90s“ when talking about Excel for managing tests. No further comment.

— (((Robert Strauch))) (@shrubbytester) 10. Juni 2016

and Michael Bolton answered on the thread later

@osxjogi … Monte Carlo simulation. Example: https://t.co/VkYCEHAAD1 @shrubbytester @ThomasPonnet

— Michael Bolton (@michaelbolton) 10. Juni 2016

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):

Influece Factors Code Development

Developer creates codeadditional
effort to
the pure
code
estimation
Notes and explanation
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.