Инновации и инсайты в мире Java из первых уст. Новая конференция Java Fest — 21 марта >>
×Закрыть

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

32-й выпуск подкаста «Откровенно про IT карьеризм».

В программе:

  • QA Senior
  • Во’IT’и
  • Престиж тестировщиков и программистов
  • Что нужно, чтобы стать тестировщиком
  • Главная задача тестирования
  • Автоматизирование тестирование = программирование
  • Имеет ли тестировщик влияние
  • Хороший тестировщик
  • Чем хорош Agile
  • Командировки, путешествия


Выпуск записан при поддержке IT компании AltexSoft. Адрес компании в сети Интернет: www.altexsoft.com
AltexSoft — лучший выбор в карьере программиста.

Текстовая версия

Михаил: Всем привет! Это тридцать второй подкаст «Откровенно про 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». Для студентов, для начинающих программистов... Там целая группа авторов, включая Майкла Коха.

Михаил: ОК, спасибо, Дим! Пожелай что-нибудь нашим слушателям. Кроме почитать эти книги.

Дмитрий: Интересной работы.

Михаил: ОК. Большое спасибо!

LinkedIn

88 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Классный подкаст. Для меня, как для начинающего был полезен.

Значит не зря старались))

Цікава розмова, дякую.

Сам ролик про «кволіті» тут: www.youtube.com/...feature=mh_lolz

Гарний ролик, дякую :)

Якось пройшов повз мене ранiше.

Многие взгляды совпадают, но не все конечно ;)

Вообще — хорошее интерью, молодцы! :)

Одному мне слышится Сандерса голос :)

Маленькая остановка и поток мысли, остановка и дальше размышления... Не знам, закрываю глаза и слышу :)

изначально там были большие остановки, спасибо нашему звукачу Алексею

Всем привет. Можна ли тестировать веб приложение без браузера? Не обезательна Selenium. Консоль или што то иное для большего быстродействия. Как вариант можна запустить UI тесты на виртуальной машыне. Но ето неудобно... Спасибо :)

en.wikipedia.org/wiki/HtmlUnit

Браузер действитильна необезательна, при определенных ограничениях.

Судя по количеству коментов, выпуск месяца)))

«не через интерфейс, аля Selenium...»

Хороший сениор, который считает что Selenium это только «через интерфейс»... (p.s. сарказм)

Selenium, в любом своем проявлении — просто драйвер для управления браузером. Для того и был придуман.

И этим он хорош. Для автоматического тестирования web приложений вполне приличный инструмент.

А расскажете мне, что он еще умеет? Это не сарказм, я правда с радостью послушаю. Я так понимаю, можно работать с веб-сервисами с помощью post/get запросов? А что еще есть?

Я не претендую на звание специалиста по Селениуму — имплементацией автоматизированных тестов я занимался редко и недолго. Есть люди, которые разбираются в этом на порядок лучше меня.

А вот о чём я с интересом похоливарю поспорю, так это о том, почему это делает меня плохим синьором :)

ps. Как это еще никто из жителей DOU не прокомментировал, что, милостью наборщика текстовой версии, хэш пароля превратился в кэш :D

Отвечаю по порядку.
1. Вы вообще понимаете смысл фразы «не через интерфейс а-ля Selenium»? Или вы имеете ввиду Selenium IDE? Что значит «что он ещё умеет»? :) Вы шутите? Лучше скажите что он не умеет (на самом деле у Selenium-а есть проблемные места, но почти все решаются). Исходя из того, что я услышал, вы считаете обязанностью automation тестера киким-то образом тестировать приложение в обход UI (API и т.п. не в счет — это отдельный разговор). Т.е. тестить код? Т.е. выполнять работу программиста?
2. Если вы не занимались плотно автоматизацией, то этот рассказ (или как минимум часть, которая косается автоматизации) не несет никакой ценности (да, были обобщенные фразы, которые вписываются в картину, но не более).
3. Профессионал (читать как «сениор») не станет разглагольствовать о том, в чем не силен. О чем здесь спорить?
4. Текстовую версию я не читал, потому и не написал :)

