С какими типами входной документации вы работали при планировании тестирования?

А, вот эта тема, блядь, про документацию! Ну это же просто пиздец, а не работа, честно говоря. Качество тестов — это как суп: если положить туда говна вместо мяса, то хоть три дня вари — всё равно херня получится, а не борщ. И мясо это — как раз входная документация, ёпта.

Вот с чем приходится сталкиваться, пока не поседеешь, блядь:

1. Требования, они же «хотелки»:

   • SRS (Software Requirements Specification) — это типа священный грааль, формальный документ. В нём должно быть всё: что система делает, а что нет. На практике же там часто написано: «ну, чтобы работало, и не лагало». Охуенно, да?
   • User Stories и Use Cases — это в этих ваших Agile-танцах с бубном. Из них надо как алхимик вытащить acceptance criteria, то есть когда мы считаем, что история — не просто рассказ, а сделана. А критерии эти иногда прописаны так, что хоть святых выноси.

2. Технические писанины:

   • API-документация (Swagger/OpenAPI и т.д.): Вот это, блядь, святое! Если она есть и актуальна — жить можно. Понимаешь, как бабать запросы, какие ошибки ждать. Если её нет... ну, это как искать чёрную кошку в тёмной комнате, где её, сука, ещё и нет.
   • Технические проекты и схемы: Нужны, чтобы понять, где одна хрень цепляется за другую, и где это всё может грохнуться с треском. Без них чувствуешь себя слепым кротом в подземном ходе.

3. Картинки для раскрашивания:

   • Мокапы из Figma/Zeplin: По ним сверяем, чтобы кнопка была не зелёная, а синяя, и не посередине лба, а там, где задумано. Проверка пиксель-пёрфект, ёбана! Иногда дизайнеры такие извращения придумывают, что волосы дыбом.
   • Гайдлайны по стилю: Чтобы во всём приложении был один шрифт, а не как в палате №6 — у каждого своя буква.

4. Наследство от предков:

   • Чек-листы и тест-кейсы прошлых команд. Их надо разбирать, как квартиру после алкоголиков. Половину — выкинуть, половину — отмыть и переписать. А то бывает такое наследуешь — просто волнение ебать, где они мозги-то прятали.

Вот, смотри, как по нормальной API-докушке можно сразу код написать, а не гадать на кофейной гуще:

import requests
import pytest

# Допустим, в Swagger ясно написано: GET /users — отдаёт список
BASE_URL = "https://api.example.com"

def test_get_users_returns_200_and_list():
    """Проверяем, что эндпоинт не сдох и отдаёт нам список, а не, например, фотку котика."""
    response = requests.get(f"{BASE_URL}/users", 
                            headers={"Accept": "application/json"})

    # Если тут не 200, а, скажем, 500 — сразу ясно: или документация врёт, или сервер горит
    assert response.status_code == 200, f"Ожидался 200, получен {response.status_code}"

    response_json = response.json()
    assert isinstance(response_json, list), "Ответ должен быть списком, а не чем попало!"
    # Дальше можно ковыряться в структуре каждого пользователя...

# А вот тест на то, что методы, которых не должно быть, — отшиваются
@pytest.mark.parametrize("method", ["POST", "PUT", "DELETE"])
def test_users_endpoint_rejects_wrong_method(method):
    """Эндпоинт /users должен говорить "иди нахуй" (405) на POST, PUT, DELETE."""
    response = requests.request(method, f"{BASE_URL}/users")
    assert response.status_code == 405, 
           f"Для метода {method} ожидался 405 'Method Not Allowed', а пришло {response.status_code}"

И главное, запомни как «Отче наш»: если в документации хуйня, неясность или прям противоречие — НЕ МОЛЧИ! Беги сразу уточнять у аналитиков, продакт-овнеров или разработчиков. Потому что если промолчишь и сделаешь по-своему, а потом окажется, что это не так — виноват будешь ты, блядь. «А чё ты не спросил?». Так что лучше выглядеть занудой, чем потом разгребать пиздец.