Есть ли разница между qa и тестировщиком?

Кто такой Software Engineer in Test

На моей текущей работе недавно сменился босс и он регламентировал, что QA — полностью обязанность каждого сотрудника, а я для них Software Engineer in Test. 

При ближайшем рассмотрении Software Engineer in Test у меня получилось, что это тоже QC Engineer с одной лишь разницей, что фокус его обязанностей в автоматизации тестирования и включает и разработку собственного фреймворка/инструмента, и написание автотестов:

• Создание/расширение фреймворка для тестирования.

• Разработка вспомогательных утилит для тестирования сервисов.

• Настройка и поддержка тестового окружения.

• Настройка автоматизированных тестов для надежного и эффективного выполнения в средах CI / CD.

• Обеспечение оптимального покрытия автотестами на всех уровнях.

• Автоматизация отчетности.

• и т.п.

Обязанности второго плана по сути копируют список QC Engineer.Подробнее про Software Engineer in Test можно почитать в How Google Tests Software (есть переведенная на русский)

Как стать QA-специалистом и куда идти дальше?

Инженеров по качеству не обучают в университетах (исключение: на нескольких факультетах КПИ читают посвященный тестированию полугодовой курс). Будущие QA приобретают знания на курсах или же самостоятельно.

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

Базовые знания теории тестирования — это умение ответить на вопросы:— что такое тестирование и для чего оно нужно;— какие бывают виды тестирования;— что такое баг, и каков его жизненный цикл;— какая документация используется при тестировании.

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

• От девелопера — понимание технических ограничений для реализации того или иного функционала и хотя бы поверхностное понимание кода;
• От бизнес-аналитика — понимание рынка и целевой аудитории;
• От PM’а — понимание целостности всех частей проекта.

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

Если говорить о личностных качествах, то необходимо:— Иметь широкий IT-кругозор и тягу к изучению нового;— Уметь общаться — качество коммуникации в команде разработки напрямую влияет на качество создаваемого ПО;— Быть внимательным к деталям, усидчивым, ответственным и настойчивым;— Обладать аналитическими способностями, уметь моделировать и работать с абстракциями;— Иметь критический или даже «деструктивный» склад ума, направленный на нахождение ошибок;— Отличать муху от слона.

Среди перспектив профессионального развития можно выделить 3 направления:

1. Изучать новые области и расти как QA: junior QA —> middle QA —> senior QA —> QA team lead —> QA-manager —> Head of QA department.
2. Освоить автоматизированное тестирование и двигаться уже по этой ветке (требует более глубоких технических знаний).
3. Переквалифицироваться в бизнес-аналитики или программисты.

Получив достаточное количество опыта, можно дорасти до менеджера проекта и затем развиваться как управленец (senior project manager —> CTO). Также сейчас открыто множество курсов по обучению QA, так что основную работу можно совмещать с преподаванием или консультированием.

P.S. Спасибо за помощь в написании статьи 46 украинским QA- и Test-инженерам, которые поделились с DOU таинствами своей профессии. Приведенные в статье цитаты взяты из их рассказов.

Часть третья. Зависимость уровня оплаты труда QA-специалистов от уровня владения навыками тестирования

Какими навыками лучше всего владеют QA-специалисты?

Что должен знать каждый QA-специалист?

1. Навык локализации и заведения дефектов — Самый распространённый навык. 4 человека им совсем не владеют, 16 – плохо владеют. А 98% респондентов владеют навыком хорошо и в совершенстве.
2. Владение системами баг-трекинга (Jira, Redmine, YouTrack, Bugzilla) – также, всего 6 человек совсем не знакомы с данным навыком.
3. Клиентское тестирование веб-приложений – им хорошо или в совершенстве владеет 81% респондентов.
4. Владение системами управления знаниями и хранилищами тест-кейсов (wiki, confluence и пр.) – те же 81%, но из них только 27% в совершенстве.
5. Владение техниками тест-анализа, тест-дизайна и тестовой комбинаторики – этим навыком 58% специалистов владеет хорошо и ещё 18% в совершенстве. Стоит ли от них отставать?

Чем можно похвастать перед работодателем/коллегами?

1. Опыт разработки скриптов нагрузочного тестирования в JMeter или аналогичных приложениях – самый редкий навык. 467 человек совсем не владеют этим навыком (46,4%). 197 человек владеют им на достаточном уровне (19,6%). Всего 49 человек владеют им в совершенстве, причем, 36 из них зарабатывают более 1500$.
2. Владение системами отчётности результатов автотестов (Allure, пр.) − на достаточном уровне владеет 204 специалиста.
3. Владение драйверами и надстройками для автоматизации тестирования – 241 специалист.
4. Владение тестовыми фреймворками для автоматизации (TestNG, JUnit и пр.) – 272 специалиста.