P.S. перестал слушать после момента, который я упомянул. Возможно остальная часть достойна восхищений.

Ждем в студию матерого автоматизатора

Отвечу по пунктам:

1. Вы вообще понимаете смысл фразы «не через интерфейс а-ля Selenium»?

Вы вырвали цитату из контекста, и поэтому мы говорим о разных вещах. Полная цитата такова:

...он способен, в принципе, читать код, чужой в том числе. Мне кажется, для хорошей автоматизации это нужно, особенно, если мы проводим автоматизацию тестирования не через интерфейс (a-la Selenium и так далее), а если наша автоматизация — это тест, работающий с back end’ом, какими-то функциями

Здесь имелось ввиду не что «Селениум = какой-то интерфейс», а «автоматизация тестирования через интерфейс (пользовательский) с помощью, к примеру, Селениума».

Соответственно, мой вопрос к вашему комментарию был о том, как еще можно использовать Селениум, помимо работы через пользовательский интерфейс тестируемого приложения.

2. Если вы не занимались плотно автоматизацией, то этот рассказ (или как минимум часть, которая косается автоматизации) не несет никакой ценности

3. Профессионал (читать как «сениор») не станет разглагольствовать о том, в чем не силен.

Обижаете. :) Всё, что я говорил, касалось моего собственного опыта. В ответ на вопрос Миши я честно сказал, какое именно отношения я имею к автоматизации: мои технические знания далеки от идеала, зато я занимался общими вещами. Например, делал постановку задачи, собеседовал людей, проектировал с ними структуру сценариев и архитектуру реализации, и так далее. В общем, делал многое из того, что позволило написанным тестам быть не просто кодом в репозитории, а решать задачу оценки качества на проекте.

Да, в рамках этого проекта своими руками тестов я написал вряд ли больше трёх десятков — ну так и в подкасте я, вроде бы, никого не пытаюсь учить, как кликнуть с помощью Селениума по флешовой кнопке. Если вы готовы слушать о том, какие качества необходимы хорошему автоматизатору, только из уст человека, проработавшего не меньше 10 лет тестировщиком в Гугле, то это ваше право.

В общем, на счет «Селениум — интерфейс», действительно спорить не стоит. Прослушав часть рассказа я не совсем точно уловил мысль.

Но тем не менее, у вас есть 1 большое заблуждение по поводу предмета тестирования для automation тестера. Тестер (даже automation) тестит рабочее приложение, а не код. Даже в случае API тестится не код, а «пользовательский интерфейс». Исходя из этого следует, что Selenium — полноценный инструмент в руках automation тестера (речь о web-е).

Тестер (даже automation) ИНОГДА тестит рабочее приложение, а ИНОГДА и сам код :)

Если нет квалификации работать с кодом, тогда, конечно, остается тестировать только приложение.

Вы хотите сказать, что тестированием «белого ящика» занимаются тестеры? (сделал_глаза_как_у_собаки_с_аватарки)

Есть реальные примеры?

Вы под «тестер» подразумеваете обделенного знаниями работника низкой квалификации?

Вовсе нет. Сам работал тестером 4,5 года. С уважением отношусь к данной профессии.

Вы уходите от ответа.

Тестирование — это деятельность, а не должность.

Программист, который занимается ревью кода, занимается тестированием. Даже будучи программистом.

Тестировщик, которые занимается ревью кода, занимается тестированием. Даже будучи тестировщиком.

Если я понял правильно, вас удивляет, что «белый ящик» может быть доступен тестировщикам. Меня же это не удивляет. Если код доступен — его тоже можно тестировать, коли сумеешь.

PS Наверное, нам стоит прояснить, в чем смысл тестирования и зачем оно проводится, но мне кажется, что общение получится холиварным, а у меня к холиварам устойчивое отвращение. Спросите Ночь варфоломеевскую и Хиросиму, что они думают по поводу холиваров. Нагасаки тоже не промолчит :)

