Есть множество определений тестирования ПО, и множество взглядов на то, как должно выглядеть ответственное тестирование в нашей области. Ваш взгляд на роль тестировщика влияет на то, какие практики и артефакты вы считаете ценными.
Мое любимое определение тестирования дал Кем Кейнер: «Тестирование – это эмпирическое исследование, которое проводится с целью предоставить заинтересованным лицам информацию о продукте или сервисе, который тестировался».
В целом я рассматриваю тестирование, как часть бизнеса по сбору информации и ее передаче.
Более того, я считаю себя тестировщиком контекстной школы. У нее семь принципов. Вот моя интерпретация этих принципов и то, что они значат лично для меня:
«Ценность любой практики зависит от контекста» и «внутри контекста есть хорошие практики, но лучших не существует». Любая проблема тестирования уникальна. Наш подход к этой проблеме, следовательно, тоже уникален. Выяснить как можно больше и передать другим свое понимание проблемы жизненно необходимо для эффективного тестирования. Чем гибче инструмент или процесс, тем выше количество контекстов, в котором я могу его использовать.
Существует практически бесконечное множество антивирусов, их версий и комбинаций настроек. Ничто в мире не совершенно, поэтому иногда они могут перестараться и, например, заблокировать нужные файлы, в безопасности которых мы уверены. Подобные проблемы совместимости могут повлечь за собой заметный отток пользователей. Чтобы не допустить такого в конечном продукте, есть тестировщики. +
Антивирусы могут просто не давать корректно работать законно купленной игре из-за подозрений на вирусы или даже их реального присутствия (такое тоже случается). Например, из-за отсутствия контроля за безопасностью на ПК разработчика, вирус может попасть в игровой билд, который позже скачают пользователи. Шансы невелики, но подобная оплошность всегда очень сильно бьет по репутации продукта и компании в целом, может повлечь за собой утечку информации о пользователях. «Подозрительные» файлы в игре могут быть помещены в «карантин», а то и просто удалены. Антивирус может блокировать установку ПО или ограничить его доступ в интернет. Например, во время наших тестов COMODO, клиент игры удалялся самим антивирусом после его закрытия. То есть пользователь мог купить игру, спокойно запустить и даже поиграть, а потом просто не обнаружить ее у себя на ПК. Также сильно распространена проблема с обнаружением троянских программ в клиенте игры, установленном на абсолютно чистом ПК. В нашем случае это происходило на Qihoo 360 Total Security Essential с любыми параметрами защиты.
Каждому человеку хочется профессионально расти и развиваться. И область тестирования не исключение. Но в последнее время в тестировании складывается тенденция: если ты не автоматизатор, то и расти особо некуда. Это не так, и наша компания может это доказать!
«Лаборатория качества» ищет талантливого руководителя направления тестирования / аккаунт-менеджера (АМ). Что это значит? Если ты давно работаешь в тестировании, за твоими плечами опыт построения процессов, управления командой и налаживания связей с заказчиком, но ты хочешь большего, то мы готовы предложить тебе работу с разными проектами и множество нестандартных задач.
Какие задачи предполагаются?
Работа с заказчиками:
Налаживание контакта (заказчик не должен быть для вас простой аватаркой в скайпе; вы должны понять, что это за человек и как с ним работать).
Выявление потребностей (не только то, что написано в ТЗ, но и понимание текущих проблем; в идеале – взгляд на готовый продукт глазами заказчика).
Счастье клиентов (решать проблему не тогда, когда уже все горит, и все в огне, а увидеть первые искорки пламени и потушить их, не дожидаясь пожара).
Работа с командой:
Налаживание контактов (решать вопросы, которые не может решить тест-менеджер, и помочь тест-менеджеру научиться в будущем решать их).
Построение процессов (не останавливаться на достигнутом, а постоянно развивать команду и совершенствовать сами процессы работы, внедрять новшества и улучшения).
Счастье команды (наладить единую систему работы заказчик – команда тестирования, донести цели, сроки и задачи по проекту до команды).
Сейчас я готовлюсь к докладу на тему использования статистики тестирования, для которого важно собрать информацию от всех коллег. Для этих целей совместно с порталом организован опрос, в котором Вы сможете поделиться опытом сбора метрик тестирования и полезности анализа тестовых данных.
Просим поделиться своим опытом работы со статистикой тестирования в этом опросе (прохождение опроса займет не более 2 минут), из результатов которого мы сможем понять:
* какие метрики вы собираете и анализируете на постоянной основе
* какая статистика была собрана лишь однажды, но оказалась очень полезной для понимания сути происходящего
* какие графики вы строите на основании собранных данных
* какими инструментами пользуетесь для сбора, хранения и визуализации данных
Более подробную информацию об опросе Вы можете найти в этом топике на форуме.
Большая благодарность каждому, кто поделится примерами графиков, которые Вы создаете на основании собранных метрик тестирования. Ответ не должен быть максимально развернут или как-то аргументирован. Важно лишь узнать какую статистику собирают и используют на практике другие команды, и какие самые популярные виды графиков, построенные на основании собранных тест данных.
Результаты опроса будут также позже опубликованы на портале.
Возможно ли уменьшить или даже исключить человеческий фактор при тестировании релизов программного обеспечения? Коротко говоря, да. В этой статье говорится как.
Тестирование релиз-кандидатов отнимает слишком много времени.
Для большинства agile команд - это одна из самых сложных задач. С этим снова и снова сталкиваются мои клиенты и коллеги, которые работают над крупными интегрированными веб-сайтами и приложениями.
Но что, если вам не нужно было бы прибегать к помощи сотрудника для проверки определенной версии билда, чтобы минимизировать риски перед деплоем? Вместо него бот сообщал бы команде о готовности билда и кому-то оставалось бы только нажать кнопку деплоя?
Внедрение такой практики потребует расширения инфраструктуры и улучшения дисциплины. Возможно, это нереализуемо в вашей команде, но существуют компании, применяющие такой подход на регулярной основе.
«В одном IT-царстве жила-была себе команда тестировщиков: Алеша Попович, Добрыня Никитич, Любава и Гай Юлий. Были в том царстве и разработчики – Змей Горыныч, Илья Муромец и Тихон. Ну и, конечно же, присутствовал тим-менеджер Царь. Все они, такие разные, творили одно доброе дело и корпели над одним общим заданием: укрепить и облегчить жизнь мирскую и не пропустить ни одного Бага. Объединяло их общее желание и стремление, а посему и решили они – будем работать вместе».
Работа над проектом – это командный процесс. В любом коллективе значительную роль играет человеческий фактор. Оставлять его без внимания нельзя – напротив, всегда нужно предвидеть и учитывать возможные сложности. Все мы разные, у всех у нас свой склад характера, взгляд на вещи и отношение к работе. Очень важно найти правильный подход к каждому сотруднику для того, чтобы не просто объединить коллектив общим проектом, но и создать комфортные условия работы. Помочь в этом может соблюдение основных принципов, которые делают коллективный труд продуктивным и результативным:
внедрение в сознание всех сотрудников постулата «общее дело объединяет»;
установление дружелюбных, искренних и налаженных коллективных отношений;
достижение сплоченности как важного фактора эффективности;
понимание того, что любой человек в команде – важное звено;
налаживание взаимодействия каждого участника со всеми остальными;
учет мотивации каждого конкретного сотрудника в зависимости от его выявленных целей и желаний.
Так уж сложилось на практике, что самые главные инструменты для специалиста в сфере тестирования ПО - это его зоркий глаз, пытливый ум и интуиция. Тем не менее, жизнь тестировщика "и опасна, и трудна", и чтобы её сделать несколько комфортнее, существует ряд замечательных инструментов. И как раз о таких инструментах будет данный доклад.
Из семян взращиваются тестовые идеи – как сорняки. Следуйте за ними. Нам нужно как можно больше идей и мыслей, как можно больше покрытия, чтобы принимать наилучшие решения про общее тестовое покрытие. Поначалу это будет выглядеть уродливо и неорганизованно. Но дайте модели вырасти. Начните переставлять ветки, подрежьте некоторые из них. По мере роста веток создание карты побудит вас задавать более четкие вопросы участникам проекта. Карта становится инструментом по улучшению самой себя. Этим и прекрасны органические системы – бросьте в них семечко, и оно вырастет само по себе, с нами в роли безумного садовника.
Вот как выглядит модель тестового покрытия после чтения спецификации и разговора с разработчиком:
На этом этапе план тестового покрытия и план покрытия продукта практически идентичны по своей природе, за тем исключением, что план тестового покрытия описывает и включает в себя тип тестирования и вопросы для исследования.
10-11 марта, в Минске, сообщество COMAQA.BY проведет большую конференцию выходного дня, посвященную вопросам ручного и автоматизированного тестирования, DevOps, разработки в контексте автоматизации и менеджмента в тестировании.
Спикеры из ведущих IT-компаний Швеции, Германии, Финляндии, Ирландии, России и Беларуси соберутся вместе, чтобы рассказать о своем опыте в тестировании и управлении, поделиться личными практическими “секретами” и наработками.
Организаторы подготовили для вас:
16 докладов в первый день конференции от профессионалов-практиков;
Видеотрансляцию докладов (условно платную) для тех, кто захочет присоединиться удаленно;
3 потока мастер-классов во второй день конференции;
Обед и кофе-паузы для комфортного общения со спикерами и нетворкинга;
Сувениры от организаторов и партнеров конференции.
Наверняка многие тестировщики хотя бы раз сталкивались с ситуацией, когда времени на тестирование совершенно нет. Даже если им чуточку повезло, и хоть какое-то время осталось, то его все равно не хватит на проверку всего продукта. И не столь важно, почему так получилось (неправильно спланирована работа, заказчик захотел «прикрутить вон ту фичу» в самый последний момент, тестировщиков поздно подключили к проекту), – главное в том, что выходить из положения как-то нужно.
Итак, что же делать, когда времени вовсе не осталось, а тестировать хочешь не хочешь, но надо? Можно искать виноватых, кивать друг на друга, бегать в панике, но, как мне кажется, каждый понимает, что это неконструктивный подход. В этой статье я расскажу о своем опыте, позволяющем справиться с тесными временными рамками. Ниже я составила список подходов, которые можно применить в условиях сжатых сроков.
