Ниже те слова, которые будешь постоянно слышать в работе.
Хорошо, если ты будешь не просто узнавать их, но и понимать.

Общие слова и выражения

• Шерить / расшарить (to share) — поделиться чем-то:
• ссылкой
• экраном
• документом
• Аппа / аппка / прилка (application) — приложение:
• мобильное
• веб-приложение
• Апрув (approve) — одобрить:
• «Задача апрувнута» — задачу приняли
• Функционал
  В IT часто говорят «функционал» вместо «функциональность».
  Грамотно — функциональность, но в речи устоялось «функционал».
• Декомпозиция — разделение чего-то большого на части:
• задача на 14 дней → разбиваем на 7 задач по 2 дня
• Атомарность — «неделимость»:
• одна операция = одна самостоятельная единица
• в тестировании: одна проверка — одна функциональность
• Спека (спецификация) — документ с требованиями.
• Дока — документация.
• Тула / тулза (tool) — утилита, инструмент:
• Postman, JIRA, Qase, Git и т.п.

QA-утилиты и процесс

• TMS (Test Management System) — система для управления тестами:
• хранение тест-кейсов
• прогон регресса
• учёт статусов
  Примеры: Testrail, Zephyr, Test IT, Qase.
• Прод / production / бой / боевая среда — «живой» сайт/система, которой пользуются реальные пользователи.
• TTM (Time To Market) — время от начала задачи до её выхода в прод.

Языки и технологии

• ЯП — язык программирования.
• JS / жс — JavaScript.
• Джава / жаба / ява — Java.
• Софт (software) — программы.
• Железо (hardware) — физические устройства:
• сервер
• компьютер
• смартфон
• Стек / стэк — набор технологий в проекте:
• ЯП + фреймворки + базы данных и т.д.

Встречи и взаимодействие

• Дейлик / стендап (daily standup) — короткая ежедневная встреча команды:
• обсуждаем, кто что делает
• Обсуждаем, какие прблемы
• One-to-one / 1:1 / ван-ту-ван — личная встреча один на один:
• с лидом
• с менеджером

Бизнес-логика и инфраструктура

• Бизнес-логика — «как и зачем» система работает с точки зрения бизнеса:
• правила оформления заказа
• условия скидок
• процесс авторизации и т.п.
• DevOps — философия + процессы + практики + иногда человек, который:

• поднимает и поддерживает инфраструктуру нашего приложения
• Стейдж / стенд / тестовый стенд — тестовая среда, как правило тестовый сайт, которым не пользуются реальные клиенты, а только тестировщики

5.6. Термины про задачи и работу

• Чекнуть / прочекать (check) — проверить.
• Скоуп / scope — область работы, тот объём задач, который входит в проект.
• Пилить / запилить
1. «Делать фичу»: «пилю новую форму регистрации»
2. «Делить»: «пилим монолит на микросервисы».
• Трабл (trouble) — проблема.
  Траблшутинг — поиск и устранение проблемы.

5.7. Хранение данных в браузере

• Куки / cookies / печеньки — маленькие записи в браузере:
• могут хранить:
• токен сессии
• настройки пользователя

• Кэш / cache — временные файлы:
• чтобы сайт открывался быстрее
• но иногда мешают тестированию (старые данные)
• Токен (token) — «пропуск» для доступа, некий набор символов, который выполняет те же функцииЮ что и пароль:
• чаще всего авторизационный (JWT, OAuth и т.п.)
• без токена не пускают к защищённым данным
• Креды (credentials) — связка логин + пароль.
• Юзер / user — пользователь.
• Акк / аккаунт / УЗ / учётка — учётная запись пользователя.

5.8. Идентификация, аутентификация, авторизация 🔐

Разница важна:

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

5.9. Деплой, релиз, откат 🚢

• Деплой / выкатывать / развернуть (deploy) — выложить новую версию приложения на стенд или прод.
• Откат / роллбэк (rollback) — вернуться на предыдущую стабильную версию.
• Релиз (release) — выпуск версии:
• либо как событие (выкатили)
• либо как новая сборка приложения
• Темплейт (template) — шаблон:
• письма
• документа
• кода
• CI/CD — автоматизация:
• CI (Continuous Integration) — непрерывная интеграция,
• CD (Continuous Delivery) — непрерывная доставка.
  Это когда код автоматически:
