LINUX.ORG.RU

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

 , ,


1

3

Допустим я развиваю проект: делаю релизы и веду версионирование. Иногда ломаю API.

Номера версий выбираются интуитивно, без какой-то строгой схемы. Релизы создаются когда кажется что созрел. Какая-то часть API тестируется, но не вся — на что хватило сил и времени.

Ну слышал про semantic versioning.

Возможно есть какой-то набор правил или подходов, какая-нибудь каноничная статья или книга, где бы чётко объяснялось как лучше создавать релизы, вести поддержку, организовывать тестирование?

ЛОР, порекомендуй.

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

Lordwind ★★★★★ ()

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

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

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

znenyegvkby ()
Ответ на: комментарий от znenyegvkby

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

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

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

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

vladimir-vg ★★ ()

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

znenyegvkby ()

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

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

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

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

Norgat ★★★★★ ()
Последнее исправление: Norgat (всего исправлений: 3)
Ответ на: комментарий от znenyegvkby

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

znenyegvkby ()

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

slovazap ★★★★★ ()
Ответ на: комментарий от znenyegvkby

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от Lordwind

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

на

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

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

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

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

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

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

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

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

znenyegvkby ()
Ответ на: комментарий от anonymous

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

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

val-amart ★★★★★ ()
Ответ на: комментарий от val-amart

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

anonymous ()
Ответ на: комментарий от znenyegvkby

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

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

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

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

топ кек

anonymous ()
Ответ на: комментарий от anonymous

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

val-amart ★★★★★ ()
Ответ на: комментарий от znenyegvkby

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

волшебно

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

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

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

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

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

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

топ кек

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

znenyegvkby ()
Ответ на: комментарий от anonymous

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

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

Lordwind ★★★★★ ()

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

Lordwind ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.