Feeds:
Записи
Комментарии

Archive for the ‘Testing like…’ Category

Владимир Железняк сообщает:

Когда в мае 2019 я, еще из Харькова, подписывал аренду дома в Монреале, я прочитал контракт. Вот больше всего запомнилось:

— курить нельзя.
— кальян тоже нельзя
— курить нельзя в доме и кругом
— в доме и кругом курить нельзя
— в гараже, на лестницах, и вокруг дома курить нельзя
— ночью тоже курить нельзя. И в другое время суток тоже.
— на бэкярде курить нельзя

Вот очень похоже на тесты программистов, написанные по команде «протестируй всё» без оглядки на дальнейшую поддержку.

Я потом выгреб дофига бычков с бэкярда.

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

В таких условиях тестировщики начинают сочинять тесты в стиле «Открыл экран, описываю последовательно все действия на этом экране», и уже с трудом можно сфокусироваться и спросить, соппсно, а в чём был обще-глобальный смысл тестируемой функциональности? Может, оно вообще не о том, о чём кажется.

А потом ротом выгребаешь с бэкярда прода окурки, которым, согласно системе и ярко-зелёным тестам, было неоткуда взяться.

Read Full Post »

А действительно, чего это мне кажется, что разница между верификацией и валидацией всем понятна без примера?

Нужен конкретный пример. А то без примера каждому… парню кажется, что его принимают за идиота.

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

Если пример непонятный — нет, ты не идиот, просто давным-давно, в другом мире

Глава первая, вступательная в зыбкое болото терминов

Верификация — проверка соответствия приложения прописанным требованиям.

Валидация — проверка соответствия приложения всем остальным (подразумеваемым) требованиям.

Ну, и чо?

Когда я только выполнял чужие кейсы, это всё было ненужным и абстрактным лайном.

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

(далее…)

Read Full Post »

Очень крутой доклад. Настя умеет!

Про всё то, что из нашего царства аутсорсинга постоянно не видно.

Read Full Post »

В 2012-ом в Виннице в ходе объяснения того, что основной функционал сайта не в его кнопках, а в его услугах, понадобилось взять и продемонстировать всё наглядно.

Read Full Post »

Техник разработки тестов очень много, и каждый тестировщик может придумать свою технику. ©

Триста раз «ха-ха-ха»!

Read Full Post »

Зачитано на «Uzhhorod developer meetup 13.0» в Ужгороде 20 сентября 2017.

Видео нет.

Определения тест-дизайна

Вот самое простое определение понятия «тест-дизайн», одно из самых распространённых, и самых логичных:

1) Тест-дизайн — это способ
придумать поменьше тест-кейсов,
но при этом сохранить
«максимальное покрытие»

…и при этом оно же самое идиотское (бо невозможно сохранить то самое драгоценное «максимальное покрытие» при насильном уменьшении количества проверок).

(далее…)

Read Full Post »

Бо нет предела.

Read Full Post »

PairWise — один из крутейших аналитических подходов в тестировании ПО. Как молот.

Если попасть молотом по башке врага — ты победил. Если промахнулся — иди учись…

Согласно pairwise.org , есть множество софтинок для этого дела, и от Microsoft (их несколько, не только PICT), и от NASA (уже недоступна, в космос улетела), от Motorola, от IBM, и др.

(далее…)

Read Full Post »

— …Вообще, поскольку терминология у нас англоязычная, то англоязычные англоязычники её воспринимают вообще иначе, нежели мы. Например, «Regression testing» наши изначально воспринимают как «Блаблабла тестинг», и просто ждут её определения (любого), бо звуки ничего не подсказывают. А они понимают слова по-отдельности, и эти слова по-отдельности очень многое подсказывают сами по себе. Как мы легко расшифровываем термины вроде «минсоцоблтруда». Бо контекст есть.

— Ну это-то то понятно.

— Понятно-то понятно… Например, ты знаешь про самую крутую технику тест-дизайна — редбрик тестинг?

— Нет. Рассказывай.

