Ужасно медленная QA

Заказала себе книгу Баха и Болтона «Taking Testing seriously”. К сожалению, она пришла поврежденная (Амазон не удосужился книгу за 56 евро хоть в пленку замотать, в итоге корешок порван, на обложке помятости). Запросила обмен. А потом полистала книгу немного и обратила внимание на схемы (майнд мапы). Фотографии приложила. Они довольно адекватно показывают реальность. Читать это невозможно:( Надеюсь, что Амазон осилит как-то сконвертировать мой запрос на обмен в запрос на возврат. Я тогда электронную куплю… наверное.

Channel name was changed to «Ужасно медленная QA»

Время от времени я случайно придумываю названия каналов/блогов о тестировании. Увы, мне нужно только одно название. Ну ладно. Два. Точнее, три. Но точно не десять! Выкладываю их тут. Названия, которые не помечены как занятые - свободны. Если кому-то захочется использовать их в своих целях - велкам. 1️⃣ Достаточно хорошее тестирование 2️⃣ Manic Pixie Testing Girl (или Manic Pixie QA Girl) 3️⃣ Синдром Тестессы (это мог бы быть канал о женщинах в тестировании) 4️⃣ QA Jedi (кааажется, уже кем-то занято, но это не точно. Повторно гуглить неохота) 5️⃣ QA Пастор (это могло бы быть название блога кого-то с большим самомнением. Например, меня) 6️⃣ QA Еретик (например, блог с критикой статей/постов про тестирование) 7️⃣ QA Unicorns (уже застолбила для группы в Линкедине, которую собиралась вести, но не веду) 8️⃣ Pairwise the Dancing Clown / Танцующий клоун Пэйрвайз (шутка для любителей QA и Стивена Кинга!) 9️⃣ Аналитический кружок имени Джима Моррисона (это название я использовала для одного маленького канала. Содержит шутеечку, которую никто не выкупает). 🔟 Ужасно медленная QA c крайне неэффективными инструментами в поисках Грааля Собственно, название этого канала. Содержит отсылки к - ролику Ужасно медленный убийца с крайне неэффективным оружием   - идее поиска ясности/просветления/знания/истины, метафорой чего является поиск Грааля. Даже если ты вооружена только ложкой, ты все равно до многого сможешь докопаться. Поддеживаю эту идею, так как я довольно медленный человек и плохо совместима с активностями, являющимися типовыми атрибутами успешного успеха (постоянно мелькать на мероприятиях, активно ходить на различное обучение, много общаться с людьми и т п). Сижу в углу, ковыряю ложкой землю, когда-нибудь доковыряю до центра Земли и найду ответ на вопрос жизни, Вселенной и вообще. *Постов про тестирование в ближайшее время все еще не планируется, я не то что томат - я томатное пюре и буду пребывать в этом агрегатном состоянии еще какое-то время.

Новый сезон конференции Podlodka QA Crew пройдет с 1 по 5 сентября. В фокусе — инструменты, которые делают тестирование быстрее, качественнее и удобнее. В программе: 💡Как раскрыть потенциал Postman и ускорить обратную связь — вместе с Ариной Ладесовой (Payler). 🪄Внедрение ИИ для генерации тестов без лишней боли — с Натальей Петровской. 📱Современные инструменты мобильного тестировщика — практические кейсы от Елены Фёдоровой (Garage Eight). 🔍 Observability автотестов и мониторинг — с Кириллом Ивлиевым (Работу.ру). Знания, которые легко применять в работе! 🔗 Подробнее и регистрация — https://podlodka.io/qacrew Мой промокод spoon даёт скидку в 500 руб.

Пока я пытаюсь решать иммиграционные квесты (количество которых только растет), желание сесть и подумать о смысле жизни тестировании не очень много. Но анонс Подлодки, тем не менее, принесу. Сама думаю сходить на доклады по AI и мобилам, но просмотрю, позволит ли это бюджет сил и времени.

Я начинаю активную фазу переезда и 1 августа прилетаю в Португалию. Ничего осмысленного в ближайшие пару месяцев тут публиковать не планирую. Сегодня придумала скороговорочку, несу сюда. Сериализацию сериализировали-сериализировали, да не высериализировали. Десериализацию десериализировали-десериализировали, да не выдесериализировали. Надо сериализацию пересериализовать-перевысериализовать, надо десериализацию передесериализовать-перевыдесериализовать.

⚡️ Доступность в тестовой документации (2) Формулировки - В качестве проверочного вопроса можно использовать этот: “Как звучит текст теста?” Да, не все люди имеют ограничения по зрению, но я думаю, что проговаривание текста вслух может помочь увидеть проблемы в формулировках и в общей структуре. - Все слова несут смысловую нагрузку. Исключаем слова вроде “успешно”, “правильно” и т. п., они не несут никакой полезности. - Текст максимально простой. Настолько простой, насколько это можно. Из синонимов выбираем самый простой и короткий. Предложения тоже максимально короткие и несложные. Ориентируемся на уровень языка - A1-A2. - В тексте есть не только шаги и результаты, но и указания, помогающие направить внимание в нужную сторону (если это нужно). Например, если результат теста - что в правом верхнем углу всплывает всплывашка на 5 секунд, хорошо бы, чтобы к моменту появление всплывашки внимание тестировщицы уже было направлено в правый верхний угол. - Заголовки имеют единую структуру, содержат важные при поиске теста ключевые слова и отражают идею теста. При сортировке по алфавиту тесты, проверяющие одну функциональность, оказываются близко и по заголовкам можно понять, что было протестирование для фичи / функциональной области. Простой пример: <Название окна> - <Название параметра> - Ввести значение разными способами <Название окна> - <Название параметра> - Ввести валидное значение <Название окна> - <Название параметра> - Ввести невалидное значение <Название окна> - <Название параметра> - Сохранить <Название окна> - <Название параметра> - Значение по умолчанию И т. д. Форматирование - Минимум форматирования. Я сама использую только два формата (помимо просто текста): выделение заголовков и выделение фрагментов “кода” (SQL запросы, логи и т.п.). - Заголовки разделов выделены через форматирование заголовков, а не жирным шрифтом. Если заголовки имеют иерархию - это отражено в форматировании (заголовок 1, заголовок 2 и т. п.) - Форматирование часто затрудняет читаемость, а не улучшает его. Например, моноширинные шрифты, курсив, декоративные шрифты (менее актуально для нас, но все же), CAPS LOCK, подчеркивание. - Списки сделаны через форматирование (нумерованный / ненумерованный список), а не проставлением дефисов или тире. - Для всех картинок прописан альтернативный текст. - Текст линков содержательный (не просто “вот линк”). Другое - Как документ воспринимается, когда масштаб увеличен до 200%? - Есть инструменты по проверке читаемости. Я не уверена, что их использование может дать релевантный результат в случае тест-кейсов или других рабочих текстов, но можно попробовать. Сама пока что не проверяла. Если вдруг у вас будут еще идеи - набрасывайте! Запишу их в свой списочек. #подпольный_евангелизм

⚡️Доступность в тестовой документации (1) Последнее время много думаю про доступность (в смысле accessibility) в рабочей среде. Мне кажется, это гораздо более важная тема, чем доступность, например, e-commerce. Сдается мне, что доступность e-commerce будет меня мало волновать, если в какой-то момент я просто не смогу выполнять работу. Поговорила на эту тему с коллегами по цеху, со специалистом по Accessibility, с ChatGPT и теперь хочется опубликовать некое саммари. Почему это важно и нужно? Доступность - это не что-то, что нужно каким-то “не таким” людям, которые тусуются в своем отдельном закончике. Это что-то, от чего получают бенефиты все. Если плохая доступность не блокирует кого-то в работе и/или не заставляет работать катастрофически неэффективно - это еще не значит, что этот кто-то от нее не страдает! Мы все бываем в состоянии стресса (позитивный стресс тоже считается!), физического нездоровья, физической/эмоциональной/ментальной истощенности и в этих состояниях тоже надо как-то работать работу. “Просто взять больничный”, увы, работает в случае только явных болезней и в случае, если мы можем себе его финансово позволить (больничные не всегда оплачиваются и не всегда оплачиваются 100%). Мы можем работать в компании, где язык документации - английский, что сразу увеличивает mental load. А еще среди нас есть нейроотличные люди, и очень часто эти люди даже не в курсе того, что они нейроотличные. Они будут страдать от отсутствия доступности и могут даже не понять, почему это им так плохо. Если я хочу (а я хочу!) чтобы в будущем я в принципе могла работать - это значит, что начинать адвокатировать доступность надо прямо сейчас. Прекрасное будущее не наступит само, нужен какой-то общий консенсус, что доступность - это нужно и полезно. Нужна культура доступности в QA сообществе. На что можем влиять? Рабочая среда - это очень много всего. Это помещения, это рабочие инструменты… У нас часто почти нет прямого влияния на все это. Но есть что-то, на что мы точно можем повлиять прямо сейчас - это наша документация. Поэтому я регулярно занимаюсь бухтением на эту тему и агитирую коллег по цеху насаждать доступную документацию уже сейчас. Тогда есть шансы, что лет через 30 это будет общими практиками:) Я буду писать про тест-кейсы, но те же принципы применимы к другим видам документации. Основной фокус В контексте текста доступность это читаемость разными средствами чтения (глаза тоже считаются), и все идеи крутятся вокруг этого. Фокус - простота и минимум визуального и информационного шума. Тогда тестировщица тратит минимум усилий на чтение и понимание текста и бережет мыслетопливо на понимание идеи теста, технические детали и само тестирование. Итак, вот те идеи, которые я собрала на данный момент: Стуктура текста - Текст читается сверху вниз, слева направо. По возможности никаких «а теперь вернитесь к п. 2». Звучит как очевидная вещь, но нет. Не так давно я столкнулась с инструкцией из N пунктов, которая начиналась примерно так: сначала выполните п. 2 - 5, потом п. 1, потом 6-10. - Линейная (не табличная) структура. Да, я знаю, что многие специалистки пишут тесты в табличках. Сами по себе таблички не являются чем-то недоступным по умолчанию. Другое дело таблички в контексте TMS. Это таблички, которые окружены огромным количеством элементов интерфейса (визуальным шумом). “Линейная” структура (текст с заголовками) в TMS более доступна. А еще этот текст можно написать в другом редакторе и потом скопипастить в условную джиру. - Нет длинных непрерывных блоков текста. - Нет разделов теста, которые не используются. Если какой-то раздел у примерно всех тестов пуст, но присутствует в тестах - это просто информационный шум. Лучше их удалить. #подпольный_евангелизм Очень подходящий тег взяла поносить у Оли Артемьевой:)