Может и должен — разные вещи. Тестировщик может и код писать, а программист может и кофе заварить, но смысл?

У меня много знакомых тестеров/программистов/ПМ-ов, но ни от кого я не слыхал чтобы тестировщики тестировали код. Доступ к коду может быть, но никто этим не занимается. На это попросту нет времени (это нереально дорого).

К примеру, есть приложение, написанное на Java. Писалось оно на протежении 9 лет. Исходный код весит около 400М. Вы представляете сколько времени надо тестировщику на то, чтобы осилить всё это? (я не усложняю спор тем, что код != примитивные методы, а ООП, паттерны, фреймворки).

Расскажите мне о смысле тестирования с вашей точки зрения. Но на сколько я понял, автор — ваш ученик. «Гарантировать качество продукта», вроде бы так он сказал. Я полностью согласен с этим. Но не пойму как это связано с «белым ящиком». Разве без этого никак нельзя гарантировать?

Именно, что

Может и должен — разные вещи.

И про «должен» вообще никто не говорит, кроме вас. Да есть случаи, когда тестировщик проверяет код. Вы об этом не слышали, но так бывает. Пример я привел выше.

Одновременно — не везде это возможно и оправдано.

Теперь вы уходите в область обсуждения того, насколько это дорого, эффективно и имеет смысл. Ответ такой же — бывает, что имеет смысл, а бывает, что не имеет.

Всё время вы мне приписываете то, чего я не говорил :) Тестирование не может «гарантировать качество продукта» и это не является целью тестирования. Так что жалко, что вы с этим согласны ;)

Ну и то, что я, оказывается, ученик Лёши — это радует, да. :)

Глянь Дим, сколько нового узнал о себе, а еще писаться не хотел сначала)))

Алексей, приходите в гости к нам в подкаст

Ы, оно нам надо? :)

Я IT карьеризмом не страдаю, про тестирование Дима уже всё сказал.

Так им страдать и не надо. Надо наслаждаться))))

Судя по коментам есть еще добавить что

тот пример — не показатель (это исключение из правил). Много таких приложений?

да, нашел в текстовой версии:

«Цель тестирования — это предоставлять информацию о качестве приложения

немного я перекрутил, но от этого связь с «белым ящиком» не прорисовывается.

Ответ такой же — бывает, что имеет смысл, а бывает, что не имеет.

Очень чёткий ответ. Спасибо. Сразу видно профессионала.

Вы передёргиваете. Вопрос был:

Alexander Kilinskiy:

Вы хотите сказать, что тестированием «белого ящика» занимаются тестеры?

Вам рассказали, что занимаются, с теорией и примером.

Теперь оказывается, что

тот пример — не показатель (это исключение из правил). Много таких приложений?

А сколько вам надо? А то я еще примеров приведу, и окажется, что они тоже исключение и ничего не доказывают.

Ответ такой же — бывает, что имеет смысл, а бывает, что не имеет.

Очень чёткий ответ. Спасибо. Сразу видно профессионала.

Переход на личности. Грубо.

На мой взгляд объяснения и пример должны были уже ответить на все вопросы.

За переход на личности — извините.
Я не люблю расплывчатые ответы. Не более не менее.
Спорить устал. Умываю руки.

Успехов вам.

1

Нет, не ученик. Это мне у него в некоторых областях есть чему поучиться :)

2

Кажется, вы подразумеваете под тестированием кода сугубо «код ревью», так? Посмотрите на это шире.

Быть тестировщиком не означает НЕ БЫТЬ программистом :) Основы — они для всех основы.

Я, тестировщик, могу при определенных ограничениях делать код-ревью. Уточню — если это нужно. Обычно — не нужно.

