Что почитать про релизы, тестирование и поддержку в общем.

Тестирование зависит только от модели разработки и наличия требований. Обычно если эти две вещи разбираются, то и тестирование.

Здравствуйте, насколько я понимаю, под

создавать релизы, вести поддержку, организовывать тестирование

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

Прочтите, пожалуйста, данную книгу.

возможно оно, погляжу.

если назревает действительно серьезный и длительный проект.

не назревает, а уже идёт. Я просто хотел бы навести порядок, повысить качество и стабильность.

какая вообще связь между номерами версий, созданием релизов, ведением поддержки и организацией тестирования?

по тестированию книг валом, начиная от библий: The Software Test Engineer's Handbook для планирования и Foundations of Software Testing для собственно тестирования, заканчивая графоманией из вот этого списка: http://www.happy-pm.com/blog/?p=1626

Огромная и неразрывная :), почитайте книгу, что я дал выше. Все это вместе как раз и называется Continuous delivery. И вообще, на эту тему много книг написано, потрясите гугл. Просто лично мне нравится именно эта книга, т.к. она абстрагирована от конкретных сред или ЯП. А есть книги о Continuous delivery заточенные под определенные среды. Допустим, вот.

Для себя юзаю такой: major.minor.something

major - версия API. Внутри одного major, API не ломается (обратная совместимость).

minor - добавление новых фич к текущему API.

something - фикс багов без обновления API.

попустись, проповедник: continuous delivery и организация тестирования - вещи абсолютно ортогональные.

continuous delivery и организация тестирования - вещи абсолютно ортогональны

Сказал человек, даже не читавший о continuous delivery. Не то что книги по данной тематике=) Тестирование - одна из частей continuous delivery, т.к. без тестирования невозможна нормальная разработка, без нормальной разработки невозможно нормально поддерживать версионность, без нормальной версионности нет вообще никакого смысла в презентацих вашего ПО заказчику, и уж тем более в релизах конечному пользователю. Я начинаю понимать, вы тот самый анонiмус да? Который ни в зуб ногой, но все пытается вставить какую-то тарабарщину, я уже вангую что скоро увижу бессмысленные куски кода на Io. Я сказал же больше не поведусь. И не надейтесь, последний раз вам отвечаю в этом треде=)

Тут не так много всего, чтобы ещё и книгу писать. Собственно, ты всё уже написал: semantic versioning, расширять покрытие тестов, релизы чаще, CI.

Сказал человек, даже не читавший о continuous delivery. Не то что книги по данной тематике=)

тебе виднее, что я читал что нет

Тестирование - одна из частей continuous delivery, ко-ко-ко, кудах-кудах-кудах, кукареку

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

Я начинаю понимать, вы тот самый анонiмус да? Который ни в зуб ногой, но все пытается вставить какую-то тарабарщину, я уже вангую что скоро увижу бессмысленные куски кода на Io. Я сказал же больше не поведусь. И не надейтесь, последний раз вам отвечаю в этом треде=)

мамку свою повангуй, поехавший

Тестирование зависит только от модели разработки и наличия требований.

ну вообще не совсем. от модели разработки - зависит. от наличия требований - зависит. от квалификации персонала - зависит. от совокупности рисков - зависит. много от чего зависит, на самом деле.

Отвечу сам себе, раз обещался не отвечать тебе, анонiмус :)

тестирование - одна из частей любой разработки.

Я где-то написал что разработка не может быть самостоятельным процессом, отдельным от continuous delivery? Я написал

Огромная и неразрывная :)

на

какая вообще связь между номерами версий, созданием релизов, ведением поддержки и организацией тестирования?

Дураку понятно что я говорю именно в контексте continuous delivery, раз даю на него ссылки.

continuous delivery и организация тестирования - вещи абсолютно ортогональные.

Я также возразил на это

Тестирование - одна из частей continuous delivery

что так же не противоречит

Я где-то написал что {разработка/тестирование/припёк анонiмуса/вставь что нравится} не может быть самостоятельным процессом, отдельным от continuous delivery?

Все что я написал сейчас - это я так, разъяснение самому себе, а то еще анонiмус придерется=) И кстати, анонiмус, гтфо, пожалуйста, если ты так сильно страдаешь буквоедством, и у тебя бомбит от всего подряд :)

абсолютно и полностью определяется отделом тестирования

организации с «отделом тестирования» уже проиграли.

ну если отдел тестирования у организации в кавычках - сами себе антропоморфные дендромутанты

не различает «организацию тестирования» и «тестирование»

раскрывает рот на эту тему

поминает анонiмуса в каждом посте

рассказывает всем, как у анонiмуса бомбит от его разъяснений

топ кек

«отдел тестирования» в большинстве организаций это плод некомпетентности менеджеров, особенно, если там работают «тестеры».

http://cs.pikabu.ru/images/big_size_comm/2013-11_3/13845120616952.jpg

не различает «организацию тестирования» и «тестирование»

волшебно

раскрывает рот на эту тему

да нет, во всём руки виноваты, я вообще молчу

поминает анонiмуса в каждом посте

мне это доставляет, почему нет?=) мы кстати тебя уже помянули, по второму кругу

рассказывает всем, как у анонiмуса бомбит от его разъяснений

Да ладно, я ведь сам с собой, жалко что-ли? :D

топ кек

Смех продлевает жизнь, анонiмус :)

от квалификации персонала - зависит. от совокупности рисков - зависит. много от чего зависит, на самом деле.

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

Господа, если хотите срацца конкретно на тему тестирования, то я с удовольствием присоединюсь и напомню самое имхо адекватное определение тестирования - это деятельность, направленная на своевременное определение качества продукта и информирование об этом команды.