Интересно:

Какие навыки оплачиваются лучше всего?

Скромнее всего (до 1410$ в мес.)Недалеко от них (до 1560$ в мес.)Ещё лучше (до 1660$ в мес.)Ну, а в если вам нравится цифра 1770$Интересно:

Преимущества и недостатки профессии

Чем, помимо заработной платы, привлекательна работа QA-инженера? Одно из самых приятных преимуществ заключается в осознании собственной причастности к созданию и улучшению IT-продукта, которым будут пользоваться тысячи или даже миллионы людей.

Кроме того, к плюсам относят возможность близко знакомиться с новейшими технологиями в тестировании и разработке. Если вы захотите сменить профессию, но при этом оставаться в IT-сфере, должность QA – оптимальное место, с которого удобно присматриваться к новому направлению.

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

Востребованность профессии и доходы тестировщиков ПО

По данным зарплатного калькулятора Хабр Карьеры, средний размер заработной платы тестировщика составляет чуть больше 96 тысяч рублей в месяц. Конечно, это среднее значение. Есть те, кто зарабатывает значительно меньше, скажем, тысяч 30, а есть и те, кто получает в 10 раз больше — около 300 тысяч рублей.

Средняя з/п тестировщика ПО в первом полугодии 2020 года

Профессионалы примерно одного уровня, выполняющие один и тот же пул задач в столице и в регионе могут получать сильно отличающуюся зарплату. В Москве это 100+ тысяч рублей, в регионах — 40-50 тысяч рублей, а в некоторых случаях и вовсе 20-30 тысяч.

Если сравнивать уровень зарплаты тестировщиков в РФ и за рубежом, то разница в среднем 30-50%.

Источник картинки https://habr.com/ru/post/446650/

Плюс можно сравнить еще разброс уровня заработной платы в зависимости от региона — Евросоюз, СНГ, США и Канада, РФ.

Источник картинки https://habr.com/ru/post/446650

Наш зарплатный калькулятор показывает и список навыков, которыми владеют тестировщики ПО:

• Тестирование ПО;

• Ручное тестирование;

• Функциональное тестирование;

• Автоматизация тестирования;

• Python;

• Selenium webdriver;

• Разработка тест-кейсов;

• Тестирование мобильных приложений;

• Контроль качества;

• Black box testing.

А вот свежие вакансии для специалистов по тестированию на Хабр Карьере. Их ищут, например, Сбербанк и Сбермаркет, Admitad, JetBrains, CSSSR и EPAM. Уровень зарплаты зависит от квалификации, стека и, конечно, компании.

Вакансии тестировщиков на Хабр Карьере

QA ≠ QC: как их различить

QC: кто эти люди, какие у них задачи, какие у них ограничения

Кто эти люди? Люди, которых называют тестировщиками, тождественны контролю качества QC. По логике вещей они на последнем этапе разработки проверяют качество продукта (любым видом и типом тестирования  —  ручным, автоматизированным, нагрузочным, тестированием безопасности и т.д.). Какая у них задача? Их задача — провести валидацию продукта и предоставить информацию бизнесу и разработчикам о соответствии продукта заявленным требованиям. Какие у них ограничения? Какие могут быть недостатки, если у вас все сотрудники проверяют продукт на соответствие:

• До взятия фичи в проверку такие сотрудники не влияют на процесс обеспечения качества и разработки, хотя их участие могло бы предотвратить некоторое количество багов и тем самым сократить затраты на тестирование.
• Зачастую такие сотрудники не могут давать рекомендации, как сделать продукт лучше. Потому что поезд ушёл и уже поздно. Им остаётся лишь сверять соответствие продукта требованиям. FYI: хотя на самом деле тестировщикам есть что сказать по поводу улучшений, которые необходимо сделать.
• Эти ребята чаще всего не видят полной картины процесса, поэтому искренне не понимают, почему разработчики дают им код, в котором приложение крашится при попытке запуститься. И, согласно п.1, ничего не могут с этим сделать. Даже если хотят. 
• Они не могут взять на себя полную ответственность за качество продукта.
• Очень часто между тестировщиками и разработчиками возникают конфликты. Так бывает, когда разработчики считают свой код самым лучшим и работающим, а в тестировщиках видят лишь попытки его сломать и показать, что код не работает. Такое положение дел порождает всем известные мемы «Это не баг, а фича».

