У меня уже произошло стойкое углубление в LaTeX, что привело к массивным экспериментам со множеством его пакетов, поэтому наличие полного набора всего и сразу мне благостно. Заранее же не знаешь, куда любопытство заведёт.
WordPress искажает символы в тексте (ординарные кавычки превращает в фигурные, а двойной дефис превращается в тире), поэтому есть ещё текстовый вариант без искажений символов и без переноса строк: http://bit.ly/2Er0x6o
Идеи легковесны и изменчивы, и постоянно требуют присмотра и ловкости обхождения с ними. Это типа лук и стрелы, много не настреляешь, но если прицелиться и жахнуть точно, да с близкого расстояния, то ура, слава нам, капец ворогам.
Но и тест-кейсы не последнее дело, это «тяжелое вооружение«, и когда оно бабахает, то неприятеля сносит ко всем прабабушкам. Но чтобы оно бабахнуло, надо долго крутить дулом и прицеливаться…
Можно быть приверженцем одного типа вооружения, но использовать надо всё, что попадается под руку, а не стрелять только воробьями по пушкам, типа я весь такой концептуальный и аджальный.
У тест-кейсов должны быть предусловия (‘pre-conditions’ по-вашему).
Во всех этих pre-condition для тест-кейсов уместно учитывать много всякого (и чем больше там будет учтено, тем лучше). Иногда в предусловиях полезно буквально процитировать требования, на основе которых тест-кейс был написан.
Цитировать требование в прекондишнах — это всяческий гуд, но, как всегда, есть сложности с реализацией…
Как это всё сделать?
1 Гиперссылка на требования
Да, но не менее 70% гиперссылок в любом документе неизбежно «дохнут» на протяжении полугода, а когда требования начинают переписывать, менять строки местами и нумерацию следом, то едрить вашу медь…
И очень сильно задалбывает постоянно куда-то переходить по ссылкам и в разбираться в обустройстве другого документа, ведь редкий документ в разгаре работы пишется
внятно,
грамотно,
однозначно,
красиво
и понятно.
Увы.
2 Логическая отсылка на нумерацию требований. Не зря они всегда пронумерованы, как законы.
Да, логические отсылки вроде «Смотри Евангелие от Программиста 9.43» более долговечны, нежели гиперссылки, но они почти постоянно нуждаются и в сопутствующих гиперссылках, и в уточнении на предмет «не поменялось ли там что-нибудь».
В какой-то момент и они перестают помогать, и тогда автор кейса начинает громко и смачно икать, бо его постоянно проклинают.
3 Процитировать требование
Самое шикарное решение. Обычно хочется (да редко можется) просто увидеть прямо на экране тест-кейса тот текст, на который сделана отсылка. Логичное решение: буквально процитировать требование в прекондишне.
С другой стороны, полное цитирование требований в тест-кейсах недальновидно, бо когда тест-кейс перестает соответствовать действительности, например, из-за того, что требования поменялись, и его надо переписать, то там переписывать и переписывать… Тогда икается всем.
Шо делать?
От страха перед иканием большинство тестировщиков (97,12%) сильно тупят и не решаются ни на то, ни на сё. А если будут требования переписываться? А если нет? А если будут? А если нет? Аааа…
Ответ: бэээ! Требования иногда переписывают, но не так часто, как может показаться, поэтому отставить панику.
Нет, когда требования начинают переписывать, это действительно Содом и Геморрой, но это беда для всех сразу, а не только для тестировщиков.
Обычно после такой беды тест-кейсы начинают переписывать, через неделю всем понятно, что переписывать — с ума сойти, и что кейсы лучше не переписывать, а написать с нуля. Жалко, конечно, но разумнее.
Заодно тестировщики начинают лучше понимать бедных программистов.
Каждому кейсу свой жизненный срок, это нормально. К этому надо привыкнуть и перестать заморачиваться поиском идеального глобального решения. Надо просто написать понятные тест-кейсы и снабдить их указанием требования, на котором тест основан, а как это сделать — неважно. Можно по-всякому.
Заголовки тест-кейсов вполне можно писать и без «проверить, что» или «Убедиться в том, что».
Достаточно просто ответить на хитрый вопрос «А что мы проверяем этим кейсом?»
А ответ «А мы проверяем то, что на сервер разрешено загружать только файлы с расширениями, разрешенными в параметре document-types» мы нагло сокращаем, выбросив необязательное вступление, и — вот вам элегантный заголовок-утверждение «На сервер разрешено загружать только файлы срасширениями, разрешенными в параметре document-types«.
Почему заголовок выглядит как утверждение? А потому, что должно же в этом мире что-то быть однозначным.
Помним и о том, что первое слово в каждом действии должно быть глаголом.
— Будем рассуждать о том, во что превратилось обучение тестировщиков в наше время, и что с ним будет в ближайшем будущем.
В 2014 году в Киеве было под тридцать курсов по тестированию. И ещё плюс в Одессе и во Львове. Для Украины это было не так, чтобы мало, и большое количество курсов обещало то, что (наконец-то) на рынке появится много обученных тестировщиков. Их можно будет брать на работу и кидать на проекты — бизнес пошёл! Ожидалось, что количество будет переходить в качество.
И вот вам 2016 год. Сколько сейчас курсов для начинающих тестировщиков? Ну, чуть меньше. Но все равно их много. В Украине сегодня много тестировщиков. Много начинающих тестировщиков. Много плохих тестировщиков. Спасибо всем причастным к созданию этой ситуации (я среди них, безусловно).
Зачитано на «Uzhhorod developer meetup 13.0» в Ужгороде 20 сентября 2017.
Видео нет.
Определения тест-дизайна
Вот самое простое определение понятия «тест-дизайн», одно из самых распространённых, и самых логичных:
1) Тест-дизайн — это способ
придумать поменьше тест-кейсов,
но при этом сохранить
«максимальное покрытие»
…и при этом оно же самое идиотское (бо невозможно сохранить то самое драгоценное «максимальное покрытие» при насильном уменьшении количества проверок).
Слов для описания программы (pdf) конференции QA Fest 2017 у меня просто нет. Всё норм, всё блестит.
Нет там вообще много чего. Например, нет базовых тем для тестировщиков.
Нет их!
С другой стороны, всё же есть в книгах.
Но с одной стороны — кто ж их читает? Разве можно верить книгам, которые написаны больше, чем 365 дней назад?! Нет, решительно нет!
Так или иначе, конференции — не место для пересказов. Своё надо сочинять.
Нет «пересказов книг о величии agile» и о «низменности модели разработки ПО по-ниспадающей».
Нет спонсорских докладов.
Нет привилегий при подаче докладов, все доклады проходят через общий фильтр программного комитета на равных условиях.
Нет опасений о том, что участники конференции уйдут подавленными, обиженными, лишенными денег, идей, но зато с чувством опустошённости и бытности тлена. Заявлено, что на выходе участники продемонстрируют противоположные чувства, например, о прекрасности мира, о понимании его обустройства, о желании просто всё взять и применить в деле.
Нет ограничений по региональному признаку, приезжают докладчики из Румынии (йееееах!), Финляндии, Великобританской Англии и проч.
Нет сомнений в том, что если бы, то я бы непременно, но увы. Едрён-батон.
