Тег: доклады

На докладах не был, диагноз по видеозаписи.

Александр Щукин "Тестирование сетевого оборудования через консольный интерфейс" http://sqadays.com/ru/talk/24015

Доклад технически описывает опыт построение консольных автотестов для специфической области (сетевое оборудование), когда доступ к тестируемому оборудованию неудобен (VPN, медленно).

Алексей Николаев "Альфабанк: НТ в Облаке при Agile на примере интернет банка" http://sqadays.com/ru/talk/25773

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

Мария Терёхина "Улучшение процесса тестирования: контентные модели" http://sqadays.com/ru/talk/25603

Процесс тестирования курильщика. Если у вас только один тестер на проекте, приоризируем его задачи и требуем оценок.

Татьяна Смехнова "История HERE Maps for Windows: меняемся не изменяя качеству" http://sqadays.com/ru/talk/25556

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

Дмитрий Химион "Инструменты автоматизации тестирования - дефективные"  http://sqadays.com/ru/talk/24213

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

Рина Ужевко "Тестируем графику силами Art QА" http://sqadays.com/ru/talk/23936

Узнал про новую для меня ветвь тестирование - Art QA. Хорошие, но несколько специфические (игры и графика) примеры. Включу в свой доклад для студентов о профессии тестировщика 🙂

Часть 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