SQA Days в Киеве: впечатления участников

В апреле в Киеве прошла конференция SQA Days. Событие стало одним из самых масштабных в Восточной Европе: в конференции участвовали более 500 человек. Докладчики SQA Days поделились своими впечатлениями от мероприятия.

Олесь Сегеда, QA-інженер, компанія Lohika

— Які основні тези доповіді?

Основна тема доповіді — це тестування та запобігання веб-вразливостей, оскільки зараз 75% всіх атак відбуваються саме через веб. Важливим моментом є те, що про безпеку часто забувають. А щоб скористатись більшістю вразливостей великий багаж знань не обов’язковий, в мережі є багато допоміжних автоматизованих засобів та матеріалів за якими легко навчитись. Тому навіть учні старших класів можуть зробити шкоду реальним аплікаціям заради забави або авторитету. Шкода, що не всі відразу розуміють, що за це потім доводиться відповідати. Також охоплюється тема якості, соціальної інженерії.

Цікавий експеримент. Одного разу проводячи доповідь у одній з ІТ-компаній, ми розіслали запрошення з посиланням на доповідь для попереднього «ознайомлення», розміщену в Google Docs (насправді це була фейкова сторінка логування в Google). Як результат, люди, які мають технічну освіту та працюють в ІТ-сфері, попадались на такий простий трюк, як phishing, і вводили свої логіни та паролі. Це показує, що ми всі люди і що всі можуть помилятись.

Я вважаю, що ця тема має бути цікава не тільки для інженерів, які працюють у сфері ІТ, але й для будь-яких користувачів Інтернету. Щоб знати, які небезпеки можуть зустрітись у мережі і як від них оберігатись.

На мій великий подив, доповідь сподобалась слухачам. Чому здивувався? Бо одною з умов конференції був виступ російською мовою. Так сталось, що мені не часто доводилось спілкуватись російською, і моя доповідь виглядала як суміш українських слів з російськими закінченнями та вкрапленнями англійської термінології. Та я радий, що мені вдалось зацікавити слухачів темою і вони не звертали на це уваги.

Тема безпеки давно мене цікавила, але завжди не знаходилось часу, займався у вільний від роботи час. Потім з’явився проект на якому можна було застосувати на практиці отримані знання. І так потрохи з підтримкою керівництва Логіки це переросло у презентацію та практичний курс. Ніколи не ставив перед собою ціль читати доповіді, але саме ця тема зацікавила багатьох. Доповідав на внутрішніх тренінгах компанії Lohika, студентам Львівської політехніки, Lviv QA (організовано компанією Lohika та testers.lviv.ua) та SQA Days #11.

— А які типові загрози користувачів в Інтернеті?

Атаки на веб аплікації можна розділити на 2 типи: спрямовані на саму аплікацію (SQL injection, parameter tampering) та на користувачів аплікації (XSS, CSRF).

Загрозами для користувачів зазвичай виступають втрата аккаунтів та доступ до приватної інформації (переписка, логін\пароль, платіжні картки і тд).

Які загалом враження від конференції? Що сподобалось, що ні?

Враження від конференції (організації та доповідей) були, але не всі позитивні. Очікував набагато більшого. Хороша перевага конференції — що вона проходила в одному приміщенні. Легко було знаходити цікавих людей, і переходити з аудиторії в аудиторію.

Серед недоліків — програма конференції, яка змінилась за кілька днів. Важко було зрозуміти на яку доповідь краще піти, оскільки було вказано лише ім’я доповідача і тему презентації (жодних деталей). Також доповіді не були погруповані за цільовими аудиторіями, не було вказано, на який рівень спеціалістів розрахована доповідь.

В загальному конференція, як подія, сподобалась. Були доповіді на цікаві теми: нефункціональне тестування, бази знань, cloud-технології і т.д.

— Які доповіді сподобались?

Конференція тривала два дні, доповідей було багато (близько 60) і відвідати всі не вдалось.

Після відкриття та довгої реклами ISTQB запам’ятався Сусуму Сасабе (японець, 64 роки), який розповідав про якість з японського боку, як вони прямують до якості.

Також хочу відзначити:

  • А вы знаете, что тестируют ваши тесты? (Николай Алименков)
  • Прицип Паретто usability-тестирования: 20% усилий дающие 80% результата (Анна Скумина)
  • Разработка тест кейсов по методике pair wise (Никита Постолакий)
  • Тестирование Сетевой Безопасности (Руфина Сарварова)
  • База знаний — пользуемся чужими наработками или изобретаем велосипед (Виктория Птицына)

