1.

Введение
Ни одну вещь в мире нельзя сделать без ошибок, и программы не исключение. Ошибки
встречаются повсеместно, и для того, чтобы убедиться, что продукт работает хорошо, то нужно
проверить. Это касается и шариковой ручки, и мобильного приложения. Пока в работе остается
человеческий фактор, профессия “Тестировщик” жизненно необходима.
Быть тестировщиком - это, прежде всего, быть внимательным пользователем, который
замечает недостатки продукта, указывает на них, а также добивается того, чтобы их исправили.
Так что это по силам каждому, в ком есть внимательность, здоровая доля перфекционизма,
способность отстаивать свою позицию, а также возможность посмотреть на ситуацию с разных
сторон. Если вы узнаете в этом описании себя, и хотите помогать создавать крутые продукты,
то, очевидно, что эта профессия для вас.

1.1 Основные термины

Тестирование программного обеспечения (Software Testing) - проверка соответствия между
реальным и ожидаемым поведением программы, осуществляемая на конечном наборе тестов,
выбранном определенным образом. В более широком смысле, тестирование - это одна из
техник контроля качества, включающая в себя активности по планированию работ (Test
Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution)
и анализу полученных результатов (Test Analysis).
Тестировщик - это специалист, который занимается тестированием. В его обязанности
входит:
1. поиск вероятных ошибок и сбоев в функционировании объекта тестирования;
2. моделирование различных ситуаций, которые могут возникнуть в процессе
использования ПО.
3. подготовка тестовых данных, которые он будет использовать в работе;
4. тестирование ПО;
5. заведение найденных дефектов;
6. анализ ошибок и их регистрация в баг-трекинговой системе;
7. формирование отчета по итогу тестирования.
Цель тестирования - нахождение ошибок в программном обеспечении до того, как их найдут
пользователи. Другими словами, это снижение стоимости разработки путем раннего
обнаружения дефектов. Компании платят большие деньги от всей стоимости разработки на
тестирование, и они не хотят их тратить на то, чтобы убедиться, что дефект есть, они хотят,
чтобы эти дефекты были вовремя исправлены и не были найдены будущими пользователями.
Цель тестировщика - находить ошибки в программном обеспечении и находить их как можно
раньше.
Качество программного обеспечения (Software Quality) - это совокупность характеристик
программного обеспечения, относящихся к его способности удовлетворять установленные и
предполагаемые потребности.
Характеристики качества ПО:
Функциональность (Functionality) - определяется способностью программного обеспечения
(ПО) решать задачи, которые соответствуют зафиксированным и предполагаемым
потребностям пользователя, при заданных условиях использования ПО. Т.е. эта характеристика
отвечает то, что ПО работает исправно и точно, функционально совместимо соответствует
стандартам отрасли и защищено от несанкционированного доступа.
Надежность (Reliability) – способность ПО выполнять требуемые задачи в обозначенных
условиях на протяжении заданного промежутка времени или указанное количество операций.
Атрибуты данной характеристики – это завершенность и целостность всей системы,
способность самостоятельно и корректно восстанавливаться после сбоев в работе,
отказоустойчивость.
Удобство использования (Usability) – возможность легкого понимания, изучения,
использования и привлекательности ПО для пользователя.
Эффективность (Efficiency) – способность ПО обеспечивать требуемый уровень
производительности, в соответствии с выделенными ресурсами, временем и другими
обозначенными условиями.
Удобство сопровождения (Maintainability) – легкость, с которой ПО может анализироваться,
тестироваться, изменяться для исправления дефектов для реализации новых требований, для
облегчения дальнейшего обслуживания и адаптирования к имеющемуся окружению.
Портативность (Portability) – характеризует ПО с точки зрения легкости его переноса из
одного окружения (software/ hardware) в другое.
Верификация (verification) - проверка того, что ПО разработано в соответствии со всеми
требованиями к нему или что очередной этап разработки выполнен в соответствии с
ограничениями, сформулированными на предшествующих этапах.
Валидация (validation) - проверка того, что сам продукт правилен, т.е. подтверждение того, что
он действительно удовлетворяет требованиям и ожиданиям пользователей, заказчиков и других
заинтересованных сторон.
План Тестирования (Test Plan) - это документ, который описывает весь объем работ по
тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и
окончания тестирования до необходимого в процессе работы оборудования, специальных
знаний, а также оценки рисков с вариантами их разрешения.
Тест дизайн (Test Design) - это этап процесса тестирования ПО, на котором проектируются и
создаются тестовые случаи (тест-кейсы), в соответствии с определенными ранее критериями
качества и целями тестирования.
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов, конкретных
условий и параметров, необходимых для проверки реализации тестируемой функции или её
части.
Баг/Дефект Репорт (Bug Report) - это документ, описывающий ситуацию или
последовательность действий, приведшую к некорректной работе объекта тестирования с
указанием причин и ожидаемого результата.
Тестовое Покрытие (Test Coverage) - это одна из метрик оценки качества тестирования,
представляющая из себя плотность покрытия тестами требований либо исполняемого кода.
Детализация Тест-Кейсов (Test Case Specification) - это уровень детализации описания
тестовых шагов и требуемого результата, при котором обеспечивается разумное соотношение
времени прохождения к тестовому покрытию.
Время Прохождения Тест Кейса(Test Case Pass Time) - это время от начала прохождения
шагов тест-кейса до получения результата теста.