• собирается,
• тестируется,
• выкатывается.
  Инструменты: GitLab CI, Jenkins, GitHub Actions, TeamCity.
• Хардкод (hardcode) — жёстко «прибитые гвоздями» значения в коде:
• вместо гибкой настройки.

5.10. Линки, токены и прочее

• Линк (link) — ссылка.
• Перелинковка — расставление ссылок между страницами/документами.
• Etc — «и так далее» (от латинского et cetera).

1.    Общие положения

1.1.       Индивидуальный предприниматель Филипенко Иван Сергеевич, именуемый в дальнейшем Исполнитель, адресует настоящий договор-оферту на оказание услуг (далее по тексту – Договор-оферта) любому лицу (неопределенному кругу лиц), чья воля будет выражена им лично либо через уполномоченного представителя, выразившему готовность воспользоваться услугами Исполнителя. Заказчиком признается лицо, которое заключило договор с Исполнителем в электронной форме в результате акцепта настоящего Договора-оферты. В дальнейшем по тексту Договора-оферты Исполнитель и Заказчик вместе именуются Стороны, а индивидуально – Сторона.

1.2.       Договор-оферта является официальным предложением Исполнителя (офертой) к заключению договора на оказание услуг и содержит все существенные условия договора на оказание услуг.

1.3.       Акцептом Договора-оферты является частичная/полная оплата Заказчиком услуг Исполнителя в порядке, размере и сроки, указанные в Договоре-оферте.

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

1.5.       Совершая акцепт Договора-оферты, Заказчик подтверждает, что воспользовался правом получить у Исполнителя разъяснения относительно условий оказания услуг, а также подтверждает то, что условия оказания услуг полностью соответствуют воле, потребностям и требованиям Заказчика.

1.6.       Заказчик понимает, что акцепт Договора-оферты в порядке, указанном в п.3 Договора-оферты равносилен заключению договора на условиях, изложенных в Договоре-оферте.

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

1.8.       Договор-оферта является равносильным договору, подписанному Сторонами, имеет юридическую силу и действителен в электронном виде.

1.9.       Договор-оферта может быть отозван в любое время до момента его акцепта.

2.           Предмет договора

2.1.       Исполнитель обязуется оказывать услуги, указанные на сайте: https://teletype.in/@qafeelsgood/mentoring_conditions, (далее по тексту – Услуги), а Заказчик обязуется оплатить Услуги.

2.2.       Услуги (часть Услуг, в случае оказания Услуг по этапам) по Договору-оферты считаются оказанными в момент осуществления Заказчиком оплаты Услуг (части Услуг, в случае оказания Услуг по этапам). Стороны пришли к соглашению, что акт оказанных услуг по результатам оказания Услуг не составляется и не подписывается. Услуги считаются принятыми Заказчиком надлежащим образом по качеству и объему, если в течение семи дней после фактического оказания Услуг Исполнитель не получил от Заказчика мотивированных письменных возражений по качеству оказанных Услуг на электронную почту.

2.3.       В случае, если Заказчик, по причинам, не зависящим от Исполнителя, не воспользовался Услугами и не уведомил Исполнителя о своем желании отказаться от Услуг в порядке, предусмотренном Договором-офертой, Услуги считаются предоставленными.

3.           Заключение, изменение, расторжение Договора-оферты

3.1.       Заказчик совершает акцепт Договора-оферты путем совершения частичной/полной оплаты Услуг Исполнителя.

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

3.3.       Договор-оферта вступает в силу с момента совершения акцепта Заказчиком и действует до полного исполнения Сторонами своих обязательств.

3.4.       Исполнитель вправе в одностороннем порядке в любое время вносить изменения в условия Договора-оферты. Изменения в условия Договора-оферты начинают свое действие с момента их опубликования.

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

4.           Права и обязанности Сторон

4.1.       Исполнитель обязуется:

