Archive for the ‘тест-дизайн’ Category
…и каждый тестировщик может…
Posted in Озарения, тест-дизайн on 30.12.2017| 2 комментария »
Техник разработки тестов очень много, и каждый тестировщик может придумать свою технику. ©
Триста раз «ха-ха-ха»!
Простота и понятность тест-дизайна
Posted in Конференции, Постановка мозгов, Презентации, Соображения, Фотографии, тест-дизайн, tagged Boris Beizer, Ужгород, Lee Copeland on 23.10.2017| 15 комментариев »
Зачитано на «Uzhhorod developer meetup 13.0» в Ужгороде 20 сентября 2017.
Видео нет.
Определения тест-дизайна
Вот самое простое определение понятия «тест-дизайн», одно из самых распространённых, и самых логичных:
1) Тест-дизайн — это способ
придумать поменьше тест-кейсов,
но при этом сохранить
«максимальное покрытие»
…и при этом оно же самое идиотское (бо невозможно сохранить то самое драгоценное «максимальное покрытие» при насильном уменьшении количества проверок).
Тест-дизайн — это беспредел
Posted in Озарения, тест-дизайн, tagged беспредел on 11.07.2017| Leave a Comment »
Бо нет предела.
Запуск Allpairs
Posted in Debian, Откровения, Скриншоты, Читерство, тест-дизайн, tagged allpairs, Calc, Excel, hexawise, IBM, inductive, Microsoft, Motorola, NASA, PairWise, PICT, testcover on 13.02.2017| 7 комментариев »
PairWise — один из крутейших аналитических подходов в тестировании ПО. Как молот.
Если попасть молотом по башке врага — ты победил. Если промахнулся — иди учись…
Согласно pairwise.org , есть множество софтинок для этого дела, и от Microsoft (их несколько, не только PICT), и от NASA (уже недоступна, в космос улетела), от Motorola, от IBM, и др.
Редбрик тестинг
Posted in Озарения, Постановка мозгов, Учеба в бою, тест-дизайн, tagged Regression testing on 10.02.2017| Leave a Comment »
— …Вообще, поскольку терминология у нас англоязычная, то англоязычные англоязычники её воспринимают вообще иначе, нежели мы. Например, «Regression testing» наши изначально воспринимают как «Блаблабла тестинг», и просто ждут её определения (любого), бо звуки ничего не подсказывают. А они понимают слова по-отдельности, и эти слова по-отдельности очень многое подсказывают сами по себе. Как мы легко расшифровываем термины вроде «минсоцоблтруда». Бо контекст есть.
— Ну это-то то понятно.
— Понятно-то понятно… Например, ты знаешь про самую крутую технику тест-дизайна — редбрик тестинг?
— Нет. Рассказывай.
— Был бы ты англоязычным человеком, ты уже спросил бы «Что за ерунда, бро, какое ещё красно-кирпичное тестирование?». А так… можно любой фуфломицин всучить под этим редбрик тестингом, и никто не будет сомневаться. Будут потом на конференциях доклады об этом делать.
— Ты сволочь.
— Да, но у нас это называется «тренер». Двигаемся дальше. Тест-дизайн — это не «наилучшие способы придумывания тест-кейсов». Это аналитическая работа с непредсказуемым результатом… А тест-кейсы появляются просто как следствие аналитики. Нет аналитики — нет тест-кейсов. Есть аналитика, но плохая — будут плохие тест-кейсы…
Тест-дизайн в очманілих руках тестувальника
Posted in Видео, Изображения, Конференции, Фотографии, тест-дизайн, tagged Binary Studio, Львов on 06.09.2016| 5 комментариев »
У прошедшую субботу выступал во Львове на QA Meetup от Binary Studio:
Вообще намеревался устроить презентацию последовательного применения техник тест-дизайна, но после реакции аудитории на некоторые идеи понял, что если перейду к демонстрации, то всё будет «мельтешить», бо причины действий и выводов будут этой аудитории неочевидны. Поэтому на ходу переключился в другой формат выступления, благо, в слайдах нет нужды. Заодно и взял более медленный темп речи.
Таки тест-дизайн — это глубинная тема, нельзя бросать в неё не умеющих плавать и тонуть, бо нам утопленники не нужны.
Про сам митап: организовано мощно, всё учтено, перекусон вообще блеск!
Что заметил ВООБЩЕ: под meetup подразумевается встреча специалистов какой-то отрасли в неформальной обстановке для обсуждения какой-либо темы или ряда тем. Типа, джем для музыкантов. Но докладание превращает неформальность митапа в мини-конференцию, в которой есть много формальностей, которые всеми соблюдается, уж ничего не поделать. Этот митап тоже выглядит как мини-конференция, разве что действие происходит в офисе
В тот же вечер заглянул в новый львовский склад старых ружбаек и немецких касок — отличное место, там таки ждут вежливых гостей!
Львов, «Залiзна шапка»
PS Если нужон перевод заголовка, то: «Тест—дизайн в очумелых руках тестировщика».
Состояние — Действие — Состояние
Posted in Озарения, тест-дизайн, State Transition testing, tagged Хватали за задницу, Хватит тупить on 08.04.2016| 2 комментария »
Таки додумался, почему State Transition testing не вызывает моментального ой-вэй эффекта у большинства увязнувших в тестировании.
Вот это самое «State-Transition Testing»
Трабла уже описана профессором Преображенским в соответствующей литературе в качестве первопричины разрухи.
Тут надо думать «исходное Состояние системы — Действие — иное Состояние системы».
А мы с «деццва» учимся продумывать тест-кейсы как «Действие — Результат действия».
Вот «кружочки» и не получаются.
А получается что-то вроде ‘Product available in the Cart — Proceed to Checkout — Checkout Page opened‘. Бред-то какой, полюбуйтесь на вашего Полиграфа…
Ну а потом начинается извечная шумерская жалобная песнь для успокоения сердца (просто выберите любимое и добавьте воды):
- У нас нет времени на тест-дизайн…
- На нашем проекте это не используется…
- Никто на проекте не говорит, какую именно технику надо использовать…
- Я тестирую только экивалентность и границы значений, и этого достаточно…
- Пожалуйста, спасите-помогите…
- Все эти техники — для задротов, реально они ничего не приносят…
- Я буду это применять, если это реально поможет уменьшать количество тестов…
- Тест-кейс — это когда надо проверить, что по шагам надо выполнять, и софт работает…
- Я клоун…
Что надо сделать
- определить happy path — их может быть несколько.
- определить другие сценарии и ветвления к ним.
- выводить в отдельные ветки всё, даже если они подразумевают переход к одному и тому же состоянию (есть множество исключений, но это должно быть основным подходом; впоследствии он сэкономит силы и нервы).
- стрелка — действие. Круг — состояние, а не результат действия, как мы привыкли писать в тест-кейсах.
- не запихивать всё в один рисунок. Пусть будет много рисунков. Переключайтесь между листами.
- если что-то пошло не так и надо перерисовывать — будете материться, а не ерзать ластиком. Проще будет быстро нарисовать правильную последовательность заново, поэтому рисуйте без детальной детализации.
А действительно, чего это мне кажется, что разница между верификацией и валидацией всем понятна без примера?
Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.
Например, здравствуйте, дети, вот это револьвер Смит и Вессон. Им можно решать разные задачи на поле боя. А ещё из него программист может выстрелить себе в ногу несколько раз. Сейчас я вам это покажу на конкретном примере. Ну, чья нога послужит хорошим, конкретным примером? Кто из вас знает C++?
Если пример непонятный — нет, ты не идиот, просто давным-давно, в другом мире…
Глава первая, вступательная в зыбкое болото терминов
Верификация — проверка соответствия приложения прописанным требованиям.
Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.
Ну, и чо?
Когда я только выполнял чужие кейсы, это всё было ненужным и абстрактным лайном.
Когда я сам проектировал тесты, да ещё и для какой-то финансовой аппликухи — приходилось знать/понимать точно, какие тесты покрывают прописанные требования (верификационные), а какие тесты покрывают НЕпрописанные требования (валидационные) и соответственно их разделять по разным сборникам тестов. И это всё стало осязаемым и важным.
(далее…)