Зачем системному аналитику думать как QA-инженер
Помню, как-то получил фидбек от разработчика. Сижу, значит, доволен собой, сделал постановку, отправил. Через пару часов влетают комменты: «А как это тестировать?» Я на автомате: «Ну я же аналитик, не QA». И тут меня осенило. Потому что реально — если я не думаю, как это будет проверяться, кто вообще должен об этом думать? QA будет вылавливать баги в проде? Разработчик должен догадываться, что я имел в виду в постановке? Или PM будет выслушивать от заказчика, что мы опять не учли половину сценариев?
Когда ты системный аналитик — ты не просто пишешь, как "должно работать". Ты формируешь мышление всей команды по отношению к фиче. И если ты не подумал, как это проверить, ты не аналитик, ты писатель художественной литературы. Мне раньше казалось, что это не моя зона ответственности. Но чем больше я работал, тем больше понимал: отсутствие логики в описаниях, непроработанные кейсы, «а давайте тут пусть просто работает» — это не «экономия времени», это накопленный технический долг. Который потом выстреливает.
Классический пример — описание: «Пользователь может фильтровать список заказов по дате, категории и статусу». Звучит адекватно. А теперь представь, что ты QA. А какие именно статусы? А если ничего не выбрать — список какой? А можно фильтровать по нескольким категориям сразу? А дата — с и по, или строго день в день? А если вбить строку вместо даты? А что, если заказов вообще нет? Ты как аналитик думал, что описал функциональность. А по факту ты породил 10 вопросов, потому что описал всё слишком в общем и забыл про граничные и негативные кейсы.
Реальность в том, что QA ловит баги, но твоя задача — не допустить, чтобы баг в принципе появился. QA может быть суперкрутым, но если в описании нет логики, то ни одни автотесты это не спасут. Разработчик тоже не телепат. Он делает по ТЗ. А если ТЗ — это набор красивых слов без конкретики, продукт рассыпается. И да, это твоя зона ответственности.
Так что, хочешь ты или нет, но думать, как QA, — это не «плюсик в карму», а базовая гигиена аналитика. Не надо быть экспертом в тестировании, не надо писать тест-кейсы. Надо просто на каждый сценарий смотреть с двух сторон: как реализовать и как проверить. Ты должен заранее видеть, где может отвалиться логика, где пользователь может ввести дичь, где нужно поставить валидации, где сценарий уходит за рамки. Всё это нужно учитывать на берегу. А не потом, когда фича уже ушла в прод и все бегают с вопросом «кто это так описал?»
Думать, как QA — значит писать постановки, которые можно проверить. Не просто «вроде всё понятно», а реально протестировать. С кейсами, с условиями, с деталями. Потому что именно на этом этапе ты либо создаёшь стабильный продукт, либо закладываешь бомбу, которая взорвётся через две недели. Мне понадобилось время, чтобы это понять. И если бы я в самом начале больше внимания уделял именно проверяемости логики, я бы сэкономил себе кучу нервов.
Так что, если ты системный аналитик и хочешь реально прокачаться — начни с простого: представляй, что завтра тебе дадут всё это тестировать вручную. Прямо руками. Без доп. вопросов, без чатов, без «а я имел в виду». Вот сможешь? Тогда норм. А если сам не понимаешь, как это тестировать — перепиши.
Потому что сильный аналитик — это не тот, кто красиво оформил диаграмму, а тот, кто закрыл все дыры в логике ещё до того, как началась разработка.
А на канале у Эда вышла статья "Зачем QA-инженеру думать как аналитик"
Помню, как-то получил фидбек от разработчика. Сижу, значит, доволен собой, сделал постановку, отправил. Через пару часов влетают комменты: «А как это тестировать?» Я на автомате: «Ну я же аналитик, не QA». И тут меня осенило. Потому что реально — если я не думаю, как это будет проверяться, кто вообще должен об этом думать? QA будет вылавливать баги в проде? Разработчик должен догадываться, что я имел в виду в постановке? Или PM будет выслушивать от заказчика, что мы опять не учли половину сценариев?
Когда ты системный аналитик — ты не просто пишешь, как "должно работать". Ты формируешь мышление всей команды по отношению к фиче. И если ты не подумал, как это проверить, ты не аналитик, ты писатель художественной литературы. Мне раньше казалось, что это не моя зона ответственности. Но чем больше я работал, тем больше понимал: отсутствие логики в описаниях, непроработанные кейсы, «а давайте тут пусть просто работает» — это не «экономия времени», это накопленный технический долг. Который потом выстреливает.
Классический пример — описание: «Пользователь может фильтровать список заказов по дате, категории и статусу». Звучит адекватно. А теперь представь, что ты QA. А какие именно статусы? А если ничего не выбрать — список какой? А можно фильтровать по нескольким категориям сразу? А дата — с и по, или строго день в день? А если вбить строку вместо даты? А что, если заказов вообще нет? Ты как аналитик думал, что описал функциональность. А по факту ты породил 10 вопросов, потому что описал всё слишком в общем и забыл про граничные и негативные кейсы.
Реальность в том, что QA ловит баги, но твоя задача — не допустить, чтобы баг в принципе появился. QA может быть суперкрутым, но если в описании нет логики, то ни одни автотесты это не спасут. Разработчик тоже не телепат. Он делает по ТЗ. А если ТЗ — это набор красивых слов без конкретики, продукт рассыпается. И да, это твоя зона ответственности.
Так что, хочешь ты или нет, но думать, как QA, — это не «плюсик в карму», а базовая гигиена аналитика. Не надо быть экспертом в тестировании, не надо писать тест-кейсы. Надо просто на каждый сценарий смотреть с двух сторон: как реализовать и как проверить. Ты должен заранее видеть, где может отвалиться логика, где пользователь может ввести дичь, где нужно поставить валидации, где сценарий уходит за рамки. Всё это нужно учитывать на берегу. А не потом, когда фича уже ушла в прод и все бегают с вопросом «кто это так описал?»
Думать, как QA — значит писать постановки, которые можно проверить. Не просто «вроде всё понятно», а реально протестировать. С кейсами, с условиями, с деталями. Потому что именно на этом этапе ты либо создаёшь стабильный продукт, либо закладываешь бомбу, которая взорвётся через две недели. Мне понадобилось время, чтобы это понять. И если бы я в самом начале больше внимания уделял именно проверяемости логики, я бы сэкономил себе кучу нервов.
Так что, если ты системный аналитик и хочешь реально прокачаться — начни с простого: представляй, что завтра тебе дадут всё это тестировать вручную. Прямо руками. Без доп. вопросов, без чатов, без «а я имел в виду». Вот сможешь? Тогда норм. А если сам не понимаешь, как это тестировать — перепиши.
Потому что сильный аналитик — это не тот, кто красиво оформил диаграмму, а тот, кто закрыл все дыры в логике ещё до того, как началась разработка.
А на канале у Эда вышла статья "Зачем QA-инженеру думать как аналитик"