1.2 Принципы тестирования

Тестирование программного обеспечения – креативная и интеллектуальная работа.
Разработка правильных и эффективных тестов – достаточно непростое занятие. Принципы
тестирования, представленные ниже, были разработаны в последние 40 лет и являются общим
руководством для тестирования в целом.
1. Тестирование показывает наличие дефектов

Тестирование может показать наличие дефектов в программе, но не доказать их отсутствие.

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

2. Исчерпывающее тестирование невозможно

Невозможно провести исчерпывающее тестирование, которое бы покрывало все комбинации

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

3. Раннее тестирование

Тестирование должно начинаться как можно раньше в жизненном цикле разработки

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

4. Скопление дефектов

Разные модули системы могут содержать разное количество дефектов – то есть, плотность
скопления дефектов в разных элементах программы может отличаться. Усилия по
тестированию должны распределяться пропорционально фактической плотности дефектов. В
основном, большую часть критических дефектов находят в ограниченном количестве модулей.
Это проявление принципа Парето: 80% проблем содержатся в 20% модулей.

5. Парадокс пестицида

Прогоняя одни и те же тесты вновь и вновь, Вы столкнетесь с тем, что они находят все
меньше новых ошибок. Поскольку система эволюционирует, многие из ранее найденных
дефектов исправляют и старые тест-кейсы больше не срабатывают.
Чтобы преодолеть этот парадокс, необходимо периодически вносить изменения в
используемые наборы тестов, рецензировать и корректировать их с тем, чтобы они отвечали
новому состоянию системы и позволяли находить как можно большее количество дефектов.

6. Тестирование зависит от контекста

Выбор методологии, техники и типа тестирования будет напрямую зависеть от природы

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

7. Заблуждение об отсутствии ошибок.

Тот факт, что тестирование не обнаружило дефектов, еще не значит, что программа готова к
релизу. Нахождение и исправление дефектов будут не важны, если система окажется
неудобной в использовании, и не будет удовлетворять ожиданиям и потребностям
пользователя.

1.3 Psychology of testing

In general, programmers can test both their own handwritten code and the functionality of the
system they are working on. But, due to the fact that people tend to incorrectly assess the results of
their own work, an independent specialist - namely, a tester - will always be more effective in finding
defects and failures in the system than a programmer.
Thus, testers evaluate other people's work, find flaws in it, so their activity is often perceived as
destructive, despite the fact that the result of this activity is fixing errors and improving the overall
quality of the product.
A good tester must have a number of personal and professional qualities. It should be:
- curious;
- critical;
- attentive to details;
- communicative;
- remember that “Software has bugs”. The tester must be able to find all the flaws in the product.
Research has shown that if a person testing a program perceives it to be working correctly, they will
find fewer bugs than someone who believes it has many flaws.
Another important point: when writing a report on a defect, be objective and in no case indicate
explicitly or implicitly the culprit, even if he deserves it. There are some simple tips for improving
communication with colleagues:
- remember that all of you are working on one project and are moving towards one goal - creating a
high-quality and popular product;
- Document the results of your work in a neutral tone, focus on facts;
- put yourself in the shoes of others and try to understand the reasons for their behavior;
- make sure that the other person understands you, and you understand him.

