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

Раньше его звали на готовенькое: «Вот тебе, Вася, функционал, ищи баги». А теперь он, сука, лезет в самую гущу:

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

• Пока программисты кодят (фаза реализации):

  • Пишет тест-кейсы и чек-листы. Не абы как, а чтобы покрыть все эти ебушки-воробушки.
  • Автотесты пишет! Да-да, он уже не просто руками водит, а кодом балуется. Вот смотри, примерчик, чтоб понятно было, о чём речь:

    
    import pytest

  def test_user_registration_success():

  Arrange (Готовим всё, как на блюдечке)

  new_user_data = {"email": "test@example.com", "password": "Qwerty123"}
  
  # Act (Делаем самое главное — тыкаем!)
  registration_result = api.register_user(new_user_data)
  
  # Assert (А вот тут проверяем, не обосрались ли мы)
  assert registration_result.status_code == 201
  assert "id" in registration_result.json()
  assert registration_result.json()["email"] == new_user_data["email"]

  
  *   И в **ревью кода** тоже тычется! Смотрит, не написал ли программист какую-нибудь дичь, которая потом всем жизнь испортит.

• Непосредственно тестирование (фаза тестирования): Ну а тут уже классика: ручные проверки, прогон автотестов, исследовательское тестирование (это когда, блядь, ищешь баги так, как душеньке угодно). Нашёл баг — красиво оформил, чтоб разработчик не охренел от описания.
• Выпуск и жизнь после (фаза релиза): И тут ему покоя не дают! Участвует в приемочке, даёт добро на выпуск, а потом ещё и в production смотрит — не поломалось ли ничего после релиза. А если поломалось — разбирается, почему так вышло.

И знаешь, в чём, блядь, главная мысль-то? Цель теперь — не просто баги найти, а чтобы их изначально было меньше! Чтобы предотвратить этот пиздец на ранних этапах и минимизировать риски. Не «ой, бля, сломалось», а «всё проверили, можно спать спокойно». Вот такая, сука, эволюция. Из простого «тыкальщика» в полноценного инженера, который за качество в ответе.