Size: a a a

2018 November 29

Z

ZEEGIN in testspro1c
я про тестирование в впринципе
источник

Z

ZEEGIN in testspro1c
Nikita Gryzlov
а вот это спорное утверждение. а как же тестирование по методу черного ящика? тесты до вообще какой-либо реализации (кроме собственно интерфейса) - это нормальная и частая практиа
черныц ящик это только ручное тестирование и на выходе новый неотработанный программистом сценарий, который он добавляет в список
источник

‌‌‎infactum in testspro1c
Тестировщики вообще не спят походу 😂
источник

NM

Nikita Mikhaylov in testspro1c
ZEEGIN
Ну и я хочу донести все таки важную вещь, сценарные тесты это очень дорого в поддержке. И нужны они только когда нужно закреплять конкретное поведение пользователя на форме. Большую часть кода проще и лучше тестировать модульными тестами.
в документации описывается конкретное поведение на форме. Если сценарий не проходит - то это звонок, что и справку/документацию надо обновить (либо что-то пошло не так).
В конечных внедрениях работает именно это, в рамках БСП - да, там больше покрытие модульное.
Но для конечного - важно имено соблюдение сценария.
Переучивать 1000+ пользователей, что теперь команда заполнения отсутствует и надо делать по другому - тоже еще та задача...
источник

NM

Nikita Mikhaylov in testspro1c
‌‌‎infactum
Тестировщики вообще не спят походу 😂
так у них столько вариантов тестирования... Кто-то спорит 1С, питон, джава... А тут модульное, дымовое, сценарное... И все надо делать )
источник

Z

ZEEGIN in testspro1c
Nikita Mikhaylov
в документации описывается конкретное поведение на форме. Если сценарий не проходит - то это звонок, что и справку/документацию надо обновить (либо что-то пошло не так).
В конечных внедрениях работает именно это, в рамках БСП - да, там больше покрытие модульное.
Но для конечного - важно имено соблюдение сценария.
Переучивать 1000+ пользователей, что теперь команда заполнения отсутствует и надо делать по другому - тоже еще та задача...
В бсп пишутся и модульные и интеграционные и сценарные тесты. Плюс большой дымовой на открытие всего, попытки перезаписать, скопировать и записать и т.п.
источник

‌‌‎infactum in testspro1c
Да БСП то как раз эталон для юнит тестов.
Интереснее тестирование прикладных решений.
источник

Z

ZEEGIN in testspro1c
Nikita Mikhaylov
в документации описывается конкретное поведение на форме. Если сценарий не проходит - то это звонок, что и справку/документацию надо обновить (либо что-то пошло не так).
В конечных внедрениях работает именно это, в рамках БСП - да, там больше покрытие модульное.
Но для конечного - важно имено соблюдение сценария.
Переучивать 1000+ пользователей, что теперь команда заполнения отсутствует и надо делать по другому - тоже еще та задача...
Если есть закрепленное поведение на форме - то это этл сценарный.
источник

NM

Nikita Mikhaylov in testspro1c
ZEEGIN
Если есть закрепленное поведение на форме - то это этл сценарный.
Про это и пишу - конечное внедрение - это в подавляющем числе случае именно сценарное тестирование. Именно поэтому и происходит ломка при смене версия типовых - меняется поведение.
источник

DB

Denis B. in testspro1c
ZEEGIN
В бсп пишутся и модульные и интеграционные и сценарные тесты. Плюс большой дымовой на открытие всего, попытки перезаписать, скопировать и записать и т.п.
Для дымовых тестов - Вы что используете?
источник

Z

ZEEGIN in testspro1c
Denis B.
Для дымовых тестов - Вы что используете?
внешнюю обработку
источник

NM

Nikita Mikhaylov in testspro1c
Nikita Mikhaylov
Про это и пишу - конечное внедрение - это в подавляющем числе случае именно сценарное тестирование. Именно поэтому и происходит ломка при смене версия типовых - меняется поведение.
ломка пользователей ("аааа, опять все не там", "зачем кнопку убрали")
источник

‌‌‎infactum in testspro1c
Nikita Mikhaylov
ломка пользователей ("аааа, опять все не там", "зачем кнопку убрали")
А как же ломка тестировщика ("ааааа, опять сценарии обновлять")
источник

NM

Nikita Mikhaylov in testspro1c
‌‌‎infactum
А как же ломка тестировщика ("ааааа, опять сценарии обновлять")
а мы для тестировшика систему делаем или для пользователя?
источник

Z

ZEEGIN in testspro1c
Nikita Mikhaylov
Про это и пишу - конечное внедрение - это в подавляющем числе случае именно сценарное тестирование. Именно поэтому и происходит ломка при смене версия типовых - меняется поведение.
да это можно свихнуться обновлять тесты после кажого обновления типовой
источник

NM

Nikita Mikhaylov in testspro1c
ZEEGIN
да это можно свихнуться обновлять тесты после кажого обновления типовой
хм, документацию тоже обновлять не будем?...
источник

DB

Denis B. in testspro1c
ZEEGIN
внешнюю обработку
и она генерит отчёт в каком-то форме (Allure, Junit) или без генерации в определённый формат... интересен процесс как дальше идёт.
источник

Z

ZEEGIN in testspro1c
Denis B.
и она генерит отчёт в каком-то форме (Allure, Junit) или без генерации в определённый формат... интересен процесс как дальше идёт.
она дает лог, который потом загружается в сппр как ошибка
технически это малоотличается от загрузки лога платформенной check config
источник

DB

Denis B. in testspro1c
ZEEGIN
она дает лог, который потом загружается в сппр как ошибка
технически это малоотличается от загрузки лога платформенной check config
понял. Спасибо.
источник

Z

ZEEGIN in testspro1c
конечно постепенно хочется все переводить на junit и аллюр, аллюр собирается для многих вариантов уже, но все равно аллюр это только текущее состояние, работы ведутся в рамках багтрекера, а не отчета по состоянию. потому работать правильно с ошибкой в сппр, джире, рэдмайне и.т.п.
источник