Я, тестировщик, могу просто посмотреть в код, и понять, как организован вызов какой-то функции, какие параметры она принимает, а на каких может загнуться. Если этой информации у меня нет в виде обычного текста-спецификации, и есть возможность глянуть в код — какие проблемы? :)

Возникло ощущение, что под тестированием «белого ящика» вы подразумеваете исключительно «код-ревью». Если да, то — нет, под этим подразумевается, что в ходе тестирования информацию можно добывать и посредством наблюдения за работающим приложением, и посредством чтения (или даже изменения) кода.

Белый ящик — код приложения доступен. Черный ящик — код приложения недоступен.

3

Смысл тестирования в том, чтобы получить информацию о состоянии продукта и предоставить добытую информацию тому, кто ее заказывал (или тому, кому она может быть важна).

Какая нужна информация?

Иногда нужна оценка состояния софта. Иногда нужно узнать, есть или нет багов. Иногда нужно узнать, работает ли софт в определенных условиях.

Получается, что добывать информацию можно разную. И разными способами. Поэтому и существует так много видов тестирования — одна только путаница между нагрузочным и стресс тестированием чего стоит; да и тестирование производительности перцу добавляет — все они используются для того, чтобы получать разную информацию.

Посему — тестировать может кто угодно, это всего лишь деятельность, а не должность или, упаси боже, состояние психики.

Разве что тестировщик — это такой дядя, который более других подготовлен и технически и психически к такой работе, и владеет чуть большими (нежели окружающие) средствами и способностями и возможностями эту информацию добывать.

Иногда тестировщик лезет своими грязными лапами в код :) Например, мне в ходе тестирования веб-магазинов ничего не стоит глянуть в код страницы, что и как там расписано для обработки данных в форме какой-нибудь. Иногда я смотрел и непосредственно в код приложения, который генерирует страницы для браузера, но в последнее время этим не занимаюсь — нет необходимости.

У меня много знакомых тестеров/программистов/ПМ-ов, но ни от кого я не слыхал чтобы тестировщики тестировали код.

Следовательно, и не должны? Это аргумент? :)

Уверен, что вы поймете: «У меня много знакомых женского пола, но я ни от кого не слыхал, чтобы мужчины насиловали женщин. Следовательно, жительницы Киева не должны бояться насилия?»

Так?

Есть приложение, написанное на Java. Исходный код весит около 400М. Вы представляете сколько времени надо тестировщику на то, чтобы осилить всё это?

А программисту сколько времени понадобится?

Всегда ли программисту нужно прожевать ВСЁ приложение, для того, чтобы с ним работать? У нас сейчас программисты работают с ОООООГРОМНЫМ приложением (e-commerce platform). Они не давятся этим слоном сразу, а жуют его по-кускам. Куда надо, туда и лезут.

Тестировщик, которому понадобится по каким-то причинам полезть в код приложения, сделает то же самое — полезет только туда, куда ему будет необходимо.

Нет, не ученик. Это мне у него в некоторых областях есть чему поучиться :)

Лёша, ты мне льстишь :)

ps. А «тестирование — это состояние психики» — это цитата дня :) Пусть ты и обратное имел ввиду, но идея хороша :) Предлагаю статью наваять с обоснованием к 1му апреля :)

Я в бизнес-аналитике так сильно не преуспел.

Допустим, в нехитрых приложениях тестер, знакомый с основами программирования, может вполне качественно вносить изменения с целью тестирования. Это косается каких-то не больших проектов (или проектов, написанных на не обьектно-ориентированных языках). В случае ООП, паттернов, фреймворков это уже должеен быть суровый тестер, который с легкостью будет лазить в код.

Я устал спорить :)

А мы спорили? о_О

Тестеры бывают всякие. Я знаю аж несколько «суровых» дядек, которые стали тестировщиками после того, как сделали карьеру в программировании. А кое-кто этим занимался попеременно, ибо задачу ставили себе не «программу написать», а «найти решение проблемы». Предположите и оцените их подходы к тестированию, масштабы возможностей и способности ревьюить код. Хочется встать и отсалютовать им по-пионерски.

