2013-11-10: SQAdays - потрясающая энергетика
м |
|||
Строка 2: | Строка 2: | ||
[[Файл:SQAdays-14-открытие.jpg|right|thumb|400px]] | [[Файл:SQAdays-14-открытие.jpg|right|thumb|400px]] | ||
− | Конференция собрала много участников и проходила на стадионе, так что можно с полным основанием говорить, что конференция тестировщиков собирает стадионы :) И, кстати, | + | Конференция собрала много участников и проходила на стадионе, так что можно с полным основанием говорить, что конференция тестировщиков собирает стадионы :) И, кстати, Львов — прекрасный город, который я хотел посмотреть и потому приехал сильно рано. Впечатления и фотки — [http://maksiq.livejournal.com/tag/Львов у меня в ЖЖ]. |
Было много докладов от новичков и для новичков, особенно в первый день: те, кто сделали успешные шаги делятся с другими тем, что и как они делают. Потому что они помнят о своем трудном пути, и хотят поделиться с другими, чтобы им было легче делать свое. В таких докладах нет идеи «сделай как я и будет успех», но и нет еще достаточно опыта чтобы представлять альтернативы и уместность тех или иных практик в условиях конкретных проектах и подать материал на таком уровне. | Было много докладов от новичков и для новичков, особенно в первый день: те, кто сделали успешные шаги делятся с другими тем, что и как они делают. Потому что они помнят о своем трудном пути, и хотят поделиться с другими, чтобы им было легче делать свое. В таких докладах нет идеи «сделай как я и будет успех», но и нет еще достаточно опыта чтобы представлять альтернативы и уместность тех или иных практик в условиях конкретных проектах и подать материал на таком уровне. | ||
Строка 8: | Строка 8: | ||
Да, все или многое из этого можно было получить из систематического обучения. Но его на пост-советском пространстве нет, причины известны. И, я думаю, уже не будет, но по другим причинам. Дело в том, что образование перестраивается, и традиционные системы должны сильно измениться. Где-то это получится эволюционно, но, думаю, что большинство старых структур просто отомрет, будучи вытеснено новыми. Это, конечно, не дело пары лет, но думаю в пределах десятилетия. | Да, все или многое из этого можно было получить из систематического обучения. Но его на пост-советском пространстве нет, причины известны. И, я думаю, уже не будет, но по другим причинам. Дело в том, что образование перестраивается, и традиционные системы должны сильно измениться. Где-то это получится эволюционно, но, думаю, что большинство старых структур просто отомрет, будучи вытеснено новыми. Это, конечно, не дело пары лет, но думаю в пределах десятилетия. | ||
− | Так что во многом это конференция не профессионалов, а дилетантов. Они не следуют каким-либо стандартным методикам, они пробуют различное и конструируют свое. И у них нет систематического | + | Так что во многом это конференция не профессионалов, а дилетантов. Они не следуют каким-либо стандартным методикам, они пробуют различное и конструируют свое. И у них нет систематического образования — они делают свою работу на ходу, в потоке. Лучше ли этот способ чем сначала получить систематичное образование, а потом его применять — вопрос открытый. Но он закономерен, и все развивающиеся отрасли через него проходили. А IT — развивающаяся, поэтому в ней так будет. И не только в ней, это тренд современного мира, работа как часть самореализации жизни, а не как скучный способ зарабатывания денег. Впрочем, об этом в другой раз. |
Но если говорить об общих пожеланиях ко многим докладчикам, то оно такое. Рассказывая о своих успешных практиках и достижениях попробуйте представить, кому, в каких проектах и ситуациях они могли бы пригодится другим, а для каких ситуаций лучше поискать другие пути. В конце концов, Вы сами искали варианты, пробовали различные методы. | Но если говорить об общих пожеланиях ко многим докладчикам, то оно такое. Рассказывая о своих успешных практиках и достижениях попробуйте представить, кому, в каких проектах и ситуациях они могли бы пригодится другим, а для каких ситуаций лучше поискать другие пути. В конце концов, Вы сами искали варианты, пробовали различные методы. | ||
− | Во второй день конференции было больше докладов от профессионалов. И для тех, кто ездит на конференцию постоянно, он скрасил сдержанные оценки первого дня. Но я слышал и обратные | + | Во второй день конференции было больше докладов от профессионалов. И для тех, кто ездит на конференцию постоянно, он скрасил сдержанные оценки первого дня. Но я слышал и обратные отзывы — о том, что доклады первого дня были более интересными, практическими, а не теоретическими. И это понятно — участникам разного уровня, из разных проектов нужны разные доклады. |
− | Сам я, кстати, во второй день совершенно неожиданно тоже оказался в роли | + | Сам я, кстати, во второй день совершенно неожиданно тоже оказался в роли докладчика — один из докладчиков почему-то не явился на собственный доклад и организаторы были вынуждены искать замену с колес. Поэтому я рассказывал свой прошлогодний [http://spmconf.ru/talk.sdf/spmconf/spmconf2/talks/7381 доклад на SPMconf] про модель командных ролей Белбина. По отзывам — получилось очень удачно и уместно, несмотря на то, что у меня не было времени даже просмотреть слайды. |
− | Если говорить о темах конференции, то я бы выделил интеграцию, различного рода ETL-процедуры и сервисы, работающие без интерфейса. На эту тему было довольно много докладов, как от подходах к тестированию, так и об инструментах, и | + | Если говорить о темах конференции, то я бы выделил интеграцию, различного рода ETL-процедуры и сервисы, работающие без интерфейса. На эту тему было довольно много докладов, как от подходах к тестированию, так и об инструментах, и это — относительно новая тема. Продолжалась тема с методиками тестирования на представительных наборах данных, техники pair-wise, которые позволяют избежать комбинаторного взрыва вариантов. И в этом сегменте есть инструменты, которые позволяют автоматически формировать представительный набор вариантов на основе распределений и описания множества значений различных параметров. |
− | Кстати, если говорить об инструментах, то большинство современных тестировщиков не используют какую-нибудь одну среду, а пользуются множеством подходящих инструментов различного назначения. Которые как-то несложно совмещаются и интегрируются друг с другом. И у профессионалов при этом получается довольно цельный фреймворк, который они, к тому же, легко модифицируют под разные цели проектов, попутно дописывая свое по необходимости. Подробнее можно посмотреть доклад Никиты | + | Кстати, если говорить об инструментах, то большинство современных тестировщиков не используют какую-нибудь одну среду, а пользуются множеством подходящих инструментов различного назначения. Которые как-то несложно совмещаются и интегрируются друг с другом. И у профессионалов при этом получается довольно цельный фреймворк, который они, к тому же, легко модифицируют под разные цели проектов, попутно дописывая свое по необходимости. Подробнее можно посмотреть доклад Никиты Гавриша — как они собирали фреймворк. Если говорить об аналогах, то это похоже на Linux и Java-мир, в отличие от подхода комплексных фреймворков одного вендора, который больше напоминает мир Windows и .Net с его Visual Studio. И это логично, потому что мир проектов сейчас очень разнообразен, технологии развиваются быстро, и производители фреймворков за этим не успевают, в то время как написать отдельные утилиты можно гораздо быстрее, это делают компании, занимающиеся тестированием, и, что интересно, многие из них выкладывают в свободный доступ, или распространяют за небольшие деньги — в отличие от тяжелых вендорских фреймворков. Обзоры инструментов и рассказ про конкретные были во многих докладах, и я бы хотел тут отметить прекрасный доклад Мясникова и Косарева на эту тему, который они сделали за один день как замену другого доклада. Этот тренд — компоновка цельных фреймворков из различных утилит — я уже отмечал на прошлых конференциях. |
Еще стоит отметить, что сама по себе автоматизация тестирования уже довольно давно не воспринимается как фишка. Большинство подходит к этому разумно, выстраивая баланс между автоматическим и ручным тестированием, между разными видами тестов, исходя из целей проекта. И рассказывают о том, что у них получилось. Если б еще рассказывали почему так и какие варианты были, было б совсем замечатльно, но так делают не все. | Еще стоит отметить, что сама по себе автоматизация тестирования уже довольно давно не воспринимается как фишка. Большинство подходит к этому разумно, выстраивая баланс между автоматическим и ручным тестированием, между разными видами тестов, исходя из целей проекта. И рассказывают о том, что у них получилось. Если б еще рассказывали почему так и какие варианты были, было б совсем замечатльно, но так делают не все. | ||
− | Было несколько докладов про совмещение ролей аналитика и тестировщика. Интересно, что несколько лет назад я делал [[Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQADays-2011)|доклад на SQAdays]] об этом. Тогда перед конференцией статью с тезисами доклада опубликовали [http://software-testing.ru/forum/index.php?//topic/21066/ на форуме software-testing] и в дискуссии оппоненты говорили, что совмещение не получится, потому что тестировщик нацелен на разрушение, а | + | Было несколько докладов про совмещение ролей аналитика и тестировщика. Интересно, что несколько лет назад я делал [[Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQADays-2011)|доклад на SQAdays]] об этом. Тогда перед конференцией статью с тезисами доклада опубликовали [http://software-testing.ru/forum/index.php?//topic/21066/ на форуме software-testing] и в дискуссии оппоненты говорили, что совмещение не получится, потому что тестировщик нацелен на разрушение, а аналитик — на созидание. Что мне это было странно, потому как у нас в компании такое совмещение есть с самого начала. С тех пор веяния изменились, и теперь совмещение никого не удивляет, а воспринимается конструктивно и правильно, доклад вызвал интерес у участников. |
− | А еще на конференции было много докладов в теме «другое». И это | + | А еще на конференции было много докладов в теме «другое». И это правильно — потому что время узких специализаций прошло, и надо выходить из этих границ. Интересно, что в Европе специализация тестировщика постепенно исчезает, это звучало в обсуждениях. Хотя я думаю, значительный вклад в это даент аутсорс тестирования в Индию и к нам, в Россию, Украину и Белоруссию. И будет ли эта ниша конкурентроспосбоной, или мы ее перерастем, оказывая комплексные, а не специализированные услуги — время покажет. В любом слуаче, надо смотреть вокруг, понимать свое место в нем. Поэтому доклады про личностный рост и коммуникации — уместны и востребованны участниками. |
И перед обзором хочу отметить те доклады, которые мне особенно понравились. | И перед обзором хочу отметить те доклады, которые мне особенно понравились. | ||
Строка 33: | Строка 33: | ||
* '''Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лида'''. Очень хороший обзор различных вспомогательных инструментов, нужных тестировщику. Которые позволяют эффективно решать очень многие задачи. | * '''Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лида'''. Очень хороший обзор различных вспомогательных инструментов, нужных тестировщику. Которые позволяют эффективно решать очень многие задачи. | ||
− | Кстати, если что-то понравилось | + | Кстати, если что-то понравилось мне — это не значит, что оно понравится вам. А еще надо учитывать, что параллельно шло несколько треков и многие доклады я слушал частично — так что запросто мог пропустить что-то ценное. И да, были доклады, на которых меня не было, поэтому я ничего не могу написать. |
− | А | + | А теперь — обзор докладов по темам, внутри доклады упорядочены по месту в программе. |
= Инструменты для тестировщиков = | = Инструменты для тестировщиков = | ||
Строка 53: | Строка 53: | ||
Про уменьшение числа тесткейсов Pair-Wise. Обычно его, конечно, сравнивают с общим перебором. Но это неправильно. | Про уменьшение числа тесткейсов Pair-Wise. Обычно его, конечно, сравнивают с общим перебором. Но это неправильно. | ||
− | Есть методики, тулы, как именно в разных инструментах, подбирать разные параметры. AllPairs, PICT и так далее,Ю список можно посмотреть на pairwise.org. Смысл | + | Есть методики, тулы, как именно в разных инструментах, подбирать разные параметры. AllPairs, PICT и так далее,Ю список можно посмотреть на pairwise.org. Смысл тула — вы для каждого параметра задаете списки значений, а он сам делает комбинации, алгоритмы можно параметризовать. Собственно, тулы — это отделение тестовых данных от кода, фреймворки. |
− | Они используют PICT. Тест с шаблонизированным поиском. При этом шаблон может быть и без метасимволов. И там разные | + | Они используют PICT. Тест с шаблонизированным поиском. При этом шаблон может быть и без метасимволов. И там разные комбинации — в каких есть шаблоны, в каких нет. PICT позволяет описать конструкции интеллектуальной генерации результата, через if как преобразование известных нам тестовых данных. |
== Ольга Киселева. Автотесты на уровне API для Java-приложений == | == Ольга Киселева. Автотесты на уровне API для Java-приложений == | ||
HFLabs. Москва, Россия | HFLabs. Москва, Россия | ||
− | На доклад зашел в самом конце, так что содержание представляю не полностью. В числе | + | На доклад зашел в самом конце, так что содержание представляю не полностью. В числе прочего — был представлен собственный свободный фреймворк для тестирования на Java. Что интересно — там заполнение данных, например, для перекладки тестовых данных из Excel в БД с привязкой по именам и т. п. А еще — рассказывали про процесс у них. Например, решения про то, требовать ли исправления тесткейсов или пометить его скипнутый, поставив баг в следующий релиз. |
== Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лида == | == Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лида == | ||
Строка 67: | Строка 67: | ||
Предупреждаю: список неполон, я слушал не с начала. | Предупреждаю: список неполон, я слушал не с начала. | ||
− | * Рассылка SMS. | + | * Рассылка SMS. GoogleDocs — замечательно посылает бесплатные SMS. Тесты свалились — CI ставит event в google docs календарей пользователя (он туда лезет, безопасность не появляется) — они получают сообщения, потому что у них настроено. |
* Teamer | * Teamer | ||
* Будильник. http://budist.ru/ Пишешь свой номер, тебе люди звонят и будят. | * Будильник. http://budist.ru/ Пишешь свой номер, тебе люди звонят и будят. | ||
* Писалки. Notepad++, Gedit, Vim, GNUnano, WebStorm. Подсветка синтаксиса. | * Писалки. Notepad++, Gedit, Vim, GNUnano, WebStorm. Подсветка синтаксиса. | ||
* Let’s sniff. Анализ пакетов, изменение пакетов, контроль трафика. Кейс, когда кто-то из программеров чего-то написал | * Let’s sniff. Анализ пакетов, изменение пакетов, контроль трафика. Кейс, когда кто-то из программеров чего-то написал | ||
− | Wireshark и др. | + | Wireshark и др. Тестировщики — не забывают смотреть, как идет логин и пароль реально. |
− | * Запись клавиш и мышек. AutoIt, Automator, UOPilot. | + | * Запись клавиш и мышек. AutoIt, Automator, UOPilot. UOPilot — была игра, там надо было прокачиваться. И фанаты написали штуку, которая цеплялась к окошку и делала что скажешь на простом скрипте. А теперь замечательно это делать не только для игры :) |
* Скринкастинки. screencast-o-matic.com, Camtasia (50$), Adobe Captivate. Они посетовали, что не нашли бесплатной. На самом деле, бесплатная есть, ее сделал Стас Фомин, когда работал над записью конференций, смотри на http://4intra.net/ Screen2Log и ConferenceRecorder, обе доступны в исходных текстах. | * Скринкастинки. screencast-o-matic.com, Camtasia (50$), Adobe Captivate. Они посетовали, что не нашли бесплатной. На самом деле, бесплатная есть, ее сделал Стас Фомин, когда работал над записью конференций, смотри на http://4intra.net/ Screen2Log и ConferenceRecorder, обе доступны в исходных текстах. | ||
* MindMaps. | * MindMaps. | ||
− | * TeamViewer, VNC. | + | * TeamViewer, VNC. Teamviewer — не надо устанавливать, можно просто запустить. И это плюс для многих, где следят за установкой ПО. |
− | * Средства | + | * Средства общения — Skype, Jabber, Teamspeak — комнаты с голосовым общением, Raid call — аналогично teamspeak, но с няшным интерфейсом, Google talk / Hangout. |
* Плагины. Баранцев весной на конфетке. Там дофига. Для проверок сайтов. | * Плагины. Баранцев весной на конфетке. Там дофига. Для проверок сайтов. | ||
− | А в конце были ролики. Демо | + | А в конце были ролики. Демо AutoIt — на нем можно автоматизировать минера замечательно. Правда, собственный язык дурацкий, но есть API к Ruby, и получается хорошо. Другие ролики показать не успели, но можно было посмотреть в холле. |
= Continious Integration и Delivery = | = Continious Integration и Delivery = | ||
− | На эту тему был роскошный доклад от Badoo, только меня на нем не | + | На эту тему был роскошный доклад от Badoo, только меня на нем не было — я слушал их на одной из прошлых конференций и потому решил послушать параллельные треки. |
== Максим Колотилкин. Автоматизация настолько хороша, насколько хорош человек использующий ее == | == Максим Колотилкин. Автоматизация настолько хороша, насколько хорош человек использующий ее == | ||
Строка 101: | Строка 101: | ||
Luxoft. Киев, Украина. | Luxoft. Киев, Украина. | ||
− | Рассказ о тестировании ETL-процессов. Сложности тут и в больших объемах данных, и в том, что эта задача подразумевает тестирование производительности, и в том, что надо порождать тестовые наборы данных, удовлетворяя ограничениям, и нельзя многократно догружать одно и то же, и | + | Рассказ о тестировании ETL-процессов. Сложности тут и в больших объемах данных, и в том, что эта задача подразумевает тестирование производительности, и в том, что надо порождать тестовые наборы данных, удовлетворяя ограничениям, и нельзя многократно догружать одно и то же, и сравнение — множественное. Они используют инструмент Informatica PowerCenter и он им много с чем помогает. |
== Александра Волкова. Тестирование Enterprise Service Bus: Что? Где? Как? == | == Александра Волкова. Тестирование Enterprise Service Bus: Что? Где? Как? == | ||
Itera Consulting. Киев, Украина | Itera Consulting. Киев, Украина | ||
− | + | Доклад — пошаговая инструкция как тестировать ESB в разных режимах: синхронное взаимодействие, асинхронное. Какие варианты надо проверить, где ставить заглушки. Для меня — понятная и очевидная. Но раз доклад — значит не для оно всех очевидно. | |
− | А еще им | + | А еще им хорошо — у них есть тестовый интеграционный стенд, приближенный к боевому. Это бывает не у всех, и из одной крупной конторы мне рассказывали, что интеграционное тестирование возможно только на проме, при чем создание каждого тестового документа требует отдельного согласования :) |
== Михаил Дырда, Александра Волкова. В поисках магической кнопки, или как воспитать SoapUI == | == Михаил Дырда, Александра Волкова. В поисках магической кнопки, или как воспитать SoapUI == | ||
Строка 120: | Строка 120: | ||
Казань, Россия | Казань, Россия | ||
− | Хороший доклад про тестирование retail-систем. Особенность в том, что в точках продаж (PoS) | + | Хороший доклад про тестирование retail-систем. Особенность в том, что в точках продаж (PoS) — много реального оборудования и тестировать нужно с ним, эмуляторы тут неуместны, так как эмулируют плохо. Даже печать на спец.принтерах, типа кассовых. надо проверять реально и глазками, картинка в PDF и на бумаге может сильно отличаться. Так что баланс между автоматизированным и ручным тестированием имеет свои особенности. |
== Владимир Кривенко. Особенности тестирования NoSQL приложений == | == Владимир Кривенко. Особенности тестирования NoSQL приложений == | ||
Paralect. Минск, Беларусь | Paralect. Минск, Беларусь | ||
− | MongoDB. Они выпустили собственный бесплатный инструмент для | + | MongoDB. Они выпустили собственный бесплатный инструмент для них — который обошел по запросов родные. Есть блог на тему. |
− | Прошли через объем | + | Прошли через объем БД — копию продакшн поднять вообще нельзя, нужна укороченная. Есть особенности конкретной БД. А еще — для эффективного использования часто применяют нестандартные архитектурные решения в Приложении с учетом особенности БД, и это надо учитывать при тестировании. А еще в этом сегменте предполагается отказоустойчивость и производительность, которые тоже надо тестировать. |
В блиц-доклад Владимир уложил все: от ликбеза до достаточно сложных особенностей NoSQL-тестирования. Круто. | В блиц-доклад Владимир уложил все: от ликбеза до достаточно сложных особенностей NoSQL-тестирования. Круто. | ||
Строка 142: | Строка 142: | ||
* Теория системного анализа: | * Теория системного анализа: | ||
* Основы бизнеса | * Основы бизнеса | ||
− | * Разработка информационной | + | * Разработка информационной системы — архитектора, юзабилити |
* Документирование (оно отдельно) | * Документирование (оно отдельно) | ||
* А еще основы менеджмента, экспертиза в предметной области и ин.яз. | * А еще основы менеджмента, экспертиза в предметной области и ин.яз. | ||
Строка 153: | Строка 153: | ||
По опыту 4 проектов, стартапы. Про совмещение аналитика и тестировщика, с рассмотрением типичных ошибок на этом пути. | По опыту 4 проектов, стартапы. Про совмещение аналитика и тестировщика, с рассмотрением типичных ошибок на этом пути. | ||
− | * Отказ от написания тест-кейсов или хотя бы чек | + | * Отказ от написания тест-кейсов или хотя бы чек листов — ведь он сам все выяснял. На самом деле — забудет или на другой проект уйдет, или расширение будет. Так что не надо срезать углы. |
* Расстановка приоритетов. Часто он делает аналитику в ущерб тестированию. Так неправильно, потому что система обрастает багами. | * Расстановка приоритетов. Часто он делает аналитику в ущерб тестированию. Так неправильно, потому что система обрастает багами. | ||
− | * Смешение ролей. Особенно при общении с | + | * Смешение ролей. Особенно при общении с заказчиком — важно позиционирование. Иначе не получается ни то ни другое, все в куче. Надо в голове — разделять. |
И рассматривал плюсы и минусы, которые стоит принимать во внимание. | И рассматривал плюсы и минусы, которые стоит принимать во внимание. | ||
Строка 174: | Строка 174: | ||
* Объяснять, что такое хорошо что такое плохо | * Объяснять, что такое хорошо что такое плохо | ||
* … | * … | ||
− | Всем этим должен заниматься аналитик. У нас в компании, кстати | + | Всем этим должен заниматься аналитик. У нас в компании, кстати занимается — у нас хорошие аналитики. |
= Процессы тестирования = | = Процессы тестирования = | ||
Строка 181: | Строка 181: | ||
ЗАО «БАРС-Груп». Казань, Россия | ЗАО «БАРС-Груп». Казань, Россия | ||
− | Это доклад о том, как в большом проекте который ведется в «допотопном» стиле, то есть без документации, декомпозиции, понимания внутренних связей, тестировщики самостоятельно и постепенно строили процесс. Включая декомпозицию системы на модули для специализации своей работы, документирование и так далее, выполняли реверс-инжиниринг проекта, данного в ощущениях. При этом их позвали, чтобы разгрузить | + | Это доклад о том, как в большом проекте который ведется в «допотопном» стиле, то есть без документации, декомпозиции, понимания внутренних связей, тестировщики самостоятельно и постепенно строили процесс. Включая декомпозицию системы на модули для специализации своей работы, документирование и так далее, выполняли реверс-инжиниринг проекта, данного в ощущениях. При этом их позвали, чтобы разгрузить аналитиков — то есть аналитик присутствуют. Ребята молодцы, но какова гримаса мира! |
− | == Андрей Иваровский. | + | == Андрей Иваровский. Рефакторинг — на позитиве == |
runteo.ru. Минск, Беларусь | runteo.ru. Минск, Беларусь | ||
− | Рассказ о том, как он последовательно инициировал рефакторинг для повышения технологичности поддержки автотестов и, как | + | Рассказ о том, как он последовательно инициировал рефакторинг для повышения технологичности поддержки автотестов и, как следствие — снижения стоимости. Критерий полезности: замещение ручного труда автотестами против поддержки автотестов. Полезно мониторить. И если несопоставимо — надо менять. Часто затраты на поддержание автотестов — неоправданно. Особенность — проект совместный с индусами, анализ и предложения по рефакторингу проводил он, а делали — они, и тут есть свои особенности :) |
− | == Виталий Петруняк. Команды из разных | + | == Виталий Петруняк. Команды из разных стран — секреты успешного тестирования и дипломатии == |
T-Systems CIS. Санкт-Петербург, Россия | T-Systems CIS. Санкт-Петербург, Россия | ||
− | T- | + | T-Systems — дочка Дойч-Телеком. Он же основной заказчик, и есть другие германские заказчики. Разработка и тестирование — распределенные на разные страны. И был рассказ о том, как у них устроена работа в этих условиях. К сожалению, целостной картины в докладе не было, между теорией и практикой в нем наблюдается определенный разрыв. Общая схема примерно такая: было плохо, сделали 1-2-3, стало хорошо. Но вот почему выбрали именно 1-2-3 или почему это полечило — до конца не раскрыто. |
== Никита Гавриш. Внедрение автоматизации на Selenium в highload-проект== | == Никита Гавриш. Внедрение автоматизации на Selenium в highload-проект== | ||
Строка 199: | Строка 199: | ||
* Симба и Нала. Кейс, когда вы ставите автотестирвоание в существующем проекте с историей. При этом там ожидают автотестов, отношение балгожелательное. Но тем не менее. И на начальном этапе вы по-сути внешний к команде проекта, пилите в одиночестве, и только через некоторое время станете своим. | * Симба и Нала. Кейс, когда вы ставите автотестирвоание в существующем проекте с историей. При этом там ожидают автотестов, отношение балгожелательное. Но тем не менее. И на начальном этапе вы по-сути внешний к команде проекта, пилите в одиночестве, и только через некоторое время станете своим. | ||
* Тимон и Пума. Кейс, когда команда даквно работает с автотестами. Тут надо поднять технические решения. | * Тимон и Пума. Кейс, когда команда даквно работает с автотестами. Тут надо поднять технические решения. | ||
− | * Проект Генри. Банзай, Шэнзи, Эд. Проект нестабильный и не знает с ним будет через | + | * Проект Генри. Банзай, Шэнзи, Эд. Проект нестабильный и не знает с ним будет через месяц — и соответственно не планируют. Проект не знает, что делать с автотестами вообще. И при этом могут пробовать забивать микроскопом гвозди. И противоречивые требования. Терпеть были готовы только 5 минут. |
− | * Человек-невидимка. Фантастический проект по | + | * Человек-невидимка. Фантастический проект по TDD — ни разу не участвовал. Но если то, о чем рассказывал Badoo-правда, то они близки. Так что тут у него знания теоретические. |
− | Техническое решение: написать свой или взять готовые? Велосипед vs Freeware. Сравнение. Плюсы понятны, | + | Техническое решение: написать свой или взять готовые? Велосипед vs Freeware. Сравнение. Плюсы понятны, Минусы — тоже, готовый все равно надо допиливать, зато со своим можно промахнуться и написать дурацкую конструкцию, с которой мучаешься. Вывод разумный, но очевидный: писать свое стоит если у вас проект имеет какие-то понятные особенности, из-за которых стандартные не подойдут (включая метрики, или интеграция). |
− | Они решили писать свое. Поверх | + | Они решили писать свое. Поверх готового — Python + Selenuim + SQLite + CouchDB + HTML/JS/CSS. CouchDB взяли чтобы хранить результаты тестов, включая логи и screenshot и представлять результаты текстов красиво. CouchDB оказалось неудачным решением, он бы взял Mongo. А SQLlite хранил всякие конфиги, потому что у них конфигурации были сложные и многовариантные — если этого нет. то можно без них. |
− | == Дмитрий Химион. Деградация | + | == Дмитрий Химион. Деградация автоматизаторов — «горе от ума» == |
Performance Lab. Москва, Россия | Performance Lab. Москва, Россия | ||
− | Рассказ был о конкретном кейсе тестирования. Завязкой был неуклонный рост времени прохождения тестов, который при апроксимации выводил общее время в недопустимую область. И как он с этим разбирался, выдвигая различные гипотезы и проверяя их наблюдением за различными метриками. Причина оказалась любопытной. У них был собственные библиотечки хелперов для тестирвоания GUI, и первоначально в тесте надо было определить 4 переменные, чтобы указать элемент экрана для тестирования. Пор мере совершенствования в него встраивали разные эвристики, чтобы не все переменные можно было не задавать. Они работали. Только в 10 раз дольше, чем при задании | + | Рассказ был о конкретном кейсе тестирования. Завязкой был неуклонный рост времени прохождения тестов, который при апроксимации выводил общее время в недопустимую область. И как он с этим разбирался, выдвигая различные гипотезы и проверяя их наблюдением за различными метриками. Причина оказалась любопытной. У них был собственные библиотечки хелперов для тестирвоания GUI, и первоначально в тесте надо было определить 4 переменные, чтобы указать элемент экрана для тестирования. Пор мере совершенствования в него встраивали разные эвристики, чтобы не все переменные можно было не задавать. Они работали. Только в 10 раз дольше, чем при задании переменных — а дальше по мере увлечения доли тестов, где переменные были не заданы время медленно, но неуклонно росло… |
− | Это, конечно, рассказ, конечно, о конкретном кейсе, но общей тенденции. В разработке она проявляется в том, что вместо использования понятных правил именования и структуризации кода разработчики полагаются на поиск и автокомплит, хотя это каждый | + | Это, конечно, рассказ, конечно, о конкретном кейсе, но общей тенденции. В разработке она проявляется в том, что вместо использования понятных правил именования и структуризации кода разработчики полагаются на поиск и автокомплит, хотя это каждый раз — приличное нажатие клавиш, да и ожидание — потому что не всегда угадываешь. |
А еще в процессе рассказа Дмитрий показывал метрики, которыми он пользуется для наблюдения за ходом проекта. | А еще в процессе рассказа Дмитрий показывал метрики, которыми он пользуется для наблюдения за ходом проекта. | ||
Строка 218: | Строка 218: | ||
Лаборатория качества. Москва, Россия | Лаборатория качества. Москва, Россия | ||
− | Хороший рассказ о практиках организации взаимодействия с заказчиком при аутсорсинге тестирования. И о поставленных процессах накопления и применения опыта собственной работы. Например, они ведут структурированный список проблем, с которыми ранее встречались, и честно показывают его Заказчику на переговорах. Первая реакция «Это что, я должен все прочесть?», но потом примерно по половине пунктов Заказчик думает о превентивных мерах. А еще надо помнить, что | + | Хороший рассказ о практиках организации взаимодействия с заказчиком при аутсорсинге тестирования. И о поставленных процессах накопления и применения опыта собственной работы. Например, они ведут структурированный список проблем, с которыми ранее встречались, и честно показывают его Заказчику на переговорах. Первая реакция «Это что, я должен все прочесть?», но потом примерно по половине пунктов Заказчик думает о превентивных мерах. А еще надо помнить, что заказчики — тоже люди. И если вы что-то спросили, а вам не ответили, то формально вы чисты и по логам это покажете, но правильно через некоторое время переспросить — он мог просто забыть. И так далее, опыт Натальи большой. |
= Строительство команд и личный рост = | = Строительство команд и личный рост = | ||
Строка 225: | Строка 225: | ||
Wargaming. Минск, Беларусь | Wargaming. Минск, Беларусь | ||
− | Доклад о личном опыте создания команд. Разном, удачном и неудачном. С анализом причин неудач. Ситуация: самооценка начальника Ковбой, команда считает Диктатором и никто не подозревает, в чем дело. Варианты развития: может выдавить лидера или лидер команду. Оба проигрышные, но лучше когда команда | + | Доклад о личном опыте создания команд. Разном, удачном и неудачном. С анализом причин неудач. Ситуация: самооценка начальника Ковбой, команда считает Диктатором и никто не подозревает, в чем дело. Варианты развития: может выдавить лидера или лидер команду. Оба проигрышные, но лучше когда команда выдавила — потому что тогда можно назначить другого, и команда останется. А если команду подавили, то фиг, они все — как дети за крысоловом. |
− | Подходы рассказывал известные. Квадрат моделей лидерства Can/Want: Supporting, Directing, Coaching, Delegating. Кстати, Supporting тут по-видимому политкорректное и лишнее, я слышал ту же модель от Петелина и у него гораздо | + | Подходы рассказывал известные. Квадрат моделей лидерства Can/Want: Supporting, Directing, Coaching, Delegating. Кстати, Supporting тут по-видимому политкорректное и лишнее, я слышал ту же модель от Петелина и у него гораздо жестче — Controlling. Стадии команды — Forming Storming Norming Performing и роль лидера в них. Из любопытного: на storming. Лид должен гасить конфликты, и должен провоцировать, но на нерабочие темы — чтобы люди выяснили отношения. А в norming — традиции, стикеры на дверь. Только не придумывать самим — должны сами зародится. |
− | Дальше будет меняться | + | Дальше будет меняться состав — будет Reforming, опять штормить. |
== Святослав Римар. 10 «тестхаков» для улучшения процесса тестирования == | == Святослав Римар. 10 «тестхаков» для улучшения процесса тестирования == | ||
SoftServe. Львов, Украина | SoftServe. Львов, Украина | ||
− | В докладе был набор разных практик самого разного характера: квантование времени Pomodoro, MindMap для любых списков, противодейстиве закону Паркинсона о том, что работа занимает все отведенное время, завоевание доверия клиента через индикатор | + | В докладе был набор разных практик самого разного характера: квантование времени Pomodoro, MindMap для любых списков, противодейстиве закону Паркинсона о том, что работа занимает все отведенное время, завоевание доверия клиента через индикатор прогресса — организацию ночных сборок с отгрузкой так, что клиент может пощупать, автоматизация повседневной работы, работа с мотивацией и геймификацией. В общем, много всего. И смысл доклада в том, что возьмите — и попробуйте применить, вам тоже может помочь. |
− | Только вот, добавлю от себя, что может помочь, а может и навредить. Можно это проверять экспериментальным путем, а можно сначала подумать, покопать механизмы и границы применимости, подумать об эффекте в долгую. Потому что многие практики при неуместном применении, давая эффект в моменте, портят ситуацию в долгую, при чем неочевидным образом. Тот же | + | Только вот, добавлю от себя, что может помочь, а может и навредить. Можно это проверять экспериментальным путем, а можно сначала подумать, покопать механизмы и границы применимости, подумать об эффекте в долгую. Потому что многие практики при неуместном применении, давая эффект в моменте, портят ситуацию в долгую, при чем неочевидным образом. Тот же pomodoro — он квантует время, не давая переключаться, требуя отдыха мозгов и вполне эффективен, когда задачи у вас ума требуют, а творчества — не очень, и делать их не особо хочется — ну как решение заданий в институте. Творческие задачи так решаются плохо. А еще — он закрывает путь к состоянию «работы в потоке» (это ввел Михай Чиксентмихайи, кому интересно можно посмотреть видео Алексея Пименова на [https://www.evernote.com/shard/s9/sh/497612c3-ad1d-4dd9-8502-9c203f9f691f/47ce75f2cdd5143da419f50c1d64f0b9 AgileKitchen], а потом почитать). И геймификацией, то есть игрофикацией тоже все не просто и не безопасно, можно посмотреть там же и в других докладах Максима Коробцева. |
== Андрей Ребров. Тестирование в Agile для больших команд: путь трансформации == | == Андрей Ребров. Тестирование в Agile для больших команд: путь трансформации == | ||
ScrumTrek. Москва, Россия | ScrumTrek. Москва, Россия | ||
− | Рассказ был про конкретный кейс в одной из компаний. И успешный: повысили скорость поставки фич в 5 раз, поставки стали регулярными 2-3 раза в неделю, ушли от работы по выходным и по ночам. Повысилась удовлетворенность работой. Как | + | Рассказ был про конкретный кейс в одной из компаний. И успешный: повысили скорость поставки фич в 5 раз, поставки стали регулярными 2-3 раза в неделю, ушли от работы по выходным и по ночам. Повысилась удовлетворенность работой. Как процесс — ставили Канбан — это самая простая методология, всего 4 правила, хотя самая сложная в поддержании. Самое распространенное — задачу пускают в работу партизанскими методами, в обход ограничений канбан-доски. А это — нарушение целей методологии. |
− | Сделали сессия рассказа требований от аналитиков. «Зачем рассказывать, есть же документ. | + | Сделали сессия рассказа требований от аналитиков. «Зачем рассказывать, есть же документ. — Мы прочитать можем, мы понять не можем.». Использовали Спецификация на примерах — Goiko Adzic. |
− | Начали думать о рисках. Пока в варианте выписать, оценить и принять превентивные меры. Как сказал Андрей «Если кто-то думает, что это работа тестлида или менеджера, то подумайте, делает он это :)». Уже от себя добавлю, что превентивные меры для | + | Начали думать о рисках. Пока в варианте выписать, оценить и принять превентивные меры. Как сказал Андрей «Если кто-то думает, что это работа тестлида или менеджера, то подумайте, делает он это :)». Уже от себя добавлю, что превентивные меры для рисков — хорошо, но часто дорого. Есть другой способ: придумываем метод раннего обнаружения и План-Б, который включается. |
− | Начали использовать DevOps. Квадрат Culture (хотя бы общайтесь) | + | Начали использовать DevOps. Квадрат Culture (хотя бы общайтесь) — Automation (google в помощь, список велик) — Measurement (нужен не только инструмент, но и разумная система измерений) — Sharing (делиться знаниями). Про Sharing — почему-то в больших компаниях у админов своя закрытая вики, у тестировщиков — своя и каждый дрожит. |
− | Интересны были и вопросы, в частности был ли практический опыт работы со звездной командой. Ответ | + | Интересны были и вопросы, в частности был ли практический опыт работы со звездной командой. Ответ Андрея — достаточно большой опыт downgrade звезд с повышением эффективности команды, например, по пути тимлид-архитектор-кусочек автономного кода. |
== Дарья Костюк. Альпинизм в тестировании или восхождение на вершину карьеры == | == Дарья Костюк. Альпинизм в тестировании или восхождение на вершину карьеры == | ||
Строка 259: | Строка 259: | ||
* Для чего нужен успех в карьере. | * Для чего нужен успех в карьере. | ||
* Как повлияет на мою жизнь карьерный рост и готов ли ты к этому. | * Как повлияет на мою жизнь карьерный рост и готов ли ты к этому. | ||
− | Начинается все с желания. | + | Начинается все с желания. Потом — Идея. Затем — Намерение. |
− | + | Успех — не дело случая, а дело выбора. Примите прямо сейчас и начните движение к цели. Сформулируйте цель. Назначьте дедлайн. Чтобы туда идти. Определите промежуточные цели. Составьте список препятствий. Восхождение — это приключение. Надо получить кайф. Но придерживаться маршрута и не сдаваться. | |
И 10 навыков и качеств | И 10 навыков и качеств | ||
− | * | + | * Направление — на перспективу. Дальновидность. |
* SMART-цели | * SMART-цели | ||
* Работа на результат | * Работа на результат | ||
− | * На решение проблемных | + | * На решение проблемных ситуаций — решаем, а не анализируем причины. |
* На инициативу, инновации | * На инициативу, инновации | ||
* На окружающих | * На окружающих | ||
Строка 275: | Строка 275: | ||
Навыки все правильные, включая видение картины. | Навыки все правильные, включая видение картины. | ||
− | Ну и | + | Ну и ретро — в позитиве. Что сделано хорошо, что дало наилучший результат, что можно улучшить. |
− | От себя я хочу отметить, что в личностном развитии есть две составляющих: видение картины и собственно движение. И вот способ движения, о котором говорит | + | От себя я хочу отметить, что в личностном развитии есть две составляющих: видение картины и собственно движение. И вот способ движения, о котором говорит Дарья — сознательно и планомерно двигаться к цели. А есть другой способ — ловить возможности, он куда прикольнее — мир такие штуки подбрасывает! А если серьезно, идти планомерно — это Решающие (Judging), а ловить возможности — Воспринимающие (Perceiving). Это типы личности [http://en.wikipedia.org/wiki/MBTI Майерс-Бриггс] (не путать с соционикой), и по тестам человечество делится пополам. |
= Доклады-размышления = | = Доклады-размышления = | ||
Строка 284: | Строка 284: | ||
Аплана. Москва, Россия | Аплана. Москва, Россия | ||
− | Любопытный доклад. Размышления о будущем разработки, о том, какие будут приложения. Попытка соотнести описанную в книгах эволюцию ПО: работать | + | Любопытный доклад. Размышления о будущем разработки, о том, какие будут приложения. Попытка соотнести описанную в книгах эволюцию ПО: работать корректно — функционально — привлекательно — удобно пользоваться — оно душевное (это будущее, Котлер) с окружающей действительностью, приземлить их. Не скажу, чтоб она хорошо удалась, все-таки между теорией и практикой — большой разрыв сохраняется, а сама теория — она тоже из нескольких разных источников, которые противоречат друг другу, в том числе — скрытно. И из зала докладчику задавали неудобные вопросы, а он путался. Но, с другой стороны, сделать хороший доклад на такую тему — тяжело, задавать вопросы — куда легче. |
== Николай Юденко. 3 закона робототехники: или безопасность, функциональность и защищенность ПО == | == Николай Юденко. 3 закона робототехники: или безопасность, функциональность и защищенность ПО == | ||
Независимый эксперт. Днепропетровск, Украина | Независимый эксперт. Днепропетровск, Украина | ||
− | Security testing. Безопасность и | + | Security testing. Безопасность и защищенность — суть разные вещи. И спроецировал на законы робототехники, потому что это актуальная для него конструкция. Из двух компаний он уходил, когда ПО становилось небезопасным, а он не мог повлиять. |
Законы. | Законы. | ||
− | * Робот не может причинить вред или бездействием допустить | + | * Робот не может причинить вред или бездействием допустить вред — Безопасность |
− | * Робот должен повиноваться, пока не противоречит | + | * Робот должен повиноваться, пока не противоречит первому — Функциональность |
− | * Робот должен беспокоиться о личной | + | * Робот должен беспокоиться о личной безопасности — в мере, не противоречащем первым двум — Защищенность. |
Собственно, известно много кейсов, когда из-за багов в ПО первый закон нарушался и тем или иным образом причинялся вред. А баги связаны с ненадлежащим тестированием, вызванным разными причинами… И некоторые кейсы Николай рассказывал. | Собственно, известно много кейсов, когда из-за багов в ПО первый закон нарушался и тем или иным образом причинялся вред. А баги связаны с ненадлежащим тестированием, вызванным разными причинами… И некоторые кейсы Николай рассказывал. | ||
Версия 15:02, 12 ноября 2013
Закончилась SQAdays-14 во Львове. Все-таки, эта серия конференций обладает потрясающей энергетикой. Наверное потому, что у тестировщиков наиболее ярко проявляется идея предназначения «Мы делаем мир лучше, повышая качество программных продуктов и, как следствие, радость людей от жизни в этом мире». При этом они наименее интровертны среди ИТ-шников.
Конференция собрала много участников и проходила на стадионе, так что можно с полным основанием говорить, что конференция тестировщиков собирает стадионы :) И, кстати, Львов — прекрасный город, который я хотел посмотреть и потому приехал сильно рано. Впечатления и фотки — у меня в ЖЖ.
Было много докладов от новичков и для новичков, особенно в первый день: те, кто сделали успешные шаги делятся с другими тем, что и как они делают. Потому что они помнят о своем трудном пути, и хотят поделиться с другими, чтобы им было легче делать свое. В таких докладах нет идеи «сделай как я и будет успех», но и нет еще достаточно опыта чтобы представлять альтернативы и уместность тех или иных практик в условиях конкретных проектах и подать материал на таком уровне.
Да, все или многое из этого можно было получить из систематического обучения. Но его на пост-советском пространстве нет, причины известны. И, я думаю, уже не будет, но по другим причинам. Дело в том, что образование перестраивается, и традиционные системы должны сильно измениться. Где-то это получится эволюционно, но, думаю, что большинство старых структур просто отомрет, будучи вытеснено новыми. Это, конечно, не дело пары лет, но думаю в пределах десятилетия.
Так что во многом это конференция не профессионалов, а дилетантов. Они не следуют каким-либо стандартным методикам, они пробуют различное и конструируют свое. И у них нет систематического образования — они делают свою работу на ходу, в потоке. Лучше ли этот способ чем сначала получить систематичное образование, а потом его применять — вопрос открытый. Но он закономерен, и все развивающиеся отрасли через него проходили. А IT — развивающаяся, поэтому в ней так будет. И не только в ней, это тренд современного мира, работа как часть самореализации жизни, а не как скучный способ зарабатывания денег. Впрочем, об этом в другой раз.
Но если говорить об общих пожеланиях ко многим докладчикам, то оно такое. Рассказывая о своих успешных практиках и достижениях попробуйте представить, кому, в каких проектах и ситуациях они могли бы пригодится другим, а для каких ситуаций лучше поискать другие пути. В конце концов, Вы сами искали варианты, пробовали различные методы.
Во второй день конференции было больше докладов от профессионалов. И для тех, кто ездит на конференцию постоянно, он скрасил сдержанные оценки первого дня. Но я слышал и обратные отзывы — о том, что доклады первого дня были более интересными, практическими, а не теоретическими. И это понятно — участникам разного уровня, из разных проектов нужны разные доклады.
Сам я, кстати, во второй день совершенно неожиданно тоже оказался в роли докладчика — один из докладчиков почему-то не явился на собственный доклад и организаторы были вынуждены искать замену с колес. Поэтому я рассказывал свой прошлогодний доклад на SPMconf про модель командных ролей Белбина. По отзывам — получилось очень удачно и уместно, несмотря на то, что у меня не было времени даже просмотреть слайды.
Если говорить о темах конференции, то я бы выделил интеграцию, различного рода ETL-процедуры и сервисы, работающие без интерфейса. На эту тему было довольно много докладов, как от подходах к тестированию, так и об инструментах, и это — относительно новая тема. Продолжалась тема с методиками тестирования на представительных наборах данных, техники pair-wise, которые позволяют избежать комбинаторного взрыва вариантов. И в этом сегменте есть инструменты, которые позволяют автоматически формировать представительный набор вариантов на основе распределений и описания множества значений различных параметров.
Кстати, если говорить об инструментах, то большинство современных тестировщиков не используют какую-нибудь одну среду, а пользуются множеством подходящих инструментов различного назначения. Которые как-то несложно совмещаются и интегрируются друг с другом. И у профессионалов при этом получается довольно цельный фреймворк, который они, к тому же, легко модифицируют под разные цели проектов, попутно дописывая свое по необходимости. Подробнее можно посмотреть доклад Никиты Гавриша — как они собирали фреймворк. Если говорить об аналогах, то это похоже на Linux и Java-мир, в отличие от подхода комплексных фреймворков одного вендора, который больше напоминает мир Windows и .Net с его Visual Studio. И это логично, потому что мир проектов сейчас очень разнообразен, технологии развиваются быстро, и производители фреймворков за этим не успевают, в то время как написать отдельные утилиты можно гораздо быстрее, это делают компании, занимающиеся тестированием, и, что интересно, многие из них выкладывают в свободный доступ, или распространяют за небольшие деньги — в отличие от тяжелых вендорских фреймворков. Обзоры инструментов и рассказ про конкретные были во многих докладах, и я бы хотел тут отметить прекрасный доклад Мясникова и Косарева на эту тему, который они сделали за один день как замену другого доклада. Этот тренд — компоновка цельных фреймворков из различных утилит — я уже отмечал на прошлых конференциях.
Еще стоит отметить, что сама по себе автоматизация тестирования уже довольно давно не воспринимается как фишка. Большинство подходит к этому разумно, выстраивая баланс между автоматическим и ручным тестированием, между разными видами тестов, исходя из целей проекта. И рассказывают о том, что у них получилось. Если б еще рассказывали почему так и какие варианты были, было б совсем замечатльно, но так делают не все.
Было несколько докладов про совмещение ролей аналитика и тестировщика. Интересно, что несколько лет назад я делал доклад на SQAdays об этом. Тогда перед конференцией статью с тезисами доклада опубликовали на форуме software-testing и в дискуссии оппоненты говорили, что совмещение не получится, потому что тестировщик нацелен на разрушение, а аналитик — на созидание. Что мне это было странно, потому как у нас в компании такое совмещение есть с самого начала. С тех пор веяния изменились, и теперь совмещение никого не удивляет, а воспринимается конструктивно и правильно, доклад вызвал интерес у участников.
А еще на конференции было много докладов в теме «другое». И это правильно — потому что время узких специализаций прошло, и надо выходить из этих границ. Интересно, что в Европе специализация тестировщика постепенно исчезает, это звучало в обсуждениях. Хотя я думаю, значительный вклад в это даент аутсорс тестирования в Индию и к нам, в Россию, Украину и Белоруссию. И будет ли эта ниша конкурентроспосбоной, или мы ее перерастем, оказывая комплексные, а не специализированные услуги — время покажет. В любом слуаче, надо смотреть вокруг, понимать свое место в нем. Поэтому доклады про личностный рост и коммуникации — уместны и востребованны участниками.
И перед обзором хочу отметить те доклады, которые мне особенно понравились.
- Андрей Ребров. Тестирование в Agile для больших команд: путь трансформации. Рассказ был про конкретный кейс в одной из компаний. И успешный: повысили скорость поставки фич в 5 раз, поставки стали регулярными 2-3 раза в неделю, ушли от работы по выходным и по ночам. Повысилась удовлетворенность работой.
- Владимир Кривенко. Особенности тестирования NoSQL приложений. В блиц-доклад Владимир уложил все: от ликбеза до достаточно сложных особенностей NoSQL-тестирования. Круто.
- Никита Гавриш. Внедрение автоматизации на Selenium в highload-проект. Речь шла о разных кейсах команд-проектов внедрения техники автотестов, постановки процесса. С чем надо быть готовым столкнуться.
- Дарья Костюк. Альпинизм в тестировании или восхождение на вершину карьеры. Доклад про планирование личностного роста и следование плану. Начало было совсем замечательное: вдохновение профессии, про самореализацию в том, чтобы сделать мир лучше.
- Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лида. Очень хороший обзор различных вспомогательных инструментов, нужных тестировщику. Которые позволяют эффективно решать очень многие задачи.
Кстати, если что-то понравилось мне — это не значит, что оно понравится вам. А еще надо учитывать, что параллельно шло несколько треков и многие доклады я слушал частично — так что запросто мог пропустить что-то ценное. И да, были доклады, на которых меня не было, поэтому я ничего не могу написать.
А теперь — обзор докладов по темам, внутри доклады упорядочены по месту в программе.
Содержание
- 1 Инструменты для тестировщиков
- 2 Continious Integration и Delivery
- 3 Тестирование интеграции (ETL, ESB и другие)
- 4 Тестирование в конкретных областях
- 5 От тестировщика к аналитику
- 6 Процессы тестирования
- 6.1 Андрей Июдин. Как принести пользу разработке и упростить себе жизнь?
- 6.2 Андрей Иваровский. Рефакторинг — на позитиве
- 6.3 Виталий Петруняк. Команды из разных стран — секреты успешного тестирования и дипломатии
- 6.4 Никита Гавриш. Внедрение автоматизации на Selenium в highload-проект
- 6.5 Дмитрий Химион. Деградация автоматизаторов — «горе от ума»
- 6.6 Наталья Руколь. Аутсорсинг тестирования
- 7 Строительство команд и личный рост
- 8 Доклады-размышления
Инструменты для тестировщиков
Кроме перечисленных ниже докладов, об инструментах рассказывал Никита Гавриш в своем докладе.
Алексей Лупан, Олег Колька. Excel всё подскажет или «Вот сколько времени понадобится на тестирование»
SysIQ & Astound Commerce. Киев, Украина
Слушал неебольшой кусочек. Ребята показывали Excel-конструкцию, с помощью которой они проводят оценку и ведут мониторинг хода проекта. Со всеми подробностями. И вроде у них можно взять готовый Excel? чтобы потом для себя подстроить. Потому что модель должна быть адекватна процессам, а они у всех разные. Вопрос насколько это нужно, для меня открытый. Точно нужно, когда тестирование поставлено на поток, имеется достаточно много сопоставимых задач и надо работать над эффективностью. И еще оно должно быть хорошо отделено от остальной деятельности, иначе надо считать все вместе.
Были интересные фенечки, например, оценка степени удовлетворенности пользователей.
Татьяна Зинченко. PairWise и тестинг инструменты
Inter Technology Group. Simferopol, Ukraine.
Про уменьшение числа тесткейсов Pair-Wise. Обычно его, конечно, сравнивают с общим перебором. Но это неправильно.
Есть методики, тулы, как именно в разных инструментах, подбирать разные параметры. AllPairs, PICT и так далее,Ю список можно посмотреть на pairwise.org. Смысл тула — вы для каждого параметра задаете списки значений, а он сам делает комбинации, алгоритмы можно параметризовать. Собственно, тулы — это отделение тестовых данных от кода, фреймворки.
Они используют PICT. Тест с шаблонизированным поиском. При этом шаблон может быть и без метасимволов. И там разные комбинации — в каких есть шаблоны, в каких нет. PICT позволяет описать конструкции интеллектуальной генерации результата, через if как преобразование известных нам тестовых данных.
Ольга Киселева. Автотесты на уровне API для Java-приложений
HFLabs. Москва, Россия
На доклад зашел в самом конце, так что содержание представляю не полностью. В числе прочего — был представлен собственный свободный фреймворк для тестирования на Java. Что интересно — там заполнение данных, например, для перекладки тестовых данных из Excel в БД с привязкой по именам и т. п. А еще — рассказывали про процесс у них. Например, решения про то, требовать ли исправления тесткейсов или пометить его скипнутый, поставив баг в следующий релиз.
Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лида
Нижний Новгород, Москва, Россия.
Предупреждаю: список неполон, я слушал не с начала.
- Рассылка SMS. GoogleDocs — замечательно посылает бесплатные SMS. Тесты свалились — CI ставит event в google docs календарей пользователя (он туда лезет, безопасность не появляется) — они получают сообщения, потому что у них настроено.
- Teamer
- Будильник. http://budist.ru/ Пишешь свой номер, тебе люди звонят и будят.
- Писалки. Notepad++, Gedit, Vim, GNUnano, WebStorm. Подсветка синтаксиса.
- Let’s sniff. Анализ пакетов, изменение пакетов, контроль трафика. Кейс, когда кто-то из программеров чего-то написал
Wireshark и др. Тестировщики — не забывают смотреть, как идет логин и пароль реально.
- Запись клавиш и мышек. AutoIt, Automator, UOPilot. UOPilot — была игра, там надо было прокачиваться. И фанаты написали штуку, которая цеплялась к окошку и делала что скажешь на простом скрипте. А теперь замечательно это делать не только для игры :)
- Скринкастинки. screencast-o-matic.com, Camtasia (50$), Adobe Captivate. Они посетовали, что не нашли бесплатной. На самом деле, бесплатная есть, ее сделал Стас Фомин, когда работал над записью конференций, смотри на http://4intra.net/ Screen2Log и ConferenceRecorder, обе доступны в исходных текстах.
- MindMaps.
- TeamViewer, VNC. Teamviewer — не надо устанавливать, можно просто запустить. И это плюс для многих, где следят за установкой ПО.
- Средства общения — Skype, Jabber, Teamspeak — комнаты с голосовым общением, Raid call — аналогично teamspeak, но с няшным интерфейсом, Google talk / Hangout.
- Плагины. Баранцев весной на конфетке. Там дофига. Для проверок сайтов.
А в конце были ролики. Демо AutoIt — на нем можно автоматизировать минера замечательно. Правда, собственный язык дурацкий, но есть API к Ruby, и получается хорошо. Другие ролики показать не успели, но можно было посмотреть в холле.
Continious Integration и Delivery
На эту тему был роскошный доклад от Badoo, только меня на нем не было — я слушал их на одной из прошлых конференций и потому решил послушать параллельные треки.
Максим Колотилкин. Автоматизация настолько хороша, насколько хорош человек использующий ее
Wix. Днепропетровск, Украина
Рассказ о хороших практиках и автоматизации, которые у них применяются и которые обеспечивают Continious delivery. При этом он их не называет, а рассказывает их содержание. А поскольку их сервис достаточно тяжелый и нагруженный, то автоматизация там на высоте, автоматизируется не только тестирование, но и другая внутренняя работа, а для того, чтобы оно прижилось и использовалось надо применять классические подходы заказной разработки, ориентироваться на потребности пользователей и делать простой и удобный интерфейс. И об этом доклад тоже рассказывал.
Руфина Сарварова. CI: Автоматизация сборки, развёртывания и тестирования
Fujitsu Russia GDC. Казань, Россия
Рассказ по шагам как у них устроена непрерывная интеграция. Они используют преимущественно TFS, стоит два: Jenkins для юнит-тестов, TFS для интеграционных. Рассказ достаточно детальный, почти пошаговая инструкция, со всякими фенечками. Включая версионные батники, версии которых связаны с конфигурацией.
Тестирование интеграции (ETL, ESB и другие)
Сергей Сташенко. Особенности тестирования ETL-процессов
Luxoft. Киев, Украина.
Рассказ о тестировании ETL-процессов. Сложности тут и в больших объемах данных, и в том, что эта задача подразумевает тестирование производительности, и в том, что надо порождать тестовые наборы данных, удовлетворяя ограничениям, и нельзя многократно догружать одно и то же, и сравнение — множественное. Они используют инструмент Informatica PowerCenter и он им много с чем помогает.
Александра Волкова. Тестирование Enterprise Service Bus: Что? Где? Как?
Itera Consulting. Киев, Украина
Доклад — пошаговая инструкция как тестировать ESB в разных режимах: синхронное взаимодействие, асинхронное. Какие варианты надо проверить, где ставить заглушки. Для меня — понятная и очевидная. Но раз доклад — значит не для оно всех очевидно.
А еще им хорошо — у них есть тестовый интеграционный стенд, приближенный к боевому. Это бывает не у всех, и из одной крупной конторы мне рассказывали, что интеграционное тестирование возможно только на проме, при чем создание каждого тестового документа требует отдельного согласования :)
Михаил Дырда, Александра Волкова. В поисках магической кнопки, или как воспитать SoapUI
Itera Consulting. Киев, Украина
На этот доклад я не пошел, а в твитере много хороших отзывов. Жаль.
Тестирование в конкретных областях
Лариса Сафина. Тестирование Retail систем
Казань, Россия
Хороший доклад про тестирование retail-систем. Особенность в том, что в точках продаж (PoS) — много реального оборудования и тестировать нужно с ним, эмуляторы тут неуместны, так как эмулируют плохо. Даже печать на спец.принтерах, типа кассовых. надо проверять реально и глазками, картинка в PDF и на бумаге может сильно отличаться. Так что баланс между автоматизированным и ручным тестированием имеет свои особенности.
Владимир Кривенко. Особенности тестирования NoSQL приложений
Paralect. Минск, Беларусь
MongoDB. Они выпустили собственный бесплатный инструмент для них — который обошел по запросов родные. Есть блог на тему.
Прошли через объем БД — копию продакшн поднять вообще нельзя, нужна укороченная. Есть особенности конкретной БД. А еще — для эффективного использования часто применяют нестандартные архитектурные решения в Приложении с учетом особенности БД, и это надо учитывать при тестировании. А еще в этом сегменте предполагается отказоустойчивость и производительность, которые тоже надо тестировать.
В блиц-доклад Владимир уложил все: от ликбеза до достаточно сложных особенностей NoSQL-тестирования. Круто.
От тестировщика к аналитику
Вера Кушнарева. От тестировщика к аналитику: путь развития
Fujitsu Russia GDC. Казань, Россия
Зачем тестировщику расти в аналитики? Чтобы написать спецификацию, о которой давно мечтал! Компании это тоже выгодно. Поэтому давайте выращивать. Дальше Вера рассказывала организованный у них процесс: список компетенций, померить уровень, выявить слабые стороны, определить способы прокачки, составить план и идти по плану. Способ, характерный для больших компаний.
И дала список компетенций, который они используют.
- Базовые компетенции: деловое общение, срекдства визуализации и прочее
- Теория системного анализа:
- Основы бизнеса
- Разработка информационной системы — архитектора, юзабилити
- Документирование (оно отдельно)
- А еще основы менеджмента, экспертиза в предметной области и ин.яз.
Интересно, что предметная область в дополнительных компетенциях, в конце списка, перед ин.язом.
И дальше Исследовательские группы, план развития, индивидуальные планы, квартальные цели. «Так как компания большая, то естественно она процессная :) И индивидуальный план повышает процессность компании.». Во многом они строят конструкцию управления знаниями. То есть молодцы.
Максим Псарев. Тестирование и Бизнес-анализ в agile проектах. Совмещая разделять
DataArt. Воронеж, Россия
По опыту 4 проектов, стартапы. Про совмещение аналитика и тестировщика, с рассмотрением типичных ошибок на этом пути.
- Отказ от написания тест-кейсов или хотя бы чек листов — ведь он сам все выяснял. На самом деле — забудет или на другой проект уйдет, или расширение будет. Так что не надо срезать углы.
- Расстановка приоритетов. Часто он делает аналитику в ущерб тестированию. Так неправильно, потому что система обрастает багами.
- Смешение ролей. Особенно при общении с заказчиком — важно позиционирование. Иначе не получается ни то ни другое, все в куче. Надо в голове — разделять.
И рассматривал плюсы и минусы, которые стоит принимать во внимание.
Ольга Павлова. Синтетические фокусы-II: что делать за пределами зоны аналитического комфорта
КБ «Собака Павлова». Санкт-Петербург, Россия
Ольга попробовала сделать довольно сложную вещь: показать места, где в аналитической работе надо включать мозги. Да еще работать быстро и на цели проекта, а не в своем неспешном темпе тщательного анализа, свойственного некоторым. И не общими словами, а с конкретными областями аналитической работы, которые требуют разного включении мозгов.
- Отличать факты от гипотез
- Умение объяснять факты
- Формулирование гипотезы. Гипотеза как движущий инструмент.
- Управление жизненным циклом (всем массивом материалов).
- Конструирование, эксперименты
- Выявлять численные показатели
- Беспокоиться о расхождении представлений с реальностью
- Отличать главное от второстепенного
- Писать понятно, рисовать схемы
- Задавать вопросы по-существу
- Объяснять, что такое хорошо что такое плохо
- …
Всем этим должен заниматься аналитик. У нас в компании, кстати занимается — у нас хорошие аналитики.
Процессы тестирования
Андрей Июдин. Как принести пользу разработке и упростить себе жизнь?
ЗАО «БАРС-Груп». Казань, Россия
Это доклад о том, как в большом проекте который ведется в «допотопном» стиле, то есть без документации, декомпозиции, понимания внутренних связей, тестировщики самостоятельно и постепенно строили процесс. Включая декомпозицию системы на модули для специализации своей работы, документирование и так далее, выполняли реверс-инжиниринг проекта, данного в ощущениях. При этом их позвали, чтобы разгрузить аналитиков — то есть аналитик присутствуют. Ребята молодцы, но какова гримаса мира!
Андрей Иваровский. Рефакторинг — на позитиве
runteo.ru. Минск, Беларусь
Рассказ о том, как он последовательно инициировал рефакторинг для повышения технологичности поддержки автотестов и, как следствие — снижения стоимости. Критерий полезности: замещение ручного труда автотестами против поддержки автотестов. Полезно мониторить. И если несопоставимо — надо менять. Часто затраты на поддержание автотестов — неоправданно. Особенность — проект совместный с индусами, анализ и предложения по рефакторингу проводил он, а делали — они, и тут есть свои особенности :)
Виталий Петруняк. Команды из разных стран — секреты успешного тестирования и дипломатии
T-Systems CIS. Санкт-Петербург, Россия
T-Systems — дочка Дойч-Телеком. Он же основной заказчик, и есть другие германские заказчики. Разработка и тестирование — распределенные на разные страны. И был рассказ о том, как у них устроена работа в этих условиях. К сожалению, целостной картины в докладе не было, между теорией и практикой в нем наблюдается определенный разрыв. Общая схема примерно такая: было плохо, сделали 1-2-3, стало хорошо. Но вот почему выбрали именно 1-2-3 или почему это полечило — до конца не раскрыто.
Никита Гавриш. Внедрение автоматизации на Selenium в highload-проект
EPAM Systems. Санкт-Петербург, Россия
Хороший доклад на реальных кейсах команд-проектов внедрения техники автотестов, постановки процесса. С чем надо быть готовым столкнуться.
- Симба и Нала. Кейс, когда вы ставите автотестирвоание в существующем проекте с историей. При этом там ожидают автотестов, отношение балгожелательное. Но тем не менее. И на начальном этапе вы по-сути внешний к команде проекта, пилите в одиночестве, и только через некоторое время станете своим.
- Тимон и Пума. Кейс, когда команда даквно работает с автотестами. Тут надо поднять технические решения.
- Проект Генри. Банзай, Шэнзи, Эд. Проект нестабильный и не знает с ним будет через месяц — и соответственно не планируют. Проект не знает, что делать с автотестами вообще. И при этом могут пробовать забивать микроскопом гвозди. И противоречивые требования. Терпеть были готовы только 5 минут.
- Человек-невидимка. Фантастический проект по TDD — ни разу не участвовал. Но если то, о чем рассказывал Badoo-правда, то они близки. Так что тут у него знания теоретические.
Техническое решение: написать свой или взять готовые? Велосипед vs Freeware. Сравнение. Плюсы понятны, Минусы — тоже, готовый все равно надо допиливать, зато со своим можно промахнуться и написать дурацкую конструкцию, с которой мучаешься. Вывод разумный, но очевидный: писать свое стоит если у вас проект имеет какие-то понятные особенности, из-за которых стандартные не подойдут (включая метрики, или интеграция).
Они решили писать свое. Поверх готового — Python + Selenuim + SQLite + CouchDB + HTML/JS/CSS. CouchDB взяли чтобы хранить результаты тестов, включая логи и screenshot и представлять результаты текстов красиво. CouchDB оказалось неудачным решением, он бы взял Mongo. А SQLlite хранил всякие конфиги, потому что у них конфигурации были сложные и многовариантные — если этого нет. то можно без них.
Дмитрий Химион. Деградация автоматизаторов — «горе от ума»
Performance Lab. Москва, Россия
Рассказ был о конкретном кейсе тестирования. Завязкой был неуклонный рост времени прохождения тестов, который при апроксимации выводил общее время в недопустимую область. И как он с этим разбирался, выдвигая различные гипотезы и проверяя их наблюдением за различными метриками. Причина оказалась любопытной. У них был собственные библиотечки хелперов для тестирвоания GUI, и первоначально в тесте надо было определить 4 переменные, чтобы указать элемент экрана для тестирования. Пор мере совершенствования в него встраивали разные эвристики, чтобы не все переменные можно было не задавать. Они работали. Только в 10 раз дольше, чем при задании переменных — а дальше по мере увлечения доли тестов, где переменные были не заданы время медленно, но неуклонно росло…
Это, конечно, рассказ, конечно, о конкретном кейсе, но общей тенденции. В разработке она проявляется в том, что вместо использования понятных правил именования и структуризации кода разработчики полагаются на поиск и автокомплит, хотя это каждый раз — приличное нажатие клавиш, да и ожидание — потому что не всегда угадываешь.
А еще в процессе рассказа Дмитрий показывал метрики, которыми он пользуется для наблюдения за ходом проекта.
Наталья Руколь. Аутсорсинг тестирования
Лаборатория качества. Москва, Россия
Хороший рассказ о практиках организации взаимодействия с заказчиком при аутсорсинге тестирования. И о поставленных процессах накопления и применения опыта собственной работы. Например, они ведут структурированный список проблем, с которыми ранее встречались, и честно показывают его Заказчику на переговорах. Первая реакция «Это что, я должен все прочесть?», но потом примерно по половине пунктов Заказчик думает о превентивных мерах. А еще надо помнить, что заказчики — тоже люди. И если вы что-то спросили, а вам не ответили, то формально вы чисты и по логам это покажете, но правильно через некоторое время переспросить — он мог просто забыть. И так далее, опыт Натальи большой.
Строительство команд и личный рост
Вячеслав Лукьяненко. Командоварение: полевая кухня
Wargaming. Минск, Беларусь
Доклад о личном опыте создания команд. Разном, удачном и неудачном. С анализом причин неудач. Ситуация: самооценка начальника Ковбой, команда считает Диктатором и никто не подозревает, в чем дело. Варианты развития: может выдавить лидера или лидер команду. Оба проигрышные, но лучше когда команда выдавила — потому что тогда можно назначить другого, и команда останется. А если команду подавили, то фиг, они все — как дети за крысоловом.
Подходы рассказывал известные. Квадрат моделей лидерства Can/Want: Supporting, Directing, Coaching, Delegating. Кстати, Supporting тут по-видимому политкорректное и лишнее, я слышал ту же модель от Петелина и у него гораздо жестче — Controlling. Стадии команды — Forming Storming Norming Performing и роль лидера в них. Из любопытного: на storming. Лид должен гасить конфликты, и должен провоцировать, но на нерабочие темы — чтобы люди выяснили отношения. А в norming — традиции, стикеры на дверь. Только не придумывать самим — должны сами зародится.
Дальше будет меняться состав — будет Reforming, опять штормить.
Святослав Римар. 10 «тестхаков» для улучшения процесса тестирования
SoftServe. Львов, Украина
В докладе был набор разных практик самого разного характера: квантование времени Pomodoro, MindMap для любых списков, противодейстиве закону Паркинсона о том, что работа занимает все отведенное время, завоевание доверия клиента через индикатор прогресса — организацию ночных сборок с отгрузкой так, что клиент может пощупать, автоматизация повседневной работы, работа с мотивацией и геймификацией. В общем, много всего. И смысл доклада в том, что возьмите — и попробуйте применить, вам тоже может помочь.
Только вот, добавлю от себя, что может помочь, а может и навредить. Можно это проверять экспериментальным путем, а можно сначала подумать, покопать механизмы и границы применимости, подумать об эффекте в долгую. Потому что многие практики при неуместном применении, давая эффект в моменте, портят ситуацию в долгую, при чем неочевидным образом. Тот же pomodoro — он квантует время, не давая переключаться, требуя отдыха мозгов и вполне эффективен, когда задачи у вас ума требуют, а творчества — не очень, и делать их не особо хочется — ну как решение заданий в институте. Творческие задачи так решаются плохо. А еще — он закрывает путь к состоянию «работы в потоке» (это ввел Михай Чиксентмихайи, кому интересно можно посмотреть видео Алексея Пименова на AgileKitchen, а потом почитать). И геймификацией, то есть игрофикацией тоже все не просто и не безопасно, можно посмотреть там же и в других докладах Максима Коробцева.
Андрей Ребров. Тестирование в Agile для больших команд: путь трансформации
ScrumTrek. Москва, Россия
Рассказ был про конкретный кейс в одной из компаний. И успешный: повысили скорость поставки фич в 5 раз, поставки стали регулярными 2-3 раза в неделю, ушли от работы по выходным и по ночам. Повысилась удовлетворенность работой. Как процесс — ставили Канбан — это самая простая методология, всего 4 правила, хотя самая сложная в поддержании. Самое распространенное — задачу пускают в работу партизанскими методами, в обход ограничений канбан-доски. А это — нарушение целей методологии.
Сделали сессия рассказа требований от аналитиков. «Зачем рассказывать, есть же документ. — Мы прочитать можем, мы понять не можем.». Использовали Спецификация на примерах — Goiko Adzic.
Начали думать о рисках. Пока в варианте выписать, оценить и принять превентивные меры. Как сказал Андрей «Если кто-то думает, что это работа тестлида или менеджера, то подумайте, делает он это :)». Уже от себя добавлю, что превентивные меры для рисков — хорошо, но часто дорого. Есть другой способ: придумываем метод раннего обнаружения и План-Б, который включается.
Начали использовать DevOps. Квадрат Culture (хотя бы общайтесь) — Automation (google в помощь, список велик) — Measurement (нужен не только инструмент, но и разумная система измерений) — Sharing (делиться знаниями). Про Sharing — почему-то в больших компаниях у админов своя закрытая вики, у тестировщиков — своя и каждый дрожит.
Интересны были и вопросы, в частности был ли практический опыт работы со звездной командой. Ответ Андрея — достаточно большой опыт downgrade звезд с повышением эффективности команды, например, по пути тимлид-архитектор-кусочек автономного кода.
Дарья Костюк. Альпинизм в тестировании или восхождение на вершину карьеры
Softengi. Киев, Украина
Доклад про планирование личностного роста и следование плану. Начало было совсем замечательное: вдохновение профессии, про самореализацию в том, чтобы сделать мир лучше.
Перед тем, как расти, стоит дать ответ на вопросы
- Для чего нужен успех в карьере.
- Как повлияет на мою жизнь карьерный рост и готов ли ты к этому.
Начинается все с желания. Потом — Идея. Затем — Намерение.
Успех — не дело случая, а дело выбора. Примите прямо сейчас и начните движение к цели. Сформулируйте цель. Назначьте дедлайн. Чтобы туда идти. Определите промежуточные цели. Составьте список препятствий. Восхождение — это приключение. Надо получить кайф. Но придерживаться маршрута и не сдаваться.
И 10 навыков и качеств
- Направление — на перспективу. Дальновидность.
- SMART-цели
- Работа на результат
- На решение проблемных ситуаций — решаем, а не анализируем причины.
- На инициативу, инновации
- На окружающих
- На личностный рост (удержаться. быть лучше других).
- На качество
- На действия
Навыки все правильные, включая видение картины.
Ну и ретро — в позитиве. Что сделано хорошо, что дало наилучший результат, что можно улучшить.
От себя я хочу отметить, что в личностном развитии есть две составляющих: видение картины и собственно движение. И вот способ движения, о котором говорит Дарья — сознательно и планомерно двигаться к цели. А есть другой способ — ловить возможности, он куда прикольнее — мир такие штуки подбрасывает! А если серьезно, идти планомерно — это Решающие (Judging), а ловить возможности — Воспринимающие (Perceiving). Это типы личности Майерс-Бриггс (не путать с соционикой), и по тестам человечество делится пополам.
Доклады-размышления
Николай Москаленко. User experience, как замена юзабилити
Аплана. Москва, Россия
Любопытный доклад. Размышления о будущем разработки, о том, какие будут приложения. Попытка соотнести описанную в книгах эволюцию ПО: работать корректно — функционально — привлекательно — удобно пользоваться — оно душевное (это будущее, Котлер) с окружающей действительностью, приземлить их. Не скажу, чтоб она хорошо удалась, все-таки между теорией и практикой — большой разрыв сохраняется, а сама теория — она тоже из нескольких разных источников, которые противоречат друг другу, в том числе — скрытно. И из зала докладчику задавали неудобные вопросы, а он путался. Но, с другой стороны, сделать хороший доклад на такую тему — тяжело, задавать вопросы — куда легче.
Николай Юденко. 3 закона робототехники: или безопасность, функциональность и защищенность ПО
Независимый эксперт. Днепропетровск, Украина
Security testing. Безопасность и защищенность — суть разные вещи. И спроецировал на законы робототехники, потому что это актуальная для него конструкция. Из двух компаний он уходил, когда ПО становилось небезопасным, а он не мог повлиять.
Законы.
- Робот не может причинить вред или бездействием допустить вред — Безопасность
- Робот должен повиноваться, пока не противоречит первому — Функциональность
- Робот должен беспокоиться о личной безопасности — в мере, не противоречащем первым двум — Защищенность.
Собственно, известно много кейсов, когда из-за багов в ПО первый закон нарушался и тем или иным образом причинялся вред. А баги связаны с ненадлежащим тестированием, вызванным разными причинами… И некоторые кейсы Николай рассказывал.