4.1.1.      Довести до сведения Заказчика необходимую информацию об Услугах и Исполнителе.

4.1.2.      Обеспечить оказание Услуг в срок, согласованный с Заказчиком, и в соответствии с описанием Услуг.

4.1.3.      Сохранять конфиденциальную информацию, полученную от Заказчика, при оказании Услуг.

4.1.4.      Соблюдать требования действующего законодательства Российской Федерации, касающиеся обработки, передачи и защиты персональных данных Заказчика.

4.1.5.      Оказывать Услуги на должном профессиональном экспертном уровне, основываясь на своем практическом опыте и накопленных знаниях / умениях и/или практическом опыте и накопленных знаниях / умениях привлеченных им третьих лиц.

4.1.6.      В соответствии с выбранным Заказчиком видом Услуг направить Заказчику ссылку на форму оплаты соответствующей Услуги.

4.2.       Исполнитель вправе:

4.2.1.      Получать от Заказчика любую информацию, необходимую для выполнения своих обязательств по Договору-оферте.

4.2.2.      Привлекать для оказания Услуг третьих лиц без согласования с Заказчиком.

4.2.3.      Не приступать к оказанию Услуг в случае нарушения Заказчиком выполнения условий, указанных в п.5.2. Договора-оферты.

4.2.4.      В течение 10 (Десяти) лет с момента окончания оказания Услуг осуществлять рассылку рекламных и информационных сообщений на номер мобильного телефона и/или адрес электронной почты (иные социальные сети известные Исполнителю, в том числе из открытых источников), указанные Заказчиком в момент оплаты Услуг.

4.3.       Заказчик обязуется:

4.3.1.      Самостоятельно и своевременно знакомиться с информацией об оказании Услуг.

4.3.2.      Оплатить Услуги на условиях, в порядке и в сроки, установленные в Договоре-оферте.

4.3.3.      Предоставить Исполнителю достоверные сведения, а также документы и иные материалы, необходимые для надлежащего исполнения Договора-оферты в сроки и на условиях, устанавливаемых Исполнителем.

4.3.4.      Потреблять Услуги исключительно лично.

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

4.4.       Заказчик вправе:

4.4.1.      Требовать от Исполнителя соблюдения условий Договора-оферты.

4.4.2.      Отказаться от рассылки рекламных и информационных сообщений Исполнителя путем направления отказа в письменной форме на адрес электронной почты и/или на телефонный номер, с которых поступает рассылка. Из уведомления об отказе от рассылки должно явно следовать намерение отказаться от рассылки, направляемой на электронную почту и/или на телефонный номер. Исключение из списка рассылки осуществляется Исполнителем в течение 30 (Тридцати) календарных дней с момента получения уведомления об отказе от рассылки.

5.           Порядок расчетов

5.1.       Стоимость Услуг указана на сайте https://teletype.in/@qafeelsgood/mentoring_conditions и определяется в зависимости от вида оказываемых Услуг:

5.2.       Заказчик оплачивает Услуги в день оказания Услуг (непосредственно перед оказанием Услуг)

5.3.       Заказчик оплачивает Услуги любым доступным на момент оплаты способом, предоставляемым ООО «Продамус» ИНН 1215156909 ОГРН 1111215003460 (далее по тексту – Агент), после перехода по платежной ссылке, предоставляемой Исполнителем, и заполнения формы оплаты.

5.4.       Безопасность, а также иные условия использования выбранных Заказчиком способов оплаты выходят за рамки Договора-оферты и регулируются соглашениями с соответствующими платежными системами.

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

5.6.       В случае выбора Заказчиком способа оплаты Услуг с применением банковского продукта «рассрочка» (оплаты Услуг с привлечением кредита в одном из банков-партнеров Агента), стоимость Услуг уменьшается таким образом, чтобы сумма уплаченных процентов за пользование кредитом вместе с суммой кредита для Заказчика составила не более первоначальной стоимости Услуг. Данный функционал рассрочки реализован на сайте Агента путем заполнения Заказчиком отдельной формы и перенаправления Заказчика на сайты кредитных организаций для дальнейшей коммуникации Заказчика и организации, предоставляющей кредит. Исполнитель не является вовлеченной во взаимоотношения Заказчика по получению кредита стороной, не несет какой-либо ответственности за действия (бездействия) организации, предоставляющей кредит и/или Заказчика. Данный функционал не является навязанным и может быть использован Заказчиком исключительно добровольно.

