Месяц: Ноябрь 2014

3

Автор Опубликовано 3 комментария

Немного наболело мне за понятие Quality Assurance (оно же Qualitätssicherung (нем.), оно же обеспечение качества (рус.)) в области разработки ПО.

Очень жалко, что это название досталось нам по наследству, от промышленного производства, понимается многими айтишниками на автомате буквально и из-за этого делаются опасные и иногда даже вредные выводы.
Давайте вспомним, что же делали работники Quality Assurance в дософтварную эпоху. На начальном этапе наши "тестировщики" брали готовые (или промежуточные) детали и измеряли их например штангенциркулем или скажем весами, на предмет соответствия ожидаемым значениям. Конечно со временем деталей стало производиться много, и "тестировщики" задействовали математико-статистический аппарат - измеряли из миллиона "одинаковых" деталей 200 случайных и оценивали количество ошибок математическими методами. Так или иначе, долгое время тестировались объекты, которые можно было объективно измерить и сравнить результат с эталоном.

И вот к нам пришло ПО (программное обеспечение). Особенность ПО по сравнению с большинством продуктов производства из прошлого, что "ошибки измерения" в ПО не лежат на поверхности. Более того, они там спрятаны настолько хорошо, что на данные момент  не существует практических методов доказательства того, что в софте отсутствуют ошибки, доказать можно только их наличие. Про это писали многие современные гуру тестирования (Болтон, Бах и другие), самое раннее упоминание в литературе, что я нашел от http://en.wikiquote.org/wiki/Edsger_W._Dijkstra в 1969 году. (Testing shows the presence, not the absence of bugs).

В результате мы приходим к тому, что никоим образом не может quality assurance assure the quality (Qualität sichern, обеспечивать качество), если речь идет о программном обеспечении. Повторюсь, QA может и должно искать и находить проблемы, но не доказывать или тем более гарантировать их отсутствие.

У меня всё.

1

Автор Опубликовано 1 комментарий

Часть 1

Часть 2

Игорь Манушин "Deep FitNesse" http://sqadays.com/ru/talk/23958

Доклад был настолько серьёзный, что я как ни старался, не смог придумать по нему ни одной шутки. На мой взгляд, круг аудитории для доклада был очень небольшой - разработчики тестов на FitNesse, пользующиеся хитрыми фреймворками FitSharp,NetRunner, Fit, Slim. Часть про FitNesse была довольно понятной и полезной, а потом на меня посыпалось тонкое сравнение того, что я перестал понимать. Возможно доклад будет интересен лучше подготовленному слушателю.

Василий Буров "Тест-план и исследовательское тестирование" http://sqadays.com/ru/talk/27522

К большому сожалению доклад подавался довольно безэмоционально, слайды изобиловали мелким текстом, присутствовали опечатки (последние пункты - небольшой камень в огород ревьюеров, на эти вещи нужно было обратить внимание). К сожалению, потому что методы озвученные в докладе мне показались весьма разумными и достойными применения и в других компаниях. Василий рассказал про смесь исследовательского тестирования с тестированием по чек-листами, местами напоминавшее мой метод  No-Test-Cases. Мне по началу казалось, что в системе чего-то не хватает, но Василий каждым следующим слайдом отвечал на мой вопрос "позвольте, а как же...?". В конце все встало на места, схема логичная и вполне рабочая. Поворчу об очередном использовании понятия "тест-план" (у которого есть четкое значение по ISTQB) для описания своего велосипеда. Я вот, например, специально для своего метода придумывал незасветившееся название, чтобы энтропию не увеличивать 🙂 Но если у Василия документ так называют в проекте, ну что ж, не может же он самостоятельно его переназвать чтобы угодить остальному миру.
На вопросы в чем отличие тест-плана (чеклиста) от набора ноу-тест-кейсов - no-test-cases мы управляем не в документах эксель, а полноценной системой управления кейсами, связываем с требованиями, с багами, с заданиями на выполнение и т.п.

Дарья Ефремова "ГИП – весёлый пожарник или человек-оркестр?" http://sqadays.com/ru/talk/25723