І, наостанок, хочу виразити подяку Валентині Стецькій та Олександру Лазарчуку за допомогу та підтримку, без них моя б доповідь не відбулась.

Михаил Поляруш, основатель портала Automated Testing

— Какие главные тезисы вашего доклада?

Веб-разработка сейчас формирует основное направление в автоматизации тестирования на просторах СНГ. Если посмотрим на небольшую статистику по опросам, то большинство сейчас используют инструмент Selenium и разрабатывают автоматизацию под веб приложения. Но за миром веб-разработки существуют и другие приложения, которые точно так же нужно автоматизировать. Я участвовал в SQADays с темой автоматизация тестирования комплексных систем.

Многие автоматизаторы создают то, что уже давно было создано. На конференции я показал инструмент Robot Framework, который умеет автоматизировать комплексные системы, и в котором уже много чего реализовано.

Первая часть доклада была об автоматизации в целом, а вторая половина — живое кодирование и реальные примеры. Живой рассказ, интерактивность доклада, живое кодирование и примеры. После доклада несколько десятков желающих узнать еще больше об этом инструменте. В итоге, мой доклад был оценен вторым местом на конференции.

Какие доклады понравились больше всего?

За два дня конференции было много докладов, как от заграничных коллег, так и от специалистов из СНГ. Хотелось бы отметить, что наши докладчики, выступили лучше, чем наши иностранные коллеги. Хотелось бы отметить докладчиков, которые действительно показали хорошие и качественные материалы: Анна Скумина, Никита Постолакий, Алексей Баранцев, Олесь Сегеда, Николай Алименков. Хотя, к сожалению, я ожидал, что на конференции будет больше практических докладов с примерами, кодированием и живыми обсуждениями, а они больше были общетеоретические.

Какие, в общем, впечатления от конференции?

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

Глеб Рыбалко, соавтор и ведущий Клуба практического тестирования

Расскажите коротко о своем докладе, основные тезисы?

