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