|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
2013-11-10: SQAdays - потрясающая энергетикаМатериал из CustisWikiКороткая ссылка: SQAdays-14-mtsepkov Закончилась SQAdays-14 во Львове. Все-таки, эта серия конференций обладает потрясающей энергетикой. Наверное потому, что у тестировщиков наиболее ярко проявляется идея предназначения «Мы делаем мир лучше, повышая качество программных продуктов и, как следствие, радость людей от жизни в этом мире». При этом они наименее интровертны среди ИТ-шников. Конференция собрала много участников и проходила на стадионе, так что можно с полным основанием говорить, что конференция тестировщиков собирает стадионы :) И, кстати, Львов — прекрасный город, который я хотел посмотреть и потому приехал сильно рано. Впечатления и фотки — у меня в ЖЖ. Было много докладов от новичков и для новичков, особенно в первый день: те, кто сделали успешные шаги делятся с другими тем, что и как они делают. Потому что они помнят о своем трудном пути, и хотят поделиться с другими, чтобы им было легче делать свое. В таких докладах нет идеи «сделай как я и будет успех», но и нет еще достаточно опыта чтобы представлять альтернативы и уместность тех или иных практик в условиях конкретных проектах и подать материал на таком уровне. Да, все или многое из этого можно было получить из систематического обучения. Но его на пост-советском пространстве нет, причины известны. И, я думаю, уже не будет, но по другим причинам. Дело в том, что образование перестраивается, и традиционные системы должны сильно измениться. Где-то это получится эволюционно, но, думаю, что большинство старых структур просто отомрет, будучи вытеснено новыми. Это, конечно, не дело пары лет, но думаю в пределах десятилетия. Так что во многом это конференция не профессионалов, а дилетантов. Они не следуют каким-либо стандартным методикам, они пробуют различное и конструируют свое. И у них нет систематического образования — они делают свою работу на ходу, в потоке. Лучше ли этот способ чем сначала получить систематичное образование, а потом его применять — вопрос открытый. Но он закономерен, и все развивающиеся отрасли через него проходили. А IT — развивающаяся, поэтому в ней так будет. И не только в ней, это тренд современного мира, работа как часть самореализации жизни, а не как скучный способ зарабатывания денег. Впрочем, об этом в другой раз. Но если говорить об общих пожеланиях ко многим докладчикам, то оно такое. Рассказывая о своих успешных практиках и достижениях попробуйте представить, кому, в каких проектах и ситуациях они могли бы пригодится другим, а для каких ситуаций лучше поискать другие пути. В конце концов, Вы сами искали варианты, пробовали различные методы. Во второй день конференции было больше докладов от профессионалов. И для тех, кто ездит на конференцию постоянно, он скрасил сдержанные оценки первого дня. Но я слышал и обратные отзывы — о том, что доклады первого дня были более интересными, практическими, а не теоретическими. И это понятно — участникам разного уровня, из разных проектов нужны разные доклады. Сам я, кстати, во второй день совершенно неожиданно тоже оказался в роли докладчика — один из докладчиков почему-то не явился на собственный доклад и организаторы были вынуждены искать замену с колес. Поэтому я рассказывал свой прошлогодний доклад на SPMconf про модель командных ролей Белбина. По отзывам — получилось очень удачно и уместно, несмотря на то, что у меня не было времени даже просмотреть слайды. Если говорить о темах конференции, то я бы выделил интеграцию, различного рода ETL-процедуры и сервисы, работающие без интерфейса. На эту тему было довольно много докладов, как от подходах к тестированию, так и об инструментах, и это — относительно новая тема. Продолжалась тема с методиками тестирования на представительных наборах данных, техники pair-wise, которые позволяют избежать комбинаторного взрыва вариантов. И в этом сегменте есть инструменты, которые позволяют автоматически формировать представительный набор вариантов на основе распределений и описания множества значений различных параметров. Кстати, если говорить об инструментах, то большинство современных тестировщиков не используют какую-нибудь одну среду, а пользуются множеством подходящих инструментов различного назначения. Которые как-то несложно совмещаются и интегрируются друг с другом. И у профессионалов при этом получается довольно цельный фреймворк, который они, к тому же, легко модифицируют под разные цели проектов, попутно дописывая свое по необходимости. Подробнее можно посмотреть доклад Никиты Гавриша — как они собирали фреймворк. Если говорить об аналогах, то это похоже на Linux и Java-мир, в отличие от подхода комплексных фреймворков одного вендора, который больше напоминает мир Windows и .Net с его Visual Studio. И это логично, потому что мир проектов сейчас очень разнообразен, технологии развиваются быстро, и производители фреймворков за этим не успевают, в то время как написать отдельные утилиты можно гораздо быстрее, это делают компании, занимающиеся тестированием, и, что интересно, многие из них выкладывают в свободный доступ, или распространяют за небольшие деньги — в отличие от тяжелых вендорских фреймворков. Обзоры инструментов и рассказ про конкретные были во многих докладах, и я бы хотел тут отметить прекрасный доклад Мясникова и Косарева на эту тему, который они сделали за один день как замену другого доклада. Этот тренд — компоновка цельных фреймворков из различных утилит — я уже отмечал на прошлых конференциях. Еще стоит отметить, что сама по себе автоматизация тестирования уже довольно давно не воспринимается как фишка. Большинство подходит к этому разумно, выстраивая баланс между автоматическим и ручным тестированием, между разными видами тестов, исходя из целей проекта. И рассказывают о том, что у них получилось. Если б еще рассказывали почему так и какие варианты были, было б совсем замечатльно, но так делают не все. Было несколько докладов про совмещение ролей аналитика и тестировщика. Интересно, что несколько лет назад я делал доклад на SQAdays об этом. Тогда перед конференцией статью с тезисами доклада опубликовали на форуме software-testing и в дискуссии оппоненты говорили, что совмещение не получится, потому что тестировщик нацелен на разрушение, а аналитик — на созидание. Что мне это было странно, потому как у нас в компании такое совмещение есть с самого начала. С тех пор веяния изменились, и теперь совмещение никого не удивляет, а воспринимается конструктивно и правильно, доклад вызвал интерес у участников. А еще на конференции было много докладов в теме «другое». И это правильно — потому что время узких специализаций прошло, и надо выходить из этих границ. Интересно, что в Европе специализация тестировщика постепенно исчезает, это звучало в обсуждениях. Хотя я думаю, значительный вклад в это даент аутсорс тестирования в Индию и к нам, в Россию, Украину и Белоруссию. И будет ли эта ниша конкурентроспосбоной, или мы ее перерастем, оказывая комплексные, а не специализированные услуги — время покажет. В любом слуаче, надо смотреть вокруг, понимать свое место в нем. Поэтому доклады про личностный рост и коммуникации — уместны и востребованны участниками. И перед обзором хочу отметить те доклады, которые мне особенно понравились.
Кстати, если что-то понравилось мне — это не значит, что оно понравится вам. А еще надо учитывать, что параллельно шло несколько треков и многие доклады я слушал частично — так что запросто мог пропустить что-то ценное. И да, были доклады, на которых меня не было, поэтому я ничего не могу написать. А теперь — обзор докладов по темам, внутри доклады упорядочены по месту в программе. Содержание
Инструменты для тестировщиковКроме перечисленных ниже докладов, об инструментах рассказывал Никита Гавриш в своем докладе. Алексей Лупан, Олег Колька. 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 в БД с привязкой по именам и т. п. А еще — рассказывали про процесс у них. Например, решения про то, требовать ли исправления тесткейсов или пометить его скипнутый, поставив баг в следующий релиз. Станислав Косарев. Андрей Мясников. Джентльменский набор тест-лидаНижний Новгород, Москва, Россия. Предупреждаю: список неполон, я слушал не с начала.
Wireshark и др. Тестировщики — не забывают смотреть, как идет логин и пароль реально.
А в конце были ролики. Демо 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 в разных режимах: синхронное взаимодействие, асинхронное. Какие варианты надо проверить, где ставить заглушки. Для меня — понятная и очевидная. Но раз доклад — значит не для оно всех очевидно. А еще им хорошо — у них есть тестовый интеграционный стенд, приближенный к боевому. Это бывает не у всех, и из одной крупной конторы мне рассказывали, что интеграционное тестирование возможно только на проме, при чем создание каждого тестового документа требует отдельного согласования :) Михаил Дырда, Александра Волкова. В поисках магической кнопки, или как воспитать SoapUIItera 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. Санкт-Петербург, Россия Хороший доклад на реальных кейсах команд-проектов внедрения техники автотестов, постановки процесса. С чем надо быть готовым столкнуться.
Техническое решение: написать свой или взять готовые? Велосипед 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 навыков и качеств
Навыки все правильные, включая видение картины. Ну и ретро — в позитиве. Что сделано хорошо, что дало наилучший результат, что можно улучшить. От себя я хочу отметить, что в личностном развитии есть две составляющих: видение картины и собственно движение. И вот способ движения, о котором говорит Дарья — сознательно и планомерно двигаться к цели. А есть другой способ — ловить возможности, он куда прикольнее — мир такие штуки подбрасывает! А если серьезно, идти планомерно — это Решающие (Judging), а ловить возможности — Воспринимающие (Perceiving). Это типы личности Майерс-Бриггс (не путать с соционикой), и по тестам человечество делится пополам. Доклады-размышленияНиколай Москаленко. User experience, как замена юзабилитиАплана. Москва, Россия Любопытный доклад. Размышления о будущем разработки, о том, какие будут приложения. Попытка соотнести описанную в книгах эволюцию ПО: работать корректно — функционально — привлекательно — удобно пользоваться — оно душевное (это будущее, Котлер) с окружающей действительностью, приземлить их. Не скажу, чтоб она хорошо удалась, все-таки между теорией и практикой — большой разрыв сохраняется, а сама теория — она тоже из нескольких разных источников, которые противоречат друг другу, в том числе — скрытно. И из зала докладчику задавали неудобные вопросы, а он путался. Но, с другой стороны, сделать хороший доклад на такую тему — тяжело, задавать вопросы — куда легче. Николай Юденко. 3 закона робототехники: или безопасность, функциональность и защищенность ПОНезависимый эксперт. Днепропетровск, Украина Security testing. Безопасность и защищенность — суть разные вещи. И спроецировал на законы робототехники, потому что это актуальная для него конструкция. Из двух компаний он уходил, когда ПО становилось небезопасным, а он не мог повлиять. Законы.
Собственно, известно много кейсов, когда из-за багов в ПО первый закон нарушался и тем или иным образом причинялся вред. А баги связаны с ненадлежащим тестированием, вызванным разными причинами… И некоторые кейсы Николай рассказывал. Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». |
 |
 |
 |
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.