QA: кто эти люди, какие у них задачи, какие у них ограничения

Кто эти люди? Инженеры по обеспечению качества (QA) — это люди, которые помогают командам разработки выпускать качественный продукт, как можно быстрее за как можно меньшие деньги. Ведь все мы знаем, что чем раньше найден баг, тем дешевле его пофиксить. Лучше всего фиксить баги ещё на уровне идеи.
QA-инженеры участвуют на самых ранних этапах создания продукта/фичи. Если бы они могли залезать в головы к PO, чтобы сказать им о недостаточности приемочных критериев или сценариев использования фичи, — они бы делали это. Какая у них задача? Задача QA-инженера  —  не допустить несоответствия продукта предъявляемым требованиям. QA-инженер замеряет качество продукта, знает его актуальное состояние и что нужно сделать, чтобы его поднять не только на этапе тестирования, но и на этапе разработки, дизайна или составления требований.Какие у них ограничения? Сложно оценить качество работы QA-инженера, потому что если он хорошо выполняет свою работу, то до этапа тестирования будет доходить минимальное количество багов не влияющих на функциональность и запуск продукта в прод. 
В отличие от QA, работу QC оценить можно, особенно если отталкиваться от самого простого и оценивать эффективность по количеству багов — сколько багов нашёл и сколько багов пропустил на прод.

GeekBrains. «Факультет тестирования ПО»

Свои курсы тестировщика онлайн предлагает и эта образовательная школа.

Первый называется «Факультет тестирования ПО».

Он подойдет:

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

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

Во второй четверти обучающие осваивают:

• Инструменты API-тестирования
• Подходы к тестированию
• Консоль разработчика в браузере
• Юзабилити и многое другое

Длительность обучения – год. Занятия проводятся дважды в неделю. Стоимость до 16 сентября от 2 907 руб./мес. Предлагается рассрочка на 36 месяцев. Вы получаете в портфолио 5 проектов, диплом об окончании курса и гарантию трудоустройства после обучения.

Пошаговая эволюция

1. Меняем тип мышления

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

Например:

2. Ищем единомышленников

Обеспечение качества — это задача не только QA-инженера и тут вопрос не в скидывании ответственности. Вовлекая в процесс всех участников проекта, можно постепенно упорядочить процессы работы на каждом этапе разработки.

3. Работаем над “проектом всей моей жизни”

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

4. Идем против системы

Не надо вестись на комментарии участников проекта: “У нас так принято/по-другому не пробовали/вроде норм”. Аккуратно ворошите улей дополнительными вопросами и весомыми аргументами. Если же возникает напряжение и застой внутри, то пригодится совет с внешней стороны — авторитет более опытных коллег поможет изменить привычный порядок вещей.

5. Не впадаем в крайности

Искусственное создание проблем на пустом месте плохо влияет на внутрикомандную атмосферу и снижает доверие. Поэтому при наличии опасений сначала стоит их высказать заинтересованным участникам команды — вполне вероятно, что кто-то из них (а может и все) чувствуют, что что-то идет не так.

В заключение

QA — это отдельный и важный вид деятельности, который улучшит производительность команды в целом. Невероятно, но факт: в компетенцию специалиста по качеству не входит лишь нахождение багов, а сам процесс Quality Assurance стоит воспринимать как комплекс мер для улучшения качества на всех этапах жизненного цикла продукта. Не давайте дефектам возможности зародиться уже в самом начале. Древняя мудрость гласит: “Лучший бой тот, который не состоялся”.

Автор статьи Павел Булич, редактор Yulia Nosakova

Результаты внедрения нагрузочного тестирования в Miro

1. Понятный и описанный процесс. Чётко описано, какие шаги нужно выполнить и что нужно делать на каждом из шагов.
2. Большие тесты: 200K, 500K пользователей online при типичном сценарии использования. Каждый сложный тест зачастую проходит много итераций перед успешным выполнением, поэтому без автоматизации столько раз гонять большие тесты было бы чрезвычайно долгим и утомительным занятием, полным ошибок.
3. Проверка компонентов перед выкаткой на прод.
4. Обоснованный выбор параметров компонентов для поддержки планируемой нагрузки. То есть не просто с потолка брать «ну наверное хватит сотни воркеров», а выбирать параметры на основе результатов проверок.
5. Автоматизация, упрощение и ускорение проведения НТ. Я говорил в начале про список из 16 пунктов, которые надо было пройти вручную при каждом запуске НТ на кластере. Теперь это один конфиг и одна команда. Больше автоматизации даёт больше надёжности и больше возможностей уделить время более творческим и сложным задачам.
6. Деградационное тестирование (начало). Автоматическое выполнение тестов по реалистичному API сценарию на типичной нагрузке каждую ночь на последней версии сервера и построение графиков трендов для отслеживания динамики показателей скорости ответа и числа ошибок.

