понедельник, 19 декабря 2011 г.

SQADays-10. День второй.

Вот и дошли руки до запоздалой второй части отчета про SQADays-10.

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

Часть обеда была пожертвована на круглый стол по развитию сообществ тестировщиков. Питерскому клубу тестировщиков наше искреннее "НЯ!")

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

Но мой день сделал доклад от Евгении Фирсовой про очереди в тестировании. Очень приятно слышать от тим-лида, что кто-то действительно учитывает неравномерность работы сотрудников. Типология очередей, личные tips & tricks и потрясающая харизма. Много детского восторга и отличное общение после. Не жалею, что пропустила Панкратова и Орлова в соседнем зале. Впрочем, приобщиться к мудрости первого все-таки получилось))

Очень рада, что выбралась. Много общения и много новых мыслей, часть из которых начала реализовывать в своей работе.

Спасибо, SQADays!




воскресенье, 4 декабря 2011 г.

Впечатления от SQADays-10. День первый.

Это была первая крупная конференция по тестированию, в которой я участвовала. А тут еще и в качестве волонтера-модератора)

В первый день запомнился доклад Святослава Куликова "Готовим тестировщика с нуля и до... (необходимого уровня)" про систему выращивания кадров в EPAM Systems. Интересна система, которая позволяет потоковым методом обеспечивать команду junior tester. И типовые ошибки, с которым столкнулась компания при выстраивании.

Далее попала на доклад Сергея Мартыненко "Приоритизация методов верификации требований". Доклад очень пересекался с уже слышанным с какого-то ЛАФа, но все равно очень полезно, да. Очень хочется распарсить это в интеллект-карту и повесить над монитором. И да, таки добраться до Карла Вигерса.

Зажигательное выступление Татьяны Зинченко "Вредные советы для тестирования юзабилити" очень порадовало.  Ярко, тезисно, с конкретными примерами.  Очень хочу презентацию и запись выступления, чтобы В моей секции был полный аншланг)

А закончился первый день докладом Андрея Степина из "Актива" про то как тестировать софт после защиты от пиратства, на что и как смотреть) И да, теперь я знаю страшное слово "обфускация".

А еще было много кулуарного общения и ценных идей.

четверг, 1 декабря 2011 г.

"Я бы в летчики пошел, пусть меня научат!".

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

Но вот то, что тестировщик не хочет заниматься программированием сверх необходимых для упрощения рутины вещей вызывает крайнее удивление. "Как? Ты не хочешь автоматизировать? Автоматизация же следующая ступень развития тестировщика!". И с придыханием такое "там серьезные профессионалы, они _почти_ как программисты!". Если перевести эту ситуацию на описанные выше IT-профессии - кажется нелепым. Зачем вместо хорошего системного администратора иметь "почти программиста". И не проще ли найти сразу хорошего программиста? И этому, как мне кажется есть несколько причин.

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

 2. Есть мнение, что программист решать задачи автоматического тестирования все равно не будет - ибо скучно, нетворчески и т.д. И поэтому мы лучше возьмем "почти программиста", который как-то нам будет автоматизировать. Касательно уровня зарплат - не так уж и отличаются зарплаты программистов и автоматизаторов.

 3. Автоматизация - это модно. Про то, что это дополнительный, нередко с сомнительной архитектурой, код, который надо тоже поддерживать задумываются далеко не все.

 Кому-то хочется развиваться в программирование, кому-то в тест-дизайн, кому-то в нагрузочное, а кто-то грезит о вертикальной карьере. И нет единого правильного пути. Но общественное мнение такое мнение...

среда, 9 ноября 2011 г.

И еще о стоимости переработок.

Переработки во многих компаниях - негласная норма. Вроде бы и добровольно все, но если ты хочешь работать не больше своих восьми часов - удивляются и не понимают. И далеко не всегда понятна стоимость этих переработок.

Сергей Бережной сделал замечательный слайдкаст о том, во что выходят овертаймы для заказчика.



Путь овертаймов from anotherpm on Vimeo.

среда, 2 ноября 2011 г.

ConfetQA. Впечатления)

Дошли руки до мыслей о прошедшей он-лайн конференции)

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

Получилась этакая сборная солянка - менеджмент, автоматизация, tips&tricks по инструментам, автоматизация. Наиболее интересными мне показались доклад о web testing framework Андрея Дзыни, о PowerShell  Игоря Любина и о метриках в нашей жизни от Натальи Руколь.

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

PowerShell оставил впечатление нормальной командной строки) Теперь и в Windows. Чую большой потенциал за этим инструментом в моей жизни) Нашла руководство, буду изучать.

Что измерять? Как измерять? И главное зачем измерять. На эти вопросы дала ответ Наталья) Тоже много мыслей к размышлению.

Доклад "приглашенной звезды" Майкла Болтона был непрост для восприятия) Но весьма способствует постановки мозгов. Буду пересматривать еще.

А так, было здорово!)

среда, 19 октября 2011 г.

"Наша служба и опасна, и трудна..." или про visibility в жизни тестировщика.

Visibility, попавшее в разговоры с легкой руки Славы Панкратова и Саши Орлова, очень причудливая штука. И вроде бы все понятно - надо кукарекать, когда снес яйцо, делать свою работу видимой для коллег и начальства, и прочее.

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

С одной стороны разговоры о качестве, а с другой до сих пор тестирование в руководящих умах нередко считается вторичным делом. И достаточно смутное представление о том, что такое тестирование и чем оно отличается от кликанья. Результат разработчиков виден и измерим, а тестировщиков  нередко упрекают ненайденными багами.

Возможный выход - больше общаться, рассказывать и показывать. По крайней мере попытаться - стоит)


четверг, 29 сентября 2011 г.

"Как мыть слона"? или интерфейс и все, все, все...

Недавно мне достался в руки Дизайн пользовательского интерфейса. Искусство мыть слона. Влада Головача. Еще одна базовая книга о постановке мозгов и не только в сфере дизайна интерфейсов)

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

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

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

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

"Занимайтесь только той оптимизацией интерфейса, которая улучшает продукт". С точки зрения тестирования - это тоже о приоритезации багов) И видении целей, аудитории и т.д.

И много еще интересного, в том числе и сравнение профессионала с врачем)

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

Ну и интересный список рекомендованной литературы)