Выступление Сергея Атрощенкова на онлайн-конференции для тест-менеджеров Chief ConfeT&QA.
Когда-то давным-давно, в середине 60-х, в США появился праздник Кванза. Это один из афроамериканских фестивалей, представляющий собой неделю предновогодних торжеств. Считается, что праздник «первого плода» отмечался в древней Нубии в эпоху фараонов, кроме того, его праздновали в средневековых африканских государствах Йоруба и Ашанти. В основу праздника положены африканские традиции и глубинная мысль, провозглашающая Семь Принципов жизни и ценностей сообщества: Единство, Самоопределение, Коллективизм, Совместная экономика, Цель, Творческий потенциал и Вера.
Казалось бы, при чем здесь тестирование?
Да при том, что принципы данного веселого мероприятия очень хорошо ложатся в основу работы любых IT команд, а в нашем случае – тестировщиков.
А когда таких принципов целых семь… Есть где развернуться и организаторским навыкам, и фантазии, и аналитическим способностям всё-улучшающего ума.
Чем принцип Единства не прекрасная возможность объединять различные роли: аналитиков, разработчиков, программистов, системных администраторов в едином порыве, нацеленном на работу над качественным продуктом?
А принцип Творчества? Чем не возможность проявить себя в тест-аналитике?
Я расскажу о том, как принципы Кванзы можно применять в своей команде, например в команде тестирования, если есть полное взаимопонимание между различными проектными ролями.
После этого доклада у тест-менеджеров и им сочувствующих сложится понимание того, как можно работать с командой не держа в голове кучу умных слов. Простое мнемоническое правило, легко запоминаемое и покрывающее навыки: организации команды, персональной работы с сотрудниками, мотивации, создания миссии команды и межролевых взаимодействий после внедрения сможет упростить им жизнь.
Меня регулярно спрашивают, как измеряется эффективность тестировщика. Обычно я отвечаю "Зачем это вам? Чтобы что?" Мой ответ вызван желанием понять мотивы менеджмента: почему измерение эффективности конкретного человека так важно для них? Обычно этот вопрос задают именно менеджеры.
Конечно, важно знать, насколько хорошо человек справляется со своей работой и достигает поставленных целей. Но не менее важно понимать, что движет теми, кто пытается это измерять. Это делается, чтобы развивать и улучшать сотрудника, предоставить ему возможности для обучения и поддержку? Или исходя из чисто коммерческих соображений?
Поймите меня правильно, я люблю метрики. Мы измеряем кучу всяких параметров, но предельно осторожно относимся к результатам подобных измерений.
В ответ на свой вопрос я обычно слышу, что менеджеры (особенно тест-менеджеры) используют эту метрику, пытаясь обосновать, что этот тестировщик действительно стоит (или не стоит) своих денег.
Как правило, они пытаются измерять две вещи. Во-первых, одинаково ли ценны тестировщик А и тестировщик Б? Можем ли мы поменять их местами и продолжать достигать своих целей? Может, один из них лучше другого?
Во-вторых, они пытаются измерить, приносят ли тестировщик А и тестировщик Б вообще какую-то ценность (что произойдет, если мы от них избавимся?).
Зачастую это приводит к тому, что менеджеры начинают измерять какую-то дичь – скажем, количество выполненных тест-кейсов, или количество найденных багов, и считают это метрикой эффективности тестировщика.
Звучит бредово, но встречается достаточно часто! Менеджеры любят простые метрики для принятия информированных решений.
В современном мире мобильными приложениями никого не удивить, наверняка каждый из вас пользуется ими ежедневно будь то игры, социальные сети или учет финансов. Заказать такси, посмотреть новости, купить билет на самолет - сейчас все это сделать легко. Но при условии, что приложение на вашем устройстве работает корректно.
Поэтому вопрос тестирования мобильных приложений так актуален в наше время. Есть ли какие-то особенности у данного процесса? Конечно! Различные типы устройств, не один десяток разрешений экрана, несколько версий операционных систем, разные типы подключения к интернету - вот далеко не полный список того, что может усложнить этот процесс.
На конференции SQA Days 19 наши коллеги, которые сталкиваются с тестированием мобильных приложений каждый день, рассказали, как именно проводить данный вид тестирования, о чем нельзя забывать в процессе и как свои теоретические знания применить на практике.
Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения - SQA Days-20, Минск, ноябрь.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Множество компаний считает, что тестировщики обязаны использовать тот язык программирования, на котором написано тестируемое приложение. Если компания пишет на Java, то все тестовые решения обязаны быть именно на Java. Это абсолютно неверный, близорукий подход к вопросу. Такая ситуация возникает, если менеджеры разработки отвечают за создание тест-команды, или когда тестировщикам приходится полагаться на других людей, чтобы они сделали их работу (и заодно подумали) вместо них самих.
Конечно, я преувеличиваю, и, возможно, это несправедливо по отношению к командам и компаниям, но я довольно часто сталкиваюсь с подобной точкой зрения, и она не перестает меня раздражать. Честно говоря, я и сам когда-то так считал – я спрашивал, должен ли язык разработки соответствовать языку автотестов. По тексту может показаться, что я склоняюсь к ответу "должен", но на самом деле я в тот момент экспериментировал со своими практиками. Большинство этих экспериментов крутились вокруг ответа на вопрос, который часто задают мне тестировщики: какой язык программирования осваивать?
В моей компании царит культура общей ответственности за создание программного обеспечения. Над нашими приложениями работают кросс-функциональные Agile-команды, совместно стремящиеся достичь целей бизнеса. Однако специалисты все еще нечасто стремятся проактивно поработать над задачами, не входящими в их прямые обязанности. К примеру, бизнес-аналитики не рвутся прогнать пару-тройку тестов и не ставят подобные задачи выше своих задач по поддержке бэклога.
Несмотря на это, недавно я отметила, что все больше разработчиков добровольно подключаются к тестированию. Нет, они не раздумывают над планированием тестирования, и не впадают в экстаз от идеи поисследовать приложение. Однако они помогают нам с автоматизацией, улучшая ее тестовое покрытие, а также работают над улучшением фреймворка, на котором запускаются наши тесты.
Я отвечаю за тренинги в нашем коллективе, и, в частности, за развитие кроссдисциплинарного сотрудничества. Честно говоря, я уделяла мало внимания развитию взаимоотношений между разработчиками и тестировщиками. Все изменения, которые в них произошли – это побочный эффект другой деятельности, к которой я имела отношение. Я хочу поговорить о причинах таких перемен и о том, почему мне кажется, что разработчики стали больше вовлекаться в тестирование.
Тестирование в стартапе, конечно, отличается от тестирования в большой компании. Продукт, с которым вы работаете, часто меняется, и это неизбежно, если ваш стартап ориентирован на успешный конечный результат. Кадровые ресурсы ограничены: ваш продукт не будет тестировать целый отдел, а банальное ограничение средств может сказаться на количестве тестировщиков в команде.
Чтобы понять, как грамотно организовать тестирование будучи стартапером, лучше всего прислушаться к опыту тех, кто знает об этом не понаслышке. На прошедшей в мае конференции SQA Days 19 некоторые докладчики делились своим опытом как раз на примерах стартапа.
Ниже вы можете посмотреть записи докладов на эту тему и, кстати, узнаете не только о том, как преодолеть сложности, работая в стартапе, но и о плюсах работы в таких условиях.
Возможно, немедленно уведомить о баге сразу же после того, как вы его обнаружили – не самая удачная идея. Сильное заявление? Возможно. Я попробую обосновать его при помощи реальной истории, которая недавно произошла со мной, а дальше перейду к теории.
Мы проводили рефакторинг одной из частей нашего приложения. Там использовался Javascript, и присутствовала корзина интернет-магазина. Я решил проверить, как она среагирует на максимально большие числа, и нашел баг. Перемножение очень больших чисел приводило, судя по всему, к фризу всей корзины. Я нажал F12, чтобы проверить, что происходит конкретно. Виноваты оказались не большие числа как таковые. Виновно было переполнение, возникающее из-за ошибки точности в Javascript (я быстро выяснил все про эту ошибку: http://www.w3schools.com/js/tryit.asp?filename=tryjs_inaccurate2). Ага, вот в чем дело! Как еще можно вызвать эту проблему? Я попробовал ввести совершенно обычные числа, которые спровоцируют ту же самую ошибку – и фриз повторился. Призванный на помощь разработчик даже не нуждался в подробных разъяснениях.
Почему бы не сообщить о баге сразу? Потому что баг, возникающий при перемножении 999999999999.99 на 99 вызовет реакцию "Какой нормальный человек так сделает", или "Ну засунь ее в бэклог, где-нибудь в 2038 году мы разберемся" – и такая реакция может быть вполне оправданной. Но демонстрация, что баг воспроизводится и на вполне обычных числах, вроде умножения 25,89 на 3, приведет к мгновенному исправлению проблемы.
Приглашаем в нашу команду инженеров по автоматизированному тестированию. Ищем настоящих QA, которые горят искренним желанием усовершенствовать процессы тестирования и улучшить качество продукта. Мы поддерживаем потенциал и саморазвитие, поэтому с интересом рассмотрим резюме, стремящихся к развитию Junior'ов. Если наши вакансии вас заинтересовали, смело отправляйте резюме.
Петер-Сервис - лидер российского рынка программного обеспечения для телекома. Более 100 млн абонентов в 13 странах мира пользуются нашими решениями ежедневно, сегодня почти каждый звонок в стране обрабатывается с нашей помощью. А это значит – настоящий highload, системы находятся под действительно высокой нагрузкой, обрабатывая гигантские объемы данных. У нас одно из самых сложных производств ПО в России.
Мы создаем максимально комфортную рабочую атмосферу для наших сотрудников, чтобы работа была для них местом вдохновения, обмена идеями и приятного общения.
У нас вы найдете:
Достойную оплату: полностью «белая» заработная плата, понятная премиальная система;
Центр обучения: повышение профессионального уровня, бесплатные курсы английского и испанского языков;
Интересные задачи: проекты федерального масштаба с уникальной структурой;
Сильную команду: работа в команде экспертов высокого уровня;
Заботу о здоровье: ДМС, страхование от несчастных случаев, компенсация затрат на питание, программы лояльности для страхования членов семьи;
Дополнительные материальные выплаты: пособие при рождении ребенка, свадьбе и др.;
Еще много интересного: возможность отдохнуть с семьей в Риме, дни заботы о здоровье сотрудников, мероприятия для сплочения сотрудников и многое другое.
Выступление Александра Федорова на онлайн-конференции для тест-менеджеров Chief ConfeT&QA.
По роду своей деятельности еще недавно я проводил множество собеседований, при этом я не мог себе позволить тратить по часу на каждое – ведь работа не ждет. В то же время, подбор кадров для компании – ответственная задача, и спускать рукава тут никак нельзя. В результате я стал анализировать процесс собеседования с целью его оптимизации: как за минимальное время узнать максимум полезной информации о кандидате на роль тестировщика? С результатом моих изысканий вы сможете ознакомиться на моём докладе. Он будет полезен тем менеджерам, кто ценит свое время и так же помешан на рациональности, как и я.
Вы узнаете:
какие вопросы на собеседовании полезны, а какие только тянут время?
какие задачки использовать, чтобы быстро оценить тестировщика?
что делать, если вы сомневаетесь – брать сотрудника или нет?
что делать с персональными симпатиями при подборе персонала?
как поступить, если с самого начала вы понимаете, что этот сотрудник вам не подойдет?
"Я знаю, как произнести "банан" по буквам, но я не знаю, когда мне остановиться", как сказала одна маленькая девочка.
Прелесть идеально "сценарных" задач в том, что мы всегда знаем, когда нам остановиться. Последняя нота, последняя строчка диалога в сценарии, последний кусочек пустого места на холсте означают, что конец работы близко. Если вы используете сценарный подход к тестированию, то вы останавливаетесь, если заметили проблему, или если у вас появились вопросы/любопытные идеи.
Если вы исследуете продукт, сказать, когда нужно остановиться, не так-то просто. На джем-сейшенах музыканты сигнализируют друг другу при помощи глаз и музыки, когда нужно затихнуть или остановиться совсем. Для человека неопытного причины, влияющие на решение закончить работу, могут быть непонятными или незримыми. Даже в среде артистов менее опытные люди могут быть не в состоянии объяснить, почему все остановились, но у мастера своего дела с объяснениями никаких затруднений не будет.
Как нам определить, когда нужно остановиться?
Первый шаг на этом пути – это осознание, что мы не можем быть уверены, что мы завершили свою работу. Любая попытка найти ответ на вопрос, когда нужно остановиться – это эвристика. Эвристики – быстрый и дешевый метод принятия решений. Они ненадежны – могут сработать, а могут и нет. Они абстрактны и могут быть похожими друг на друга. Они зависимы от контекста – предполагается, что ими будет пользоваться достаточно компетентный и опытный человек. Они похожи на лампочки на приборной панели вашей машины. Когда какая-то из них загорается, вам нужно решить, а не остановиться ли до того момента, пока она снова не станет зеленой – но, возможно, важнее игнорировать ее и продолжать движение?
Я составил список эвристик для остановки тестирования, а также привел причины для сомнений в каждой из них.
Автор: Джефф Найман
Автор: Майкл Болтон (Michael Bolton)