morincer

Для варианта конечной дискретной последовательности (как в Вашем случае) задача решается достаточно просто вариацией метода Монте-Карло.

Допустим у нас есть массив A натуральных чисел от 0 до n (0, 1, ..., n — 1) и для каждого из этих чисел задана вероятность его генерации p(a_i) (естественно, сумма всех вероятностей равна 1). Идея метода: разделить отрезок [0;1) на n отрезков, длина каждого из которых равна вероятности появления соответствующего числа из массива А. Далее, уже стандартным генератором ПСЧ выбираем число в диапазоне [0;1) и проверяем в какой из отрезков оно попало. Соответствующий данному отрезку элемент исходного массива возвращаем в качестве результата работы нашего генератора.
Реализацию алгоритма оставим читателю в качестве домашнего задания :)

Триста тридцать пять… © ДМБ
На солнце, что ли, пятна высыпали — чегой-то хабр последние пару месяцев так лихорадит? Но эта так — мысли вслух.

Если по теме. Ваша ошибка состоит в том, что вы рассматриваете карьерную лестницу как одномерную прямую и, соответственно, т.н. «карьерный рост» рассматриваете как движение строго вдоль этой единственной прямой. И вам не понятно, почему ваша прямая под названием «решение все-более технически сложных задач» не совпадает с прямыми других людей.
Реальность же такова, что карьера — это многомерное пространство и каждый сам для себя выбирает, по каким осям он хочет двигаться и что считает «карьерным ростом», особенно с учетом того, что двигаться сразу по всем направлениям — невозможно. Примерами таких осей в IT, например, являются «уровень дохода», «ответственность за действия других людей», «внедрение сложных систем», «личная независимость», «работа с людьми» и т.д. и т.п.
Поэтому для кого-то, например, важно двигаться по оси «решение сложных технических задач» и он становится из программиста архитектором, а для другого — «личная независимость» — и он перестает быть архитектором и уходит во фриланс, где занимается парсингом сайтов в свое удовольствие. Еще из программистом можно уйти в менеджеры, тим-лиды, аналитики, консультанты (в т.ч. независимые) — и еще в кучу направлений. И для людей с другой системой ценностей по карьерным осям это будет выглядеть как карьерный упадок (как же так, он был архитектором, строил ERP-системы, а потом стал каким-то консультантом???), а для тех, кто живет на тех же осях — как карьерный рост (прикинь, он теперь работает на себя, общается с интересными людьми, а не парится как мы в офисах, внедряя в пятисотый раз одну и ту же платформу!!!)

Если говорить на основании собственного опыта в попытке применить к Вашему случаю.
В Вашем случае, скорее всего, вам стоит применять несколько ключевых видов тестирования:
— Ad-hoc — т.е. «протыкивание» — когда тестировщик верифицирует принципиальную работоспособность и общую корректность работы «свежего» функционала. Результатом его работы обычно являются замечания в виде «А вот тут у тебя не работает», «Здесь работает не так», которые иногда(!) оформляются как баги. В этом случае, тестировщик выступает, де-факто, как последнее звено в команде разработки перед передачей функционала в дальнейшее тестирование и задачи ему передаются разработчиком по факту написания блока функционала.

— Тестирование по тест-кейсам — тест-аналитик на основе анализа требований пишет тест-кейсы, которые в дальнейшем выполняются тестировщиком (естественно, эти две функции можно объединять, но есть риск перегрузки человека). Когда требования уходят в разработку, эти же требования уходят тест-аналитику, который на их основе идентифицирует, а затем и описывает тест-кейсы. В данном случае, важно отладить нормальные процессы а) управления требованиями с точки зрения коммуникаций (разработчикам и тестировщикам уходят одни и те же требования, об изменении требований уведомляются и разработка, и тестирование, обеспечена трассировка требований на тест-кейсы и пр.). После передачи функционала в тестирование, тест-кейсы собираются в тест-сет (тестировщиком, тест-аналитиком, тест-менеджером или кем-то еще) и «прогоняются» тестировщиком. Результатом работы являются баги, которые возвращаются разработчикам, классифицируются (например, дефект разработки (ошибка в разработке), дефект документации (ошибка в аналитике), дефект тестирования (ошибка в тест-кейсы) и отрабатываются соотв. группой. В этом случае, группа тестирования выступает как следующее звено производственного цикла (вроде ОТК).

Еще есть дымовое тестирование (smoke testing), нагрузочное тестирование, интеграционное тестирование — их применимость следует оценивать, исходя из реалий проектов (Вы дали слишком мало информации).

Соответственно, видятся три основных роли:
— Тест-аналитик (он же тестплан-девелопер, он же, иногда, тест-менеджер)
— Ad-hoc тестировщик
— Тестировщик

Тест-аналитик подключается, как только требования готовы к передаче в разработку. Ad-hoc — как только разработка начала выдавать результат на «пощупать». Тестировщик — как только закончена разработка блока требований.