5.7.       По согласованию Сторон размер стоимости Услуг может быть уменьшен. Для получения согласованной скидки Заказчик при заполнении формы оплаты обязан указать промокод, который был предоставлен ему Исполнителем.

5.8.       Обязанность Заказчика по оплате Услуг считается исполненной с даты поступления денежных средств на банковский счет Агента.

5.9.       В случае невозможности исполнения, возникшей по вине Заказчика, Услуги подлежат оплате в полном объеме.

5.10.    В случае, когда невозможность исполнения возникла по обстоятельствам, за которые ни одна из Сторон не отвечает, Заказчик возмещает Исполнителю фактически понесенные им расходы.

5.11.    Совершая акцепт Договора-оферты, Заказчик дает согласие на получение одного чека оплаты Услуг по признаку «Полный расчет» в момент внесения полной стоимости Услуг/части Услуг.

6.           Конфиденциальность

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

6.2.       Режим конфиденциальности распространяется на любую иную информацию, которую любая из Сторон идентифицирует как конфиденциальную до или сразу после ее предоставления другой Стороне.

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

6.4.       Обязательства о конфиденциальности сохраняют силу в течение 3 (Трех) лет после истечения срока действия или расторжения Договора-оферты.

7.           Права на результаты интеллектуальной деятельности

7.1.       Материалы и любые иные сведения (информация), предоставляемые Исполнителем Заказчику в процессе оказания Услуг, являются интеллектуальной собственностью Исполнителя (третьих лиц, привлекаемых Исполнителем) и защищены законодательством. Незаконное использование (воспроизведение, распространение, публичный показ и т.д.) указанных материалов, информации в целях извлечения прибыли без письменного согласия запрещено.

7.2.       Заказчик вправе использовать указанные в п.7.1 Договора-оферты материалы и информацию исключительно в личных целях.

7.3.       Использование указанных в п.7.1 Договора-оферты материалов и информации ограничено обязательством Заказчика не воспроизводить, не повторять и не копировать, не продавать и не уступать, не использовать их для каких-либо коммерческих целей, а также не передавать третьим лицам сами материалы и информацию и доступ к ним.

8.           Ответственность Сторон

8.1.       Стороны несут ответственность за неисполнение или ненадлежащее исполнение своих обязательств по Договору-оферте в соответствии с действующим законодательством Российской Федерации.

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

8.3.       Исполнитель не несет ответственности за невозможность оказания Услуг Заказчику по причинам, не зависящим от Исполнителя, в том числе: нарушение работы Интернета, оборудования или ПО со стороны Заказчика. В данном случае Услуги считаются оказанными надлежащим образом.

8.4.       Заказчик несет ответственность за полноту и достоверность сведений (в том числе персональных данных), предоставленных Исполнителю. Заказчик самостоятельно и в полном объеме несет все риски, связанные с отсутствием у Исполнителя актуальных сведений (в том числе персональных данных).

9.           Разрешение споров

9.1.       Споры и разногласия, которые могут возникнуть при исполнении Договора-оферты, могут быть урегулированы в претензионном порядке.

9.2.       Претензия Заказчика по неисполнению и/или ненадлежащему исполнению Исполнителем своих обязательств по Договору-оферте предъявляется Исполнителю по адресу электронной почты, указанной в п.12 Договора-оферты. К претензии прилагаются необходимые для рассмотрения претензии документы, в которых должны быть указаны сведения о неисполнении или ненадлежащем исполнении обязательств Исполнителя. Срок ответа на претензию составляет не более 10 (Десяти) рабочих дней с момента поступления претензии.

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

9.4.       В случае недостижения соглашения споры разрешаются в судебном порядке в соответствии с действующим законодательством Российской Федерации.

10.        Обработка персональных данных

