пятница, 6 октября 2017 г.

Конференция КоТэ 2017 (отзыв)

Логотип КотЭ!
27-29 сентября прошла КоТэ — онлайн-конференция для тестировщиков. А я только сейчас поняла, что так и не написала отзыв Smile :)

На самом деле мысленно я его уже написала, рассказала как то понравилось, это и вот это... Так и думала, что уже все сделала))) Но теперь исправляюсь и записываю свои впечатления сюда. Конференция крутая, надо брать! Если пропустили, в следующий раз не зевайте )))) Докладов много и по существу. На форуме фыркали, что с таким названием стыдно за профессию, а я считаю, что это прикольно. Лучше уж мимимишное название и отличное содержание, чем наоборот.

Я побывала только на двух днях конференции, 1 и 3. Автоматизацию пропустила, но уже выложены видео (для участников конференции), буду наверстывать. Судя по отзывам, там тоже было очень круто и интересно, аж захотелось послушать. Но расскажу о том, где была.

1 день


1. Мастер-класс по заведению дефектов. Ольга Назина


Я рассказывала о том, как заводить баги, чтобы потом не было мучитель больно вспоминать, о чем там вообще речь шла. Так как это мастер-класс, то большую часть времени мы общались с аудиторией. Смотрели на баги в гуглодоке (это было домашнее задание, завести туда баги), обсуждали, как их можно сделать лучше.


Ребята очень активные, молодцы! Для меня стало полной неожиданностью утром в среду увидеть целых 130 ответа на домашнее задание. Ведь в последний раз их там было всего 33 ツ И на самом мастер-классе многие давали ответы, хорошие, четкие, сама бы лучше не сказала.

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

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

Надеюсь, ребятам было полезно))) В чате было с десяток «Спасибо!», так что вроде как зашел доклад!

2. Как избежать ошибок при покрытии мобильных окружений. Виктория Юркевич


Одна докладчица заболела прямо в день конференции и ее срочно подменила Вика. Вика — герой! Я бы распаниковалась))) Шучу, наверное, нет. Но сдвигать свое время желанием бы не горела.

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

Все тайны тестирования раскрывать тут не буду, слушайте доклад ツ


3. Три лучших инструмента для управления тестами. Стас Косарев


Стас прилюдно сравнил Testlink, TestRail и Testopia. Что когда применять, какие плюсы и минусы есть у каждого. Хороший доклад, особенно для тех, кто только выбирает инструмент под себя.

Если с Testlink и TestRail я хоть как-то работала, то про Testopia вообще только слышала. Так что мне было любопытно. Мы не применяем эти инструменты (и вряд ли начнем), но для общего развития — почему нет? Ведь сами идеи можно применить где угодно.

4. Эффективный тестировщик: почему недостаточно просто хорошо тестировать? Олег Грабко


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

И на слайдах показывал всякие черточки и крестики. Типа «я то думал, что менеджеры считают так, а реально они отметили вот это». В чате сразу появилась куча вопросов «а что значат эти галочки» ツ

Как вы думаете, какая проблема самая глобальная? Правильна, проблема коммуникации! А вовсе не плохое обучение или что-то еще )))) Любопытный доклад, рекомендую послушать. Как, впрочем, и все остальные

5. Как писать чек-листы для готового продукта без ТЗ. Юлия Бурматова


ТЗ? Какое такое ТЗ? Не, не слышали. Такова суровая реальность работы тестировщиков, причем многих. Так что доклад Юли зацепил многих. Слушали, задавали вопросы ))))

Как все начиналось? Пришел Заказчик: потестируйте как пользователи, много документации не хочу, тест-кейсы не хочу, а чек-листы бы пригодились. Что в итоге? «Лажа ваши чек-листы и вообще все плохо!». Вот как избежать такой ситуации? Юля рассказала о реальном опыте и выводах, которые ее команда из этого опыта извлекла. Ценная история!


3 день


Практический мастер-класс по проведению проектной ретроспективы. Наталья Руколь


О, этим докладом даже наш РМ заинтересовался, просил потом рассказать, что там да как. Сам доклад огонь! Как обычно у Наташи ツ

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

Во многом ведь узнаешь себя, свою команду. Постоянно киваешь "да да, это плохо, а это вообще не работает". Но Наташа ведь говорила не только о том, что НЕ работает, но и о том, что работает. И о разных уровнях зрелости ретроспективы. «Встретились и обсудили, что было плохо, а что хорошо» — это только первый уровень зрелости, самый нижний.

