Продолжим про доклады.
Часть-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 тесты можно и нужно использовать, но для высокоуровневых проверок главных путей использования программы (Андрей про это, если я не ошибаюсь тоже сказал в конце).