Мыслетрекер

Наткнувшись на подборку плакатов советских времён о безопасности на производстве, при просмотре почти каждого из них у меня складывалось всё более чёткое ощущение: так это же про нас!

Конкретнее и с картинками — ниже.

Смотри куда ступаешь!

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

Не приступай к работе без инструктажа!

Времена манки-тестинга прошли. Сейчас, если ты хочешь выпускать качественные продукты, клацать на кнопки недостаточно. Подумай хорошенько: что именно ты будешь тестировать? Как скомбинировать проверки? Ничего ли ты не пропустил? Нарисуй майнд-карту, проанализируй требования, обсуди стандартные сценарии использования с аналитиком. Нарисуй табличку входных значений. Больше времени удели работе мозгом, меньше — клацанию мышкой. Существенные отличия в результатах работы не заставят себя ждать!

Не проверяй напряжение пальцем!

Тестировать в условиях, максимально приближенных к эксплуатации, очень важно. Но это ещё не значит, что тебе нужно тестировать на данных пользователя и на его окружении. Залог успешного тестирования — тестовый стенд. С чит-кодами, расширенным логгированием, возможностью вносить виртуальные деньги на счёт и спокойной уверенностью, что пользовательские данные не будут потеряны. Озаботься полнофункциональным тестовым стендом, договорись с разработчиками о testability системы, попроси их предоставите на тестовом сервере те фичи, которые тебе нужны для расширения возможностей тестирования.

Чёткие надписи

Умей оставлять за собой чёткие надписи. Пиши тесты так, чтоб их понял ребёнок с синдромом Дауна. Оформляй дефекты так, чтобы они были примером для отдела техписателей. Потрать лишние пару минут — они всё равно будут сэкономлены на вопросах, которые не будут тебе заданы в будущем из-за непонимания. А в качестве бонуса ты получишь благодарность коллег и уважение разработчиков. Каждый раз перед регистрацией дефекта перечитывай его и убеждайся, что он ИДЕАЛЕН. И учти, что понятное для тебя далеко не всегда понятно другим — проведи опрос разработчиков, что они думают про твои дефекты? Ты либо узнаешь, что улучшать, либо тебе будет приятно. В любом случае, останешься в выигрыше!

Сделай своё рабочее место помощником, а не помехой

В Kaizen есть такие термины, как муда и мура — это то, что мешает тебе работать. Это те вещи, которые тебе мешают, это лишние задачи, которые тебе не нужны. Тратишь каждую итерацию часы на создание окружения? Дублируешь одинаковые вещи в дефект-репортах? Копипастишь тесты?

Везде ищи переиспользование, шаблоны, экономию времени. Отслеживай, что в рабочем процессе отвлекает твоё время попусту, и ищи способы от этого избавиться. Работай на работе, а не отвлекайся на мусор!

Берегись буферов!

В общем, не отвлекайся на коллег, когда тестируешь