Size: a a a

QA — русскоговорящее сообщество

2021 March 24

ИС

Иван Снегов... in QA — русскоговорящее сообщество
Илья Попов
Вы пишете :2) Прирост времени затрачиваемого на тестирование тасок был небольшим - по моим субьективным оценкам 5-10%. Больше времени затрачивалось на уточнение требований.
Так Вы тестировали по старым тест-кейсам? Не изменяя их что-ли?
По старым тесткейсам, по необходимости изменяя, удаляя или дописывая новые
источник

ИП

Илья Попов in QA — русскоговорящее сообщество
Так получается продукт не менялся сильно?
источник

ИС

Иван Снегов... in QA — русскоговорящее сообщество
Илья Попов
Так получается продукт не менялся сильно?
Нет, менялся
источник

AG

Andrew Gasov in QA — русскоговорящее сообщество
Иван Снегов
По возможности расписывали максимально атомарно.

1) ~90% функционала приложения было покрыто тесткейсами. В дальнейшем все влетающие задачи покрывались тесткейсами. Измеряли по таблице переходов
2) Прирост времени затрачиваемого на тестирование тасок был небольшим - по моим субьективным оценкам 5-10%. Больше времени затрачивалось на уточнение требований.
3) По ним прогонялся регулярный регресс. Часть функционала была покрыта автотестами. Так же при ручном тестировании тасок было требование проверить связанные с этим функционалом тесткейсы на соответствие новым требованиям и, по необходимости, внести правки
Я скорее говорил не про атомарность, а про детализацию ака "подробность".
Пушта очевидно, что чем больше деталей -> тем чаще их нужно обновлять.

Так вот.
1) 90% переходов это, конечно, круто.
Хотя переходы не всегда тождественны состояниям приложения (и уж совсем не равны тестовым сценариям).
Но респект, в любом случае, цифра хорошая. :)

2) 5-10% времени на каждую задачу это, на мой субъективный взгляд, так-то дофига.
Это условные 2-4 часа времени в неделю на каждого тестировщика.
Учитывая, практику "пройтись по связанным тест-кейсам и обновить" - эта цифра, по мере роста количества логики, документации и состояний, будет только расти.

3) Проблема с "проверкой на основе регулярного регресса" как раз в том, что потом оказывается, что половина тест-кейсов нифига не актуальна.
Просто потому, что те, кто его регулярно проходят, лезут обновлять тест-кейсы если они уже совсем сломаны\не актуальны.
А в остальных случаях особенно не вчитываются, потому что и так их наизусть знают.
Выглядит похожим на правду -> ставим passed.
Естественно, это один из сценариев и бывает по другому.
Но по моему опыту это довольно частый кейс.


Это я, собственно, не к тому, что тестовую документацию нереально поддерживать.
Это к тому, что большинство людей которые утверждают "да мы особо не тратим на это ресурсы" или пребывают в блаженном неведении о том, в каком состоянии у них документация, или просто не считают количество времени, которое на это тратится.
источник

ИС

Иван Снегов... in QA — русскоговорящее сообщество
Andrew Gasov
Я скорее говорил не про атомарность, а про детализацию ака "подробность".
Пушта очевидно, что чем больше деталей -> тем чаще их нужно обновлять.

Так вот.
1) 90% переходов это, конечно, круто.
Хотя переходы не всегда тождественны состояниям приложения (и уж совсем не равны тестовым сценариям).
Но респект, в любом случае, цифра хорошая. :)

2) 5-10% времени на каждую задачу это, на мой субъективный взгляд, так-то дофига.
Это условные 2-4 часа времени в неделю на каждого тестировщика.
Учитывая, практику "пройтись по связанным тест-кейсам и обновить" - эта цифра, по мере роста количества логики, документации и состояний, будет только расти.

3) Проблема с "проверкой на основе регулярного регресса" как раз в том, что потом оказывается, что половина тест-кейсов нифига не актуальна.
Просто потому, что те, кто его регулярно проходят, лезут обновлять тест-кейсы если они уже совсем сломаны\не актуальны.
А в остальных случаях особенно не вчитываются, потому что и так их наизусть знают.
Выглядит похожим на правду -> ставим passed.
Естественно, это один из сценариев и бывает по другому.
Но по моему опыту это довольно частый кейс.


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