27 марта провела небольшой вебинар на тему "Как понять, что мы протестировали достаточно" Вместе посмотрели на майнд-мапу с направленими "для подумать" во время тестирования. Обсудили верхнеуровневые идеи, которые можно учитывать при принятии решения. Что не обсуждали: волшебные чеклисты, где можно просто проставить галочки и понять, что все хорошо. Впрочем, их не существует. Запись тут.

⚡️ “Тестирование программного обеспечения. Контекстно-ориентированный подход” Кем Кейнер, Джеймс Бах, Брет Петтикорд (отзыв о книге) Немного писала о переводе тут. К сожалению, все оказалось сильно хуже, чем я думала. Перевод мало того, что неаккуратный. Мало того, что используется специфическая терминология (например, "журналирование" вместо "логирование"). Он местами попросту искажает смысл авторского текста. Более-менее нормально переведена примерно половина уроков (половина из тех, что я успела прочитать и сравнить с оригинальным текстом). Резюме: не рекомендую В комменты положу файлик с примерами из первой главы книги. П. С. Готова отдать свой экземпляр за сыр. Правда, есть нюанс - самовывоз из Софии. П. П. С. Ну и по классике - "she" в тексте перевели как "он"

⚡️ Операция “П”, или Immigrant Song начинается с “ААААААААА” Я живу в Болгарии почти четыре года. Но… душа просит чего-то другого, поэтому в этом году планирую переместиться в Португалию. Благодаря компании, в которой я работаю, у меня есть возможность это сделать. Даже проект и команду менять не надо. Это огромный бонус. Даже не хочу представлять, как это - менять страну и компанию одновременно. Процесс небыстрый и нервный. Сейчас занимаюсь оформлением справок об отсутствии судимости (их нужно две - от Болгарии и от РФ) и уже успела пару раз немного поседеть. А еще после всех вложенных сил и нервов переезд в итоге может не состояться. Слишком много факторов, которые влияют на успешность мероприятия. Поскольку похожую булочку я уже ела, планирую использовать тайм-менеджмент для того, чтобы можно было комфортно жить и эффективно работать. Шутка. Никакого тайм-менеджмента (кстати, я его и в других ситуациях не использую). Только "энерджи-менеджмент". Снижение дополнительных активностей. Не буду давать консультации, даже если на это есть время и энергия. Текущие договоренности, конечно же, остаются в силе. На мероприятия тоже ходить не буду. Может быть, выступлю на QA митапе в апреле - и все. Корректировка рабочих целей. Даже если я прохожу курс в рабочее время - это дополнительная когнитивная нагрузка, а это мне сейчас не нужно. Буду фокусироваться на обычных рабочих задачах и избегать подвигов. Дополнительный отдых. По мере необходимости буду брать дополнительные дни отпуска за свой счет. В прошлый раз я потратила на деланье дел часть оплачиваемого отпуска, в оставшееся время пыталась работать и параллельно заниматься поиском квартиры, формлением документов и т п. То есть увеличина нагрузку и при этом уменьшила время на восстановление и отдых. Не понравилось, по возможности буду избегать. Фокус на комфорте. Где есть возможность доплатить за бОльший комфорт - буду доплачивать за комфорт. Чем более комфортным, а точнее, менее дискомфортным будет переезд, тем быстрее я вернусь в полностью функциональное состояние и смогу работать на прежнем уровне перформанса (ну, плюс-минус:). ...Посты про тестирование буду писать как обычно - по вдохновению:)