В фирме "Перфоманс Лаб" изобрели русский ответ CTO (Chief Technical Officer), назвали его ГИП (Главный Инженер Проекта) и сказали, что это не должность, а роль. ГИП - это супермен от IT, на всякий случай владеющий методами анализа, тестирования, разработки и управления. Откуда они таких берут не сказали, но утверждают что 3-4 у них есть. Хотя на мой взгляд тех оленей, ты не ври, нет ни в Туле, ни в Твери! Что в Твери, в самом Багдаде их от силы штуки три. В общем, хорошо иметь крутых спецов, и плохо их не иметь. Но вообще кроме шуток, мотивировать людей впрягаться в роль крутого всезнающего коуча, организовав для этого специальный термин (надеюсь и к премии прибавку организовали) - может быть хорошей идей, почему не попробовать.

 

Это были те доклады, которые я смотрел вживую, к ним на данную минуту еще нет видео.

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

Юрий Неваленный "SysInternals. Топ-5 инструментов тестировщика" http://sqadays.com/ru/talk/24009

Инструменты полезные для тестировщиков работающих в Windows "близко к коду". Но более полезные программистам для отладки :). Замена TaskManager, программа для скриншотинга и что-то для управления процессами.

Алексей Петров "Обучение тестировщиков. Практический опыт и советы" http://sqadays.com/ru/talk/27496

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

Роман Шейко "Коммуникации в тестировании" http://sqadays.com/ru/talk/25789

Роман, спасибо за слайд 4 "Тестирование - это ..."!  Так победим! 🙂 Хорошая общая пробежка по коммуникации, опирающаяся на опыт докладчика. Роман и ревьюеры: "минутки" - это "протокол", "адженда" - "план митинга" 🙂

Алексей Никитин "Белоснежка и шесть гномов или разработчики тоже тестируют" http://sqadays.com/ru/talk/24134

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

Станислав Бахарев "Грязная автоматизация" http://sqadays.com/ru/talk/25757

С огоньком рассказано, как 300 спартанцев подручными инструментами и напильником поворачивали вспять реки (автоматизировали через UI). Если я правильно понял намёки докладчика про боль, он понимает и согласен, что поворачивать реки вспять не надо было изначально :). Почему и что делать вместо этого? Смотрите доклад Андрея Солнцева из части 2.

Алексей Лянгузов "Визуализация покрытия автоматизированными UI тестами" http://sqadays.com/ru/talk/26051

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

Автор Опубликовано Оставить комментарий

Продолжим про доклады.
Часть-1

Юлия Свистунова "Как оценить команду тестирования и как направить их развитие в нужное русло" http://sqadays.com/ru/talk/25922

Слушая этот доклад про грейдинг я сразу вспомнил забавные истории из блога Макса Дорофеева ( Первая история , Вторая история), что несколько затруднило объективное восприятие доклада 🙂 В докладе говорят, что оценки персонала нужны топ-руководству, менеджерам и специалисту. Последнему "для прозрачности и понятности" - тут не удержусь, читайте первую историю :-). Наверное, если использовать оценки, то приведенный метод в докладе хорош, он был достаточно прост и логичен. Я хочу от себя предложить другой метод "оценки", довольно распространённый к счастью у нас, в Германии. А именно, если вы руководитель-менеджер - говорите со своими подчинёнными, и не раз в год на общем собрании, а лично и регулярно. Замечайте глазами, что они умеют и как работают, спрашивайте ртом, какие у них проблемы и как они хотят развиваться. Если вы подчиненный - то говорите о своих идеях с начальством, не стесняйтесь. В том числе и справедливость зарплат вполне может обсуждаться с глазу на глаз, без табличек в экселе. У табличек есть на мой взгляд одно важное применение - когда вашу фирму поглотит более крупный конкурент и скажет вам, менеджеру, увольте-ка к Новому Году 60% сотрудников, вот тогда вы и возьметесь за грейдинг. Такие дела.

Игорь Горчаков "SOLIDарность: Тестирование как разработка" http://sqadays.com/ru/talk/27319