Будущее тестировщика

• Разработка программного обеспечения — логичный и не самый сложный путь для тех, кто увлечётся языками программирования и захочет не только ковырять чужой код и готовый проект, но и создавать что-то внутри команды.
• Руководитель проекта. Отличное знание проекта в целом, понимание потребностей и требований клиентов — прямой путь к этой точке.
• Скрам мастер — интересный разворот, который у тестировщиков хорошо удаётся благодаря опять же знаниям проекта в целом и умениям жёстко планировать сроки работ.
• Бизнес-аналитик, внедренец — денежные, но не столь технические должности для ребят с прокачанными коммуникативными навыками.

Какие бывают

В ИТ-среде в свя­зи с тести­ро­ва­ни­ем и каче­ством при­ня­то три обо­зна­че­ния:

QA — quality assurance, самый глав­ный по каче­ству;QC — quality control, кон­тро­лёр каче­ства;Tester — тести­ров­щик.

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

QA — это тот, кто дума­ет о каче­стве про­дук­та в целом, при­чём не толь­ко о конеч­ном коде, но и все­го про­цес­са раз­ра­бот­ки. Напри­мер:

Как понять поль­зо­ва­тель­ские сце­на­рии, в кото­рых веро­ят­нее все­го воз­ник­нут ошиб­ки? Как их собрать? Как систе­ма­ти­зи­ро­вать? Как ниче­го не упу­стить? (Напри­мер, как понять, какие имен­но пред­ме­ты люди могут дога­дать­ся засу­нуть в мик­ро­вол­нов­ку, и как защи­тить­ся от иди­о­тов, кото­рые засу­нут туда дина­мит?)Как соеди­нить запро­сы людей, тре­бо­ва­ния биз­не­са и реаль­ные воз­мож­но­сти про­дук­та с точ­ки зре­ния каче­ства? Что если наш про­дукт совсем не дела­ет то, чего поль­зо­ва­те­ли могут ожи­дать? Напри­мер, если они будут сушить в мик­ро­вол­нов­ке кош­ку — это чья про­бле­ма? Будем ли мы с этим что-то делать?Кто, как и в каком поряд­ке будет исправ­лять ошиб­ки? Как мы будем повтор­но тести­ро­вать места с ошиб­ка­ми?Что и как тести­ро­вать от вер­сии к вер­сии про­грам­мы, что­бы это было доста­точ­но быст­ро, но не в ущерб каче­ству?

Мож­но пред­ста­вить, что QA — это дирек­тор по каче­ству, глав­ный чело­век на пути у багов. Он не менее важен, чем глав­ный архи­тек­тор или ИТ-директор. Мно­гие его функ­ции могут пере­се­кать­ся с функ­ци­я­ми дру­гих ИТ-директоров.

QC — это тот, кто сфо­ку­си­ро­ван на тести­ро­ва­нии само­го про­дук­та:

Что имен­но тести­ру­ем? Какие функ­ции, кноп­ки, состо­я­ния, сце­на­рии?Какие резуль­та­ты тести­ро­ва­ния нам нуж­ны? Какие исхо­ды пра­виль­ные, а какие — ошиб­ки?Как авто­ма­ти­зи­ру­ем тесты? Что нуж­но обя­за­тель­но прой­ти руч­ка­ми?Как син­хро­ни­зи­ро­вать рабо­ту несколь­ких тести­ров­щи­ков? Как рас­пре­де­лить зада­чи, обла­сти, слои?

Мож­но пред­ста­вить, что это такой глав­ный бри­га­дир тести­ров­щи­ков. Его рабо­та — что­бы тесты шли ров­но и чёт­ко, без про­блем. Разу­ме­ет­ся, очень полез­но, если он уме­ет непо­сред­ствен­но тести­ро­вать.

Тести­ров­щик — это тот, кто тести­ру­ет про­дукт: про­хо­дит его руч­ка­ми или пишет авто­ма­ти­че­ские тесты; опи­сы­ва­ет баги; обща­ет­ся с раз­ра­бот­чи­ком по пово­ду этих багов; зано­во тести­ру­ет исправ­лен­ное.

Для чего необходимо обеспечение качества

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

Ежедневные советы от диджитал-наставника Checkroi прямо в твоем телеграме!

Подписывайся на канал Подписаться