ИС

Иван Снегов... in QA — русскоговорящее сообщество
Имхо фронтовые ручные кейсы лучше покрывать тесткейсами
Бэкенд/автоматизированные - чеклистами
источник

S

Sub in QA — русскоговорящее сообщество
имхо надо от бизнес велью отталкиваться
источник

YP

Yan Purvenes in QA — русскоговорящее сообщество
Иван Снегов
Имхо фронтовые ручные кейсы лучше покрывать тесткейсами
Бэкенд/автоматизированные - чеклистами
Ну зависит что за фронты и сколько. Плюс есть ли автоматизация или штат ассесоров
источник

AG

Andrew Gasov in QA — русскоговорящее сообщество
Иван Снегов
В моем опыте на проектах часто возникали вопросы "а как сейчас должен работать этот функционал" и документации либо не было никакой, либо свежая таска в которую не всегда вписывали конечное решение из мессенджера.  Да и в целом с моей субъективной колокольни время затрачиваемое на текущую поддержку тесткейсов должно входить во  время затрачиваемое на непосредственно тестирование фичи.
Но опять же - все зависит от конкретных проектов.
Не, я не спорю с тем, что писать тестовую документацию может иметь смысл.
Как и с тем, что в некоторых случаях она спасает. :)

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

ИС

Иван Снегов... in QA — русскоговорящее сообщество
Andrew Gasov
Не, я не спорю с тем, что писать тестовую документацию может иметь смысл.
Как и с тем, что в некоторых случаях она спасает. :)

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

E

Elena in QA — русскоговорящее сообщество
Всем привет, хочу научиться тестировать. Кто посоветует хорошие курсы инженера тестировщика ? Я человек с нулевым знанием 🙂
источник

К

Коля in QA — русскоговорящее сообщество
Elena
Всем привет, хочу научиться тестировать. Кто посоветует хорошие курсы инженера тестировщика ? Я человек с нулевым знанием 🙂
поиск в гугл + поиск по чату
источник

E

Elena in QA — русскоговорящее сообщество
Зачем тогда сообщество ? Чтобы просто в Гугл послать 🤷🏽‍♀️ я думала у вас опыт есть и вы можете поделиться.
источник

AG

Andrew Gasov in QA — русскоговорящее сообщество
Elena
Зачем тогда сообщество ? Чтобы просто в Гугл послать 🤷🏽‍♀️ я думала у вас опыт есть и вы можете поделиться.
@qa_courses вот тут целый чатик про курсы.
Можете почитать отзывы и посмотреть, чем уже поделились.
источник

E

Elena in QA — русскоговорящее сообщество
Благодарю
источник

IS

Ice Spirit in QA — русскоговорящее сообщество
Elena
Зачем тогда сообщество ? Чтобы просто в Гугл послать 🤷🏽‍♀️ я думала у вас опыт есть и вы можете поделиться.
Сообщество по вопросам в сфере, а не о том как в эту сферу попасть.  Таких как вы в чате ежедневно с идентичным вопросом много, в закрепе должна быть инфа по специализированным каналам для новичков.
источник

E

Elena in QA — русскоговорящее сообщество
Тоже спасибо ) согласна что таких вопросы каждый день хватает.
источник

МA

Мария Amanalyre in QA — русскоговорящее сообщество
Мне в текущем проекте нравится, что бОльшая часть всего покрыта автотестами, которые, по сути, и являются тестовой документацией.
Тест-кейсов, как таковых, минимально.
Отдельно лежат доки на что-то глобально важное для команды, например, регистрацию или ивенты трекинга
источник

RG

Richard Gears in QA — русскоговорящее сообщество
Elena
Всем привет, хочу научиться тестировать. Кто посоветует хорошие курсы инженера тестировщика ? Я человек с нулевым знанием 🙂
источник

YP

Yan Purvenes in QA — русскоговорящее сообщество
Мария Amanalyre
Мне в текущем проекте нравится, что бОльшая часть всего покрыта автотестами, которые, по сути, и являются тестовой документацией.
Тест-кейсов, как таковых, минимально.
Отдельно лежат доки на что-то глобально важное для команды, например, регистрацию или ивенты трекинга
Автоматизацией кто занят?
источник