Давно слышал про SOLID, но не было времени почитать, так что доклад пришелся мне в кассу. SOLID это принципе объектно-ориентированного дизайна (паттерны), сформулированные впервые отцом движения Clean Coders Робертом Мартином, более известным как Uncle Bob, оказывается аж в начале 2000-ых. Докладчик объяснил доступно для подготовленного слушателя все 5 паттернов и показал хорошие примеры на языке Java. В принципе хорошая, важная вещь... особенно для программиста. Мне кажется, что эти конкретные паттерны гораздо реже будут нужны тестировщику, пишущему код автоматизации или юнит-тесты. Зато от доклада родилась другая идея. Почему бы не создать коллекцию паттернов, с примерами, характерную именно для задач встречающихся тестировщику. Например PageObjects, ChainedMethods для автоматизаторов, есть наверняка и паттерны для юнит-тестеров. По первому, я сразу нашел слайды с доклада Николай Алименкова http://de.slideshare.net/alimenkou/design-patterns-in-web-testing-automation-with-webdriver . Был бы рад услышать продолжение этой темы :).

Михаил Кравченко "Сертификация. Приводим знания в порядок" http://sqadays.com/ru/talk/25461

Доклад про экзамены ISTQB. Докладчик в основном зачитал содержимое сайта  http://istqb.org, почему-то оставив половину слайдов без перевода. Ну что сказать, сайт большой, может быть кому-то сложно кликать по нему самостоятельно. Из хороших моментов были упомянуты трудности перевода (пример ошибочного перевода на русский, не позволяющий правильно ответить на вопрос сертификации), а также то, что опытным тестировщикам сдать экзамен Foundation Level (базовый уровень) сложнее чем новичкам, так как они понимают гораздо больше тонкостей тестирования, чем учтено составителями в вопросах теста. Да, так оно и есть. Для тех, кто никогда не слышал про ISTQB или слышал, но заходил на их сайт, доклад был полезен, думаю таких людей было достаточно много. Сам я про ISTQB двоякого мнения. В принципе сертификация подводит знания по общий базис, и это хорошо. С другой стороны она может внушить то, что стандарты ISTQB всегда правильны и непоколебимы, и это плохо. Почему плохо - смотрите мой доклад про No-Test-Cases :-).

Андрей Ладутько  "Приключения белого ящика в стране покрытий" (мастер-класс) http://sqadays.com/ru/talk/25769

В своем мастер-классе Андрей подробно объяснил 4 вида покрытия при тестировании методом белого ящика. Целевая аудитория - начинающие и продолжающие начинать тестировщики. Считаю, что для них доклад был вполне хорош. Если вы уже готовились к ISTQB и поняли главу про белый ящик самостоятельно, то ничего нового из доклады вы скорее всего не узнаете. Впрочем открыть новое и не было его целью.

Андрей Солнцев "The fast and the continuous" http://sqadays.com/ru/talk/25882

Один из лучших докладов конференции по моей версии, к сожалению не попал в призеры. Как заметил Андрей, сложно победить с докладом, в котором говоришь, что вы все делаете неправильно!  🙂 Андрей рассказал про то, что UI-тесты - зло ( мой комментарий "так, как их применяют во многих проектах") и что во многих случаях, вместо решения проблем вида "как мне сделать мои UI-тесты стабильнее", "мои UI-тесты проходят слишком медленно" стоит задуматься о том, чтобы перенести тесты на нижние уровни (в юнит-тесты). Любопытно, что я не в первый раз вижу путаницу с видами тестирования, так же и тут был слайд (сейчас нету на сайте) с пирамидой автоматизации, где были уровни module tests, integration tests, functional tests. Последнее конечно неверно, потому что functional тест, это все которе не non-functional. 🙂 Т.е. и module tests и integration tests обычно тоже functional. Правильно использовать понятия system tests или например ui tests, если хочется подчеркнуть тестирование через графический интерфейс. Вобщем хороший доклад, на правильную тему, про которую в угаре автоматизирования часто хронически забывают. Да, UI тесты можно и нужно использовать, но для высокоуровневых проверок главных путей использования программы (Андрей про это, если я не ошибаюсь тоже сказал в конце).

Часть 3

 

 

Автор Опубликовано Оставить комментарий

Ну пройдемся немного по докладам.

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

Не ко всем докладам пока есть видео, но скоро появятся, потерпите :).

Сергей Атрощенков "Тестовые оракулы на основе концепции EI/EQ (эмоционального интеллекта)"  http://sqadays.com/ru/talk/25831