1.4. Business communication

It would seem that everyone knows how to communicate, someone is more sociable, someone
prefers to just quietly do their job, but you still have to communicate and it's better to do it right.
Why focus on communications in testing? The fact is that a tester interacts with many people: with
project managers, with analysts, developers, sometimes with customers and, undoubtedly, with the
same testers. How to ensure the required level of communication?
There are basic rules:
The work should focus not on informal communication, but on business.
You don't have to be friends with all families at all. Business communication relies on the fact that
you are all team members and do one common thing. You cannot afford to be offended by a developer
and therefore not send him bugs or ignore your project manager.
Learn written communication.
The life of a tester cannot be imagined without writing reports, bug reports, test cases, and many
testers often make a mistake - “as we hear, we write”. I saw an error, ran to fix it, wrote down
everything in solid text: "this blue button does not work" and sent it. The developer opens your report
and cannot understand what happened, where it happened and under what conditions.
The problem in this case is that the tester did not particularly delve into his report and wrote as if in
spirit - he understands everything, the button does not work. And the developer is a different person,
he may well think a little differently and see his headache in your report. He will ask you many
clarifying questions, ask you to attach files and describe everything step by step, you will spend a lot
of time figuring out all the details, respectively, the losses will be significant.
All of this could have been avoided if everything was initially expressed and formalized correctly.
In our testing team, the guys said that a good bug report is when even your grandmother can
understand its essence and reproduce the error. A bit funny, because reports are not written for
grandmothers, but it becomes not so fun when you see someone else's report, re-read it about five
times and in the end you can only say one thing: "And what should I do with this?"
That is why it is so important to learn how to write bug reports, scripts, reports correctly. And the
advice here is quite simple: "Practice and everything will come!" There is no more powerful way to
master a skill than learning and practicing it. Read test cases written by other testers, analyze, write
your own and do not be afraid to ask questions, ask colleagues for advice, discuss skills and ways to
solve emerging problems.
Learn to ask questions correctly.
The ability to ask questions is one of the key skills of a tester, especially at first. Why? You are not yet
very experienced and savvy, there are many blank spots in your knowledge, each project has its own
specifics. Dealing with this on your own, without referring to anyone, can be problematic, and this is
not the best way.
Imagine that you come to a team, you have your own project and work tasks. You take on one of
these tasks, but you have a very vague idea of what to do with it now. You try to remember everything
that you were taught in the courses, maybe even shyly google, but spend half a day on it, and when
they ask you how you are doing, you have nothing to brag about.
If you initially turned to your colleagues and asked to bring you up to date, the work would surely be
done. The fact is that all the people in the team are busy with their work and often they don't even
think that that new guy hasn't figured it out yet, and he needs help. Feel free to ask and do it right.
How to ask questions correctly?
Before asking a question, analyze it. What exactly is your difficulty at the moment? As soon as you
have done this, try to briefly but succinctly bring the interlocutor up to date, explain the essence of
your question or request. Do not be afraid that the interlocutor will consider you stupid, he, most
likely, also once started from scratch and, having heard a specific question or request from you, is
unlikely to refuse, probably, he will gladly help, nostalgic about his first days in IT.

1.5. ISTQB

Что такое ISTQB?

ISTQB (International Software Testing Qualifications Board) ─ это международная
организация, которая занимается сертификацией специалистов в области QA. На сегодняшний
день это самая авторитетная система аттестации. В разных странах есть свои
представительства этой организации, в России это RSTQB.
Сертификаты ISTQB имеют три уровня:
 Зачем сертификат ISTQB специалисту?