10.1.    Под обработкой персональных данных в настоящем Договоре-оферте понимается сбор, систематизация, накопление, хранение, использование, уточнение (обновление, изменение), обезличивание, блокирование, уничтожение персональных данных Заказчика в целях оказания Услуг, а также осуществление любых иных действий с персональными данными Заказчика с учетом действующего законодательства Российской Федерации.

10.2.    Совершая акцепт Договора-оферты, Заказчик дает Исполнителю согласие на обработку своих персональных данных, а именно:

−     Фамилия, имя, отчество;

−     Почтовый адрес;

−     Адрес электронной почты;

−     Номера телефонов;

−     Год, месяц, дата рождения;

− Данные о трудовой деятельности:

−     Паспортные данные.

10.3.    Совершая акцепт Договора-оферты, Заказчик дает согласие на обработку своих персональных данных Исполнителем с применением следующих основных способов (но, не ограничиваясь ими): автоматизированная обработка, обработка без использования средств автоматизации, хранение, запись на электронные носители и их хранение, составление перечней, ведение баз данных.

10.4.    Согласие на обработку персональных данных действует с момента акцепта Договора-оферты. Срок хранения персональных данных после окончания оказания Услуг – 10 (Десять) лет. Согласие на обработку персональных может быть отозвано Заказчиком при представлении Исполнителю заявления в простой письменной форме в соответствии с требованиями действующего законодательства Российской Федерации.

11.        Прочие условия

11.1.    По вопросам, неурегулированным Договором-офертой, Стороны руководствуются действующим законодательством Российской Федерации.

11.2.    Стороны признают обмен сообщениями по адресам электронной почты, указанным в п.12 Договора-оферты и предоставленным Заказчиком при заполнении формы оплаты, а также с помощью мессенджера Telegram надлежащим способом передачи юридически значимой информации (содержимое писем и сообщений) и документации, признают их равнозначными документам, составленным в письменной форме, подписанным собственноручной подписью, так как только сами Стороны и уполномоченные, ими лица имеют доступ к соответствующим средствам связи. Доступ к электронной почте каждая Сторона осуществляет по паролю и/или логину и обязуется сохранять его конфиденциальность. Все сообщения и документы, направленные/полученные Сторонами указанным в настоящем пункте способом, могут использоваться в качестве письменных доказательств в суде.

11.3.    Обо всех изменениях контактной информации, банковских и иных реквизитов, а также способов обмена информацией, имеющей отношение к Договору-оферте или в связи с ним, Стороны обязаны письменно уведомить друг друга в течение 3 (Трех) рабочих дней со дня такого изменения.

12.        Реквизиты Исполнителя

Индивидуальный предприниматель Филипенко Иван Сергеевич

ИНН: 500914343004

ОГРНИП: 324508100109462

e-mail: evandays95@gmail.com

Дата публикации 19 июня 2024 года

Для чего проводится тестирование ПО?

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

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

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

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

При хорошем раскладе с первого дня в компании новичку назначается buddy - человек, который будет ответственным за адаптацию. На практике часто таким человеком является другой тестировщик, если таких на проекте нет - подойдёт любой живой член команды разработки, начиная ПМ-ом и заканчивая работником службы поддержки. Как раз на нём будет висеть в Jira задачка "Ввести в проект Теста Тестова". Бадди открыт для любых вопросов, связанным с рабочими процессами, доступами, коммуникацией в команде, а еще он будет давать новичку простые задачи наподобие "прочитай вот эту страничку в Confluence" или "проведи смоук-тест вот по этим кейсам".

👉 Компания №1, проект - сайт randewoo.ru, з/п 70-130к рублей

Я пришёл на проект честным джуном, в качестве бадди мне предоставили единственного тестировщика, который к моменту моего трудоустройства уже положил завяление на увольнение на стол руководству. Эмпатия по отношению ко мне отсутствовала, на все вопросы было 3 ответа: "это есть в доке", "загугли" и "хм, не знаю, обратись к разрабу". Благо после его ухода обучением занялся ПМ, исключительный в плане продуктивности человек, у которого было 100 других дел помимо онбординга. Через созвоны с ним я более-менее разобрался в проекте и уже через месяц самостоятельно тестировал сайт. Однако было 2 НО:

1. Так как команда была маленькой, а бизнес стремительно расширялся, в мои обязанности входило примерно всё: тестирование, взаимодействие и споры с другими командами разработки из внешних систем, поддержка 3-ей линии, написание документации проекта (не тестовой), выгрузки данных из БД. А когда я пошёл за закономерным повышением к тимлиду через год работы, он сказал: "ну тут маловато хардскиллов для 120к рублей в месяц, выучи сначала Ruby". Лицо тестировщика представили?
2. Кодовая база проекта представляла из себя кривое легаси, старые разработчики уже не помнили, как всё работает, а новые не могли в этом разобраться. Даже спустя год работы не мог сказать "Я знаю проект", а с учетом предыдущего пункта это заставляло понервничать. Если бы я занимался только тестированием, то меня бы не волновало, как списать у 10.000 пользователей на проде бонусные баллы и что делать, если у некоторых клиентов после этого баланс ушёл в минус 💀

Ставлю этому онбордингу 1 крит на проде из 10.

👉 Компания №2, проект - сервис для рассылки сообщений, з/п 3000$

В команде никогда не было QA, в мои задачи входило прийти и наладить процессы тестирования с нуля. В качестве помощника мне достался python-разработчик, который ни разу не работал с тестировщиками и не понимал, зачем нужны QA. Несмотря на предвзятое отношение к моему ремеслу, Андрей оказался неплохим buddy, который сам написал проект, знал его и отвечал на все возникающие вопросы. Спустя месяц я самостоятельно составил User guide к нашему сервису и приступил к боевым задачам, а ещё через 2 месяца мог смело сказать, что знаю проект, потому что:

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

То, что я единолично и с самого начала представлял собой обеспечение качества в компании, оказалось преимуществом. Меня никто не торопил и не контролировал, с возникающими проблемами и новыми тасками я разбирался в своём темпе. На такое доверие я отвечал ответственным отношением к работе, а возникло это доверие в большей степени из-за того, что в резюме больше не было написано "Junior QA".
Ставлю онбордингу 5 массажных кресел в офисе из 10.

👉 Компания №3 (работаю сейчас), проект - внутренний сервис для общения операторов с клиентами банка через чат, з/п 320к+ рублей

• В качестве buddy мне досталась тестировщица, которая проработала 9 лет в компании и уходить не собирается. В течение первого месяца было проведено 7-8 созвонов с демонстрацией продукта, где детально разобрали интерфейс и внтреннюю логику, на мои вопросы не то, что отвечали, а выпытывали, остались ли незакрытые моменты и нужно ли повторить
• Когда понадобилась помощь с заведением заявок на доступы - помогла бизнес-аналитик из нашей команды, причём сама предложила помощь. Такую же вовлеченность в процесс моей адаптации я получил и от других членов команды
• Каждую среду проходит созвон с QA-лидом, который в индивидуальном порядке интересуется, как проходит процесс онбординга и нужно ли содействие
• Первую боевую задачу я получил только в конце первого месяца онбординга, для выполнения предоставили тестовые данные и провалидировали план, помогли добить проверки. Сейчас идёт второй месяц онбординга и все задачи на тестирование выполняются совместными усилиями в онлайн-режиме, чтобы у меня не было шансов накосячить

С точки зрения архитектуры проект трудный, но спектр задач ограничивается UI-тестированием и в рабочее время на связи человек, к которому можно обратиться. Несмотря на крутую должность и з/п от меня не требуют чрезвычайных усилий и сверхрезультатов.
Ставлю онбордингу 9 созвонов из 10.

Если хочешь облегчить buddy работу, то вот пара практических советов:

1. Записывай все созвоны. Если планируется демо - записывай в видеоформате.
   Иногда объяснения не ложатся в голову с первого раза - это нормально, потом можно переслушать записи в спокойной обставновке и разобраться. Формально это запрещено по NDA, но на практике к этому нормально относятся, а если никому не говоришь - рисков 0
