10 дней назад на нашем форуме Василий Касимов инициировал опрос про зарплаты в области тестирования. На текущий момент в опросе приняло участие более 1 200 человек и уже можно подводить промежуточные итоги.
Мы отдельно собрали результаты по трем странам: Россия, Украина, Беларусь.
В отчете по России мы выделили отдельно статистику по Москве, Санкт-Петербургу и остальной части России, включая удаленную работу.
В Украине отдельно выделили Киев.
Ниже представлены диаграммы на 28 июля (по ссылкам более актуальная информация, представлены диаграммы и сводные таблицы). На диаграмме по вертикали количество человек, по горизонтали диапозон зарплаты (Россия – рубль, Украина и Беларусь- доллар), цветом обозначен опыт работы.
Ссылки на результаты опроса и сводные таблицы (таблицы находятся на отдельных вкладках внизу страницы). По ссылкам вы сможете найти данные не только по городам ниже, но и посмотреть какие зарплаты получают тестировщики в вашем городе.
Кто такой эффективный тест-менеджер? Он - лидер в команде тестировщиков, который должен уметь правильно управлять ей, понимать какие процессы необходимо контролировать в первую очередь. Ему необходимо знать, что происходит в его подразделении, насколько эффективно работает его команда. Как тест-менеджеру грамотно подобрать специалистов по тестированию и организовать их работу так, чтобы успешно проходить все этапы от становления команды до успешного релиза на проекте?
Своим опытом в этих вопросах поделились наши зарубежные коллеги на конференции SQA Days 19.
Недавно я прочитал статью в блоге Скотта Хансельмана "Темная сторона разработки – скрытые 99%". Основной мыслью статьи было то, что большинство разработчиков не читают профессиональные блоги, не ведут свой, не участвуют в групповых обсуждениях, не пользуются твиттером и фейсбуком, и не посещают крупные конференции.
Я часто наблюдал таких людей в командах, где я работал, и это не менее верно для тестировщиков. Небольшая их часть активно интересуется тестированием вне своего основного рабочего времени, и если вы это читаете – поздравляю, вы в меньшинстве. Все остальные находятся на темной стороне.
Почему?
Скотт считает, что причина кроется в постоянно растущих темпах перемен в мире разработки программного обеспечения. Это демотивирует многих следить за новостями индустрии – как только вы наконец-то освоили последние новинки, они уже превратились в преданья старины глубокой, потому что появилось нечто еще более новое и совершенное. Поэтому стоит ли стараться?
Это очень верно для мира разработки ПО, но для тестировщиков технология все-таки вторична по сравнению с функциональностью. Да, мы тоже чувствуем давление постоянных технологических перемен, но при этом не сражаемся на передовой, как наши коллеги-разработчики. Битва тестировщиков проходит на поле определений тестирования, оправданий тестирования, защиты тестирования. Эти вопросы постоянно всплывают в той или иной форме, они уже всех утомили, но это отражение состояния нашей отрасли.
Тестирование для многих – просто некий переходный период. Нет, это могут быть профи своего дела, опытные и любящие свою работу тестировщики, но в большинстве своем люди не мечтают об этой профессии с пеленок, и не хотят работать тестировщиками до конца дней своих. Добросим еще тот факт, что в мире не существует некого общего образования или набора идеальных практик для тестирования, и желаемые навыки очень варьируют в зависимости от конкретной компании или даже страны. Правда, неудивительно, что тестировщики не испытывают большого желания участвовать в жизни отрасли? Даже если они не прочь принять участие, это страшновато – в ней царит какофония различных мнений.
Вышел июльский выпуск рассылки портала Software-Testing.RU, в котором собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.
Мы проводим опрос по уровню зарплат в тестировании, и в нем уже приняло участие более 600 человек. Мы продолжим собирать статистику до конца июля, а после этого опубликуем результаты. Спешите принять участие!
Каждому тестировщику от джуниора до менеджера не безразлична судьба своего проекта, естественно, что каждый из них пытается качественно выполнять поставленные задачи. Всегда ли это удается сделать на 100%?
Любопытно узнать историю тех, кто имеет больший опыт, чем вы, или имел ранее схожий опыт, но решал поставленные задачи по-другому. Интересно, у кого получилось лучше?
Ниже мы опубликовали три видеозаписи выступлений с конференции SQA Days 19, в которых наши коллеги рассказывают, как они улучшали процесс тестирования на своих проектах и что из этого получилось.
Выступление Александра Федорова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
По специфике своей работы я провожу десятки собеседований и общаюсь со множеством начинающих и имеющих некоторый опыт специалистов в области тестирования. Как правило у них есть масса вопросов, связанных как с работой и ее организацией так и со своей ролью и перспективах в компании.
Большинство из них желает скорейшего карьерного роста и повышения зарплаты и перед ними встает вопрос: как проявить себя, как сделать так чтобы твои старания заметили? Ведь одних амбиций и желания проявить себя недостаточно. Если вы хотите самоутвердиться, получить повышение или просто прибавку к зарплате вам недостаточно быть хорошим специалистом, вам необходимо выглядеть «лучше» остальных, выделяться.
В своем выступлении я дам ряд советов из личного опыта, как обратить на себя внимание тех, чьего признания вы добиваетесь и от кого зависит решение о вашем продвижении.
Уже месяц как я провожу эксперимент по парному тестированию в моей компании. Основная его цель – распространить знания между тестировщиками разных команд, занимающихся совершенно разными приложениями и платформами.
Структура эксперимента
Изучив особенности парного тестирования, я разработала структуру своего собственного эксперимента. С моей точки зрения, нужно было четко определить мои ожидания, чтобы более двух десятков моих тестировщиков смогли получить ценный опыт.
Чтобы не звучать безапелляционно, я уделила особое внимание личной ответственности каждого тестировщика за организацию сессий и того, что будет происходить в течение них. Эксперимент никому не навязывался сверху, при этом большинство участников были воодушевлены возможностью поучиться у коллег из других команд.
Я решила, что эксперимент будет продолжаться три-четыре месяца, итеративно. В течение месяца каждая пара тестировщиков будет посвящать совместной работе один час в неделю, еженедельно меняя или проект, над которым они работают, или напарника. К примеру, Сэнди, работающая над проектом А, попала в пару к Дэнни (проект Б). В течение первой недели они тестируют проект А за столом Сэнди, затем тестируют проект Б за столом Дэнни, и так далее. В конце каждого месяца каждая пара проводит четыре сессии тестирования, работая дважды над каждым проектом.
Между итерациями команды делятся обратной связью по эксперименту как таковому и конкретным сессиям парного тестирования. При необходимости по результатам обратной связи параметры эксперимента можно изменить, прежде чем стартовать вторую итерацию.
Я надеялась, что спустя три месяца каждый участник эксперимента будет иметь четкое мнение по поводу ценности парного тестирования и того, как мы можем применять его в дальнейшем. В конце эксперимента я запланировала глубокую ретроспективу, чтобы определить наши дальнейшие действия.
Выступление Александра Орлова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.
Из своих почти 9 лет тестирования 9 лет я проработал в распределенных проектах. Поначалу был тестировщиком, потом руководил командами и отделами тестирования. Проекты были разного размера – от 7 до 150 человек, с разными технологиями и количеством тестировщиков в них.
Кто там говорит про скорость коммуникаций и сидение в одной комнате? Мы работали в двух, трех и даже пяти городах с абсолютной разницей в часовых поясах. А коммуникации нещадно обрубались юридическими отделами корпораций. :) При всем этом удавалось выпускать на рынок продукты, которыми пользовались миллионы людей, и что самое удивительное заказчики практически всегда были довольны нашей работой.
Оглянувшись назад и проанализировав свой опыт, удалось сделать несколько выводов о том, как команде тестирования работать в распределенных командах в условиях сверх-медленных коммуникаций. Этими выводами я и хотел бы поделиться.
Сейчас я работаю над экспериментом в парном тестировании, цель которого – донести знания о тестировании до членов Agile-команд в моей организации. Ниже - краткое содержание изученного мной материала про парное тестирование, который будет полезен желающим внедрить эту практику у себя в компании.
Подход к парному тестированию
Парное тестирование – это способ подойти к тест-дизайну путем одновременного тестирования одной и той же функциональности двумя людьми, находящимися рядом друг с другом и постоянно обменивающимися идеями.
Объединяясь в пару, эти люди используют одно и то же устройство для тестирования. Один из них манипулирует клавиатурой (хотя клавиатура может переходить из рук в руки во время сессии), а другой генерирует идеи для тестов, следит за процессом и ведет записи, слушает, задает вопросы, ищет вспомогательные материалы…
Пара должна работать над одной и той же задачей, имеющей общую, четкую, ясную обоим цель. Хоть они и работают вместе, кто-то один берет на себя полноту ответственности. Этот человек может предварительно подготовиться, но лучше, если пара не будет загонять себя в жесткие рамки. Для начала вполне сгодится простой высокоуровневый чек-лист или набор идей для тестов.
Во время парной сессии тестировщики должны много разговаривать – не меньше, чем тестировать – с целью добиться общего понимания, что они, собственно, делают, и что еще важнее – зачем это вообще делается.
В мае вышла новая версия JMeter 3.0. Концептуальных изменений в ней нет, однако поменялся интерфейс, изменились названия некоторых элементов, а также появились новые элементы.
Работа над курсом кипит, а мы решили поделиться записью первого вводного модуля курса. Модуль позволяет познакомиться с тренером и оценить его манеру преподнесения информации.
Содержание модуля:
Что такое производительность? Тестирование производительности -- зачем мы его проводим?
Функциональные и нефункциональные характеристики качества. Производительность + надёжность + удобство использования (дизайн). Скорость и ресурсоёмкость. Уровни изменений: производительность алгоритмов, производительность ПО, производительность человека, использующего ПО.
Какие ошибки мы можем обнаружить: узкое место («бутылочное горлышко»), медленная подсистема/функция, точки насыщения, функциональные дефекты.
Ложно-положительные и ложно-отрицательные результаты.
В эпизоде TestTalks Пол Гроссман рассказал про свои пять секретов автоматизации тестирования (то есть про пять вещей, которые ни в коем случае не нужно делать, если вы хотите эффективно автоматизировать).
Ниже – краткое содержание интервью с ним.
Отсутствиедокументации
Казалось бы, это очевидная проблема, но я тысячи раз видел, как автоматизация проваливалась из-за того, что никто не понимал, что же она конкретно проверяет. Или из-за того, что она ломалась при любом мелком обновлении. Если вы работаете на крупную компанию, занимающуюся разработкой копроративных приложений, где множество команд вносят свой вклад в автотесты, ваши тест-библиотеки могут быстро вырваться из-под контроля.
Если ваши инженеры не дают своим переменным и методам внятные тестовые названия и не комментируют код, ваши автотесты будет очень тяжело поддерживать. Вы должны убедиться, что ожидаемые и фактические результаты автотестов просты для понимания, и эта информация должна документироваться.
Первое, что сделал Пол, когда стал разбираться в унаследованной от предшественника системе автотестов – это убедился, что каждое внесенное разработкой или тестировщиком изменение внятно документировалось.
Автор: Брэндан О'Коннолли (Bredan O'Connolly)