Доклад доложен, несу сюда:) Релизить нельзя тестировать Видео на Youtube. О чем доклад? О формальных критериях готовности фичи или релиза в продакшен, о том, как на эти критерии можно посмотреть с разных сторон и принять финальное решение. К докладу прилагается майнд-мапа с идеями на подумать и наводящими вопросами (и ответами). В приложении к посту - мапа в пдф формате.

Неспешно читаю «Тестирование программного обеспечения. Контекстно-ориентированный подход» (перевод книги Lessons Learned in Software Testing, вышедшей больше 20 лет назад). Оригинальная книга - полный рекомендасьон, а вот про перевод, к сожалению, пока что такого сказать не могу. Кое-где перевод заметно меняет смысл оригинальной фразы. По мере чтения наклеиваю на страницы книги стикеры с заметками, если когда-нибудь потом будут время и силы - соберу все эти заметки в кучу и напишу более подробный пост. Я не придерживаюсь идеи, что надо обязательно читать все в оригинале иначе Земля налетит на земную ось. Читать на русском как минимум 1) быстрее 2) дешевле (сравните 1000-1500 р за русскоязычную книжку и 30-100 евро за оригинальное издание). Но, кажется, как минимум в этом конкретном случае читать перевод стоит с некоторой осторожностью. …Без всякой связи с вышесказанным добавлю, что до конференции осталось всего пару недель. Для читательниц и читателей канала есть промокод QA_SPOON_13. Он дает право на скидку 500 р.