2. Добавляй в закладки ссылки на все веб-ресурсы, даже если это 2 раздела одной и той же документации. Это сэкономит 20-30 минут в день, не придётся перебирать ссылки по чатам с коллегами и заниматься исследовательским тестированием на ровном месте
3. Если появляются вопросы к buddy - собирай в блоки вместо того, чтобы задавать по одному. При таком подходе наставнику будет проще вникнуть в проблему и исчерпывающе ответить, к тому же так уменьшается шанс подрыва жопы от постоянного переключения контекста.

• Компания заинтересована в твоей адаптации больше тебя
• Сложность онбординга никак не коррелирует с позицией или зарплатой
• Если buddy разбирается в проекте - это хорошо. Если не валит из компании - еще лучше
• Не нужно понять проект досконально, чтобы пройти онбординг
• Вместо переспрашивания наставника по 10 раз - проще записать и переслушать

• Если пришёл на проект, но остался без buddy и не знаешь, что делать - пиши в личку, порешаем

Спасибо за внимание!
Жду всех начинающих, продвинутых и состоявшихся QA-специалистов в своём Telegram-канале QA feels good

Обо мне

Привет! Меня зовут Иван, 28 лет, 3 года коммерческого опыта в QA. В феврале я заработал 3187$ + 205.000р. на тестировании. В марте ожидается на 429.000р. больше за счёт нового проекта и я бы не заработал этих денег, если бы не чувствовал, что вправе их брать.

Вопрос "За что мне платят?" пронизывает карьеру айтишника и особенно тревожит начинающих специалистов. На этапе знакомства я спрашиваю учеников о зарплатных ожиданиях после обучения и слышу "нууу 100", "хотя бы 80", "лишь бы устроиться", хотя они приходят по ссылке из моей визитки, где написано "Средняя зарплата ученика после трудоустройства - 150.000 рублей".
Нет понимания, как человек, который не пишет код, способен генерировать пользу. С трудоустройством это непонимание никуда не девается, а эволюционирует в синдром самозванца, который сидит на шее и душит при попытке выбить повышение или сменить работу.
Эта статья поможет самому придушить внутреннего самозванца, выступать на дейликах с гордостью и не испытывать муки совести, когда придёт время уходить из "компании-семьи" на x2 от предыдущей зарплаты.

Наглядный ресёрч по вилкам в США я подсмотрел в этом видео, если кратко - медианная зарплата Manual QA составляет 99.000$ в год.
Человек, который боится больших цифр, скажет: "Ну, такая зарплата светит только с идеальным знанием английского и современного стэка технологий". Родной, с современным стеком можно замахнуться и на 200к$, вот биржа вакансий. Да, придётся разобраться с блокчейном, но это тот случай, когда потраченное на обучение время стоит того.
А за условные 8000$ в месяц работают простые смертные, как мы, и ребята из СНГ и даже индусы. Также пишут тест-кейсы, сопровождают интеграции, пропускают криты на прод и потом доказывают на дейлике, что на препроде этот баг не воспроизводился. Уровень английского для этого не обязан быть запредельным, и до конца 2024 года я со своим B2 докажу это на практике.

Ситуация на российском рынке тоже радует по сравнению с другими отраслями. Для Manual QA озвучивают вилки в 230к рублей. А инженеры со знанием авто и нагрузочного натягивают даже backend-разрабов внутри одной и той же компании:

Держим в уме, что опубликованные вилки, как правило, не отображают всего бюджета, выделенного на найм сотрудника и часто компания готова подвинуться ещё на 5-25%, если кандидат классный. Напомню, что эти ништяки достаются человеку, у которого из инструментов порой только Devtools и папка "Скрины для работы".