Конечно, надо готовиться к ретро заранее. Надо анализировать, что стоит улучшить. И тут важно выбрать три улучшения, а не десять или пятьдесят. А то ведь бывает такое, что наберешь себе кучу обязательств, ничего не сделаешь и растеряешь запал, «оно не работает!». Да и не будет таким образом.

А еще бывает, что ретро противопоказано. Это когда одна проблема перетекает из одного ретро в другое. То есть боль есть, но никто ничего не делает. Продалбываем сроки? Продолжаем! А потом, конечно, ретро виновата, потому что пользы не принесла.

В общем, для меня оказался самым полезным на конференции доклад. Есть над чем поразмышлять.

Экстренное тестирование: Один за всех! Александр Филиппов


Проекты обычно делятся на стабильные и экстренные («вечный дедлайн»). Что делать, если ты попал во второй? Если ты один тестировщик и от тебя хотят всего и сразу? Александр рассказал про опыт одного из своих проектов, где сжатые сроки, удаленная работа, ТЗ пишется в процессе разработки и вот это вот все.

Что важно сделать, когда надо провести много проверок в короткий срок? Расписать проверки, расставить приоритеты. А потом пойти к аналитику и рассказать: так и так, сроки есть только на это, вот это тестировать не буду. Но если ты молча не будешь что-то проверять, потом огребешь.

Еще про важность коммуникации — не надо молча делать что-то сверх оговоренной работы. Например, написание ПМИ. Если исходно не закладывалось и тут пришел Заказчик и требует, то надо ему объяснить: «Смотрите, это займет столько-то времени. Если я буду это делать, от чего-то другого придется отказаться, чтобы успеть в срок. Что мы можем выкинуть и не сделать?». Фишка в том, что исходно Александр просто пытался все успеть. И не успел. И если ты не проговоришь вслух, что что-то сделано не будет, то Заказчик потом дико возмутится, хотя он сам подкинул тебе работу.

В общем, о том, как выживать в экстремальных условиях — в докладе Александра.


Инструменты эффективного тестирования и планирования в распределённой команде. Оксана Разина


Итак, у нас есть распределенная команда. Эффективное тестирование стоит на 3 китах — планирование, организация, контроль.

Зачем вообще планировать? А как оценивать результаты? Надо придумать метрики, которые будем собирать, иначе непонятно, хорошо планируем или нет.

А вот дальше уже пошли инструменты. Можно планировать в гуглодоках. Вот примеры реализации таблиц. Вот плюсы и минусы. А есть еще Gantter for GoogleDrive, опять же плюсы и минусы.

Ок, напланировали, следуем дальше, как это все делать. Как строить коммуникации, распределять задачи, не флудить :-) Ну и, наконец, как проконтролировать весь этот процесс

Итоговый отчёт по проведённому тестированию. Нина Агеева


"Без бумажки ты - букашка!". А бумажки никто не читает =)

Общий посыл доклада — меньше слов, больше визуализации. Но рассказывает Нина очень круто! Рекомендую ツ

Она столкнулась с тем, что вроде люди стараются, пишут отчет по тестированию, отправляют... А Заказчик молчит. В итоге они приехали к Заказчику, заперли его в конференц-зале и устроили демонстрацию, рассказав все на словах и показав. И по задаваемым вопросам поняли, что «Блин, так никто не читал мой отчет! Ведь там все это было!»

Решение оказалось довольно простое, вместо кучи текста Нина делала наглядную картинку и потом звонила по телефону «Готовы обсудить?». По картинке сразу видно, где улучшились показатели, а где просели, даже не вникая в цифры. Это очень удобно и, главное, улучшается результат, люди начинают читать ваши письма.

Полностью согласна с Ниной, очень актуальная проблема. Могу также порекомендовать доклад Павла Абдюшева с ЛАФ — Как писать Release Notes, чтобы их читали. Проблема то та же, Заказчик перестает читать ваши письма =)

Как организовать погружение новичков в команду? Анастасия Смирнова


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

Короткий доклад, но зато все по делу! Мне понравилось ツ

Резюме


Надеюсь, эта была не последняя конференция с котиками. Докладчики все молодцы, хорошо подготовились! Было интересно и познавательно Smile :)

Будем ждать следующей конфы ^_^

2 комментария:

  1. > Мы не применяем эти инструменты (и вряд ли начнем), но для общего развития — почему нет?

    Оля, привет. Спасибо за отзыв о конференции. Интересуем, почему не планируете использовать инструменты для управления тест-кейсами. Установил TestLink на mac, ужаснулся кривости его интерфейса. Удалил. Надеюсь Testopia как-то заинтересует.

    ОтветитьУдалить
    Ответы
    1. Потому что мы не пишем тест-кейсы. У нас есть чек-листы и описания автотестов, все

      Удалить