Любопытный доклад про то, как наблюдения за эмоциями (субъективные факторы) могут помочь в работе определять объективные факты (например, баги замечать). Кое-что общего в идее есть с  вебинаром от  it-boost с http://it-boost.com/statistika-ili-intuitsiya-chey-kung-fu-kruche , где я впервые услышал понятие "жопочуй".  Хочу обратить внимание, что хотя эмоции наверняка дают интересные сигналы, их верную трактовку сильно усложняет наличие внешних (вне рабочих) эмоций (забыл молоко купить, футбольная команда вчера выиграла, зарплаты вечно не хватает и тд.) как очевидных, так и более глубоких подсознательных. Сергей посоветовал разделять вектора рабочих и внешних эмоций, но я думаю, что это на практике не всегда просто, может даже невозможно.

Ольга Павлова "Порог вхождения как критическая точка пользовательского опыта"  http://sqadays.com/ru/talk/24046

Веселенький доклад, который напоминает, что если просто сделать "как в спецификации записано", то можно очень быстро получить провальный проект, особенно, если сделать это на точке входа пользователя в программу. Юзабилити наше все, а если вам при первом запуске программы предлагают заполнить формуляр на 30 полей, то возможно вы даже и не узнаете, как хорошо и правильно все устроено внутри. В конце доклада возник небольшой флейм с зрителем из "Одноклассники.ру" по поводу того, что автор "только указывает на проблему, но не дает путей решения". Возможно это так, но тут я согласен с Ольгой - докладчик строит доклад на свое усмотрение. Укажешь путь решения - спросят "почему не обсудил, когда данные пути не подходят". Обсудил - "почему не все альтернативы указал". "И вообще теперь наговорил всякого, половина мне вообще не подходит, зря и слушал" :). Ребята, у нас 30 минут на "длинный" доклад, еще меньше на блиц. Есть вопросы - общайтесь с докладчиком. Хотите решить именно вашу проблему в глубине - некоторые докладчики предлагают консальтинговые услуги, звоните-заказывайте ;-).

Владимир Мозжечков "Техническое собеседование Senior QA. Проведение и прохождение" http://sqadays.com/ru/talk/24011

