Вон чего вспомнилось поутру

https://testitquickly.com/2013/06/03/good-enough/

https://testitquickly.com/faq/

На некоторые вопросы о тестировании ПО можно ответить только объёмной лекцией. Другие разруливаются одним кивком.

Можете задать мне любой вопрос про тестирование ПО — от теории до практики (и обратно). Отвечу или объяснением, или советом, или ободряющей поддержкой.

Если ответ будет объёмным — сделаю отдельную запись в блоге.

Если можно будет ответить «Да/Нет» — отвечу на емайл.

Если не смогу ответить — отвечу, почему так.

https://testitquickly.com/2023/07/08/tananica-fara-cizme/

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

Произошло всё то, о чём так тихо и неуверенно предупреждали ещё в 2012-м году.

https://highload.today/dzhuniory-v-it-chto-nuzhno-uchit-chtoby-nanyali-na-rabotu/

«…наблюдается общая тенденция проседания уровней зарплат джуниор специалистов. Это происходит из-за притока свитчеров и выпускников по курсам, которых компании подхватывают как дешевую рабочую силу – новички охотно идут работать за небольшую оплату.

Наиболее заметно это сейчас среди QA, Python, JavaScript, DevOps. Рынок перенасыщен специалистами и всех хороших предложений не хватит» ©

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

Сэнсэй Баранцев сказал:

«…ну и не говоря уже о том, что огромное большинство тренеров мямлит, отвлекается от темы, иногда тупит».

Я просветлился.

Сборник майндмап на тему тестирования — в github, но в виде разляпистых изображений. Вертеть майндмапы — особенно широкие, да с телефона — в виде картинок неудобно. Всегда хочется открыть полноценные файлы mmap или xmind (будь он неладен). И в таком виде можно найти здравые соображения, особенно если монитор широкий. Но неудобность в частностях…

Например:

Accessibility Testing Tools — это сборник ссылок. Много ты накликаешь, если мапа представлена как растровое изображение.

50 Bugs - Test Ideas - Software Testing - Test Insane — действительно insane, мапа широченная, при экспорте в изображение всё сжалось, и чтобы прочитать текст нужно увеличить её на 200%, а это как раз уровень начала расплываемости мелкого текста…

В общем. Остаётся только снимать файло и смотреть руками.

Любопытно, что любая майндмапа по сути своей - разноуровневый список, который элементарно делается в plain text. Такой репозиторий в txt был бы бесконечно шикарен. Но привыкли к картинкам…

Майндмапи з тестування на будь-який смак

#testing

Знайшов підбірку майндмапів з багатьох аспектів тестування - web, mobile, api. Щось цікаве знайти можна.

Древний инсайт, который усложняет любой разговор о качестве — в разработке ПО, особенно в современной, QA в принципе недоступно, потому что нет возможности сделать продукт с предсказуемыми параметрами, ни по частям, ни целиком.

Почему невозможно:
а) истеричная хаотичность разработки,
б) каждый продукт уникален, поэтому и получается непредсказуемо.

А там, где технологично делают клоны (хлеб, жемчуг, карты) — там QA работает полностью, от начала до финиша. И чем сильнее клонирование, тем дешевле производство и тем выше качество. И нет нужды тестировать надкусывать каждый батон, чтобы убедиться в том, что он соответствует ожиданиям. А это наше ПО делать «как на заводе» не получается, и приходится «кусать» его часто и объемно, иначе гаплык, пиндык, каюк и амба.

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

Голь на выдумки богата

Бот в slack, который ежедневно спрашивает «Чо как дела, что делал, что будешь делать?!» — это удобно и работает, особенно когда маленький постоянно развивающийся коллектив таки начинает постоянно развиваться. Еще бы всем научиться указывать над чем работаешь, а не перечислять ссылки в jira…

Онбоардинг тестировщиков таки разумно делать не в гуглоэкселях, а собрать все шаги в тест-сьют и их новичку в виде run. С одной стороны, это все опасно закатывать в тест-кейсы, бо всегда будут сложности с продалбыванием/устареванием какой-то информации, которая скрыта в массиве тестов. Тут хочется все держать в одном файле (Confluence, Notion etc). Но ран тестов киллерфичит любой список «под рукой» наглядностью отчетности! Что ж, нужно все держать в файле, и только затем, при необходимости, синхронизировать его с тестами в «пофигу каком сервисе». Мне нравится по старой привычке Zephyr (который плагин для Jira), но это упарываться по нему нет никакой необходимости.

Прифигел от возможностей Notion для рабочих групп. Там можно планировать и трекать вообще весь цикл разработки… Всё настраивается на шаблонах, как и полагается. Гуглодоки после этого воспринимаются как резко highly outdated.

Вон чего творится:

- Notion for Product manager — https://www.youtube.com/watch?v=Kz8UTFgLPpg
- Creating a Release Template [at 26:00] — https://youtu.be/Kz8UTFgLPpg?t=1560&feature=shared

- Notion at work: Product roadmap — https://www.youtube.com/watch?v=ii6R6c5bEmE

- Timeline views — https://www.youtube.com/watch?v=I4CtApkWoRk

