QA battle at QAClubKiev: ISTQB - to be or not to be

Yesterday, there took place an event in a "pair competition" format or a public discussion, or even a "QA Battle"! This time with my participation. At this 19th QAClubKiev meeting, I tried to convince the audience and my dear opponent, Alexandra Kovalyova, that ISTQB Foundation Level certification is more harmful than useful. And in her turn, Alexandra tried to do the opposite.

VIDEO: The first 42m here (in Ukrainian)

Походження слова "скрам"

Щойно дізнався про походжєення слова "скрам" з чудового блоґу Wordlady:
http://katherinebarber.blogspot.com/2017/03/of-gaggles-and-scrums.html

"Scrum" is a shortening of "scrummage", a variant of "scrimmage", which is ultimately related to "skirmish". 

Перестрілка чи бійка, значить. Цікаво :-)

"5 hours a day" keeps pressure away

A common question raised by customer-side management:

• How to control software engineers? 
• How I, as a customer who pays huge bags of cash per hour to this hippies, can really know that they are not cheating me watching youtube half a day?

But even if the question is not asked explicitly, does not mean nobody has doubts alike. 

I worked in various environments. Let me review the most common solutions and their pros and cons.

"Done" for everyone!

Probably each of us had that dialogue with a developer:

- How is your task? Is it okay?

- Yeah! It's done!

- Where can I test it?

- No, it's not yet covered with unit tests / not passed code review / the last commit is almost there.

(Google points here for this picture: https://hoangluongsjsu.wordpress.com/ )

What is missing here is not exactly "Definition of "Done"", but a substitution of different levels of "Done":

- Personal "Done": "I can do nothing more about it", the task is handed over to another team member."

- Team's "Done": "We have done all we could do internally. Now we can demonstrate the results to a wider audience, but we are still open for changes and suggestions in case of interference with some other team."

- Project's "Done": "We ship it! All your claims and change requests you should send to our legal department."

Working with agile Scrum-like process which states team commitment, we should always put the Team's "Done" to tasks' Acceptance Criteria.

Because putting personal commitments to a task description looks like avoiding responsibility for possible future changes in its scope due to integration issues.

But putting project oriented goals is even worse as they are likely not to be testable at the point, when a particular task is done. That leads to "requirements inflation", when the "key project points" are written everywhere and at the same time are not met anywhere.

Watch your requirements. And keep your task descriptions clear and testable.

Рівні інтеграції коду та об’єм тестів

Тестування, як вчать книжки, відбувається на трьох рівнях:

• Integration testing
• System testing
• Acceptance testing

Класична V-модель рівням тестування ставить у відповідність стадії розробки ПЗ. Але у теперішніх умовах саме таку відповідність можна робити хіба що для певних продуктових проектів.
Більшість компаній (принаймні, мені відома) все ширше використовують agile, зокрема scrum, де розробка проходить ітераціями, коли на виході кожної має з’являтися "potentially shippable product increment" - готовий до випуску приріст фунціональності, як би самостійна частина ПЗ. Всюди панує Git Flow, модульність, де кожну фічу розробляють незалежною, із можливістю її повного вимкнення на продакшені.

Таким чином, часто кожна фіча вже є окремим продуктом, що пройшов усі стадії розробки. І усі ці рівні тестування відбуваються, або мали б відбуватися, щодня.

Тому, логічніше поставити у відповідність рівням тестування - стан коду, що перевіряється, тобто гілку у системі контролю версій:

• (Feature) Integration testing  ->  feature code branch
• System (Integration) testing  ->  develop code branch
• (System) Acceptance testing  ->  master code branch

This is a list of ideas to consider when reviewing the software development process at your project. It gives you a base-line to compare to what you already have, and simplified understanding of what you may improve.

Стратегія Тестування.
Як на мене, подібні списки ідей потрібні, щоб посидіти й поміркувати, чи все у вас на проекті так добре працює, як хотілося б, і одразу побачити шляхи покращення у кожній фазі процесу розробки.

Testing Strategy Template

Purpose

Testing is a continuous and integrated process where all parties in the project are involved. The purpose of this Test Strategy is to create a shared understanding of the overall targets, approach, tools and timing of (not only) test activities. The objective is to achieve higher quality and shorter customer request lead times with minimum overhead, frequent deliveries, close teamwork with team and the customer, continuous integration, short feedback loops and ability of frequent changes of the design. Test strategy guides us through the common obstacles with a clear view of how to evaluate the system. Lets us look at the development process as a whole.

 

This is a list of ideas to consider when reviewing the software development process at your project. It gives you a base-line to compare to what you already have, and simplified understanding of what you may improve.

Стратегія Тестування.
Як на мене, подібні списки ідей потрібні, щоб посидіти й поміркувати, чи все у вас на проекті так добре працює, як хотілося б, і одразу побачити шляхи покращення у кожній фазі процесу розробки.

Testing Strategy Template

Purpose

Testing is a continuous and integrated process where all parties in the project are involved. The purpose of this Test Strategy is to create a shared understanding of the overall targets, approach, tools and timing of (not only) test activities. The objective is to achieve higher quality and shorter customer request lead times with minimum overhead, frequent deliveries, close teamwork with team and the customer, continuous integration, short feedback loops and ability of frequent changes of the design. Test strategy guides us through the common obstacles with a clear view of how to evaluate the system. Lets us look at the development process as a whole.

Scrum та невідкладні задачі серед спринта

Усі, хто читав книжки по Scrum'у, знають про правило непорушності обсягу спринта: Усе, що включили до спринт-беклогу на плануванні, має робитись; і не можна допускати жодних змін під час самого спринта!
У той же час усі, хто працював чи намагався працювати по Scrum'у, відчули, що виконання цього правила іноді коштує дуже багато зусиль, а бува - і добрих стосунків із ПО. Особливо важко буває коли треба і підтримувати вже випущений продукт, і одночасно робити нову функціональність.
Повз мене пройшли сотні "Великих Битв за Спринт", де енергійний, щойно просвітлений еджайлом скрам-майстер, зіштовхувався з не дуже начитаним, але дуже переконливим ПО. Часом перемагав скрам-майстер. Він (чи вона) тоді виглядав героєм: тепер команда може працювати без страху, що зараз таски втратять усю бізнесову цінність.
Але коли перемагав ПО, годі було шукати людину більш розгублену, ніж щойно впевнений у майбутньому скрам-майстер. У цьому випадку або треба було скасовувати весь спринт та влаштовувати нове планування, або продовжувати старий "зіпсований" спринт. І тоді лише горбочок на burn-down chart'і щодня нагадував про програний бій.