Специалист в области QA, успешно сдавший экзамен, получает следующие возможности и
гарантии:
1. Конкурентоспособность при приеме на работу, в том числе в международную компанию.
Это связано с тем, что сертификация ISTQB популярна, ей доверяют во многих странах мира.
Кроме того, некоммерческий характер ISTQB и бесплатное предоставление материалов при
подготовке к экзаменам выступают гарантией непредвзятости аттестации.
2. Карьерный рост и повышение зарплаты. Когда знания специалиста подтверждены
сертификатом международного уровня, то у руководства больше доверия к такому сотруднику.
Он получает возможность работать над более сложными проектами, которые хорошо
оплачиваются.
3. Систематизация знаний. Подготовка к экзаменам «разложит по полочкам» разрозненные
теоретические и практические знания и заполнит отдельные пробелы. А при подготовке к
экзамену на экспертный уровень (Expert Level) более половины заданий носят практический
 характер. Работа над теорией и практикой помогает углубить профессиональные навыки и
научиться чему-то новому.
4. Развитие навыков и экспертизы. Получить сертификаты можно только последовательно: с
базового уровня до экспертного. И на каждом этапе подготовка к экзамену потребует новых
знаний, поэтому специалист действительно прикладывает немало усилий. Сертификат эксперта
подтверждается практическими навыками, например, выполненными задачами или
выступлениями на профильных конференциях. Это тоже может стать стимулами для развития
в своей сфере.
Помимо очевидных конкурентных преимуществ, есть и другие положительные результаты
сертификации:
● Все специалисты, которые прошли обучение и сдали экзамен, владеют
общепринятой терминологией. Участники команды разработки говорят на «одном
языке», не возникает проблем из-за недопонимания друг друга.
● Оценка результатов беспристрастна, поскольку знания проверяют сторонние
независимые эксперты, для которых равны и Иванов, и Петров, и Сидоров.
● Сертификация дает возможность оценить, в каких областях сотрудник разбирается
лучше всего, а какие знания нужно развивать.
Для работодателя наличие у соискателя сертификата ISTQB ─ своеобразный «знак качества»
знаний его владельца. Крупные IT-компании стремятся привлечь в штат сертифицированных
сотрудников или организовать экзамены самостоятельно.

2. Модели разработки ПО
У любого программного обеспечения есть жизненный цикл — этапы, через которые оно
проходит с начала создания до конца разработки и внедрения. Чаще всего это подготовка,
проектирование, создание и поддержка. Этапы могут называться по-разному и дробиться на
более мелкие стадии.
Модель разработки программного обеспечения описывает, какие стадии жизненного цикла оно
проходит и что происходит на каждой из них.

2.1. Основные модели разработки ПО

К основным моделям разработки ПО относят:
● Waterfall Model — каскадная модель, или «водопад»;
● V-model — V-образная модель, разработка через тестирование;
● Incremental Model — инкрементная модель;
● Iterative Model — итеративная (или итерационная) модель;
● Spiral Model — спиральная модель.

Waterfall (каскадная модель, или «водопад»)

В этой модели разработка осуществляется поэтапно: каждая следующая стадия начинается
только после того, как заканчивается предыдущая. Если всё делать правильно, «водопад» будет
наиболее быстрой и простой моделью. Применяется уже почти полвека, с 1970-х.

Преимущества:
● Разработку просто контролировать. Заказчик всегда знает, чем сейчас заняты
программисты, может управлять сроками и стоимостью.
● Стоимость проекта определяется на начальном этапе. Все шаги запланированы уже
на этапе согласования договора, ПО пишется непрерывно «от и до».
● Не нужно нанимать тестировщиков с серьёзной технической подготовкой.
Тестировщики смогут опираться на подробную техническую документацию.
Недостатки:
● Тестирование начинается на последних этапах разработки. Если в требованиях к
продукту была допущена ошибка, то исправить её будет стоить дорого. Тестировщики
обнаружат её, когда разработчик уже написал код, а технические писатели —
документацию.
● Заказчик видит готовый продукт в конце разработки и только тогда может дать
обратную связь. Велика вероятность, что результат его не устроит.
 ● Разработчики пишут много технической документации, что задерживает работы.
Чем обширнее документация у проекта, тем больше изменений нужно вносить и
дольше их согласовывать.