Несколько провокационный доклад про то, как проводят собеседования в фирме аутсорсинговой фирме Smartech (http://smartru.com). Оказалось, что мне проще положительно пройти тест на беременность, чем закончить техническое собеседование на Senior QA на отлично. Потому что, полный ответ на поставленную задачу даст мне только 3 балла из 5, а для 5-ки нужно еще догадаться, что часть задания была скрыта, и успешно решить ее про запас. Подход спорный, так как с одной стороны, некоторые сильные кандидаты просто по-доброму удивятся, увидя объём задания и соскочат. С другой стороны, представьте, у вас есть кандидат который сделал всё что задавали, плюс тест-план, плюс автоматизированные тесты, плюс еще небольшую диссертацию по TCP/IP протоколу приложил. Если спросите меня, то возможно и в работе он, когда получит задание протестировать небольшой проект, вложит туда свою энергию и способности, и потратит ресурсы на то, чтобы сделать больше, чем предусмотрено бюджетом заказчика. По мне, так лучше меньше, да лучше :). Доклад тем не менее весьма полезный, вы можете теперь представить, что потенциально могут спрашивать на собеседованиях, и если вы основательно подготовитесь к этому, то никакой другой вас уже не испугает :). К слову, в данный момент открытых QA вакансий на сайте фирмы, и на hh.ru нет.

Инна Смирнова "Эффективный тест-менеджмент... и как с ним бороться" http://sqadays.com/ru/talk/25902

Вопреки услышанной от кого-то из организаторов установки, что нельзя пересказывать чужие книжки в своем докладе, я считаю, что хорошая презентация отличной и полезной книги имеет свою ценность. Что и показали оценки доклада (2-ое место). Инна говорила про один из бестселлеров Ицхака Адизеса "Стили Менеджмента и Мисменеджмента" (http://www.amazon.com/Management-Mismanagement-Styles-Kalderon-Adizes/dp/0937120014 ) в применении к общению с (тест)-менеджерами, а также со взглядом на саморазвитие. Адизес различает 4 компоненты в стиле управления P (Производитель), А (Администратор), Е (предприниматель), I (интегратор). В каждом менеджере наиболее развиты одна или две компоненты, и недоразвиты или отсутствуют остальные (и это - норма (с) 🙂 ). У каждого стиля свои плюсы и минусы, к каждому стилю - свой подход. Можно пройти тест http://adizes.me/paei_test/ и узнать, к какому стилю относились бы вы, если бы были менеджером :).  У меня вышло PaEi, с преобладающим E:). Мне показалось, что большинство примеров были взяты прямо из книжки, было бы еще лучше, если бы Инна придумала примеры из повседневной жизни тестировщиков. Я книжку прочитал в 2011 году, и вспоминаю о разнице в типах, как правило, сразу после неудачного подхода к одному из "менеджеров", т.е. слишком поздно :). Поэтому меня интересовало то,  как можно практически применять знания типов (оценивать менеджеров и записывать буквочки в телефонную книжку)? Надеемся услышать об этом в следующий раз. 🙂
А в целом, если вы не слышали об Адизесе - обязательно прослушайте доклад!

Часть 2

Часть 3

Автор Опубликовано Оставить комментарий

"Тестировщик - это который по сайту кликает?".
"Ты тестировщик? То есть ты знаешь программирование? И ищешь в исходниках ошибки, да?"
Студенты-стартаперы. Обоих обратил в правильную веру, день прожит не зря.

Автор Опубликовано Оставить комментарий

МТС обогатил мой словарный запас словосочетанием "нечисловые символы".И еще они прислали SMS о том, что ответ на запрос придёт по SMS. Нет, вы не подумайте, действительно пришёл.

Автор Опубликовано Оставить комментарий

Услышал интересную версию значения "командный игрок" (team player)

"Тот, кто может быстро понять, кто из команды за что отвечает, и что знает, и использовать эти знания для пользы проекта"

Новый взгляд, и пожалуй соглашусь.

6

Автор Опубликовано 6 комментариев

В очередной раз имеем ситуацию, когда один человек дизайнит тейст-кейсы, а совсем уже второй человек их выполняет. Или автоматизирует (проблема та же самая).
Так вот, в процессе выполнения (или автоматизирования) за первым "дизайнером" приходится некисло исправлять. Более того, часто (да почти всегда), чтобы исправлять за дизайнером, надо самому въезжать в предметную область и требования. Иначе как ты поймешь, что надо исправлять и на что?
В одном из докладов советовали такое: на позицию тест-дизайнера нужно брать самого умного-благоразумного тестировщика. И тогда мол, выполнять тесты сможет любой студент с улицы. Немножко за кадром остался ответ на вопрос - выполняет ли свои тесты тест-дизайнер сам или только "студент".
На мой взгляд в этой конструкции есть проблема. Если тест-дизайнер не выполнит и не отладит (а часто это можно сделать, в отличии от написания тест-кейсов только в конечной стадии разрабоки, когда ПО близко к состоянию "готово").
А заменять фазу отладку тест-кейсов усилением на фазе дизайна, это все равно что использовать пару гуру-студент для программирования - гуру пишет код, а студент компилирует, дебажит, исправляет найденные ошибки. Такая связка, конечно работать не будет.
Выводы.
1. Отлаживать и исправлять тест-кейсы при выполнении должен квалифицированный тестировщик (например, сам же тест-дизайнер).
2. Если при ручном тестировании пользоваться вместо тест-кейсов - ноу-тест-кейсами, то как и предыдущем пункте, без квалифицированного тестировщика при выполнении не обойтись, зато затраты на "отладку" и "исправления" сократятся в десятки раз.

А что вы думаете по этому поводу?

Автор Опубликовано Оставить комментарий

Ну и теперь официально.
Меньше, чем через две недели буду громить тест-кейсы и восхвалять ноу-тест-кейсы на конференции по тестированию "SQA Days 16".

До сих пор доклады читал пока только на немецком перед 5-20 человек), так что будет непросто.

Но все равно, приходите! 🙂 14 ноября, в Санкт-Петербурге. По плану мой доклад в 11:50.
http://sqadays.com/ru/talk/25572