— Был бы ты англоязычным человеком, ты уже спросил бы «Что за ерунда, бро, какое ещё красно-кирпичное тестирование?». А так… можно любой фуфломицин всучить под этим редбрик тестингом, и никто не будет сомневаться. Будут потом на конференциях доклады об этом делать.

— Ты сволочь.

— Да, но у нас это называется «тренер». Двигаемся дальше. Тест-дизайн — это не «наилучшие способы придумывания тест-кейсов». Это аналитическая работа с непредсказуемым результатом… А тест-кейсы появляются просто как следствие аналитики. Нет аналитики — нет тест-кейсов. Есть аналитика, но плохая — будут плохие тест-кейсы…

Read Full Post »

У прошедшую субботу выступал во Львове на QA Meetup от Binary Studio:

14249732_1076818582373714_3118954000420683221_o(1)

14249712_1076818742373698_1207932363929895134_o(1)

14231132_1076818842373688_324068661532505217_o(1)

Вообще намеревался устроить презентацию последовательного применения техник тест-дизайна, но после реакции аудитории на некоторые идеи понял, что если перейду к демонстрации, то всё будет «мельтешить», бо причины действий и выводов будут этой аудитории неочевидны. Поэтому на ходу переключился в другой формат выступления, благо, в слайдах нет нужды. Заодно и взял более медленный темп речи.

Таки тест-дизайн — это глубинная тема, нельзя бросать в неё не умеющих плавать и тонуть, бо нам утопленники не нужны.

Про сам митап: организовано мощно, всё учтено, перекусон вообще блеск!

Что заметил ВООБЩЕ: под meetup подразумевается встреча специалистов какой-то отрасли в неформальной обстановке для обсуждения какой-либо темы или ряда тем. Типа, джем для музыкантов. Но докладание превращает неформальность митапа в мини-конференцию, в которой есть много формальностей, которые всеми соблюдается, уж ничего не поделать. Этот митап тоже выглядит как мини-конференция, разве что действие происходит в офисе

В тот же вечер заглянул в новый львовский склад старых ружбаек и немецких касок — отличное место, там таки ждут вежливых гостей!

Львов, "Залiзна шапка"

Львов, «Залiзна шапка»

PS Если нужон перевод заголовка, то: «Тестдизайн в очумелых руках тестировщика».

Read Full Post »

Таки додумался, почему State Transition testing не вызывает моментального ой-вэй эффекта у большинства увязнувших в тестировании.

State-Transition Testing

Вот это самое «State-Transition Testing»

Трабла уже описана профессором Преображенским в соответствующей литературе в качестве первопричины разрухи.

Тут надо думать «исходное Состояние системыДействиеиное Состояние системы».

А мы с «деццва» учимся продумывать тест-кейсы как «ДействиеРезультат действия».

Вот «кружочки» и не получаются.

А получается что-то вроде ‘Product available in the CartProceed to CheckoutCheckout Page opened‘. Бред-то какой, полюбуйтесь на вашего Полиграфа…

Ну а потом начинается извечная шумерская жалобная песнь для успокоения сердца (просто выберите любимое и добавьте воды):

  • У нас нет времени на тест-дизайн…
  • На нашем проекте это не используется…
  • Никто на проекте не говорит, какую именно технику надо использовать…
  • Я тестирую только экивалентность и границы значений, и этого достаточно…
  • Пожалуйста, спасите-помогите…
  • Все эти техники — для задротов, реально они ничего не приносят…
  • Я буду это применять, если это реально поможет уменьшать количество тестов…
  • Тест-кейс — это когда надо проверить, что по шагам надо выполнять, и софт работает…
  • Я клоун…

Что надо сделать

  1. определить happy path — их может быть несколько.
  2. определить другие сценарии и ветвления к ним.
  3. выводить в отдельные ветки всё, даже если они подразумевают переход к одному и тому же состоянию (есть множество исключений, но это должно быть основным подходом; впоследствии он сэкономит силы и нервы).
  4. стрелка — действие. Круг — состояние, а не результат действия, как мы привыкли писать в тест-кейсах.
  5. не запихивать всё в один рисунок. Пусть будет много рисунков. Переключайтесь между листами.
  6. если что-то пошло не так и надо перерисовывать — будете материться, а не ерзать ластиком. Проще будет быстро нарисовать правильную последовательность заново, поэтому рисуйте без детальной детализации.