- Notion at work: Product requirement documents — https://www.youtube.com/watch?v=hI1aSnb6fr0

- Notion at work: Tech specs — https://www.youtube.com/watch?v=YSFdy-ZuFHk

- Notion at work: Issue tracking — https://www.youtube.com/watch?v=8oGqPPkFTbg

- Manage tasks in sprints — https://www.youtube.com/watch?v=EGtiYmvpUP8

You can record the business requirements in a vision and scope document.

User requirements ­typically are represented in the form of use cases or user stories.

Detailed software functional and nonfunctional requirements are recorded in a software requirements specification (SRS) or an ­alternative repository, such as a requirements management tool.

Вигерс, третье издание, стр. 51

PowerPoint убил целую индустрию создания мультимедийных презентаций. А там были задействованы фотографы, художники, операторы, танцовщицы и прочие блэк-джеки и их семьи…

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

Я уже много лет не испытываю сложностей с написанием тест-кейсов, мне сложно быстро понимать новый объёмный продукт. Очень мешают иллюзии вроде «а, это мне знакомо…», а потом «ну кажетаг-то, мне же казалось, что оно вот так, а оно вон оно как…»

Тест-кейсы выглядят по-разному не по чьей-то злой воле.

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

Когда они условно-подробные — их тупо неудобно быстро выполнять, и большинство опытных тестировщиков просто перестают их читать (а там что-то может быть изменено, ойёпт), но их можно предсказуемо выполнять средне-медленно, потому что есть подробная инструкция, которую придётся переписывать во множестве мест, если что-то где-то ВНЕЗАПНО поменяется… Ой.

Логично предположить, что если мы будем придерживаться одного ХОРОШЕГО стандарта, то все сложности исчезнут. Однако логично и то, что «стандарты» всегда тяготеют к «пусть будет много нужной и полезной информации», а это всегда в итоге формат «условно-подробнейших тест-кейсов», которые постоянно хочется «переписать попроще», но времени нет.

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

Тест-кейс — инструкция по созданию тестовой ситуации.

Иногда ситуацию можно объяснить одним предложением, и результат её очевиден. Иногда надо предварительно объяснить предусловия и не факт, что всё будет понятно. Иногда достаточно просто упомянуть, что «а ещё в базе надо проверить, что наценка на товар правильно применилась и повсюду посчиталась». Иногда надо прямо указать, куда зайти и какой запрос использовать.

Не нужно искать один-единый формат тест-кейсов. На одном и том же проекте надо использовать разные форматы тестов в зависимости от условий и контекста возникающих задач.

Общий подход — пишем тесты в виде идей. Коротко.

Идею можно уточнять — добавить несколько нужных строк. Если выглядит достаточно понятным самому себе — всё норм.

Идею можно снабжать отсылкой к подробной инструкции для выполнению отдельных шагов. Инструкции можно записывать в общие места (Confluence, Notion, тыды).

Какие-то тесты навсегда останутся однострочниками. Какие-то будут монстрами. Думать надо о том, чтобы они были понятными, а не стараться заранее определять, что и как из них получится. Это было бы так же странно, как точно знать завтрашний курс криптовалюты в Молдове и призывать всех вкладывать в передовую технологию будущего из прошлого ценную валюту с изображением Штефана чел Маре.

Don't fake it ’til you make it.

Fake it ’til you become it.

© Amy Cuddy, social psychologist

In the long run, the stupid experiment with AI will go the same way as all the other scams. Companies will find that they still have quality problems, and still need people to try to find them before its too late. © Джеймс Бах

Ну, пока речь идет о том ИИ, который есть сегодня, то да.

Автомобили, скажем, в 1907-м году были смешным чудачеством, а не… Рассуждать о их будущем в принципе было незачем. Но…

Про скриншотеры в KDE

Основной Spectacle в целом норм, у него есть (не очень очевидная и не совсем удобная) возможность рисовать стрелочки поверх скриншотов. Есть шаблонизация названия файлов при автосохранении и др штучки.

Ksnip
очень хорош, прям SnagIt былой эпохи. Напоминает добрый мелкий https://picpick.app/ru/ (подвиндовый). Сумел всё, чего мне от него захотелось — автосохранение, наложение, перемещение, редактирование и отображение изображений во вкладках. Мой выбор.

Flameshot
тоже крут, выглядит неожиданно, но изящно. Тоже может рисовать поверх скриншота, делать надписи, выделять сектора кругами или квадратами и всё это перемещать (надо приноровиться захватывать объекты в фокус).

Но невозможно редактировать текстовые объекты, можно только удалять и делать новые.

И даже если есть мощный шаблонизатор имён, — нет автосохранения, картинка сохраняется только по нажатию Ctrl+S или соответствующей кнопки под скриншотом.

Shutter
пришёл из Gnome, простоват, нет возможности рисовать/писать поверх снимка.

Шмякнуто в https://github.com/testitquickly/bystro.linux/blob/main/Linux/%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B8_KDE/%D0%A1%D0%B5%D0%B0%D0%BD%D1%81/%D0%A1%D0%BA%D1%80%D0%B8%D0%BD%D1%88%D0%BE%D1%82%D0%B5%D1%80%D1%8B.txt