|
 |
Персональные инструменты
Просмотры |
|
Персональные инструменты |
|
||
|
|
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. Безопасность и защищенность — суть разные вещи. И спроецировал на законы робототехники, потому что это актуальная для него конструкция. Из двух компаний он уходил, когда ПО становилось небезопасным, а он не мог повлиять. Законы.
Собственно, известно много кейсов, когда из-за багов в ПО первый закон нарушался и тем или иным образом причинялся вред. А баги связаны с ненадлежащим тестированием, вызванным разными причинами… И некоторые кейсы Николай рассказывал. Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации. |
 |
 |
 |
[ Хронологический вид ]Комментарии
Войдите, чтобы комментировать.