Значимость программистов давно не вызывает сомнений. Разработчик генерирует value, которое может десятикратно и стократно превышать его зарплату, чтобы доказать это - достаточно посмотреть на капитализацию BigTech-компаний, единственная ценность которых - программные продукты. Но если бы команда разработки генерировала прибыль стабильно и без посторонней помощи, я бы не писал эту статью. Людям свойственно косячить. Косячат менеджеры, приоритезируя задачи. Косячат аналитики, формируя требования. И конечно же косячат разрабы, уменьшая, а то и сводя на нет созданный профит, когда отдают забагованное ПО.
Здесь и проявляется ценность QA-инженера, который за счёт досконального знания проекта направляет разработку в нужное русло. Мы обнаруживаем баги на ранних этапах жизненного цикла продукта, тем самым экономим время разработчиков (значит, и деньги компании) и им не приходится дважды делать свою работу. А за счёт недопущения дефектов на продакшн мы сохраняем лояльность клиентов и бизнес не лишается дохода на ровном месте.
С увеличением количества разрабов на проекте ценность каждого QA будет только расти: к примеру, наладка процессов тестирования, проведение regression и smoke страхуют от дефектов, вызванных сразу всеми разработчиками.
К слову о материальных потерях из-за недостаточного тестирования:

Приведу примеры из статьи о самых эпичных багах за всё время существования ПО.

• NASA Mars Climate Orbiter — $193.000.000 убытков. Кратко - ребята не провели тестирование локализации и не учли, что американские и континентальные единицы измерения отличаются. На потерянную сумму денег можно было в течение 16 лет кормить 10 тестировщиков с зарплатой в 100.000$ в год!
• Баг 2000 года. $600.000.000.000 убытков. Известная история о том, как компьютеры прошлой эпохи некорректно обрабатывали дату "01.01.2000", из-за чего нахлобучились бы банковская, военная, ядерная и другие сферы, в которых использовались компьютеры. Суммарные затраты на хотфикс составили полтриллиона долларов.
  Многие мечтают попасть в прошлое, чтобы сколотить состояние на ставках, но я предлагаю альтернативный вариант достижения успеха: достаточно применить технику тест-дизайна "граничные значения" в 1960х и предотвратить тем самым миллениум-баг.
• Mariner 1 — $18.000.000 убытков. Разработчик пропустил минус в формуле при деплое в продакшн во время ввода информации в бортовую систему и ракета развалилась.
  Можно ли было избежать такого исхода? Да, с налаженными процессами тестирования, с исчерпывающими тестовыми данными, смоук-тестом, код-фризом, а главное - с QA-инженером, который внедрил бы все эти практики.

Ты можешь сказать: "Это не про меня, тут какие-то ракеты и спутники, а я работаю в ООО «Пятничный релиз» и обслуживаю интернет-магазин по продаже товаров для левшей". Отвечу так - конечно мы не измерим с точностью до рубля пользу каждого QA-инженера, но это и не нужно, ведь за нас это уже сделал рынок. Бизнес умеет считать деньги, и если мы видим вакансию QA - скорее всего в этой компании уже навернули рисков за обе щёки и отдавать 200к в месяц за спокойствие вместо того, чтобы получить очередной крит на прод - очень даже выгодная сделка.

Зачем нам тестировщик, лучше бы наняли ещё одного разраба
© Андрей, Python developer

Ценность QA как специалиста состоит в том, что он знает продукт на уровне ПМа: понимает бизнес-процессы, в курсе последних и грядущих изменений в коде, знает, к кому обратиться за требованиями и уточнениями. Это даёт возможность делать эффективные проверки.
Программист же иногда понятия не имеет, как его код повлияет на работу всего сервиса или вместе с какими другими изменениями его фича поедет на прод. У него другие важные дела: думать над наилучшей реализацией логики, воевать с другими разрабами на код ревью, пить ванильный раф в конце концов. Ещё разрабу, как и кому угодно, тяжело объективно оценивать результаты собственной работы. Основные причины:

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

1. Компании готовы платить QA-инженерам хорошие деньги
2. QA-инженеры экономят время других участников команды разработки за счёт оптимизации процессов, а ещё страхуют бизнес от убытков, вызванных багами
3. Баги обходятся бизнесу очень дорого: от нескольких зарплат разработчика до ВВП целой страны
4. Разработчики не хотят и не могут делать работу QA
5. Сколько бы ты сейчас не зарабатывал - ты заслуживаешь большего

Спасибо за внимание!
Жду всех начинающих, продвинутых и состоявшихся QA-специалистов в своём Telegram-канале QA feels good