Read Full Post »

Непременно помре.

Когда все тестировщики помрут, так оно и…

Вы покайтеся да раскайтеся заранее.

Сегодня имел удовольствие поматериццо объяснять начинающему тестировщику, что не существует «автоматизация тестирования» как некий отдельный объект или навык, который нужно учить отдельно от всего; что учить автоматизацию тестирования нужно в комплексе со всем остальным; что не надо «Сперва я выучу html, а затем CSS, потом JS и Selenium IDE», что надо ковырять всё одновременно.

А он не поверил.

Read Full Post »

Если смотреть на мир из черепа обыкновенного заказчика ПО, требования — совершенно лишний артефакт, который отнимает очень много средств и ничуть не гарантирует получение качественного результата. Вам надо — вы их и прописывайте.

А загляните в череп опытного заказчика ПО — он требования прописывает сам. Всегда. Да, общепонятно, что через требования он хочет получить хотя бы именно, что было заказано, но засада не в том, что «без ТЗ результат ХЗ» (можно ваять ПО и без предварительного малевания ТЗ). Проблема в коммуникациях. Чем более опытным становится заказчик, тем сильнее он эту проблему осознает и начинает решать.

(далее…)

Read Full Post »

Ну, наконец-то Алексей Баранцев замутил запустил тренинг на тему автоматизации тестирования «Автоматизация функционального тестирования», в ходе которого можно научиться не только автоматизировать, но и тестировать.

Можно ли представить себе хорошего линуксового системного администратора, который не знает общую теорию операционных систем и сетей, не подозревает о существовании Windows и MacOS, не умеет пользоваться для настройки системы консолью так же хорошо, как графической оболочкой? Можно ли считать хорошим инженером-строителем человека, который не владеет сопроматом, не знает про современные строительные материалы и особенности их применения, даже если на текущем объекте строительства они не используются? Можно ли признать хорошим актёром того, кто день за днём играет одну и ту же роль, не знает о современных тенденциях в театральном искусстве и не пытается попробовать себя в других амплуа?

Хороший специалист должен обладать достаточно широкими знаниями. Да, он глубоко изучает какую-то одну тему, специализируется в каком-то направлении, но при этом он должен представлять себе общую картину своей профессиональной области. Если он не будет это делать — мир уйдёт вперёд, его узкая тема окажется устаревшей и невостребованной, а он ничего другого не знает и не умеет.

Умение создавать автоматизированные тесты предполагает владение специализированными инструментами, которые так и называются «инструменты для автоматизации тестирования». Но знания хорошего специалиста должны охватывать всю область автоматизации. Какие вообще инструменты бывают? Для чего они предназначены? В какой ситуации следует (или наоборот не следует) использовать тот или иной инструмент? Как выбрать наиболее подходящий для решения задачи инструмент среди множества похожих?

И конечно же надо уметь делать хорошие автотесты. Да, сначала надо научиться понимать, чем «хорошие» автотесты отличаются от «плохих». А потом — научиться делать «хорошие». Эти правила являются общими, независимыми от конкретного используемого инструмента.

Решение мастера крайне одобряю.

Умиляют заколебали дети, которые уверены в том, что надо «или автоматизировать, или тестировать». Странно, что они не выбирают по утрам «или зубы чистить, или глаза промыть».

Read Full Post »

В LibreOffice можно подключить к документу odb файл (реляционная база данных) с хорошо оформленным списком литературы, например. Сразу плюшки:

  • единый формат хранения данных,
  • единое место хранения,
  • автоматический учет использованных в документе записей из этой базы данных и их автоматическая сборка в виде оглавления списка использованной литературы.

(далее…)

Read Full Post »

Older Posts »

%d такие блоггеры, как: