Статус книги 2: доделала рукопись, сдала в издательство

 

А знаете ли вы, что у моей первой книги будет продолжение? Точнее, новая книга, которая шире раскрывает тему тест-дизайна. 400+ страниц чисто про тест-дизайн:

• классы эквивалентности
• границы
• чек-листы базовые
• другие техники
• ...

Тут бы я хотела дать ссылку на страницу этой книги, но её пока нет ¯\_(ツ)_/¯

Чуть позже сделаю...

Однако уже хочу похвастаться статусом! В декабре мы подписали договор с издательством, и вот я наконец-то отдала им рукопись! Правда, я должна была сделать это ещё в марте... Но знаете, как это бывает)))

SQA Days 30. Как это было и что посмотреть

 

Ссылка на программу конференции

Заметки от Максима Цепкова

Что-то я припозднилась с отзывом, уж 2 недели после конференции прошло, а всё некогда да некогда. Исправляюсь!

22-23 апреля 2022 года прошла юбилейная SQA Days, уже 3-ая по счету! Это круто, от души поздравляю Влада и Татьяну Орликовых, вы делаете классное дело 👍

Конференция была в Москве, там была куча плюшек и ништяков для участников. Это и чай с печеньками, и целая куча разных стендов на любой вкус. И даже робот был =))) В общем, с орг части всё здорово. Но давайте сразу к главному, к докладам! 

Нагрузочное тестирование

Нагрузка — возможность одновременной работы с приложением большого числа пользователей.

Вот, например, если я создам свою социальную сеть, в ней будет 3 калеки. А сколько человек каждый день заходят в инстаграмм? А в фейсбук? Сбербанк онлайн? Если у вас высоконагруженное приложение, то тестировать нагрузку просто обязательно. 

Особенно если речь идет про банк. Если он не выдержал нагрузку и прилег, то:

• Данные могут побиться, деньги потеряться где-то посреди трансфера — со всем этим придется разбираться после того, как приложение поднимут.
• Колл-центр завалят звонками — создадут высокую нагрузку уже на операторов.

Во время нагрузочного тестирования важно проверить:

• Производительность — насколько шустро приложение работает под нагрузкой?
• В какой момент наступит отказ?

См также: Тестирование производительности

Грепаем ГАР, чтобы проверить потроха XML-ек

Хочу поделиться историей из жизни, какую задачку я сегодня решала грепом, как у меня не работала регулярка и как именно я её отлаживала =)

Тестирую загрузку ГАР (справочник адресов от налоговой) в нашу систему. Для этого изучаю сам справочник. Он разбит по папкам-регионам, и в каждом набор файликов — дома, улицы, квартиры... Все они ссылаются на reestrobj, поэтому с этого файлика я и начала.

Для начала хочется посмотреть на данные, как они выглядят. Но как это сделать, если файлики весят слишком много и простой блокнот просто зависнет при попытке открыть  reestrobj для Москвы или даже Адыгеи?

Тут есть 2 варианта:

1. Сделать grep — выцепить первые 2000+ строк в отдельный файл. Потом открыть спокойноблокнотом и изучить
2. Открыть файл мелкого региона, где мало данных.

Пойдем сначала по второму пути. Погуглим «гар коды регионов» — вот какая отличная статья попалась! Тут сразу видно, сколько весит каждый регион.

Ага, регион 08 весит мало, попробуем открыть его.

Смотрим в распакованном ГАР, и правда, не очень много:

Запихиваем этот файлик в Идею (IDEA — среда разработки), пока выглядит не ахти:

Реформат кода сделать нельзя, потому что файл слишком большой… Чтож, пойдем по пути грепа!

Тестирование надежности (стабильности)

Тестирование стабильности или надежности (Stability / Reliability Testing) — проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.

Если не перезагружать компьютер, рано или поздно начнет даже ворд тупить. Потому что «ну хватит уже, месяц ап-тайма, дай мне почистить внутренние кеши!». Или браузер — открыли вы кучу вкладочек, работает нормально. А через день-два-три-неделю начинает тормозить, пока не перезапустите. Это и есть надежность приложения — сколько он проработает в нормальном режиме?

Особенно важно для мобильных телефонов — вы вообще часто закрываете приложение? Я обычно просто жму на домашнюю кнопку, сворачивая его. А потом снова открываю. Приложения, не тестировавшиеся на надежность, постоянно зависают / вылетают / теряют соединение с сетью. 

ИТ-книга от идеи до выпуска. Часть 1: работа с фриланс-художниками

Ссылка на Хабр

В конце прошлого года я выпустила свою первую книгу по тестированию — «Курс молодого бойца». Это было нелегко и долго =) 

Книгу я писала… 3 года! Потом ещё год искала художников и доделывала картинки. Потом искала издательства, проходила редактуру и т.д. Итого — 4.5 года:

07.09.2017 — 11.01.2022 (дата выхода книги на площадках типа OZON)

Я хочу поделиться своим опытом, рассказать про весь процесс. Что вообще предстоит автору, какие фазы нужно пройти от идеи до публикации. Может быть, мой опыт поможет вам тоже решиться на такую авантюру =)

Свой рассказ я решила разделить на цикл статей:

• Часть 0. Как начать и не бросить

• Часть 1. Работа с фриланс-художниками

• Часть 2. Поиск издательства

• Часть 3. Процесс производства

Сегодня я расскажу про свой опыт поиска фриланс-художников. Фишка в том, что мне не нужен был один человек. Мне надо было много, чтобы в минимальные сроки решить мою задачу. Спойлер — не удалось =) Но опыт получился хороший, и контакты на будущее остались!

SQA Days. Приходите послушать про нашего телеграм-бота!

 

В эту субботу, 23 апреля, в 14:10 буду выступать на конференции SQA Days!

Описание доклада

Программа конференции

Телеграм-бот как помощь в воспроизведении багов

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

Мы прошли длинный путь такой диагностики. Сначала собирали данные через SQL-скрипты, потом автоматизировали их и даже внедрили в систему. А потом упростили задачу разворачивания билда, делегировав это… Телеграм-боту!

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

— истории из реальной жизни «споткнулись о проблему — как решали»;

— примеры того, что получалось на каждом этапе;

— исходный код телеграмм-бота, который поднимает докер на виртуалке и запускает в нем сборку maven-a: https://github.com/hflabs/dolores

Приходите, будет интересно! А ещё меня можно будет поймать в кулуарах и подписать мою книжечку 😅 Купить на месте не получится, но принести свою и подписать — это пожалуйста!