Добрый день Меня зовут Евгений, я руководитель отдела тестирования облачных решений Acronis и хочу рассказать вам о том, как мы все это делаем.
Совсем, ОК — это почти как КГБ: нас не всегда видно, но мы везде .
Мы участвуем в процессах, начиная с самых ранних стадий, когда технические требования еще обсуждаются, дорабатываются и создаются черновые прототипы функций.
QA не имеет права голоса, но всегда объясняет разработчику и менеджеру программы опасные места, исходя из своего опыта.
И, как правило, это объяснение влияет на требования к фиче.
Пошаговый процесс
Первый этап: дизайнер, нарисовавший фичу в интерфейсе, разработчик, PM и QA садятся в одной комнате и обсуждают, как это должно работать.В самом начале мы занимаем позицию «Что будет, если…» — думаем о том, что будет с продуктом во время продажи и какие подводные камни могут возникнуть в этом процессе.
Ученый по продукту редко оценивает фичу именно с точки зрения стабильности — его задача — подумать о том, как она поможет конечному пользователю, а наша — подумать о том, как она может навредить.
Например, однажды мы захотели добавить пару настроек и предоставить доступ к ним еще одной роли для пользователей чуть ниже администратора.
Мы, как представители обычных пользователей, выступили против, поскольку это усложняло интерфейс и понимание происходящего.
Вместо этого мы решили сделать эту функцию по-другому, разгрузив графический интерфейс, но добавив эти параметры как скрытые сущности в консоли.
Второй этап: QA смотрит технические характеристики и показывает дефектные места (как правило, это касается системных вещей — типа, что лучше сделать по-другому на текущей архитектуре или с пониманием той новой архитектуры, к которой мы движемся).
Когда все готово, начинается «продажа функций»: разработчик собирает дизайнера, PM и представителя QA. Дизайнер проверяет, что сделано так, как он задумал, ПМ смотрит функционал, а QA соглашается, что фичу можно тестировать в таком виде.
Затем фича после реализации возвращается на QA от разработчика и получает уровень качества.
Конечно, разработчик перед этим сам тестирует, как может. Если фича попадает на сырой QA, то мы ставим ей низкий уровень, и она сразу, без дальнейшего рассмотрения, уходит обратно в разработку со списком открытых ошибок.
Если функция успешно «продана» и выполняет свою функцию, то начинается работа.
Первым этапом является уточнение плана испытаний.
Как правило, мы начинаем писать план тестирования сразу после того, как требования к функции согласованы и записаны.
Автотесты можно писать сразу или добавлять со средним и низким приоритетом.
Бывает, что фича будет проверена автотестом только в критических местах, а затем постепенно включена в план более полной обкатки на роботах.
Естественно, не все функции являются кандидатами на автоматизацию.
Например, в сегменте Enterprise часто бывает много разовых мелочей, которые нужны буквально паре компаний-заказчиков.
Чаще всего они проверяются вручную, как мелкие функции в потребительских товарах.
А вот все, что отвечает за непосредственную функциональность продукта, почти всегда полностью покрывается автотестами, но не всегда за один проход. У нас есть собственный фреймворк Python для написания тестов.
Далее по плану проводится ручное и автоматическое тестирование.
Результатом этого этапа является оценка, основанная на уровне качества.
Чтобы функция была включена в релиз, она должна получить «4» или «5» по пятибалльной шкале.
При пятерке (придирки, пожелания по улучшению) проходит без вопросов, при четверке (парочка не очень существенных крупных ошибок) включается в релиз только по решению продакт-менеджера.
В целом: 1 - функция не работает вообще, 2 - работает, но большая часть ее функционала не реализована, 3 - значительная часть работает, но есть очень неприятные критические баги, 4 - работает практически полностью, но есть мелкие жалобы.
5 - функция работает идеально, ошибок либо вообще нет, либо они совсем незначительны.
Пару раз в год мы подключаем необходимый функционал с рейтингом чуть ниже четверки, но для конечного клиента всегда помечаем его как бета-версию.
Если ошибка затрагивает базовую функциональность, то она имеет критический приоритет; если он еще и стреляет часто, то у него очень высокий приоритет по срочности.
Ошибки при ручном тестировании создаются вручную в Jira. Ошибки автотеста обнаруживаются автоматически, и наш фреймворк проверяет, существует ли уже такая ошибка и имеет ли смысл ее повторно открыть.
Критичность и приоритет ошибки назначается вручную специалистом по контролю качества.
Что происходит, если разработчик не согласен с мнением отдела контроля качества об ошибке? Потом мы все вместе сядем и разберемся.
Надо сказать, что года три назад действительно была такая проблема, но сейчас мы выделили QA в отдельный отдел и записали довольно много признаков и свойств бага, не допускающих двоякой трактовки.
Вообще все наши разработки в России, большая часть людей в Москве.
Весь QA сидит в одном офисе и рядом, поэтому проблем с разъяснениями и взаимодействием не возникает. Он быстро прибыл на ноги и оперативно все обсудил.
Это очень помогает. Сначала мы проверяем сборки на местных стендах.
Если все ок, то загружаем эту сборку в препродакшн, развернутую на производственной инфраструктуре, где находится последняя выпущенная сборка.
Таким образом, мы еще раз проверяем обновление в условиях, максимально приближенных к реальному производству.
После этого загружаем сборку на бета-сервер.
У нас есть портал, на котором можно поиграться с новой версией (как правило, туда имеют доступ наши проверенные и самые активные партнеры и дают достаточно обширные отзывы).
Кстати, если вы хотите получить приглашение на этот сервер, вы можете написать коллегам и они все организуют ([email protected]).
Люди
Требования к QA почти такие же, как и к разработчикам, но с учетом того, что вам придется писать в основном автотесты.Плюс мы подбираем людей, которые понимают основы UI/UX (и при необходимости проводим дополнительное обучение), потому что большая часть фич теперь находится на стыке с интерфейсом.
В нашу команду входят специалисты технически грамотные, обязательно сообразительные и обладающие развитой логикой.
Время тестировщиков, как обезьян, тупо повторяющих тесты, давно прошло.
Вместо обезьянок у нас модули автотестирования, которые сами разворачивают инфраструктуру примерно из 30 стандартных сред, приводят ее в нужное состояние, устанавливают бета-версии и запускают их через тестовую программу, попутно записывая логи и делая скриншоты.
Хотя, конечно, ручного труда у нас еще достаточно много.
Обычно распределение рабочего времени следующее: 30% уходит на общение с разработчиками и уточнение технических требований, затем примерно половина уходит на ручную работу и написание автоматических тестов в нашем фреймворке.
Естественно, есть люди, которые всё больше и больше делают руками, а есть те, кто почти всегда пишет код. Говоря о развитии тестирования как профессии, могу сказать, что инженеры по автоматизации часто хотят попробовать себя в роли разработчика.
Почему? Потому что до сих пор существует стереотип, что в разработке ты делаешь свой продукт, а в тестировании обслуживаешь чужой.
Наш путь немного отличается от этого стандартного — дело в том, что задачи по автоматизации зачастую интереснее задач по разработке.
Большая часть развития в стабильных многолетних проектах — это поддержка.
А у нас в стране, как оказалось, последние несколько лет развитие шло достаточно бурно: мы только поднимали ракетостроение на испытания.
Раньше я работал в Parallels, и мы потратили пять лет на разработку системы, которая все автоматизирует. От виртуальных машин до аппаратного обеспечения, где программное обеспечение развертывается, запускается, отправляются ошибки и отмечаются проверенные ошибки.
Я думаю, нас ждут бурные пару лет. Поэтому наши лучшие специалисты часто вырастают в менеджеров по продукту.
Поскольку квалификация предполагает мышление на несколько шагов вперед, плюс коммуникабельность, плюс знание всего продукта, плюс желание улучшить продукт и понимание того, что в нем следует улучшить в первую очередь, то за 2-3 года работы в QA вы получаете практически готовый ПМ.
.
Рекурсия
Автотесты проверяет тот, кто их написал.
В противном случае нам понадобится еще один QA.
Старые мелкие ошибки
Практически каждый трекер долгосрочных проектов накапливает группу несрочных, несерьезных или вообще странных редких багов с самым низким приоритетом, которые тянутся хвостом из года в год. На их основе мы примерно раз в год проводим процедуру переоценки и решаем, нужно ли тянуть хвост. Чаще всего в этом нет необходимости.Закрываем его усилием воли и «отрезаем» хвостик.
«Внешние» ошибки
После релизов к нам приходят баги от поддержки или от команды, ищущей отзывы в соцсетях (от них больше подозрений, чем готовых симптомов).Иногда до третьей строчки доходят совершенно волшебные вещи.
Например, клиент (Тайвань, источник – английская поддержка) установил продукт на ОС Win8.1 Pro и использовал его для создания «защищенной области на диске», а затем 750 раз перезагрузил свой ПК.
И после этого у него начал мерцать экран.
По настоятельной просьбе пользователя этот скрипт был протестирован несколько раз на разных машинах.
Или вот история из Гонконга: СЦЕНАРИЙ: 1) Создайте резервную копию диска, на котором установлена старая ОС, например Win98 или DOS в данном случае (не поддерживается UR) и Windows 7. 2) Загрузите ту же систему, используя загрузочный носитель ABR 11 с функцией Universal Restore. 3) Создайте задачу восстановления и выберите вышеупомянутую резервную копию диска.
4) Выберите диск/разделы для восстановления.
ФАКТИЧЕСКИЙ РЕЗУЛЬТАТ: Universal Restore не предлагается во время восстановления диска/раздела.
ОЖИДАЕМЫЙ РЕЗУЛЬТАТ: Опция универсального восстановления должна быть доступна и должна правильно восстановить Windows 7. Старая ОС может быть не загрузочной, но ее необходимо восстановить.
Среда: RAID-контроллер (LSI 9260-8i) ОРИГИНАЛЬНАЯ НАСТРОЙКА: 4x 640 ГБ на уровне RAID 5, раздел -> C: (1-й раздел, FAT32), D: (2-й раздел, система Windows 7, NTFS), E: (3-й раздел для хранения данных, NTFS), F: (4-й раздел для хранения данных, NTFS), N: (5-й раздел для хранения данных, NTFS) Эта история закончилась тем, что нам удалось разобраться, в чем причина сбоев при загрузке клиентской ОС, и, конечно же, успешно загрузиться.
Ошибок в товаре не было.
Даты выпуска
Как правило, за каждым семейством продуктов закреплены конкретные специалисты.Когда формируется новый продукт, мы набираем под него людей, иногда назначаем их руководителем кого-то из «ветеранов».
Если продукт небольшой, его сначала тестируют на базе родителя и на его инфраструктуре, а затем разделяют. Что-то вроде того.
Вы можете спросить меня о процессе, но мой коллега, который занимался автоматизацией тестирования, как раз пишет о том, как правильно все это организовать с программной точки зрения.
Теги: #qa #тестирование #функции и ошибки #разработка веб-сайтов #тестирование ИТ-систем
-
Re: Как Правильно Писать Sql-Запросы
19 Oct, 24