V-образная модель
Это усовершенствованная каскадная модель, в которой заказчик с командой программистов
одновременно составляют требования к системе и описывают, как будут тестировать её на
каждом этапе. История этой модели начинается в 1980-х.

Преимущества:
● Количество ошибок в архитектуре ПО сводится к минимуму.
Недостатки:
● Если при разработке архитектуры была допущена ошибка, то вернуться и исправить её
будет стоить дорого.

Incremental Model
Это модель разработки программного обеспечения, при котором продукт разрабатывается,
внедряется и тестируется поэтапно, пока он не будет завершен. Это включает в себя как
разработку, так и сопровождение. Продукт определяется как законченный, когда он
удовлетворяет всем его требованиям.
Преимущества:
● Не нужно вкладывать много денег на начальном этапе. Заказчик оплачивает создание
основных функций, получает продукт, «выкатывает» его на рынок — и по итогам
обратной связи решает, продолжать ли разработку.
● Можно быстро получить фидбэк от пользователей и оперативно обновить
техническое задание. Так снижается риск создать продукт, который никому не нужен.
● Ошибка обходится дешевле. Если при разработке архитектуры была допущена ошибка,
то исправить её будет стоить не так дорого, как в «водопаде» или V-образной модели.
Недостатки:
● Каждая команда программистов разрабатывает свою функциональность и может
реализовать интерфейс продукта по-своему. Чтобы этого не произошло, важно на
этапе обсуждения техзадания объяснить, каким он будет, чтобы у всех участников
проекта сложилось единое понимание.
● Разработчики будут оттягивать доработку основной функциональности и «пилить
мелочёвку». Чтобы этого не случилось, менеджер проекта должен контролировать, чем
занимается каждая команда.

Iterative Model (итеративная модель)

Это модель, при которой заказчик не обязан понимать, какой продукт хочет получить в
итоге, и может не прописывать сразу подробное техзадание.
Преимущества:
● Быстрый выпуск минимального продукта даёт возможность оперативно получать
обратную связь от заказчика и пользователей. А значит, фокусироваться на наиболее
важных функциях ПО и улучшать их в соответствии с требованиями рынка и
пожеланиями клиента.
● Постоянное тестирование пользователями позволяет быстро обнаруживать и
устранять ошибки.
Недостатки:
● Использование на начальном этапе баз данных или серверов — первые сложно
масштабировать, а вторые не выдерживают нагрузку. Возможно, придётся
переписывать большую часть приложения.
● Отсутствие фиксированного бюджета и сроков. Заказчик не знает, как выглядит
конечная цель и когда закончится разработка.

Spiral Model (спиральная модель)

Используя эту модель, заказчик и команда разработчиков серьёзно анализируют риски
проекта и выполняют его итерациями. Последующая стадия основывается на предыдущей, а в
конце каждого витка — цикла итераций — принимается решение, продолжать ли проект. Эту
модель начали использовать в 1988 году.
Преимущества:
● Большое внимание уделяется проработке рисков.
Недостатки:
● Есть риск застрять на начальном этапе — бесконечно совершенствовать первую
версию продукта и не продвинуться к следующим.
● Разработка длится долго и стоит дорого.

2.2. Оценка трудозатрат при тестировании

Оценка трудозатрат позволяет определить:
● приблизительную стоимость проведения тестирования;
● сроки тестирования;
● примерный график работ.
Существуют различные методы для проведения оценки. Некоторые из которых более
серьезны в применении и требуют использования специальных математических расчетов,
но часть из методов является простыми и может даже неосознанно применяться в
планировании.
1. Метод «пальцем в небо»
Оценивание осуществляется с учётом некоторого прошлого опыта или же и вовсе без такового
на основании предположений и догадок. Является полностью неточным и содержит
значительный процент погрешности.
 2. Экспертная оценка