PS ООП не поминайте в таком контексте, а то получается, что в случае если НЕ ООП, тогда суровости не надо; тут я начинаю ржать, а мне ржать ещё нельзя, я только что с обеда :) Это же не тайные знания, нынче все сразу с этого и начинают учиться программировать.

Ржите на здоровье :)

Я имел ввиду, что наличие абстракции в коде усложняет его восприятие. Что не так?

То, что его усложнение ничуть не означает «теперь ни фига не разобрать», или что «тут не каждый разберется, нужен особенный талант». Что сложного, особенно если наличествует абстрактное мышление и уже есть умение читать код не только на уровне содержимого одного файла с тестовым классом?

Оно, конечно, в какой-то момент задалбывает переключаться между файлами в поисках какого-то простого метода, который вовсе было не обязательно выносить в отдельный класс, но елы-палы, это нас не остановит...

Я когда-то работал с первоклассными программистам, которые смогли подхватить, поднять и успешно развить проект, код которого был прокомментирован латышскими <s>стрелками</s> программистами на их аборигенных наречиях. Даже на стену распечатали кусок кода с подобным комментарием :) После этого латыши взбунтовались, что кто-то где-то лучше них работает, завели интриги, и наш офис проекта лишили.

Я не над вами ржу, простите, если что. Но мне действительно нельзя, я же лопну. Уборщица разозлится.

Есть такая должность — SDET, Software Development Engineer in Test. Работают на ней обычно либо переквалифицированные программисты, либо тестировщики-автоматизаторы, которые переходят на новый уровень. Эта должность есть в Microsoft, думаю, и в других крупных продуктовых компаниях тоже, даже если называется по-другому.

Но согласитесь, что позволить такую роскошь могут единицы компаний.

Соглашусь. Я просто привел пример, когда тестировщики занимаются тестированием «белого ящика», который вы спрашивали. Ничего страшного здесь нет, нас просто извратил аутсорсинг с его пониманием, что такое тестировщик и для чего он нужен.

Привет, Саша :)

Кстати, расшифровывают это то как Software Development Engineer in Test, то как Software Design Engineer in Test.

По первой ссылке — набор вопросов на собеседовании в MS на эту должность.

Да, ты прав :) Привет

И еще. Я нигде не утверждал, что я считаю обязанностью automation-тестировщика тестировать в обход UI.
Тем не менее, такие задачи возможны и регулярно возникают — UI’я может вообще не быть. И если оставить в стороне API, то да, тестить код может являться задачей тестировщика. Это может быть как и код ривью, так и, например, необходимость разобраться с кодом, чтобы правильно разбить тестовые данные на классы эквивалентности.

Чтобы вы не считали, что этот пост не несет никакой ценности, потому что я в этом не силён, скажу, что описанные выше задачи были моей основной обязанностью в течение, примерно, полугода. Код был на T-SQL, если что.

Если нет UI, API, Web Services (SOAP, REST и т.д.) как пользователю работать с таким приложением? :)

Можете привести пример такого приложения?

Я не говорил, что API нет :) Это же вы его попросили оставить в стороне:

API и т.п. не в счет — это отдельный разговор

Понятное дело, что если программа не общается с внешним миром, то от неё нет толку. Речь здесь о том, что black box тестирование через интерфейс может оказаться совершенно недостаточным. Примеров этом можно придумать много, например, следующий:

Приложение — это хранимая процедура MSSQL, которая преобразует базу данных в 150+ таблиц в базу с уже другой структурой и, как следствие, несколько изменёнными данными. Исходных баз, понятное дело, множество. И все с данными — от тысяч, до миллионов строк. Пользователи такого приложения — администраторы серверов.

Весь интерфейс — это вызов процедуры и логи уровня работы с таблицами. Т.е. его не то, чтобы вообще совсем нет,... но автоматизированное тестирование через этот интерфейс не решает задачу выяснения качества — максимум, можно проверить, где упало. При этом стоит задача убедиться в том, что не произошло потерь данных.

