четверг, 28 апреля 2022 г.

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

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

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

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


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



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

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

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

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

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

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

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


понедельник, 18 апреля 2022 г.

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

 


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

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

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


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

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

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

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

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

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

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


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