Слав, у нас менеджеры очень плотно работают и без ручного тестирования. И у нас нет «Project Managers» у нас есть «Product Managers» (railsware.com/careers/product-manager) вот тут можно посмотреть требования.

Браво! Прочитать статью и не понять основной сути!

Концепция «T Shape» о качестве. Рейты это производная.

Обычно пишет скрам-мастер и команда дополняет расширяет в процессе. И эту статью все-таки стоит читать после этой dou.ua/...​manual-testing-railsware, в ней чуть больше деталей по QA как процессу в целом.

Ярослава,

Если быть точным $75/час

этакая

Это какая :) ?

Максим, я очень рад, что получилось донести важность идеи «обмена фичами»!

Кстати, Сергей, а Вы как-то мониторили напрямую метрики по багам до и после внедрения такого подхода?

Дело в том, что у нас не было изначальной цели внедрить такой подход одномоментно, все происходило постепенно и естественно. Потому не было четкого эксперимент с одинаковыми входными параметрами и сравнения двух подходов.

Денис, спасибо за комментарии.
Часть из них не совсем корректны, но это скорее проблема глубины описания с моей стороны.

звичайне регресивне тестування

Да действительно под капотом концепция регрессионного тестирования и Test Fest это не новая концепция тестирование это процесс вокруг тестирования. Так что противоречия нет

ваш тестфест триває день

Непосредственная фаза тестирования длиться часа 2-3, остальная же часть дня — это работа со скоупом и устранение наиболее важных проблем, очевидно что тестировщики не могут выполнять часть этих функций. Давайте так же не игнорировать один из ключевых моментов — обмен фичами. Как инженер я знаю, что занимаясь своим набором фич ты просто теряешь из виду что происходит в соседних бранчах. И это в целом влияет на то насколько крутые будут твои идеи для решения поставленых перед тобой задач. И еще немаловажный факт это дисциплина, которая значительно повышается в рядах инженеров — нет ощущения что сделаю как-нибудь, если будут проблемы — их найдут тестировщики.

Но опять же не отрицаю что есть проекты в которых будет целесообразно ко всему выше изложенному добавить еще и тестировщика.

Мы же ему не будем говорить, нету денег на тесты с самого начала, уходи?

Просто нет такого понятия как «деньги на тесты». Нужно принять, что это все часть фичи. Если клиент приходит и говорит: «вы мне сделайте машину, чтобы ездила, но только на разработку шасси у меня денег нет» вы ж не скажите а ну окей сделаем машину без шасси что бы не впадать в крайности и не гворить клиентоу уходи.

В стандартом представлении его там нет. Ну нет там людей чья основная работа сводиться к постоянному ручному тестированию. А вот подходы как выпустить качественный продукт там есть.

Я понимаю что есть желание словить меня на слове. Но если не брать только часть фразы, то смысл появляется другой. По сути они используют фидбек комьюнити для улучшения продукта. Так делают не только Open Source проекты и это отличная практика. И я не утверждаю в статье что вообще нет примеров использования ручного тестирования — я говорю о том что в Outsourcing индустрии его слишком много и используется там где можно обойтись без него.

И если зайти глубже в ссылки developer.mozilla.org/...​_one_of_our_quality_teams
то можно увидеть что речь идет не совсем о ручном тестировании.

есть прототипы, внутренние эксперименты, есть проекты в процессе миграции от предшественников ну и наши косяки иногда тоже есть (но их действительно не много)

после предшественников мы зачастую постепенно рефакторим и покрываем тестами те места которых касаемся

sweet... все что я хотел сказать но ленился написать :) спасибо

Касательно ограниченного бюджета. Если нет денег на то что бы начинать нормальный бизнес то может и не стоит его начинать и тесты тут не причем.

Я понимаю что для тебя ценно поддерживать дискуссию, но может все таки почитаешь книги и попробуешь сам что-то сделать с тестами и без них?

Я уже писал что с тестами писать быстрее — если мы не пишем двухнедельный прототип. А быстрее потому, что тесты помогают держать технический долг на низком уровне. Если ты знаешь что такое технический долг, то мне и продавать тебе ничего не нужно.

Спасибо, стараемся.

Тесты несомненно важны. Они сразу помогают локализовывать ошибки без траты времени на их обнаружение при тестировании.

Николай а ты про программирование знаешь из личного опыта или понаслышке? По твоим комментариям видно что ты в принципе не понимаешь для чего тесты нужны, и приведенный пример про срочность вообще не том. Если что-то срочно — то это не продукт это прототип и нужно называть вещи своими именами. Да для прототипа тесты не обязательны.

Очень часто у команд не пишущих тесты находится миллион причин. То инвестору нужно, то на рынок нужно срочно выйти то бюджет маленький. Нужно выставлять уровень качества ниже которого вы не опускаетесь и уже плясать от туда. Тесты это не дополнительная опция это обязательная часть фичи. И кстати считать что с тестами медленнее — это заблуждение. Тесты сильно экономят время и нервы в среднесрочной перспективе и делают продукт поддерживаемым. Без тестов же всегда команда приходит к выводу что «нужно все переписать на новую технологию»

В стандартом представлении его там нет. Ну нет там людей чья основная работа сводиться к постоянному ручному тестированию. А вот подходы как выпустить качественный продукт там есть. Вот об этом собственно и статья.

Тексты читают. Но в этом конкретном случае под вычиткой подразумевалось нечто другое. Для меня не до конца прозрачный намек.

У меня достаточно опыта на различных позициях, что бы изложить видение без дополнительных вычиток. К тому же это не история о том как бы мы хотели сделать, а история о том как было сделано. Если есть комментарии по сути, то было бы интересно прочитать.

Конечно удалось найти, и не одного. И кстати хороший менеджер не обязательно должен быть лузером в инженерии — это стереотип.