Feeds:
Posts
Comments

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

Но и тест-кейсы не последнее дело, это “тяжелое вооружение“, и когда оно бабахает, то неприятеля сносит ко всем прабабушкам. Но чтобы оно бабахнуло, надо долго крутить дулом и прицеливаться…

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

У тест-кейсов должны быть предусловия (‘pre-conditions’ по-вашему).

Во всех этих pre-condition для тест-кейсов уместно учитывать много всякого (и чем больше там будет учтено, тем лучше). Иногда в предусловиях полезно буквально процитировать требования, на основе которых тест-кейс был написан.

Цитировать требование в прекондишнах — это всяческий гуд, но, как всегда, есть сложности с реализацией…

Как это всё сделать?

1
Гиперссылка на требования

Да, но не менее 70% гиперссылок в любом документе неизбежно «дохнут» на протяжении полугода, а когда требования начинают переписывать, менять строки местами и нумерацию следом, то едрить вашу медь…

И очень сильно задалбывает постоянно куда-то переходить по ссылкам и в разбираться в обустройстве другого документа, ведь редкий документ в разгаре работы пишется

  • внятно,
  • грамотно,
  • однозначно,
  • красиво
  • и понятно.

Увы.

2
Логическая отсылка на нумерацию требований. Не зря они всегда пронумерованы, как законы.

Да, логические отсылки вроде “Смотри Евангелие от Программиста 9.43“более долговечны, нежели гиперссылки, но они почти постоянно нуждаются и в сопутствующих гиперссылках, и в уточнении на предмет “не поменялось ли там что-нибудь”.

В какой-то момент и они перестают помогать, и тогда автор кейса начинает громко и смачно икать, бо его постоянно проклинают.

3
Процитировать требование

Самое шикарное решение. Обычно хочется (да редко можется) просто увидеть прямо на экране тест-кейса тот текст, на который сделана отсылка. Логичное решение: буквально процитировать требование в прекондишне.

С другой стороны, полное цитирование требований в тест-кейсах недальновидно, бо когда тест-кейс перестает соответствовать действительности, например, из-за того, что требования поменялись, и его надо переписать, то там переписывать и переписывать… Тогда икается всем.

Шо делать?

От страха перед иканием большинство тестировщиков (97,12%) сильно тупят и не решаются ни на то, ни на сё. А если будут требования переписываться? А если нет? А если будут? А если нет? Аааа…

Ответ: бэээ! Требования иногда переписывают, но не так часто, как может показаться, поэтому отставить панику.

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

Обычно после такой беды тест-кейсы начинают переписывать, через неделю всем понятно, что переписывать — с ума сойти, и что кейсы лучше не переписывать, а написать с нуля. Жалко, конечно, но разумнее.

Заодно тестировщики начинают лучше понимать бедных программистов.

Каждому кейсу свой жизненный срок, это нормально. К этому надо привыкнуть и перестать заморачиваться поиском идеального глобального решения. Надо просто написать понятные тест-кейсы и снабдить их указанием требования, на котором тест основан, а как это сделать — неважно. Можно по-всякому.

 

Advertisements

Заголовки тест-кейсов вполне можно писать и без “проверить, что” или “Убедиться в том, что”.

Достаточно просто ответить на хитрый вопрос “А что мы проверяем этим кейсом?

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

Почему заголовок выглядит как утверждение? А потому, что должно же в этом мире что-то быть однозначным.

Помним и о том, что первое слово в каждом действии должно быть глаголом.

Традиционная целиком и полностью посвященная автоматизации тестирования конференция «Selenium Camp 2018» пройдет в Киеве 2-3 марта 2018 в Mercure Congress Hall (ул. Вадима Гетьмана, 6).

Новый программный комитет, свежие направления в программе конференции, множество практиков своего дела.

За два дня конференции свои доклады представят полсотни спикеров в трёх параллельных потоках, один из которых будет работать в формате мастер-классов.

Билеты традиционно поделены на несколько этапов, но принцип остался тем же: раньше купил билет – сэкономил больше денег (early уже проданы).

Продолжается эксперимент с новым, «облегчённым» билетом для начинающих — на 40% дешевле, но посетить можно только ряд заранее  определённых докладов. Отличное предложение для развития рынка автоматизации тестирования и ряда заранее определенных докладчиков!

Как всё это было в прошлом году:

 

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

Триста раз “ха-ха-ха”!

Конференция для тестировщиков ‘TestingStage 2018‘ пройдёт в Киеве 13-14 апреля 2018 на территории Mercure Congress Centre (ранее Cosmopolit, ул. Вадима Гетьмана, 6).

testingstage 2018

Конференция входит в список ISTQB® Conference Network.

Приглашены ТОП спикеры по всем направлениям из 10 стран.

Мероприятие запланировано объемное: два полных этажа, пять залов для докладов и мастер-классов (и две зоны питания) вместят 55+ докладов (а также 12 мастер-классов, 3 мастер-класс за день до конференции, круглые столы, розыгрыши, призы и подарки), которые будут разделены на пять ежедневных потоков докладов по шести базовым направлениям:

  • Security,
  • Embedded (впервые в Украине),
  • Performance,
  • Automation,
  • Test management and process,
  • Out of the box.

Заявлено, что набор спикеров по направлению Security не уступает специализированным конференциям.

В стоимость билета включено полноценное питание и, что удивительно, неограниченное количество кофе-пауз.

Зачитано на «QA Fest 2016» http://qafest.com в Киеве 1 октября 2016.

Видео после текста.

— Будем рассуждать о том, во что превратилось обучение тестировщиков в наше время, и что с ним будет в ближайшем будущем.

В 2014 году в Киеве было под тридцать курсов по тестированию. И ещё плюс в Одессе и во Львове. Для Украины это было не так, чтобы мало, и большое количество курсов обещало то, что (наконец-то) на рынке появится много обученных тестировщиков. Их можно будет брать на работу и кидать на проекты — бизнес пошёл! Ожидалось, что количество будет переходить в качество.

И вот вам 2016 год. Сколько сейчас курсов для начинающих тестировщиков? Ну, чуть меньше. Но все равно их много. В Украине сегодня много тестировщиков. Много начинающих тестировщиков. Много плохих тестировщиков. Спасибо всем причастным к созданию этой ситуации (я среди них, безусловно).

Continue Reading »

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

Видео нет.

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

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

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

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

Continue Reading »

%d bloggers like this: