Pull to refresh

Comments 9

>Каждый тестировщик должен сам понимать, чем сейчас нужно заниматься

Кто и как это контролирует?
В теории, мы стараемся не брать разгильдяев, но реальность, конечно же, гораздо суровей.
Вообще, считается, что ПМ узнает о подобном из-за возросшего количества повисших на одном человеке задач на скрам-доске, но в запущенных случаях об этом узнают после откаченного неудачного релиза. Дальше команда ищет причины ошибок и если оказывается, что тестировщик Гвидон не проверил важную задачу, а был занят другими, на его взгляд, более важными вещами, то, естественно, ему делают атата.
По идее этим должен заниматься тест-лид или тест-менеджер.
Статья звучит так:

Если вы хоть немного понимаете в IT, и хоть немного не глупый — приходите к нам, у нас весело.

То, что описано в статье, адекватный человек (если ему платить адекватные деньги), понимает за месяц. Если набирать «школьников» и отпускать их на вольные хлеба (чтобы они бегали, теребили своих коллег и прочее), то конечно, начнутся «первые» месяцы вникания.
бох ты мой… а простой юзер потом на элементарных вещах вспотыкается…
Странно выглядит, когда пирамида Маслоу упоминается в статье ровно один раз, но в конце написано «это всё была пирамида».
Раскройте, что ли, как уровни описанной пирамиды связаны в вашем пониманиии, аналогия-то интересная.
Любой проект начинается с технического решения, после реализации которого к процессу подключается тестировщик.

Т.е. само техническое решение не тестируется? А я вот в умных книжках читал и в жизни имею несчастье наблюдать, что не протестированное техническое решение — это боль, страдание и отчаянье, тлен, тоска и безысходность. Ну и много других подобных слов.

Да, техническое задание стараемся тоже тестировать. Иногда бывает так, что проект тяжелый и сложный, и техническое задание пишется по ходу дела, но в таких случаях определенно можно сказать, что ошибок будет много везде, не только в ТЗ
Sign up to leave a comment.