от жеж повівся я на заголовок) очікування від статті були трохи більші.

все вірно, але це теорія, яка останні роки перетікає зі статті в статтю.
Як на мене, це загальний підхід до тестування любого BI проекту. Big data проекти ж відрізняються технологіями, на яких реалізоване рішення, де складність додають обєми даних, швидкістю опрацювання і т.д. (і знову таки це дуже субєктивно, де межа, що ось це вже біг дата проект, а цей ще ні). В багатьох випадках приставка Big data до проекту використовується для додавання такої «перчинки» і вагомості.

хотілося б почути практику:
— яким чином і підходом на практиці ви реалізували види тестування, описані в статті, особливо Data Validation Testing, Accuracy Testing
— які існують нові тулзи, що вміють порівнювати дані

всьо цікаво, но щось не так

Як проводити Design Sprint 2.0

Design Sprint 2.0 — це оновлений 4-денний процес

День 0 + День 1 + День 2 + День 3 + День 4 + День 5 = 6
не зійшлося

то все тестери винуваті :)

чого) виділитись =)

Круто читати такі статті, успіху і натхнення у Вашій нелегкій справі ;)

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

Ви праві, але знову ж таки. з 3 переваг описаних в

Среди основных преимуществ трансформации QA и применения TestFest-ов выделю следующие:

1. Девелопери і так мали б знати не тільки свою функціональність. В даному випаду цей тестфест просто помагає вивчити інші...
2.

они изначально более ответственно относятся к написанию кода

це смішно читати. толку з девів які не відповідально відносяться...
3.

TestFest помогает быстрее выявлять проблемы в продукте

як? якщо він проводиться в кінці ітерації... це явно значно пізніше ніж можна було б.

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

В активной фазе TestFest-ом заканчивается каждая итерация (раз в 2 недели)

якщо відкинути зайві навзи, то testfest звичайне регресивне тестування в кінці спринта яке покриває end-to-end сценарії більше. можливо чуть інакше побудоване.

Участники команды тестируют соседние фичи (те, которые не разрабатывали сами)

давайте переведемо в цифри. Спринт 2 тижні, тобто 10 робочих днів, ваш тестфест триває день. команда скільки людей? ну хай 5-7. тобто це приблизно 7 людино/днів, з середньою зп більшою ніж в тестерів. З грубша ви на ці ж кошти могли найняти одного мідл тестера, який б працював цілий спритн.
Пятниця вечір, є результати тестфесту... баги, які впринципі можна було знайти протягом спринту і пофіксати їх.

а оце капці

TestFest не стоит проводить непосредственно перед релизом. В случае выявления багов, вам понадобится время для исправления наиболее критичных и тех, которые не могут ждать следующей итерации.

перефразую як воно звучить. Не тестуйте перед релізом, бо можуть бути баги, на які треба час щоб пофіксати. Релізьте з багами....

а як увас з перевіркою дефектів?

і як завжди, гарного дня ;)

тут ще треба дивитсь іншу сторону. для чого курси тим хто ці курси проводить.
Я б виділив основні два типи шкіл — незалежні та при компаніях. На ринку потрібні обоє, так як переважно тіки великі компанії можуть собі дозволити утримувати школи. В багатьох компаніях курси з безплатних переросли в платні. Тому ці школи різняться між собою, але для обох це стало бізнесом (школи при компаніях стали ланкою рекретингу в цій компанії).
І щось мені думається, що мета допомогти людям здобути освіту далеко не основна ціль.
Відповідно між курсами виникає конкуренція за людьми хто йде на ці курси (хоча думаю що людей більш ніж хватає, принаймі пару років тому було). Один з простих критеріїв якості курсів — це відсоток людей які працевлаштувались на роботу після курсів і це веде до того що описував автор -> людей не вчать тестувати, а готують до співбесід.

Окремо ще б відзначив. Для себе розділяв знання на знання теорії, її розуміння і найважливіше то вміння її застосувати. Часто люди після курсів зупиняються тільки на знанні теорії

В цікавий час живемо ;)

хехе, нормальний підхід. описати процеси на проекті. в коментарях розжують проблемні місця, поправити процеси — ляпота)
вангую, що зараз набіжить тестерів з криком... ааа, забирають хліб!

цікаво побачити було б відсотковому значенні на скільки менше багів і т.д.
Більшість того, що ви пишете воно звісно впливає в якійсь мірі на якість кінцевого продукту. Доцільність впровадження одгого чи іншого процесу впершу чергу залежить від проекту. Грубо кажучи — додали код ревю — стало краще там то. стали деви витрачати більше часу, але виловлюється певна кількість багів. Забрали тестерів, зекономили грошей, хз чи вплинуло на якість =)

TestFest

ніколи ранше не чув, і щось ненагуглив (погано гуглив). та такі речі давно вже названі... якби регресивним тестуванням. хоча нові назви, нові тренди... чекаю статтю.

В ней участвуют инженеры, продакт-менеджеры, иногда UI/UX дизайнеры, команда со стороны клиента

така толока звісно класно, але без системного підходу, якогось мінімального плану не дає вам ніякої гарантії, що все буде перетестовано

Разработка с ручным тестированием

розділ це крах, якщо у вас так було... то проблема, здається, не в тестерах

якісних продуктів вам ;)

і справді цікавіше ніж більшість статей про переїзди, недоїзди і т.д.
мене ще на співбесідах часто цікавить не тільки знання функцій, а вміння їх застосувати
типу знаю count, group by і having. а дублікати в колонці знайти не можу

не раз зустрічав в розмовах, що люди не розуміють для чого ISTQB.
З доцільності ISTQB все доволі просто:
— для людини, папірець, який підтверджує певний рівень знань теорії;
— для компанії(аутсорс-аутстаф), легше продати 5 сертифікованих тестерів, ніж просто 5 тестерів;
— для спільноти тестерів, стандарт, можливість опиратись на одні і ті самі поняття-терміни. Не раз зустрічав що одні і ті самі речі в різних компаніях називають по різному.

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

Рецепт ж підготовки до здачі дуже простий — книжка і заклікувати тести (власне вони і дають основну підготовку). Хто здав просто прочитавши книжку — ви мій герой.

Сам не здавав, напевно варто буде ;) гарного дня

на доу якийсь водопад статей на теми: ІТ в Ураїні, Україна це ІТ, ІТ в цифрах і т.д.. Таке враження що тільки лінивий не пофілософствував на цю тему.
Молодець, супер заклик, тільки тоді ще в темі треба було додати таки кому в правильному місці.
стаття про... вода-вода, реклама, пару слів про патріотизм, і знову вода-вода.
гарного дня!

почитав, поржав, пішов.
таке враження, що пані Донцова найшла новий стиль/місце. Чекаю нову книжку =)

а ви помітили, що більшість коментів від тестерів? зачіпило певно =)