Инициативная группа DataArt в Харькове приглашает профессионалов, преподавателей, студентов и начинающих разработчиков и тестировщиков принять участие в 25-ой встрече. Она пройдет в Харьковском национальном экономическом университете (ХНЭУ) 25 февраля.
Программа встречи достаточно интересная. Кирилл Тимофеев выступит с докладом “Rails and JavaScript-heavy applications”:
Кирилл пришел в DataArt в те светлые времени, когда о Ruby еще говорили картонные лисы. За восемь лет успел поработать в проектах различной степени тяжести и драматичности. Любит помогать решать сложные задачи. Сейчас работает газовым ключом или, как написано на бумаге, Chief Architect. Верит в математику и ее следствия.
Второй доклад “Cloud — обзор возможностей открытой платформы” подготовила Людмила Дежкина. Речь пойдет об истории возникновения и основных решениях предложенных на рынке в сфере облачных техлогий. Также будут описаны основные модули и архитектура CloudFoundry, последние улучшения и планы развития. Людмила – опытный веб-разработчик, с 2007 года занимается разработкой на Ruby. Также хорошо владеет Java и JavaScript.
Участие во встречах IT talk — бесплатное. Регистрация участников обязательна! Количество место ограничено! Место проведения: Харьковский национальный экономический университет, пр. Ленина 9а, ауд. L 37. Начало в 19:00.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Мне часто задают вопрос как можно стать тренером XP Injection. Я решил написать об этом один раз и потом просто давать ссылочку (автоматизация – наше все). Начнем с того, что тренером XP Injection стать вполне реально. Но это не так просто. Совершенно не потому, что мы считаем себя такими крутыми, а потому что мы очень тщательно отбираем тренеров. В основном, мы приглашаем к себе в тренерский состав на основе наших наблюдений и знакомств.
Итак, начнем с требований. Первое из них – это опыт публичных выступлений. Мы не готовы брать всех желающих стать тренером. Мало того, мы не верим в то, что любой человек может стать тренером. Вы можете быть очень грамотным специалистом, хорошим человеком, позитивным работником, но это не делает из вас тренера. Поэтому в первую очередь мы обращаем внимание на ваши публичные выступления: на конференциях, в технологических клубах, в рамках встреч, внутри компании и т.д. Очень желательно увидеть записи всех ваших выступлений, для тренера это очень важно. Поэтому стоит заботиться о том, чтобы ваши “творения” вошли в историю. Тренеру нужно уметь хорошо говорить, держать аудиторию, увлекаться темой своих выступлений, держаться на публике без боязни.
Второе требование касается тематики тренингов. Она должна не идти в разрез с основным направлением работы тренинг-центра. У нас есть определенное видение процессов разработки, технологий и практик, которые актуальны и востребованы в современном мире разработки. Если вы собираетесь готовить тренинг на тему, которая не вписывается в эти представления, то нам не по дороге. Причина проста – мы не можем продавать то, во что не верим. К примеру, если вы используете JavaFX, верите в возможности внедрения RUP, являетесь экспертом в Struts, то нам с вами не по пути.
Третье требование – желание и наличие времени на тренинговую деятельность. Многим кажется, что все просто – взял материалы и провел тренинг. Но на самом деле все не так. На подготовку качественных материалов уходит очень много времени. Мы проводим ревью материалов чтобы не допустить некачественной работы. Да и сама тренерская активность часто вынуждает вас работать по выходным или же брать выходные/отгул/отпуск для проведения тренингов в будние дни (если вы конечно работаете помимо тренерской деятельности).
Обязательным требованием является ваша практика. Мы берем в тренера только тех, кто практикует то, о чем рассказывает в своем тренинге. Без практики ваши знания являются “сферическим конем в вакууме” и очень быстро устаревают. Вы не можете рассказать практических интересных историй и ответить на реальных примерах из жизни на вопросы участников. Это наш подход и вы вправе его принимать или не принимать. Наблюдая за рынком образования в IT, мы видим множество “бла-бла-бла консультантов”, которые не участвуют в реальной разработке уже много лет и при этом уверенно рассказывают другим как надо разрабатывать или применять определенные практики, инструменты и подходы.
Следующее требование – возможность и готовность работать тренером. Работа тренера предполагает, что вы будете много работать с людьми, много говорить, сильно уставать, часто ездить по другим городам и странам, много выступать на конференциях и встречах, ходить на конференции и встречи, много читать и анализировать полученную информацию. Поверьте мне на слово, это очень трудно и занимает много времени. Если вы к этому не готовы, то вам лучше держаться подальше от работы тренера, по крайней мере в нашем тренинг-центре.
Наконец, последнее требование. Вы должны быть публичным человеком, вас должны знать и вы должны над этим работать. Поэтому вы просто обязаны вести свой блог, регулярно писать статьи, иметь аккаунт в Twitter, желательно на Хабре, снова же проводить много публичных выступлений, аккаунт на githib. Требования к тренингам на современном рынке меняются – все больше людей приходят на тренера, а не на тему тренинга. Если вас никто не знает, то вас очень тяжело продавать. Никому не доказать, что вы круты, если этому нет объективных доказательств. Поэтому тренер должен заботиться об узнаваемости.
Ну вот пожалуй и все. Вроде я ничего не забыл. А если и забыл, то вы меня можете дополнить в комментариях. Мы нацелены на высокое качество работы наших тренеров и предпочитаем иметь меньше тренеров, но действительно достойных.
Если вы поняли, что идеально подходите на роль тренера по нашим требованиям и хотите работать именно с нами, то обращайтесь и мы будем рады видеть вас в нашей команде!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
21 февраля буду выступать на IT-People PechaKucha в Киеве. Программа собралась весьма неплохая. Долго думал о чем таком интересном можно было бы рассказать без упора на специализацию. В итоге решил поговорить о профессиональном разработчике и современным требованиям к нему.
Доклад называется «Портрет профессионального разработчика». Какой он, современный профессиональный разработчик? Что должен знать и уметь, чтобы не только работать на интересном проекте и получать высокую зарплату сегодня, но и иметь стабильный завтрашний день? Технологии и процессы не стоят на месте, а вместе с ними и требования к разработчикам. Чтобы оставаться «на плаву» надо работать над своими знаниями и навыками. Именно об этом мы и поговорим в течение 6 минут 40 секунд…
Если вы успели зарегистрироваться, то приходите послушать. Если нет, то я обязательно выложу слайдкаст этого выступления через некоторое время.
Недавно у меня появился аккаунт на Хабре и я опубликовал на статью “Не обманывайте своих заказчиков”. Было много обсуждений в комментариях и я решил сделать более детальное рассмотрение данной темы.
Я достаточно много занимаюсь не только разработкой, но и постановкой процессов, в том числе тестирования. И всегда несколько скептически относился к ручному тестированию, точнее к той его части, которая отвечает за «обеспечение работоспособности существующей фунциональности» (в простонародье регрессионное тестирование). Что же плохого в этом тестировании и почему многие компании его тогда используют?
Проблема достаточно несложная, но ее суть не лежит на поверхности. Представьте себя на месте заказчика. Вы приходите с набором требований к исполнителю, в данном случае будем рассматривать в роли исполнителя команду разработки. Вы договорились о всех деталях с командой и она готова начать работать над вашим продуктом. Вы как умный и опытный заказчик грамотно расставили приоритеты и выдаете команде требование за требованием в правильном для бизнеса порядке. Вроде пока все звучит неплохо и ситуация не напоминает проблематичную.
Но вот проходит месяц-другой и выясняется неприятная деталь — на тестирование тратится все больше и больше времени. Оно вполне логично — ведь готовой функциональности в продукте становится все больше и надо постоянно контролировать, что она по-прежнему работает. Это эффект называется «регрессионная спираль смерти» (термин подсмотрен в выступлении Макса Дорофеева «Обезьянки против Роботов»). Эта спираль развивается со временем и становится все шире и шире. И если раньше тестировщики успевали «пробежаться» по продукту за несколько часов, то вскоре на это начинает уходить несколько дней.
Все очень просто — отдавая заказчику «готовую» работу мы не даем ему способа бесплатно и легко контролировать ее работоспособность в будущем. Утрируя, это может звучать так: «Мы закончили работать над X, Y и Z. Но уже через пару недель есть шансы, что они перестанут работать нормально…» Но как же так? Ведь заказчик заплатил за полное завершение работ. Как же ему теперь быть? Ему предлагается очень простое решение — плати нам постоянно дополнительную плату за то, что мы будем контролировать работоспособность на протяжении жизни продукта.
Получается, что стоимость одной конкретной функциональности будет продолжать расти на протяжении всего проекта. И чем быстрее работает команда, тем быстрее будет расти стоимость затрат на поддержание регрессии. Это же нечестно! В жизни бы мы никогда не согласились на такое. Представляете, вы заказываете ремонт, а вам предлагают платить дополнительные деньги за то, чтобы при работе над кухней не развалилась гостиная…
Почему же при всей ущербности подобной модели она не перестанет применяться? Тут есть несколько причин:
При этом, во многих современных продуктовых компаниях к такого рода затратам относятся скептически и не поддерживают идею ручного регрессионного тестирования. В таких компаниях нет позиции monkey тестировщика, так привычной для рынка аутсорсинга.
Для того, чтобы работать честно, надо пересмотреть «критерии готовности» команды разработки и расширить их наличием автоматизированных приемочных тестов. Перед работой над определенной функциональностью хорошая команда (заметьте, я не использовал слово Agile) задает заказчику вопросы о том, как функциональность должна работать и как заказчик будет проверять готовность. Это и есть процесс формирования приемочных критериев. Они представляют из себя мини-контракт между заказчиком и командой на реализацию этой функциональности.
Речь идет о работе над требованиями на очень короткий срок — обычно одна итерация. Если заказчик не может на такой срок сформулировать требования во всех деталях и ответить на все вопросы, то у вас уже проблемы. Работа над приемочными тестами помогает выявить их на самой ранней стадии.
Не стоит ожидать от заказчика, что он придет и выложит вам приемочные критерии на блюдечке. Вопросов «а как вы проверите, что это работает», «а давайте рассмотрим на примерах», «а как это будет использоваться» в умелых руках достаточно, чтобы получить набор критериев на практике. Главное чтобы не приходилось в процессе разработки делать предположения и обращаться к “здравому смыслу”. Это очень опасно и может привести к переделкам и недовольству заказчика.
Дальше хорошая команда снабжает эти критерии приемки конкретными примерами, данными и «прикручивает» к работающему продукту. Таким образом, добавляется возможность с помощью приемочных тестов в любой момент времени проверить, работает ли та или иная функциональность в продукте после любых изменений. Запустить эти автоматизированные приемочные тесты может любой, обычно они добавляются к Continuous Integration серверу и запускаются на каждое изменение или в ручном режиме.
Почитайте как работает на примере одной команды командное написание приемочных тестов и про эволюцию необходимости таких тестов к запуску в облаке.
Но ведь есть же модульные тесты? Зачем еще раз делать ту же работу? Модульными тестами хороший разработчик покрывает код, чтобы убедиться, что его точечная идея для класса, функции, метода или их связки работает правильно. К сожалению, модульные тесты не способны обеспечить проверку даже возможности запуска приложения, не говоря уже о его функциях. Плюс, приемочные тесты написаны на языке, понятном заказчику, в отличии от модульных тестов. Если искать связь, то модульные тесты рождаются из приемочных, в то же время играя роль приемочных тестов на уровне кода.
И теперь никто не тратит время на ручное регрессионное тестирование. Это время тратится на исследовательское тестирование, на помощь команде разработки завершить свою работу вовремя и с высоким уровнем качества, на обеспечение работоспособности канала донесения требований от заказчика к команде разработки. Заказчик при этом имеет под рукой мощный инструмент контроля качества и работоспособности своего продукта, при этом понимая, что заплатил за это не напрасно.
Кто-то может подметить, что понадобится время на написание и поддержку такого рода автоматизированных тестов. Затраты на написание конечно же включаются в оценки выполнения работ по разработке. А вот стоимость поддержки будет зависеть напрямую от уровня команды. Грамотно написанные тесты будут основаны на правильных инструментах и фреймворках, которые абстрагируют тестовую логику от деталей вашего продукта и дают возможность изменять что-то только при серьезных изменениях в продукте. И пусть себе требования на здоровье меняются, но скорее всего не вся функциональность перепиливается каждую неделю, особенно в большом проекте.
Не все легко покрыть автотестами. Но из моего опыта, люди зачастую просто не знают, не хотят или не умеют этого делать. Для веб проектов есть Selenium, для совершенно произвольных есть Sikuli. А еще уйма специализированных инструментов. Можно замечательно с помощью Selenium тестировать UI (расположение элементов, верстку, отработку JavaScript). Советую посмотреть мое выступление на одной из конференций по поводу подобного тестирования. В разделе материалов можно найти больше на эту тему. Если не получается протестировать через конечный пользовательский UI, то можно тестировать API бизнес логики. Это все равно будет лучше чем ничего. Тогда ручное тестирование может быть сосредоточено больше на тестировании UI слоя.
Есть еще одно преимущество от наличия таких тестов – возможность делать рефакторинг. Рефакторинг — последовательность изменений, которая изменяет внутреннюю структуру программы без изменения ее внешнего поведения. При рефакторинге тесты не меняются. Более того, без них невозможно убедиться, что внешнее поведение не изменилось, а значит называть это рефакторингом.
Эти же тесты придут вам на помощь и на этапе сопровождения. На этом этапе часто меняется только часть функциональности, а остальная должна продолжать работать стабильно. И вот тогда польза от приемочных тестов колоссальная. Мало того, по ним можно понять как должна была работать та или иная часть приложения. Потому что доменные знания теряются за документами, в которых устаревают практически моментально.
Задумайтесь, стоит ли продолжать обманывать своего заказчика. Или лучше работать так, чтобы можно было гордиться результатами своего труда, при этом убирая максимум скучной ручной работы и оставляя только интересную творческую составляющую? Если вы выбираете второй подход, то вам нужно обеспечить прозрачность и расписать все плюсы и минусы на самом раннем этапе. На более поздних этапах вводить описанное в статье тестирование может быть гораздо труднее и затратнее.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Я решил собрать несколько признаков, которые могут подсказать, что с тестированием (или с процессом разработки целиком) на вашем проекте что-то не так:
Этот список можно и нужно продолжать долго. Я на этом остановлюсь и дам слово вам. Какие пункты вы бы добавили? Какие удалили?
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
И снова выпуск “полезного чтива”. Накопилось достаточно много интересного:
А вот список интересного видео для просмотра:
Читайте и набирайтесь новых знаний!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Меня давно волнует один и тот же вопрос: почему для многих слово тестировщик ассоциируется с временной профессией или той, где можно просто хорошо заработать и при этом знать минимум?
Изначально я был уверен, что это зависит не от самого человека, а от окружения, в котором он работает. Но спустя время я понял еще одну причину. Проблема не в том, что процесс поставлен не должным образом, а в том, что профессия тестировщика недооценивается. У многих людей бытует мнение, что тестирование – это обезьяний труд и научить быть тестировщиком можно каждого. Лично я с этим не согласен. Ведь аналогично можно сказать о программировании, бизнес анализе, менеджменте и любой другой профессии. Все зависит от того, насколько качественно этот труд будет выполняться.
Требования к хорошему тестировщику достаточно высоки. Он должен быть осознанным в технологиях как программист, уметь структурировать документацию как бизнес аналитик и еще при всем этом быть экспертом в тестировании ПО. Если вы еще считаете, что это очень легко, то посмотрите весь цикл видео материалов от Cem Kaner. Я сейчас не говорю об автоматизации или тест менеджменте, я говорю о тестировании как о непрерывном исследовании продукта для поиска несоответствий, потенциальных улучшений и уязвимостей.
Умные менеджеры решили защитить свои проекты от так называемых “monkey-тестировщиков”, изменив название позиции на гордое «Инженер по обеспечению качества» (QA Engineer). Нельзя сказать, что намерения были плохими. Наверное, это было сделано с целью хоть каким-то образом мотивировать тестировщиков на развитие и поднятие их авторитета в глазах программистов. Правда, одно понимание было упущено. Обеспечение качества – это не работа отдельно взятых людей, это обязанности всей команды, к тому же не только разработчиков и тестировщиков.
Чтобы быть хорошим тестировщиком нужно отвечать за свои решения. Помните, мы в ответе за то, что протестировали! И нужно принимать это. Хватит скрываться за тест планами и тест кейсами, оправдываясь, что такого сценария не было в твоем списке. Если ты специалист, то проведи анализ, выбери подходящую технику, выполни тестовую сессию, расскажи о результатах и проблемах, которые волнуют или остались не протестированы. Сделай так, чтобы другие видели результат твоей работы. Сделай так, чтобы ты был ценным игроком в команде. Экспериментируй с минимально-необходимой документацией для того, чтобы спланировать тестирование и предоставить отчетность. Прочти, осознай и примени Heuristic Test Strategy Model, Exploratory Testing и Session Based Test Management. Вдумайся в основные пункты Agile манифеста, прочти еще раз постулаты Context Driven School, повтори Craftsmanship манифест.
Работа тестировщика требует активной позиции. Чтобы быть профессионалом, нужно постоянно находиться в движении, непрерывно развиваться и всегда уметь задавать неудобные вопросы. Лишь свободный человек может обладать всеми этими качествами. Когда у вас есть эта свобода, вы сможете максимально спроецировать свои навыки и умения на решение поставленной проблемы в нужном направлении, чтобы принести максимальную пользу проекту! Речь идет не о менеджерах или тим лидах, а о тестировщиках. О тех специалистах, которые: анализируют, тестируют, находят проблемы, генерируют идеи, обучаются продукту и умеют фокусироваться над решаемой задачей отведенный для этого промежуток времени.
Гордитесь и любите свою профессию – будьте настоящим тестировщиком!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