Тема доклада "Ice Age Testing"("Тестирование проектов времен ледникового периода«). Собрав опыт работы за последние несколько лет, в этом докладе я поделился полезными приемами работы тестировщиков на долгосрочных и длинных проектах, которых хватает на рынке IT. В таких проектах ничего не получается «с наскока» и если Вы пришли работать тестировщиком, то стоит подумать о системном подходе. Конечно же, везде есть свои нюансы, именно о них Вы можете узнать из моего доклада.

Тезисы таковы: начиная с зарождения, так называемого «каменного века» тестирования и по сей день, тестировщики и тестменеджеры допускают ошибки, которые в дальнейшем влияют на ход разработки продукта и выливаются в обидные ошибки и разочарования. Особым количеством пропущенных ошибок и сорванных сроков отличаются «мамонты ледникового периода» в тестировании — длинные и долгоиграющие проекты. Этот доклад построен на практическом опыте автора работы с такими «мамонтами от тестирования»:

  • Как определить проект-мамонт, и чем он отличается от других проектов.
  • Ошибки тестировщиков при первой встрече с мамонтом и как их избежать.
  • Как тестировать мамонтов.
  • Разбор практических кейсов тестирования мамонтов.

Какие доклады понравились больше всего?

Больше всего привлекали доклады, в которых была практическая составляющая. То есть не только слайды, но и живая демонстрация инструментов и подходов. Могу выделить три доклада, которые понравились мне.

  • Доклад Юлии Шевченко «Подходы к тестированию андроид приложений». Честно говоря, не ожидал чего-то от первого доклада, так как было ранее утро, мой мозг еще не перешел в фазу активного восприятия информации. Но Юля после первых нескольких слайдов очень заинтересовала рассказом о том, как у них настроен процесс тестирования андроид приложений. Она практически дала чеклист того, что стоит и что не стоит тестировать, и как это делать на андроиде. Мне доклад очень понравился и показался очень практическим. Обязательно пересмотрю его снова и очень жду слайдов. Как по мне, этот доклад наравне с докладом Николая Алименкова были лучшими на конференции.
  • Доклад Николая Алименкова «А вы знаете что тестируют ваши тесты?». Докладчик в необычной для тестировщиков-консерваторов, но при этом в свойственной себе манере рассказал о том, как писать тест кейсы на языке программирования (для примера была выбрана Java). При этом Николай все делал с предельно практической точки зрения. Он показывал инструменты на практике, в докладе была масса скриншотов и примеров. Мне доклад понравился. Коля показал инструмент Thucydides, на его примере продемонстрировав, как можно связывать требования с тестами. Показал интеграцию тестов с JIRA. Размышлял немного на тему того, как следить за тем, какая часть кода покрывается тестами, а какая нет. Рассказал о том, что такое тепловая карта элементов и каким образом её можно использовать в тестировании.
  • Доклад Олеся Сегеды Web Security. Олесь прямо на докладе показывал приемы хакерского искусства, вплетая SQL инъекции в код, совершая XSS атаки и так далее. Это доклад признали одним из лучших докладов конференции. Поэтому советую его посмотреть.

Какое общее впечатление от конференции?

Впечатления о конференции позитивные. Помещение (корпус КИМО) отлично подошло для организации конференции таких масштабов (конференцию посетило 550+ человек). Доклады в 3 потока, а также стендовые доклады, давали большую свободу выбора, и подобрать доклад можно было практически на любой вкус, начиная от функционального тестирования, заканчивая нагрузочным тестированием и тестированием в облаках. На конференции встретил много старых знакомых из других городов и стран, которых объединила конференция. Во время конференции работал wi-fi, организаторы постарались обеспечить участников информацией о предстоящих докладах и программе конференции. Кроме печатной версии программы, участники могли воспользоваться онлайн программой, благодаря организаторам участники могли в онлайн режиме задать вопрос докладчикам проголосовать за лучший доклад и пообщаться между собой.

Мой отчет о конференции

Не пропустіть результати зарплатного опитування — підписуйтеся на Telegram-канал редакції DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn



7 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

А можно ли вообще как-то сократить объём необходимого тестирования, повлияв на методологии разработчиков?

Это можно сделать, но с весьма неопределенными допущениями.

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

Касательно методик тестов — прежде всего мне интересны изменения. Создаётся софт, с тестовыми интерефейсами (закладками, юнитами, тестовыми данными). Но в процессе этапа производства риск-модель меняется! К примеру разработанный по какому-то шаблону, софт вообще не нуждается в тесте шаблона.

В идеале — может ли сам разрабочик СЭКОНОМИТЬ на времени взаимодействия с тестером, и сам со своей стороны выполнить типичные тесты (типичные для тестера, но не разработчика)? Да, получается что фактически управление разработчиком при этом делегируется в группу тестирования.

Мне интересно просто лично мнение: где сейчас идут основные потери времени, и чьего — не столько при тестировании, а вообще от альфа-версии и углубляясь в процесс боевой эксплутатации. Хочу проверить уровень собственной квалификации в вопросе, совпадёт ли мнение (в идеале — нет). В особенности интересно бета-тестирование и выгода экстремального программирования.

У вас вопрос слегка запутаный.

Где сейчас идут основные потери времени — на этапе проектирования закладываются основые ошибки :)

От альфа-версии и углубляясь в процесс боевой эксплутатации — тут непонятно.

В особенности интересно бета-тестирование и выгода экстремального программирования — выгода есть, если делается грамотными руками.

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

Слово одно (тестирование), но процессы кардинально разные.

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

Функциональное тестирование не всегда автоматизируется, но всегда требуется — и выполнять его может кто угодно; тот же менеджер проекта проводит много времени за подобным занятием.

Альфа-версия — это граница между прекращением вносить ключевые перемены, отсев идей «поменять всё», фактически граница той самой 0%-ной вероятности готовности кода, от этого момента вероятность начинает возрастать.

Про этап проектирования — поподробнее. Здесь чувствую будет ключевое несогласие (я тут и сам с собой не согласен, есть противоречивый опыт). Мне кажется сложно заложить «ошибку» на этапе проектирования. В английском 2 слова — mistake и error. Можно очень хорошо ошибиться на этапе постановки задачи, и исправить там невероятно сложно [согласовано с заказчиком]. А вот этап проектирования самый гибкий — у него есть план, притом этот самый план меняется в процессе. Как раз тот случай, когда нужно БЫСТРО до чего-то договориться, выйти на какие-то решения, и уже потом менять курпноблочно подходы не затрагивая мелкие детали.

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

Я не вижу, где здесь может случиться потеря времени. Самый быстрый этап! Если пытаться преодолеть риск — как раз вылетит дороже, и как раз по времени.

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

Это не теоретический вопрос (теории тут на 5 томов), скорее о личном мнении и реальной истории. В виде сказки для юниоров — самое оно :)

Виправіть, будь ласка, «Сусумо Васабе» на «Сусуму Сасабе» (див. it-conf.ru/.../466.htm#TOC-11 )

Підписатись на коментарі