Через три недели буду рассказывать на Подлодке о том, как принимать решение о готовности релиза (или фичи) к продакшен. Доклад "Релизить нельзя тестировать" Представьте, что вы стоите перед одним из финальных Quality Gate до выпуска в продакшен. Все ли мы сделали? Достигнут ли требуемый уровень качества? В докладе мы рассмотрим ключевые критерии оценки готовности релиза, разберем подходы к проверке качества и определим, как принять взвешенное решение о доставке. Цель – понять, что нужно сделать, чтобы уверенно сказать: «Поехали!» Расскажу про формальные критерии, про то, как на них можно посмотреть с разных сторон, какие наводящие вопросы задать себе при принятии решения. Поделюсь артефактом (майнд-мапой). Запись будет, выложу по готовности.

Юрий Чернов «Искусство Agile-тестирования» (2) Testability (тестируемость): должны быть четко определены критерии качества, по которым элемент может быть принят в эксплуатацию. Как правило, это набор тест-кейсов. (Стр. 43) 0_0 Kanban… ориентирован на достижение результата. (Стр. 45) А другие методологии разве нет?… Каждая организация, да и каждый проект вносят свои нюансы. (Стр. 47) Наверное, имеют свои нюансы?… Вносить вроде можно вклад, а не нюансы. Или нюансы тоже можно?:/ Производительность здесь не так актуальна, поскольку ССД не является компонентом реального времени (стр. 59). Компонентом, работающим в реальном времени?… Продукт должен иметь правильный строгий уровень доступа… (стр. 87) По моему опыту самыми хорошими тестировщиками становятся программисты (стр. 127) 🥲 Резюмирую: как мне кажется, для опытных специалисток эта книга слишком верхнеуровневая, а новички (да и не только новички) могут слишком запутаться из-за формулировок. Поэтому не буду рекомендовать ее к прочтению. *если вдруг вы все же готовы рискнуть и попробовать ее прочитать (и при этом находитесь в Софии) - я готова поделиться:)