Оценка осуществляется на основании работы с предыдущими проектами, либо же для работы
привлекаются эксперты определённой области или специалисты, знакомые с тестируемым
приложением.
3. Специальный метод
Оценивание трудозатрат осуществляется на основании предполагаемых временных рамках.
Учитывая, что при таком подходе не берутся во внимание даже предыдущий опыт,
погрешность достаточно велика.
4. Структура декомпозиции работ
Расчет количества заданий, выполнение которых ожидается от команды на этапе тестирования,
осуществляется на декомпозиции проекта на определённые логические более мелкие части
(например: модули –-> подмодули —> функциональности). И уже после проведения
декомпозиции оценивается объем работ каждой небольшой части проекта.
5. Метод Дельфи
Основывается на том же методе декомпозиции работ, но ожидаемые к выполнению задания
распределяются на каждого отдельного члена команды, который самостоятельно оценивает
временные затраты на их выполнение. Данный метод характеризуется значительной
точностью.
6. Метод определения трудозатрат в процентном отношении к разработке
Оценка основывается на предположении, что трудозатраты на тестирование являются прямо
пропорциональными от таковых на разработку.
7. Метод процентного распределения
Все этапы разработки программного продукта выражаются через процентное значение
трудозатрат для каждого отдельно этапа. При этом непосредственно этап тестирования также
делится на его составляющие (планирование, проектирование тестов, выполнение тестов,
анализ результатов), каждому из которого присваивается свой процент трудозатрат.
При осуществлении оценки трудозатрат принимаются во внимание следующие факторы:
● уровень мастерства команды в целом;
● наличие и качество проектной документации;
● применение автоматизации;
● используемые инструменты и средства при тестировании.

2.3 Features of teamwork

It is physically impossible to create a quality product - without colleagues - in a short time, therefore
it is very important to behave correctly with others in order to achieve maximum career and
professional growth, as well as a comfortable pastime at the workplace.
Let's take a look at the basic rules to help you work as a team:
Straightness and tact
It is important for any person who wants to achieve success in their career to be able to convey their
thoughts to the interlocutor as quickly as possible. Modesty and nurturing are wonderful traits, but
they often work against you in your work. If you constantly think about how not to offend and not
“load” a person, you risk not communicating your point of view to him, not pointing out mistakes, and
giving out vague conditions.
But don't confuse bluntness with tactlessness. Be straightforward, be open, but don't cross the
invisible line where the worker meets the personal. The ideal way to keep your distance is to befriend
each team member. But since this is physically impossible, just show good manners outside of office
hours.
Сommon goal
At whatever level of the hierarchy in your company you are, strive to be the person who constantly
reminds others of common goals. Even if there is a new team around - you are already part of the
team.
Demonstrating commitment to the collective spirit is very simple - sincerely worry about the work
you do, that is, be attentive, executive, at least during working hours, forget about personal troubles.

A responsibility
In case of missed deadlines, errors in the code, non-fulfillment of points of the TOR, do not be
afraid to take responsibility. Admit your guilt, and you will increase the level of trust of others and, no
matter how paradoxical it may sound, you will get out of the situation as a “white sheep”.
Do not go to extremes and take on other people's problems. First, it looks ridiculous, and secondly,
it is in your best interest for your colleagues to follow suit and also know how to admit their mistakes.

Your tasks
Do not try to gain the trust of others by constantly providing help and small talk. First of all, show
yourself as a cool specialist in solving your own problems. But there is one important point: if a
colleague came up to you for advice, take a break for at least 1 minute to listen, give a short answer,
promise to come back later. This simple courtesy will earn you respect and financial bonuses.
Hierarchy
Any IT team has a clear division into strong and weak programmers. As bad as it sounds, your first
priority is to gain the authority of the leading group. They are the backbone of the entire team, it is
they who will help you with solving problems and your career. There is only one way to gain their
respect - hard and productive work. Those at the bottom of the hierarchy should not be ignored either.
Try to help them grow professionally and support them after public criticism. It will benefit everyone.

Words are more important than actions

Forget the stereotype that actions are more important than words. If you do not put your colleagues
behind their backs, they will evaluate you by what and how you say. Be polite, do not forget to
mention their merits and achievements in conversation with colleagues. Feel free to admit that you are
learning from them. All this will help to quickly integrate into the team.
Well-functioning teamwork benefits each of its members. The less ambitious receive a decent
salary and comfort, the rest step up the career ladder, sometimes mercilessly changing teams.
Whichever path you choose, remember - it is almost impossible to achieve great success alone.