Differences between SQA and Software Testing

Following table explains on differences between SQA and Software Testing:

Тестирование методом черного и белого ящика

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

Полнота тестирования

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

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

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

И вот когда мы собираем с вами эту коллекцию бабочек, мы можем, конечно же, ориентироваться только на раскраску крыльев

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

Но одного рисунка нам недостаточно. Нам нужно еще принимать во внимание внутреннее устройство

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

Нам нужно еще принимать во внимание внутреннее устройство

И вот это как раз и есть разница между тестированием методом черного ящика и тестированием методом белого ящика.

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

При тестировании методом белого ящика, или правильнее говорить, наверное, «прозрачного ящика», мы смотрим, как программа устроена внутри, и эту информацию используем при выполнении и особенно при проектировании тестов.

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

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

Мы принимаем во внимание и ее внешнее поведение, и ее внутреннее устройство. Коллекция тестов увеличивается

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

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

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

Задачи и обязанности

Основная задача QA — обеспечение качества

QA-инженер фокусирует внимание на процессах разработки ПО, улучшает их, предотвращает появление дефектов и проблем (Makes sure you are doing the right things, the right way)

Процесс обеспечения качества состоит из таких этапов:— проверка требований к продукту;— оценка рисков;— планирование идей по улучшению качества продукта;— планирование тестирования;— анализ результатов тестирования;

Внутри процесса QA выделяют процесс Quality Control — контроль качества продукта. QC-специалисты анализируют результаты тестирования и отвечают за выявление и уничтожение дефектов в продукте (Makes sure the results of what you have done is what you expected).

Еще более узкая специальность в рамках QA/QC — тестировщик ПО, который проверяет готовый продукт на наличие ошибок (багов) и несоответствие требованиям, и затем документирует найденные дефекты и пути их воспроизведения. Тестирование — это один из этапов обеспечения и контроля качества.

Есть 4 основные роли:

• Test Analyst — занимается статическим тестированием требований: проверяет, насколько они полны, однозначны, непротиворечивы etc;
• Test Designer — создает набор тестов на базе требований, планирует конфигурации, необходимые для тестирования;
• Test Executor — выполняет заранее подготовленные тесты, документирует найденные ошибки и шаги их воспроизведения;
• Test Manager — скорее управленец, чем инженер. Планирует и контролирует работы, связанные с тестированием: оценки сроков, работу над планом-графиком, контроль покрытия требований тестами, постановку задач членам команды, коммуникацию со стейкхолдерами).

В Украине различия между должностями QA и тестировщика смазаны, и на практике это одно и то же. Хотя теоретически тестировщик тестирует продукт как результат, а QA работает над обеспечением процессов, которые могут повысить качество ПО в целом.

В круг обязанностей QA-инженера входит:— Анализ и уточнение требований с заказчиком или бизнес-аналитиками;— Планирование процесса тестирования;— Написание тест-кейсов (сценариев тестирования);— Тестирование функционала;— Идентификация проблемных мест, внесение их в трэкинговую систему;— Обсуждение фиксов с разработчиками;— Отслеживание жизненного цикла ошибок;— Ре-тест починенных дефектов;— Анализ тестирования;— Оптимизация процесса тестирования;— Анализ процессов работы в команде;— Улучшение процессов;— Ведение тестовой документации.

Типичный рабочий день QA-специалиста включает в себя:— Написание тест-кейсов, тестирование, документирование ошибок (в зависимости от фазы проекта);— Проверка баг-трекинговой системы на предмет появления исправленных ошибок;— Стенд-ап митинги;— Изучение требований, их уточнение у заказчика;— Активное общение с разработчиками;— Оформление тестовой документации.

CMMI level

The Capability Maturity Model Integrated (CMMI) is a process improvement approach developed specially for software process improvement. It is based on the process maturity framework and used as a general aid in business processes in the Software Industry. This model is highly regarded and widely used in Software Development Organizations.

CMMI has 5 levels. An organization is certified at CMMI level 1 to 5 based on the maturity of their Quality Assurance Mechanisms.

• Level 1 – Initial: In this stage the quality environment is unstable. Simply, no processes have been followed or documented
• Level 2 – Repeatable: Some processes are followed which are repeatable. This level ensures processes are followed at the project level.
• Level 3 – Defined: Set of processes are defined and documented at the organizational level. Those defined processes are subject to some degree of improvement.
• Level 4 – Managed: This level uses process metrics and effectively controls the processes that are followed.
• Level 5 – Optimizing: This level focuses on the continuous improvements of the processes through learning &  innovation.