Цейтнот как стиль жизни

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

Прошло время. В декабре (а именно 26 декабря) будет три года, как я радостно уволилась из офиса с мыслью, что буду тихо искать новую работу, а фриланс будет как поддержка в безработный период времени.

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

И вместе с этим я набрала кучу проектов.

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

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

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

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

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

Чтобы не провести осень также чудесно, как лето, пока вижу такие варианты:
1. Помощник. И он ко мне придёт через 2 недели, как рассчитается на рабочем месте.
2. На день брать не больше 4 небольших задач. Или 2 больших.
3. Отчитываться каждый день в проектных чатиках о том, что сделано, что буду делать (и когда), а также какие проблемы были.
4. Вспомнить правило 15ти минут: вполне себе можно на вопрос не отвечать. Люди сами смогут найти решения.
5. В борьбе с прокастинацией, которая вылезла из усталости снова завести плагинчик Pomodoro
6. В нерабочих чатах отключить уведомлялки.
7. Гулять. Выходить из дома на спорт или ещё куда, чтобы проветривать голову.
8. Вспомнить, что не все деньги можно заработать :)

И ещё несколько пунктов, которые находятся в эдаком "тестировании"

У вас есть, что добавить? Как боретесь с нехваткой времени из-за большого количества работы?

В помощь маленьким

Когда я только уходила на фриланс одним из самых больших кайфов в начале работе было то, что ТЕПЕРЬ Я ОТВЕЧАЮ ТОЛЬКО ЗА СЕБЯ. Видимо, слишком рано мне дали создавать отдел и руководить людьми. Не была я к этому готова тогда.

Но время идёт и меняется. И сейчас у меня снова появился джуниор, которого я учу плохому потихоньку воспитываю. Конечно, на данный момент это всё происходит совсем не так, как это было 2,5 года назад, когда мне подсунули первого человека, не знающего ничего о тестировании. И это - о, Боги! - мне начинает нравиться. Хотя до этого я плевалась.

Так о чём это я? Ах, да.

Все мы знаем, что над любым элементом можно производить 4 действия:

1. Создание
2. Просмотр
3. Редактирование
4. Удаление

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

Действие при работе с элементом	Необходимая проверка
Создание элемента:	Создание элемента со всеми пустыми полями Создание элемента с незаполненными обязательными полями Создание элемента с незаполненными необязательными полями Создание элемента с неверными значениями в полях (спец. символы, скрипты, для даты - дата из будущего, дата из прошлого, неверный формат даты и т.д.) Создание элемента с данными, уже существующими в системе Отмена создания элемента с пустыми полями Отмена создания с заполненными полями
Редактирование элемента:	Удаление всех данных и сохранение элемента Удаление данных из обязательных полей и сохранение Удаление данных из необязательных полей и сохранение Изменение данных на корректные Изменение данных на те, которые уже существуют в системе Изменение данных на неверные (спец. символы, скрипты, для даты - дата из будущего, дата из прошлого, неверный формат даты и т.д.) Сохранение элемента без изменения данных Изменение данных и отмена редактирования Отмена редактирования
Просмотр элемента:	Отображение данных после создания Отображение данных после редактирования (в списках элементов, на форме элемента, в элементах, связанных с изменённым)  Отображение данных после отмены редактирования (в списках элементов, на форме элемента, в элементах, связанных с изменённым)  Двойное открытие формы просмотра
Удаление элемента:	Удаление только что созданного своим пользователем элемента Удаление элемента, созданного другим пользователем Удаление элемента, используемого в других айтемах Отмена удаления

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

ТЗ? Не, не слышала...

Я не умею работать с техническим заданием.
Ну, как не умею.
Если я его вижу (а вижу я его редко), то я его читаю и получаю общее представление о том, что же за систему мы будем писать.

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

В одном ТЗ вообще мы с коллегами встретили очень милую фразу: "Программа должна меняться в соответствии с изменениями в законодательстве, не меняя программного кода". Смеялись долго, да. Отпаивались тоже потом. Это же реализовывать, да.

Так к чему это я?, А, да.  У тестировщиков есть одна активность, вроде как:, под названием "тестирование требований". И тут вопрос: а как это делается правильно?

Выписываются функции из тз?
Просто проверяется, чтобы вот таких фраз не было?
Ещё что-то делается, чего я пока что не знаю?

Сейчас я выписываю функции, которые должны быть реализованы. Раньше пунктами, теперь составляю из них майнд-карту, чтобы видеть, как они взаимосвязаны между собой. А потом иду к аналитику и задаю вопросы, как именно должна работать та или иная функция.

Что делаете вы, когда получаете ТЗ?
И видели ли вы идеальное ТЗ, в котором всё расписано по пунктам и прям сразу понятно, что да как?

И чтобы два раза не вставать: не переоценивают ли ТЗ? Может, реально проще общаться с аналитиком, чем читать? Он как человек, больше поможет-то, чем бумажки...