Беседа с Дмитрием Кальметьевым про QA и тестирование

Михаил: Всем привет! Это тридцать второй подкаст «Откровенно про IT карьеризм». С вами Ольга Давыдова…
Ольга: … и Михаил Марченко.
Михаил: У нас сегодня немного затянулось начало выпуска, поэтому все слегка уставшие. В гостях сегодня Дмитрий Кальметьев. Дмитрий, ты можешь поздороваться со слушателями.
Дмитрий: Здравствуйте, слушатели!
Михаил: Так же известный как Чайник. Дим, прикинь, тебя сейчас… ты дважды особенный у нас. Во-первых, ты первый QA. Вот за тридцать два выпуска – первый. Как? Чувствуешь первую брачную ночь? Это раз. А во-вторых ты тридцать второй, то есть степень двойки. Это значит уже по-любому особый выпуск. Так что, ты вообще в респектах.
Дмитрий: Я постараюсь не ударить лицом в грязь.
Ольга: Можно грязью в лицо.
Михаил: Тоже лучше не надо. Ну опять же этот выпуск… у нас сейчас такая небольшая серия, когда основной ведущий скорее Оля у нас в ходе диалога, поэтому, Оля, тебе первое слово.
Ольга: Да, это было неожиданно, но хорошо. Дим, давай буду банальной: расскажи о себе. Вот так как тебе хочется.
Дмитрий: Ну… я в IT примерно 5 лет с небольшим. Начинал как программист баз данных, но довольно быстро перебежал в тестирование, устроился в компанию Validio, которая потом стала Global Logic’ом. И там в течении двух лет работал на одном большом интересном проекте, постепенно выростая от Junior тестировщика до Senior’а. Ну я, конечно, сейчас понимаю, что Senior через два с небольшим года довольно смешно звучит, но…
Ольга: Senior в 28 лет…
Дмитрий: Вот… потом я перешел в компанию TeamDev, и там-то, в общем, началось самое интересное, потому что на проект на который я туда пришел… это был проект начинавшийся с нуля, то есть не поддержка какого-то проекта, а разработка нового интересного, и я там был довольно долго единственным тестировщиком. Ну и так в общем исторически сложилось, что систему Quality Assurance организовывал я. Хотя тогда я в общем я, пожалуй, не тянул даже на Senior’а, как я сейчас понимаю, и уж тем более ни на какого Lead’а, но так получилось, было много всего интересного… ну и в общем я то время считаю самым, наверное, знаковым в формировании себя как тестировщика и немножко как бизнес аналитика, потому что я много работал с требованиями, мы собеседовали много людей, организовывали работу как нам хотелось, в общем – было интересно.
Михаил: Смотри, ты сказал, что начал ты как разработчик баз данных. Что тебя из разработки перевело в тестеры?
Дмитрий: Ну на самом деле так получилось практически случайно. То есть была довольно своеобразная вакансия, которая требовала знаний баз данных, но по сути была вакансией тестировщика. Поскольку базы данных я знал, а тестировать меня обещали научить – ну и тьфу-тьфу-тьфу, научили.
Михаил: Слушай, кстати да, вот к тебе такой вопрос. Мы его не задали почему-то, но ты сказал, что ты 5 лет в IT. А что тебя туда привело? То есть ты ж не проснулся 5 лет назад: «О! Я в IT!»
Дмитрий: Сложно вспоминать студенческие годы – много тогда было всего разного. Наверное, мне было просто интересно. То есть у меня папа работал программистом, у меня с детства был компьютер, начиная со старенького 386-ого ноутбука с черно-белым экраном и весом в 5 килограмм… да это была страшная машина. Ну потом так как я так или иначе сталкивался с компьютерами, и мне всё это было интересно – в детстве игрушки, понятное дело, пото какие-то там... Интернет, графические редакторы. Потом я учился в 174-ом лицее «Профессионал» на компьютерном отделении, ну и там соответственно уже сложилась определенная тусовка тех, кому программирование и всё с этим связанное было интересно.
Михаил: Ты сказал были игрушки в детстве. Я вот помню как я хотел в детстве быть тестером хотя бы, то есть к игрушкам поближе и типа и работа, и вообще супер… Возникает отсюда вопрос, хотя, наверное немножко странно, что он отсюда возникает: как ты думаешь, почему считается, что профессия тестировщика менее престижна, чем профессия программиста? Потому что я таки стал программистом.
Дмитрий: Ну, на самом деле причин много. Если так немножко обобщить, то я совершенно согласен, что у тестировщиков гораздо более халявная работа. То есть начнем с того, что у тестировщиков меньше необходимость в каких-то технических знаниях. То есть надо там меньше гнаться за поездом технологий, чтоб не отставать от всех новинок. Надо гораздо меньше беспокоится о том на какой технологии разрабатывается проект, на который ты хочешь устроится, например. Вот… Ну соответственно просто меньше порог входа, то есть проще попасть а IT. Но с другой стороны за меньшее количество технических знаний, как правило, тестировщикам в самом вначале и меньше платят. При этом многие считают тестировщиков такой второстепенной профессией. С одной стороны, нельзя не согласиться. Действительно, если developer’ов не будет, то тестировщики особо никому не понадобятся. Но мне сразу приходит на ум аналогия. В изданиях, журналах, газетах есть редакторы. Они такие странные люди, то есть, казалось бы, без аторов редактор тоже никому не нужен. Тем не менее там главный редактор журнала, да и просто редактор в журнале – это такая уважаемая профессия. Они там определяют политику, задают тон… выбирают авторов. К IT эта аналогия вряд ли применима… В принципе, в некотором смысле, халява в том, что, на мой взглад, тестировщикам проще проще пробиться в менеджеры. Но тут нюанс: это как бы уже касается не всех, то есть это уже нужны какие-то специальные знания и некоторые особенные навыки.
Михаил: … Некая ловкость рук.
Дмитрий: Например.
Ольга: А скажи, тестировщиком может быть любой?
Дмитрий: Ну конечно нет. Ни в какой профессии любой не может быть без подготовки…
Ольга: Ну ты вот сказал «никаких особых технических знаний»
Ольга и Михаил: А что надо?
Дмитрий: Есть базовый пакет, то есть те простые всем понятные вещи без которых в тестировщики и, в некотором смысле, вообще в IT приходить бессмысленно. То есть нужно уметь пользоваться компьютером на каком-то уровне, нужно знать английский… Ну и если мы уже говорим про тестировщиков. То нужно хотя бы поначалу обладать каким-то минимальным пакетом знаний: общая теория тестирования, зачем это всё нужно и так далее… Дальше начинаются знания и навыки, из-за которых, собственно, на мой взгляд, тестирование, то есть профессия тестировщика, гораздо сложнее и не такая халявная как кажется со стороны, по-началу. Очень много мелких нюансов, очень много каких-то вещей, которые, ну например, тяжело проверить на собеседовании, или вещей, которые плохо формализируются. То есть, например, казалось бы, такая простая штука как понимание того, зачем нужно тестирование… В общем, я много достаточно людей собеседовал, и у огромного числа кандидатов это вызывает неожиданные сложности. Потому что, есть типичный традиционный ответ: «Тестирование нужно для того, чтобы софт был без багов, чтобы софт был качественный, и так далее…» Ну обычный контраргумент: тестировщик не может сделать так, чтобы софт был без багов. Ну потому, что баги он не фиксит. Ну в общем после этого обычно идет разговор о всяких философских материях. Мне кажется, что правильный ответ на такой вопрос: «Цель тестирования – это предоставлять информацию о качестве приложения». В разных книжках этот ответ считается одним из традиционных классических. То есть задача тестировщика сказать правильным людям, которым это нужно, и которые обладают правом принимать решения: «Вот у этого приложения уровень качества такой-то такой-то». А вот что дальше будет, это уже как пойдет, потому что бывают ситуации, когда (пример, который я всегда использую на собеседованиях), если нам действительно быстро нужно выпустить софт, то иногда бывает второстепенно, что он низкого качества. Нужно забить нишу на рынке, обыграть конкурентов, забрать на себя wow-эффект, а там баги потом уже пофиксить, тем более пользователям их сможет найти гораздо эффективнее. Кстати, тот факт, что задача тестирования не сделать софт без багов, а предоставить информацию о качестве, она объясняет, почему нельзя обойтись без тестировщиков, взяв просто очень умных классных девелоперов, дав много времени и они всё классно напишут так, что багов не будет. Они-то может и напишут, но пока никто этого не проверит нельзя утверждать, что багов не будет.
Михаил:Слушай, у меня к тебе вопрос, из твоего монолога. Сейчас по сути выделилась отдельная каста, отдельный вид тестировщиков – автоматизаторы. Вот те люди, которые описывают… своего рода они пишут код, скрипты, которые применяются как раз по рабочему продукту для автоматизированного… Слушай, по-моему, лучше будет если ты расскажешь, что такое автоматическое тестированее.
Ольга: На мой взгляд это уже больше похоже на программирование.
Михаил: Да, мне интересно твоё мнение по этому поводу. Насколько это идет на скрещение с программированием и какие там другие качества должны быть?
Дмитрий: Тестировщики, которые занимаются на фул-тайм автоматизацией, это очень интересные люди. С одной стороны, там уже нужно большое количество технических навыков. Это всё равно не те навыки, которые нужны такому настоящему матерому девелоперу, но технические навыки требуются в гораздо, конечно, большем объеме, чем рядовому тестировщику, который с автоматизацией сталкивается мало или поверхностно. Вместе с тем, это один из тех пунктов, по
которому тестировщики от девелоперов отличаются, и по которому нужно оценивать такого настоящего хорошего тестировщика. В любом случае, там нужен другой подход.
Михаил: В чем же другой подход?
Дмитрий: Задача программировать, задача… я очень не люблю первое, что мне приходит в голову, но я очень не люблю такую формулировку, когда тестировщику говорят: «Думай, как сломать». Она слегка упрощенно описывает тип мышления, который нужен для того, чтобы хорошо писать тесты. Условно говоря, сломать очень многие вещи очень просто: если выбросить телевизор из окна, то он сломается, поэтому это не совсем правильная формулировка. Тем не менее, нужен критический склад ума, то есть нужно подходить к программному продукту с другой стороны. Если девелопер старается сделать хорошо, он творец, он что-то производит - грубо говоря, код это его ребенок, в некотором смысле, - то тестировщик – это такой человек, который пытается (немножко сейчас грубо прозвучит, но…) пытается найти пункты, по которым этот ребенок неудачен: где-то не успевает, что-то не может, в общем – почему ребенок плохой. Это такой достаточно сложный подход с психологической точки зрения, когда ты идешь потом и объясняешь девелоперу, что ты тут старался-старался, а получилось плохо.
Михаил: Я помню такие случаи в своей практике.
Дмитрий: Это, кстати, тоже одно из важных качеств для тестировщика. Если сказать слишком резко, слишком грубо, слишком категорично, то человек просто обижается, потому что он-то на самом деле старался сделать всё как лучше.
Михаил: Скорее всего.
Дмитрий: Скорее всего. Да, я согласен, если иногда по результату явно видно, что человек не старался, то тогда правильно в воспитательных целях прийти и пристыдить, сказать что «ты – нехороший человек, не делай такого больше». Возвращаясь к автоматизации, я, честно говоря, не знаю как, с каким подходом, с каким отношением к продукту девелоперы пишут unit-тесты, если их пишут девелоперы. Но тестировщику для написания автоматизированных тестов всё равно нужен вот этот критический склад ума, постоянное задавание вопросов почему, попытки найти какие-то неожиданные сценарии и, вместе с тем, скурпулёзность, позволяющая проверить всё от и до, не оставить там пробелов.
Михаил: Дима, а кто по-твоему должен писать unit-тесты, если не сами программисты, именно unit?
Дмитрий: Ну я знаю проекты, на которых их пишут тестировщики. Это, как правило, те люди, которые занимаются white box тестированием, и так далее, и так далее.
Михаил: Ну вот это отдельная, конечно, тема, unit тестирование, когда с white box’ом, конечно, интересная идея, но по сути самая основная из простых идей unit тестирования – это чтобы быть уверенным, что… вот человек писал этот код с таким-то алгоритмом, этот алгоритм до сих пор работает. Хотя бы вот так. То есть якась (простите, у меня математика в школе была на украинском языке, поэтому для меня) «необхидна та достатня умова».
Дмитрий: Тут позволь тебя поправить, она конечно необходимая, но…
Михаил: Не «достатня»…
Дмитрий: Не достаточная ни к коем разе.
Михаил: Это вот какая-то «необхидна умова», чтоб программист был уверен и спокоен, что после всех изменений вот эта бизнес логика, она работает вот так-то, именно просто бизнес, unit, я на сколько вижу и понимаю для себя, unit тестирование ориентировано на проверку заложенных алгоритмов, скажем так.
Дмитрий: Ну смотри, по классическому определению, unit тестирование на то и unit, что оно проверяет – удивительно, но unit! То есть оно проверяет какой-то маленький модуль на работоспособность.
Михаил: Один алгоритмик. Или кусочек его.
Дмитрий: Да, кусочек алгоритма может быть. В принципе, по классическому определению, никто не заставляет – поправь меня, если я не прав – но то что ты говорил, ты описывал использование unit-тестов, как тестов для test junior developer. То есть из определения unit-теста не следует, что ты должен использовать unit-тест в качестве test junior developer.
Михаил: Я согласен с этим. Я просто не большой любитель тест дривен девелопмента. Поэтому мне немножко странно, что мои слова сравнивают с ним. Оля совсем заскучала от всех этих технических подробностей. Уже почти засыпаем, поэтому вернемся дальше к теме. Тебе доводилось собеседовать тестировщиков-автоматизаторов?
Дмитрий: Мало.
Михаил: И на что ты пытался в этом «мало» обратить внимание?
Дмитрий: В основном, как правило, техническую составляющую проверяли другие. Я сам с автоматизацией сталкивался, но я не опытный зубастый автоматизатор. В общем, в технике у меня есть некоторые пробелы. Я в основном у автоматизаторов интересуюсь вопросами построение структуры автоматических тестов, их архитектуры, в каком-то смысле. То есть есть набор классических граблей, на которые все наступают при автоматизации, мы на разных проектах на них наступали также. Довольно сложно обеспечить, с одной стороны, независимость тестов, с другой стороны, быстроту их прохождения и не прохождения функциональности некоторых участков несколько раз. То есть, классический простой пример: у меня есть функциональность, которая позволяет создавать и редактировать пользователя. Если я напишу первый тест, который создает пользователя, а потом постараюсь написать второй тест, который пользователя редактирует, то у меня встает вопрос: какого именно пользователя, какую сущность в системе мне редактировать? Если я испоьзую того пользоателя, который был создан первым тестом, то я этим самым завязываю один тест на второй. То есть если первый пользователь не будет создан, то редактировать будет нечего. А если я для теста, редактирующего пользователя, напишу еще раз код, который специально для этого теста создает пользователя, то я тем самым два раза, во-первых, прохожу один и тот же кусок, что удлинняет весь процесс прогона тестов, ну а во-вторых, это всё равно меня не застрахует, если там какая-то серьёзная ошибка, то есть у меня не просто в первом тесте свалился asset и из-за этого пользователь не создался, а у меня в первом тесте ну действительно не создается пользователь, потому что функционал не работает, то второй тест проверить редактирование тоже не сможет. Ну и дальше есть несколько вариантов ответов: вариант создавать тестовые данные предварительно, вариант прямо в тесте напрямую обращаться к функционалу (к API, в базу данных). В общем, всякие вот такие фокусы, связанные с построением тестов мне всегда очень интересно послушать.
Михаил: Понятно. Мы, кстати, как-то ушли от ответа на предыдущий вопрос. Всё-таки, насколько близок тестировщик-автоматизатор от тестировщика к программисту? Он где-то посередине или это уже другая совсем стезя?
Ольга: Он тестировщик, программист или это что-то уже вообще что-то…?
Дмитрий: Родила царица в ночь не то сына, не то дочь. Я сказал бы что – как я вижу идеального автоматизатора – он всё-таки тестировщик. То есть, он обладает гораздо большим набором технических навыков, он способен, в принципе, читать код, чужой в том числе. Мне кажется, для хорошей автоматизации это нужно, особенно, если мы проводим автоматизацию тестирование не через интерфейс (a-la Selenium и так далее), а если наша автоматизация это тест, работающий с back end’ом, какими-то функциями. То есть, это не unit-тест, касающийся больше чм одного модуля, но всё равно тесты взаимодействующие с API, с веб сервисами, и так далее. Но при этом, поскольку этот человек должен, в первую очередь, мыслить, чтобы написать хорошие тесты, должен мыслить правильным образом, должен быть подход тестировщика. Он должен заботится о том, чтобы его тесты сообщали нужную информацию о качестве приложения. Снова-таки, у меня есть знакомые, которые сталкивались – не они писали эти тесты - сталкивались с тестами, которые проходили не смотря на то, работало ли прилжение: хороший способ плохо делать свою работу.
Михаил: Немножко вспоминается песенка львовских ребят-тестировщиков, что «немаэ quality»… Не видел?
Дмитрий: Нет, не знаком.
Михаил: Я добавлю ссылочку, наверное, к описанию этого подкаста. Очень-очень советую посмотреть. Когда РМ говорит QA’ю, что ты там глубоко не лезь, там куча проблем, но эстимейты уже так горят, что… Как-то так.
Ольга: Дима, вот ты говорил и всё время повторяешь фразу о том, что задача тестирования – это предоставление информации о качестве приложения и всё. И получается, что на этом ответственность тестировщика заканивается. То есть информацию предоставил и, как ей воспользовались, в общем-то не важно. Я почему спрашиваю: на мой взгляд, если эта информация не получила продолжения, например, ее не приняли во внимание, то человек демотивирован - результа-то труда нет. Информация сама по себе не может рассматриваться как результат труда.
Дмитрий: Ну почему, может. Демотивация это, конечно, отдельная тема для разговора. Сейчас я к ней вернусь. Во-первых, я не говорил, что предоставление информации – это единственная цель тестирования. Это основная, безусловно, и ее нужно в первую очередь держать в голове. Вместе с тем, иногда бывают ситуации, когда задача тестирования – просто вполнить определенные действия. Для примера: мы предоставили информацию о том, что в этом продукте есть какие-то проблемы. Информация была принята к сведению. Проблемы нужно исправить. После этого нужно перепроверить, что исправление проблемы ничего не поломало: регрессионное тестирование, классическое. В принципе, это, конечно, тоже предоставление информации, заново о качестве продукта, но это в многом просто работа, призванная помочь девелоперу, что всё хорошо. То есть, когда я выполняю регрессионный тест конкретного кусочка, я не решаю задачу предоставления информации обо всем приложении, я помагаю девелоперу сделать фикс хорошо. По-поводу демотивации и по-поводу того, что с информацией делают дальше. Да, к сожалению, так бывает. То есть, клиенты никогда не хотят, за редким исключением, иметь софт с нулевым количеством багов. Поэтому с этим приходится жить. То есть, ты сообщаешь информацию о том, что есть проблемы такие, такие и такие. Верхушку из 10-и, 15-и, 20-и, как повезет, процентов из этих проблем назначают на фикс, их планируется убрать, а остальные проблемы остаются. Конечно работать с приожением, в котором количество багов держится уровня нуля – легко и приятно. Но не то чтобы это совсем сказки, мне рассказывали, что такие приложения всё-таки бывают. Но я в реальной жизни не встречался и, в общем, знаю мало людей, которые с такими приложениями встречались. В основном всё-таки – это, кстати, тоже одно из необходимых качеств тестировщика – приходится работать в условиях, когда в приложении есть баги, когда качество никогда не идеально. Тут очень важно следить, чтобы не замыливался взгляд, потому что, наверняка знаете, есть такая теория «разбитых окон». То есть, если в здании разбито окно, и стекло не заменили в течении некоторого времени, то в здании очень быстро разобъются все остальные окна. На проекте с большим количеством багов это очень серьёзно мешает тестировщикам. Я испытывал это на себе, когда, поработав полгода на проекте, на котором порядка тысячи открытых багов постоянно поддерживается, ты начинаешь у себя в голове постепенно по-другому относится к качеству этого продукта. То есть, к тебе приходит, например, новичок-тестировщик и говорит: «А вот я там нашел, если проскроллировать такую-то страничку, там лэйоут плывет». А ты думаешь: «Господи! У нас пароли в базе хранятся незакэшированные. Какой лэйау?!» И это уже полгода никто не может пофиксить. Соответственно, нельзя сказать, что вот это вот замыливание глаз – это хороший ход.Всё равно, проблема с лэйаутом – это проблема с лэйаутом, ее нужно репортить, ей нужно давать правильный приоритет, а дальше посмотрим. Но проблема такая есть и с этим приходится бороться. Тогда люди демтивируются, конечно, но что делать…
Ольга: А нужна ли настойчивость для того, чтобы продвигать, заставлять исправлять или как-то влиять на решение? Может ли тестировщик вообще влиять на приложение, на качество приложения?
Дмитрий: Рядовой тестировщик – не всегда. Это зависит от того, как организован проект, насколько тот вот человек, который отвечает за фактическое пинятие решения о том, что мы будем фиксить, а что нет, насколько он это решение делегирует тестировщику. Бывают проекты, где тестировщики имеют право завернуть релиз-кандидат, потому что в нем слишком много багов. Бывают случаи, когда тестировщики могут только предоставлять факты, а дальше клиент, менеджер, кто-нибудь единолично принимает решение, и тестировщикам остается только разводить руками. Ну они как бы могут попытаться его уговорить, но… с тем же успехом можно попобовать уговориь директора поднять тебе зарплату. Вроде бы надо всё время делать…
Михаил: Дим, наверное, здесь есть ответ на вопрос, который ты вначале так или иначе говорил: пчему-то из тестировщиков часто получаются менеджеры. Если человек смог пробегать и попробивать кучу вещей из рядового , наверное, это и есть те качества, которые нужны менеджеру.
Дмитрий: Да, это как раз тот пункт, о котором я собирался сказать. Помимо тестирования, есть еще такие слова как quality control, quality assurance. Это три слова из классической теории тестирования. Я для себя их понимаю как… Для меня quality control – это задачи, связанные не только с качеством продукта, но и с качеством проекта. Грубо говоря, сделать так, чтобы проект был хороший и на нем людям работалось хорошо, зарабатывали деньги лучше и так далее, и так далее. Quality assurance – это вообще круто, это делает все тоже самое, но еще предсказывает заранее. То есть не исправляя проблемы, которые уже есть, а помогает построить заранее всё так, чтобы проблемы и сложности не возникали. И тут, конечно, если есть возможность, если есть authority заниматься реальным quality assurance, quality control, если тестировщик видит и может доказать тот факт, что исправление большего количества багов в итоге сделает лучше всем, принесет клиенту больше денег каким-то образом, в конечном итоге, позволит людям не работать в overtime и комфортнее себя чувствовать, и так далее, и так далее, то это, конечно, высший пилотаж. То есть, убедить клиента и влиять на уровень качества, достаточный для клиента – это круто. Хорошо, когда такое получается. На самом деле ведь есть уровень качества, нужный клиенту, чтоб он деньги зарабатывал, а есть то, о чем Оля говорила – это демотивация команды. То есть, никто не любит работать на проектах, которые глючат.
Михаил: Слушай, а давай вот к тебе вопрос. Он как-то всё время проскальзывал рядом: а какие качества хорошего тестировщика?
Ольга: Ну вообще необходимые качества. Из кого вообще может выйти тестировщик? Хороший, понятное дело.
Дмитрий: Ну, мы с этого уже начинали.
Михаил: Мы вот рядом как-то касались этого. Дим, вот резюмируя все, что ты сказал уже: какие качества отличают хорошего тестировщика от… просто от?
Дмитрий: Помимо банальных, с которых мы начинали, навыков работы с компьютером, английского и минимального понимания того, зачем нужно тестирование, хороший тестировщик, конечно, должен хорошо знать теорию тестирования и уметь применять ее на практике. То есть, это банально звучит, но можно переформулировать так: тестировщик всегда должен понимать зачем он делает то, что делает. Очень многие люди работают в рамках каких-то устоявшихся процессов без реального понимания, зачем это нужно и что это приносит для проекта, для качества. Нужно обладать критическим складом ума (то что я пытался описать. Сложно формулировать, я не психолог), навыками общения, потому что тестировщик – это тот человек, который приносит дурные вести очень часто, уметь работать под давлением, когда сроки поджимают, багов много, и при этом сопротивляться этому замыливанию взгляда, которое приводит к тому, что у людей опускаются руки: «всё равно багов много – чего там…»
Ольга: А перфекционизм нужен тестировщику? Полезен или скорее во вред?
Дмитрий: Он должен быть контролируемым. Нужно иногда включать у себя состояние «я хочу чтобы всё было очень хорошо»и пытаться этого добиватьтся, бороться за это. Но поскольку реалии жизни таковы, что тестированием всегда жертвуют…
Михаил: Почему им жертвуют?
Ольга: Ну уже ведь говорили об этом.
Михаил: Да, помню… все эстимэйты горят…
Ольга: Ну конечно.
Дмитрий: Так вот. Поскольку тестированием всегда жертвуют, то люди, которые во всем стремятся к перфекционизму и активно за это воюют, они перегорают. Нужно поимать, что идеал – к ему всегда нужно стремиться, но он никогда не достижим.
Михаил: Хорошо, давай пойдем тогда дальше. Я тебя знаю, как минимум раньше знал, как сторонника agile подходов. Насколько помню и знаю, ты ведешь блог про agile-методологии, или вел одно время. У тебя была фишка у блога, что меня удивила, несмотря на то, что я много вещей веду, но у меня реально никогда, наверное, не получится так делать, но ты вел его и на русском и на английском одновременно. Это реально круто. Что тебя к agile так притянуло?
Дмитрий: Agile мне давно нравится. И работаю я, в общем так сложилась, что и работал я всегда по agile. Мне очень нравится, мне очень удобно, что agile – это настраиваемая методика, и что в agile, как правило, обычно очень мало лишнего. То есть даже классический менеджмент можно превратить в настраиваемый инструмент, и инструмент будет реагировать на изменения довольно быстро, но там всегда это сопровождается, как правило какими-то тяжеловесными процедурами, и требуется очень стараться, чтобы не отказаться и не сделать их какими-то более удобными. Agile подходит с другой стороны. Все начинается с четырех всем известных базовых принципов Agile-манифеса, дальше разные ребята надстраивают свои какие-то соображения (SCRUM, и так далее), при чем эти ребята в общем, как правило, не утверждают тот факт, что то, как получилось у них работать по таким принципам, гарантирует, что получится у кого-то другого. Это приводит к тому, что людям приходится задумываться над тем, как организовать их работу, отсутствие сложных процессов, возможность всё часто менять, менять подходы, позволять сделать удобно. Плюс, что мне нравится, как правило, чем больше человек вовлечен в проект, тем больше влияния у него есть на процесс, в частности, благодаря agile и retrospective meetings. То есть, если человеку всё равно, он там сидит помалкивает, но постепенно, те, кому не всё равно, они делают удобно под себя, и это правильно. Что касается блога, это был своеобразные эксперимент по-поводу двух языков, ну и в общем, в последние несколько месяцев я не писал ничего нового, хотя накопилось несколько тем для постов, ну и в командировке, в достаточно длительном отпуске был, в разъездах, поэтому ничего не обновлялось. Не знаю, насколько два языка интересны читателям, в основном, делаю это для себя, потому что сформулировать одни и те же мысли на двух языках очень помогает, в общем-то, в изучении языка.
Михаил: Этих мыслей?
Дмитрий: Да, этих мыслей. Помогает сформулировать лаконично и не растекаться лишней болтавней.
Михал: Слушай, вот коль ты говорил о путешествиях и командировках, я немножко владею информацией, что ты недавно вернулся из Лаоса. Мне интересно твоё мнение. Я тебе, наверное, два вопроса задам сразу, а ты уже отвечай как тебе будет удобнее. Насколько в принципе полезны для тестировщиков командировки для общения с конечным заказчиком, ну и какой еще есть смысл командировок, можешь рассказать подробнее, у вас был, и у тебя лично. А второй: насколько путешествия помагают работе? То что ты посмотрел что-то больше, что-то другое, просто отдохнул, насколько влияет на работу. Хотя, наверное, путешествиям посвятим что-то другое.
Дмитрий: Ну я хочу ответить насчет Лаоса: это была не командировка на самом деле, слава Богу!
Михаил: А, Лаос еще не аутсорсит в Украину!
Дмитрий: Думаю, нет, и, боюсь, еще долго не будет. В принципе, командировки и общение с реальными людьми – это очень хорошая штука. Мне очень понравилась на прошлом Agile Eastern Europe, честно говоря, я не помню, кто из докладчиков, но кто-то из спикеров сказал что «you have to pay for face-to-face communication and it doesn’t matter if you use it». Ну то есть, в любом случае, за общение лицом к лицу придется заплатить, не зависимо от того, используется ли оно. Я был когда-то очень удивлен, поехав очередной раз в командировку для того, чьлбы ообщаться с заказчиком, то что я больше чем год до этого занимался формулированием требований, немножко для заказчика¸немножко от лица заказчика, такой себе странный бизнес анализ без общения с реальным клиентом, попытка угадать, что ему на самом деле надо. И мне казалось, что я понимаю, как сделать это приложение лучше. Были места, которые мне откровенно и сильно не нравились, где всё было, на мой взгляд, реализованно ужасно, непривычно для людей, и мне казалось, что это работать не будет никогда. В этой командировке мы общались с группой представителей заказчика, я рассказывал, как функционирует приложение, которое они хотели. Неожиданно для меня, в той части, где я рассказывал про один из сильно не нравящихся мне кусков, я пытался это как-то оень аккуратно сформулировать, потому что тема была сложная, всё запутано, неочевидно, и я аккуратненько начинаю рассказывать, ну а мне несколько человек говорят: «Ну а дальше вот ттак и вот так, и вот так, да?». И вот тут я понимаю, что – да! Общение с коиентом нужно в любом случае, потому что для них это поведение – естественное и очевидное. Год взаимодействия через skype, e-mail, различную документацию в разном виде, не привело к тому, что у меня не появилось такое же ощущение того, что хорошо, а что плохо. Не могу сказать, что после командировки оно у меня появилось, но по крайней мере, стало понятно, что существует гораздо больше, чем одно мнение, и те части, которые мне не нравятся, возможно не нравятся только мне, а кому-то другому это будет самое то. Вообще поездки полезны, потому что ты смотришь на другие культуры, ты понимаешь, как они устроены, это расширяет кругозор, безусловно. Тайланд, Лаос – страны с культурой сильно отличающейся от украинской и европейской. Но США тоже страна с культурой отличающейся от украинской, европейской очень сильно. Хотя мы пользуемся одним и тем же гуглом, работаем на одних и тех же ноутбуках. У людей в Тайланде, у них культура другаю, потому что у них уровень жизни другой, другие вещи их окружают. Пусть даже с Европой, С Америкой нас часто окружают одни и те же вещи, всё равно отношение в жизни, к бизнесу очень разное.
Михаил: Спасибо, Дим! Так незаметно пролетели уже больше 40-а минут нашего общения. Поэтому к тебе вопрос, который для меня стал классическим: какие движки ты посоветуешь почитать нашим слушателям? Как профессиональные, так непрофессионльные, любые, которые тебе кажутся прикольными, для тебя.
Дмитрий: Из профессиональных посоветую почитать rework – очень небольшая, но дающий сильный толчок книжка. Касается не столько IT, сколько бизнеса в целом, хотя написана айтишниками.
Михаил: Ну Стив Джобс и бИл Гейтс – они айтишники. Были, как минимум, когда-то.
Дмитрий: Сейчас бы я их назвал бизнесменами, на последнем этапе их карьеры к IT как такового отношения нет.
Михаил: Какая вторая?
Дмитрий: Для тех, кто не читал, я бы посоветовал «Agile, Project Management and SCRUM». Для студентов, для начинающих программистов… Там целая группа авторов, включая Майкла Коха.
Михаил: ОК, спасибо, Дим! Пожелай что-нибудь нашим слушателям. Кроме почитать эти книги.
Дмитрий: Интересной работы.
Михаил: ОК. Большое спасибо!