Соответственно, тесту нужно лезть в базу и проверять данные — это вам как раз пример, чего Selenium не умеет. Причем, прежде чем понять, как проверять реальные данные, нужно потренироваться на тестовых. А чтобы нормально сделать тестовые, нужно разобраться со всем процессом — всеми структурами таблиц и кодом, их преобразующим.

Это не говоря уже о том, что в таких условиях и просто ривью кода процедуры много каких проблем позволяет найти.

нечаянно нажал «поддержать» :)

Ну, если для вас хранимая процедура == приложение... то да, код хранимой процедуры проанализировать можно.

P.S. чуть не забыл, «код ревью» тестировщиком — это нечто ))

Давайте обойдёмся без подначек, а? А то я тоже могу перейти в формат «Ну, если для вас ..., то....»

Да, для меня такая хранимая процедура — приложение. Она самодостаточна, выполняет определённые действия и решает чьи-то задачи. А перед этим её пишут, тестируют, запускают в продакшн. Ответьте мне, чем она по-вашему, не приложение?

чуть не забыл, «код ревью» тестировщиком — это нечто ))

Я рад, что вам нравится.

Нажмите «поддержан» — поддержка исчезнет.

chaynick молодцом!

Так выдерживать!

Если сам Лупан одобряет значит мы и правда подросли)))

“спiвпрацювальник по підготувальні тестувальників” — это на каком языке?

Неявно не украинский, не так ли?!

«з навчання» наверное будет лучше (посыпаю голову пеплом, что осмелился такое писать)

Нееее, нельзя, ведь шутка юмора исчезнет :)

Навчання, звичайно, лiтературно правильнiше.

Про мою должность в ДОУ-профиле.

Теперь про саппорт еще надо :)

Мы ж не против, найдем запишем

Если что, обращайтесь :)

Огромное спасибо за текстовую версию интервью!!!

Появился доброволец, если продолжим работать, то опубликуем благодарность и контакты

Миша, при всём уважении к добровольцу и при полном одобрении идеи текстовой версии, хочу всё-таки предложить набранный текст прогонять через спелл-чекер и давать на вычитку гостю подкаста :) А то и хэш в кэш превращается, и у книжек названия меняются... :)

Дим, у большинства моих гостей нет на это время. Ты поидее должен знать добровольца. Давай возьмем тебя на добровольных началах редактором

Нет, я не знаю, кто доброволец. Насчёт меня в качестве редактора — это не есть здраво. Следующий докладчик обмолвится о каком-нибудь «сегфолте» — а я его в «дефолт» превращу :)
Пусть каждый читает, что он наговорил — специфическую терминологию, названия и имена точно знает только он.

Если времени у человека нет совсем, пусть наборщик хоть сверяет с ним эти вещи.

поддержу!

спасибо и продолжайте добавлять текстовую версию.

Будем надееться у добровольца запал не упадет

Первый блин, конечно, комом: тавтологии, слова-паразиты, запинки :) Надо работать над собой и учиться говорить лучше.

И да, Agile Project Management with Scrum написал Ken Schwaber, конечно.

Интересно координаты гостя: блог и твиттер. Так можно продолжить общение если что.

Блог здесь: chaynick.blogspot.com

Твиттер забросил — не мой формат

ыы, 174 FTW!! алсо, пост проплачен? :)

какой именно пост? и кем проплачен? мне почему не занесли?

Ты лучше запиши подкаст с «Тех. поддержка / Support engineer» из Best Employer 2011: Vox Populi. Ото будет интересно послушать.

это не интересно слушать???

Ок . Хорошая идея

А то! Оплата была авансом, но бартером — они меня 4 года учили, а их за это упомянул в подкасте :)

Имел в виду ненавязчивую рекламу альтексофта внизу. :)

аааа

так она уже давно выпусков 10, наверное

Подписаться на комментарии