10-11 марта, в Минске, сообщество COMAQA.BY проведет большую конференцию выходного дня COMAQASpring 2018, посвященную вопросам ручного и автоматизированного тестирования, DevOps, разработки в контексте автоматизации и менеджмента в тестировании.
11 марта в рамках конференции организаторы подготовили для Вас новый формат участия – день, полностью посвященный мастер-классам.
Каждый мастер-класс проходит в небольшой группе – до 20 участников. Каждый мастер-класс это практика. В процессе Вы вместе со спикером детально прорабатываете тему мастер-класса, разбираете интересующие Вас вопросы и ситуации, возникающие конкретно в Вашем проекте.
На COMAQA Spring 2018 вас ожидают 3 потока мастер-классов:
1 поток: два мастер-класса, направленных на развитие soft-skills в контексте тестирования и не только:
"Mindset Tools approach to testing" от Vivien Ibironke Ibiyemi. Вы будете поражены тем, использование подхода «Mindset tools» может «катапультировать» ваше мышление и направить вас на непрерывный рост, независимо от вашей роли в проекте;
"Деловые переговоры в голливудском стиле" от Романа Сороки в формате деловой игры, где Вы наглядно увидите, из каких этапов состоят переговоры, и научитесь заключать контракты в ролях заказчика и подрядчика.
Обычно на должность руководителя проектов в IT-компании требуются люди с опытом от 1 года. Поэтому часто неопытные менеджеры устраиваются на работу аналитиками, тестировщиками, иногда даже разработчиками.
Если хорошо себя проявить, то со временем вам будут доверять больше управленческих задач. При этом не всегда получается отказаться от старых обязанностей. Приходится совмещать две роли на проекте. Так и я, имея опыт в тестировании и аналитике, дополнительно стала получать задачи руководителя проекта. Со временем я полностью перешла в управление проектами.
В этой статье я делюсь наблюдениями и выводами. Как в одном человеке конфликтуют привычки тестировщика и обязанности руководителя проекта? С какими проблемами приходится сталкиваться? Какую пользу можно извлечь при таком переходе? Если хотите получить ответы на эти вопросы, добро пожаловать под кат.
Работа с тестовыми инструментами обычно начинается с немедленной яростной обратной связи. Со временем программисты добавляют новые фичи, тестировщики – новые тесты, и тесты занимают все больше и больше времени. Чтобы чем-то себя занять, технический персонал работает над чем-нибудь еще, ожидая, пока тесты закончат работу.
Рано или поздно тест-результаты становятся такими медленными, что уже неактуальны – а даже если актуальны, нуждаются в археологах, чтобы разобраться, что в них вообще происходит. Все это можно предотвратить быстрой обратной связью.
Мои советы нацелены на ускорение петли обратной связи: тестируйте меньше, распределяя тесты во времени и пространстве. Для этого придется запускать расширенный набор инструментов, коммерческих или открытых, предоставляющих большее покрытие при более медленном темпе и быстрейшими, наиболее важными тестами, работающими непрерывно.
10-11 марта, в Минске, сообщество COMAQA.BY проведет большую конференцию выходного дня COMAQASpring 2018, посвященную вопросам ручного и автоматизированного тестирования, DevOps, разработки в контексте автоматизации и менеджмента в тестировании.
Спикеры из ведущих IT-компаний Швеции, Германии, Финляндии, России и Беларуси соберутся вместе, чтобы рассказать о своем опыте в тестировании и управлении, поделиться личными практическими “секретами” и наработками.
Организаторы подготовили для вас:
★ 16 докладов в первый день конференции от профессионалов-практиков;
★ видеотрансляцию докладов для тех, кто захочет присоединиться удаленно;
★ 3 потока мастер-классов во второй день конференции;
★ Обед, кофе-паузы и after-party для неформального общения со спикерами и нетворкинга;
★ Сувениры от организаторов и партнеров конференции.
Полную программу и билеты вы найдете на официальном сайте конференции: conference.comaqa.by
Тестировщики! Когда мы обсуждаем ручное тестирование, мы помогаем “тонуть кораблю”.
Это сильное заявление, но оно сформировано на основании долгих лет наблюдения за людьми, которые говорят на тему тестирования неосторожно. Опасность заключается в том, что людей, не специализирующихся на тестировании (и даже некоторых из тех, кто специализируется) вводит в заблуждение формулировка, что какой-то вид тестирования называется “ручным”, а какой-то - “автоматизированным”. Они не понимают, что разработка ПО и тестирование в рамках разработки можно сравнить с тонкой дизайнерской работой, а не фабричным выпуском продукции. Эти люди ослеплены скоростью и надежностью автоматизации, внедренной на производстве. Очень скоро они зацикливаются на идее, что тестирование может быть автоматизировано. Ручное тестирование - плохо, автоматизация - хорошо.
Впоследствии тестировщики, обладающие хорошими способностями к критическому мышлению, и навыками выявления проблем, испытывают сложности в поиске работы. Вместо них нанимают тестировщиков с весьма скромными навыками программирования и не внушающими доверия аналитическими способностями, которые месяцами пишут программы, суть которых сводится к нажатию кнопок компьютером. Целью становится отладка автоматизированных проверок, а не выявление проблем функционала, который важен для пользователя. Сложности, связанные с тем, чтобы “заставить” компьютер взаимодействовать с продуктом, отнимают время, которое могло быть потрачено на изучение продукта и наблюдение за тем, как ведет себя система. В результате имеем продукт, который мог быть тщательно или не очень протестирован, но в котором присутствуют дефекты, снижающие или даже напрочь уничтожающие его ценность.
Тема внедрения KPI в тестирование является актуальной уже много лет, этому вопросу посвящено немало исследований. В данной статье мы на примере реального проекта рассмотрим процесс внедрения KPI и методику оценки качества нашей работы.
Что такое KPI?
Итак, для начала обратимся к самому понятию KPI. KPI (Key Performance Indicator) – это показатель достижения успеха в определенной деятельности или в достижении определенных целей. Можно сказать, что KPI – это количественно измеримый индикатор фактически достигнутых результатов.
В нашем случае KPI на проекте – это показатель эффективности работы всей команды тестирования. Помимо термина KPI в статье будет использоваться термин «метрики», под которым мы будем понимать числовое значение для измерения этой эффективности.
Есть множество определений тестирования ПО, и множество взглядов на то, как должно выглядеть ответственное тестирование в нашей области. Ваш взгляд на роль тестировщика влияет на то, какие практики и артефакты вы считаете ценными.
Мое любимое определение тестирования дал Кем Кейнер: «Тестирование – это эмпирическое исследование, которое проводится с целью предоставить заинтересованным лицам информацию о продукте или сервисе, который тестировался».
В целом я рассматриваю тестирование, как часть бизнеса по сбору информации и ее передаче.
Более того, я считаю себя тестировщиком контекстной школы. У нее семь принципов. Вот моя интерпретация этих принципов и то, что они значат лично для меня:
«Ценность любой практики зависит от контекста» и «внутри контекста есть хорошие практики, но лучших не существует». Любая проблема тестирования уникальна. Наш подход к этой проблеме, следовательно, тоже уникален. Выяснить как можно больше и передать другим свое понимание проблемы жизненно необходимо для эффективного тестирования. Чем гибче инструмент или процесс, тем выше количество контекстов, в котором я могу его использовать.
Существует практически бесконечное множество антивирусов, их версий и комбинаций настроек. Ничто в мире не совершенно, поэтому иногда они могут перестараться и, например, заблокировать нужные файлы, в безопасности которых мы уверены. Подобные проблемы совместимости могут повлечь за собой заметный отток пользователей. Чтобы не допустить такого в конечном продукте, есть тестировщики. +
Антивирусы могут просто не давать корректно работать законно купленной игре из-за подозрений на вирусы или даже их реального присутствия (такое тоже случается). Например, из-за отсутствия контроля за безопасностью на ПК разработчика, вирус может попасть в игровой билд, который позже скачают пользователи. Шансы невелики, но подобная оплошность всегда очень сильно бьет по репутации продукта и компании в целом, может повлечь за собой утечку информации о пользователях. «Подозрительные» файлы в игре могут быть помещены в «карантин», а то и просто удалены. Антивирус может блокировать установку ПО или ограничить его доступ в интернет. Например, во время наших тестов COMODO, клиент игры удалялся самим антивирусом после его закрытия. То есть пользователь мог купить игру, спокойно запустить и даже поиграть, а потом просто не обнаружить ее у себя на ПК. Также сильно распространена проблема с обнаружением троянских программ в клиенте игры, установленном на абсолютно чистом ПК. В нашем случае это происходило на Qihoo 360 Total Security Essential с любыми параметрами защиты.
Каждому человеку хочется профессионально расти и развиваться. И область тестирования не исключение. Но в последнее время в тестировании складывается тенденция: если ты не автоматизатор, то и расти особо некуда. Это не так, и наша компания может это доказать!
«Лаборатория качества» ищет талантливого руководителя направления тестирования / аккаунт-менеджера (АМ). Что это значит? Если ты давно работаешь в тестировании, за твоими плечами опыт построения процессов, управления командой и налаживания связей с заказчиком, но ты хочешь большего, то мы готовы предложить тебе работу с разными проектами и множество нестандартных задач.
Какие задачи предполагаются?
Работа с заказчиками:
Налаживание контакта (заказчик не должен быть для вас простой аватаркой в скайпе; вы должны понять, что это за человек и как с ним работать).
Выявление потребностей (не только то, что написано в ТЗ, но и понимание текущих проблем; в идеале – взгляд на готовый продукт глазами заказчика).
Счастье клиентов (решать проблему не тогда, когда уже все горит, и все в огне, а увидеть первые искорки пламени и потушить их, не дожидаясь пожара).
Работа с командой:
Налаживание контактов (решать вопросы, которые не может решить тест-менеджер, и помочь тест-менеджеру научиться в будущем решать их).
Построение процессов (не останавливаться на достигнутом, а постоянно развивать команду и совершенствовать сами процессы работы, внедрять новшества и улучшения).
Счастье команды (наладить единую систему работы заказчик – команда тестирования, донести цели, сроки и задачи по проекту до команды).
