Хоча помилка може статися на будь-якому етапі: від невірно сформульованого юзерсторі до некоректної імплементації. Та попри це, відповідати найчастіше доводиться саме QA.
Саме тому QA мають відрізнятися від манкі-тостерів!
це залежить від продукту і сфери, в деяких галузях мабуть взагалі заборонено працювати без QA відділу. В геймдеві випускати ігри/оновлення без попередьного тестування це норма.
Катерино, підкажіть, будь ласка, а як подивитися тих, хто пише сугубо технічні статті і щоб їх номінувати? Я не знаю, чи є така опція, але я впевнена, що це буде справедливо. Дякую.
Це фактично не вдалось продати стекхолдерам QA процесс. Дуже часто мав таку проблему. Без чисел — з дуже ясною презентацією, які покажуть — що QA гарна ідея з фінансової точки зору, буде важко.
Скажіть, будь ласка, а якщо розглядати,як приклад, нещодавні пошуки лимонів від монобанку. По сути, всі користувачі монобанку були пару днів тестувальниками. Чи після цього є доцільним брати в штат тестувальників, чи вже було достатньо звичайних користувачів?
Зазвичай більшість багів за статистикою пов’язані із невірним використанням API та інтерфейсів.
Еее, ну це, якщо чесно, вже якийсь дитячий садок або лютий ковбой кодинг.
По ідеї на початок 90х вже не було ніякого креслення як обов’язкова дисципліна на звичайних університетських факультетах (такі як нп фізика etc. вже не було на кінець 80х), а на 94й... тобто де то залишалося — взагалі загадка.
А чому до кого ? Писати треба — що не так. Тобто які результати очікуються, які результати по факту і як цього досягнути, шляхи до відтворення. Таким чином будь який розробник зможе визначити першопричину і виправити помилку.
Поки конкретні моделі не розглядала, тестила у знайомих BMW I3 (тут по запасу малувато), VW ID4 та Unix дуже комфортні і нормальний запас ходу. Ну і те, що ID4 уже доволі багато в Україні, тому проблем з ремонтом чи деталями не має бути.
Назар Степорук
Коментарі