Юрий Чернов «Искусство Agile-тестирования» (1) На днях прочитала, так что делюсь впечатлениями. Сложновато было читать, постоянно сбивался фокус из-за того, что не всегда было понятно, что хотел сказать автор. Терминология была непривычная: летучка (стендап), продуктивная система / продукция (реальная система, продакшен) и т.п. Со многими идеями и утверждениями я бы прямо поспорила. А еще мне показалось, что в книге про Agile-тестирование как-то маловато Agile-тестирования. Автор обещает раскрыть тему тестирования в контексте Agile подхода: В этой книге мы рассматриваем не столько Agile-подход сам по себе, сколько Agile-тестирование. (Стр. 12) При этом книга включает - Обзор методологий. Agile - с бОльшими подробностями, остальные - с мЕньшими) - Верхнеуровневые описания различных видов тестирования, техник тест-дизайна и т п (общие сведения о «тестировании вообще», которые не являются специфичными для Agile) - Психологические аспекты работы в команде - Типология людей по «стилям общения» - и т. п. Глава «Agile-тестирование» занимает 14 страниц из 200. Ниже приведу некоторые цитаты (с моими комментариями и без). …Кроме того, тестирование - это свобода, по крайней мере в выборе используемых средств. Профессионал способен автоматизировать свою работу без внешних ограничений, которые необходимы при разработке. Он имеет больше свободы. Поскольку здесь важен результат. (Стр. 10) У меня сразу возник вопрос - а что, разве для программиста результат не важен? И свободы у него нет? Какие внешние ограничения есть у программистов, которых нет у тестировщиков? Они точно так же могут выбирать используемые средства (а иногда - не могут. Как и тестировщики!). С сегодняшними инструментами <…> каждый человек с развитым здравым смыслом может быстро стать профессионалом. Но хорошим специалистом его сделает только знание предметной области. Это все равно, что сказать «только тот тестировщик хорош, который хорошо умеет автоматизировать». Мне все же кажется, хорошими специалистами нас делает довольно много всего. Знание предметной области играет в этом роль среди всего прочего. Исключать потери. Продвигаться небольшими шагами, будучи всегда готовыми откатиться назад. Принимать возможность неудачи и разрабатывать планы так, чтобы провал, если он произойдет, мог быть выявлен как можно раньше. Стремиться увеличивать скорее производительность, чем эффективность. (Стр. 25) Тут я опять не поняла, что хотел сказать автор, так как до того шла речь о том, как Agile помогает повысить эффективность. Что конкретно тут имеется в виду под производительностью, не указано. …создайте условия, обеспечьте поддержку и полностью доверьтесь «мотивированным профессионалам». Этот принцип сформулировали как раз они. (Стр. 21) Общеизвестный обмен информацией за кофе часто очень эффективен. (Стр. 22) Выпуск работающего продукта на каждом спринте… (стр. 23) Когда старая бюрократия сменяется новой или теперь Scrum-мастер навязывает мелочную опеку вместо менеджера, то бесполезно ожидать увеличения эффективности. (Стр. 25) …в конце книги есть список терминов, понятия которых, естественно, даны в контексте этой книги. (Стр. 14) …что-то из этого является общеизвестным, но необходимым для создания полной гомогенной картины… (стр. 13) Возможно, автор имел в виду «непротиворечивой»?… Эта методология в принципе является воплощением прикладного эмпиризма…(стр. 38) Во-первых, следует снижать идеальные ожидания и требования к производительности всех команды. (Стр. 40)