Size: a a a

2020 October 06

KR

Kirill Ryazantsev in QA juniors
во славу сатаны
источник

M

Maxim in QA juniors
Сейчас бы без опыта в сферическом коне требования научиться анализировать и тестовую документацию писать
А потом придти на первое место работы и заново научиться с требованиями работать и тестовую документацию писать
источник

AI

Alexander Ivanov in QA juniors
Kirill Ryazantsev
во славу сатаны
источник

KR

Kirill Ryazantsev in QA juniors
Maxim
Сейчас бы без опыта в сферическом коне требования научиться анализировать и тестовую документацию писать
А потом придти на первое место работы и заново научиться с требованиями работать и тестовую документацию писать
+
источник

AG

Andrew Gasov in QA juniors
Maxim
Сейчас бы без опыта в сферическом коне требования научиться анализировать и тестовую документацию писать
А потом придти на первое место работы и заново научиться с требованиями работать и тестовую документацию писать
Добро пожаловать во взрослый мир.
Каждый раз, когда вы будете менять работу, может оказаться так, что на новом месте и требования по другому пишут, и тестовую документацию по другому ведут.
А где-то вообще не будет ни того, ни другого.

Анализ требований упирается в три составляющих:
1) Понимание принципов работы продукта (платформы, стэка, бизнеса).
2) Понимание теории тестирования (потому что, в общем-то, большая часть пробелов в документации отлично ловится на написании тестов, если уж раньше не получилось).
3) Способность задавать (правильные) вопросы aka критическое мышление и здравый смысл.

В целом, каждый из этих пунктов не особенно-то привязан к наличию реального прям продакшена и опыта с ним.
Естественно, когда аналитик метает в тебя ТЗ, которое ему пришлось написать в три часа ночи на пути из бара в бордель, а вокруг бегает проджект менеджер с криками «НУ ЧО ТАМ ВСЁ НОРМАЛЬНО????» процесс обучения проходит быстрее, чем когда тебе приходится выкапывать знания самому из недр интернетов или курсов.
Точно так же, как понимание проблемных мест и частых ошибок в тех или иных доменных областях гораздо быстрее приходит когда протестированная тобой задача роняет продакшен тринадцать раз к ряду.

Но это всё ещё не значит, что практика на продакшене- единственный способ для получения этих знаний.
источник

К

Константин Соснин... in QA juniors
Вот умеешь ты по полочкам все разложить👍
источник

M

Maxim in QA juniors
Andrew Gasov
Добро пожаловать во взрослый мир.
Каждый раз, когда вы будете менять работу, может оказаться так, что на новом месте и требования по другому пишут, и тестовую документацию по другому ведут.
А где-то вообще не будет ни того, ни другого.

Анализ требований упирается в три составляющих:
1) Понимание принципов работы продукта (платформы, стэка, бизнеса).
2) Понимание теории тестирования (потому что, в общем-то, большая часть пробелов в документации отлично ловится на написании тестов, если уж раньше не получилось).
3) Способность задавать (правильные) вопросы aka критическое мышление и здравый смысл.

В целом, каждый из этих пунктов не особенно-то привязан к наличию реального прям продакшена и опыта с ним.
Естественно, когда аналитик метает в тебя ТЗ, которое ему пришлось написать в три часа ночи на пути из бара в бордель, а вокруг бегает проджект менеджер с криками «НУ ЧО ТАМ ВСЁ НОРМАЛЬНО????» процесс обучения проходит быстрее, чем когда тебе приходится выкапывать знания самому из недр интернетов или курсов.
Точно так же, как понимание проблемных мест и частых ошибок в тех или иных доменных областях гораздо быстрее приходит когда протестированная тобой задача роняет продакшен тринадцать раз к ряду.

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

AG

Andrew Gasov in QA juniors
Одно, в общем-то, не противоречит другому.
Хотя я бы, например, сказал, что способность джуниора посмотреть на кривое ТЗ и задать хотя бы топ-10 очевидных вопросов по пробелам в нём - гораздо важнее, чем то, что он молодец и выучил наизусть типы тестирования и какие артефакты бывают.
источник

AG

Andrew Gasov in QA juniors
А по поводу около-нулевой-эффективности, тут сложнее.
Есть, например, люди, которые искренне убеждены, что учиться тестированию самостоятельно, без ментора, курсов и прочего - неэффективно.
Есть люди, которые считают, что если на новой работе тебе не преставили всё того же ментора, который тебя онбордит и учит - то эффективность обучения тоже стремится к нулю.
В конце концов, если почитать этот и смежные чатики, очень многие люди убеждены, что научиться писать автотесты можно только устроившись автотестером. Потому что какой там опыт без продакшена-то.

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

В

Влад Савчук... in QA juniors
Народ, а если у вас есть бек таска на новое апи, и фронт для неё, вы только фронт потыкаете и закроете?
источник

В

Влад Савчук... in QA juniors
Или будете и бек тыкать
источник

KR

Kirill Ryazantsev in QA juniors
Влад Савчук
Народ, а если у вас есть бек таска на новое апи, и фронт для неё, вы только фронт потыкаете и закроете?
ну если с фронта отправляется всё так, как я хочу, то потыкаю только фронт
а если ещё к этому захочу попробовать поломать и отправить напрямую что-то, что невозможно отправить через фронт, например, отрицательные значения, которые на фронте блокируются, то можно и бек потыкать
источник

AG

Andrew Gasov in QA juniors
Влад Савчук
Народ, а если у вас есть бек таска на новое апи, и фронт для неё, вы только фронт потыкаете и закроете?
Это зависит от ситуации.
Более правильным подходом будет проверять и то, и другое, но это, ожидаемо, повлечет больше затрат ресурсов с неясным результатом.

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

Из минусов:
- Интерфейсы API могут меняться по мере интеграции фронта с бэком, в таком случае ранее проведенные тесты будут пустой тратой времени.
- Больше затраты времени засчёт того, что тесты фронта и бэка будут частично пересекаться.


(Спойлер: есть команды, где это делается в три этапа: API - UI (со стабами) - E2E)
источник

KR

Kirill Ryazantsev in QA juniors
тут как хочешь
источник

В

Влад Савчук... in QA juniors
Меня отчитали разрабы за то что я сначало тыкаю апи, потом фронт
источник

В

Влад Савчук... in QA juniors
Ибо это "долго"
источник

KR

Kirill Ryazantsev in QA juniors
Влад Савчук
Меня отчитали разрабы за то что я сначало тыкаю апи, потом фронт
хуйня какая-то
источник

И

Иисус in QA juniors
Влад Савчук
Ибо это "долго"
Это действительно долго.
источник

И

Иисус in QA juniors
А для чего это делать, если уже готов фронт?
источник

KR

Kirill Ryazantsev in QA juniors
Иисус
А для чего это делать, если уже готов фронт?
действительно
источник