Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Ранее мы уже выпустили статью с ответами на вопросы ручного тестировщика про автотесты (а также в формате видео). Продолжаем серию ответов: в этой статье мы ответим на 5 самых популярных вопросов менеджера про автотесты. Расскажем о том, сколько времени и ресурсов будет потрачено на автоматизацию, и как скоро она начнет приносить пользу. Видеоверсию можно посмотреть тут.
Быстрое развитие IT-сферы провоцирует рост нагрузки на QA-команду, увеличивается число сотрудников, задачи усложняются. Для обеспечения конкурентного темпа работы при высоких требованиях к качеству необходимо создавать особую IT-инфраструктуру и привлекать современные удобные инструменты, способные при этом подстроиться под запросы конкретной QA-команды.
Мы снова провели срез-анализ рынка старых и новых TMS-решений, выбрали основные функции, которые хотели бы видеть в системах управления тестированием, сравнили их возможности и цены. Не было цели составить рейтинг, так как у каждого инструмента есть свои плюсы и минусы. Делимся свежим списком тулзов для тест-менеджмента, один из которых точно вам подойдёт.
В поисках формата для рассказа о практиках тестирования я обратилась к гуглу с запросами “с чего начинать тестирование ПО” и “как подготовиться к тестированию ПО”. И нашла статьи о том, что нужно уточнять требования, применять техники и т. д. Хм… А что, если “составляющими контроля качества ПО” и даже в своем роде глоссариями в том самом поиске и стали стандарты и производные об этапах STLS? Да, все это необходимо – но недостаточно, подумала я.
И если вы, при наличии всех процессов тестирования,
выводили в PROD не то, что протестировали;
тестируете не то, что нужно;
находите баги в PROD, которых точно нет в тесте;
вынуждены много раз тестировать одно и то же из-за процессных сбоев
– знайте, эта статья для вас.
Велосипед не едет, если у тестирования нет основы. В статье я хочу рассказать, что мы предварительно настраиваем, чтобы тесты были достоверными, эффективными и предсказуемыми.
Слой API любого приложения - один из важнейших программных компонентов системы. Это канал, который соединяет клиента с сервером (или один микросервис с другим), управляет бизнес-процессами и представляет сервисы, которые приносят пользу пользователям.
Общедоступный API, ориентированный на клиента, который делают открытым для конечных пользователей, сам по себе становится продуктом. Если он сломается, это подвергнет риску не только одно приложение, но и целую цепочку бизнес-процессов, построенных вокруг него.
Знаменитая пирамида тестов Майка Кона помещает тесты API на сервисный уровень (интеграционный), что предполагает, что около 20% или более всех наших тестов должны быть сосредоточены на уровне API (точный процент зависит от наших потребностей).
Автор: Саймон Найт (Simon Knight) Оригинал статьи Перевод: Ольга Алифанова
Не утомляйте и не путайте ваших заказчиков длинными тест-планами. Вместо них воспользуйтесь этими вариантами – они легче, проще, и удобопонятнее.
По моему опыту планирования тестирования в различных условиях, командах и организациях, ценность этого планирования не состоит в документе как таковом – она заключается в мыслях, рассматриваемых видах деятельности, ресурсах, потенциальных рисках и предположениях о проблемах.
Глубокие размышления об этих факторах и их фиксация в любой форме – вот в чем задача этого упражнения.
За пятнадцать лет работы в тестировании я наблюдаю, как отрасль из простой и незрелой, ориентированной на начинающих айтишников, становится профессиональным направлением. Раньше тест-менеджер должен был распределять задачи между тестировщиками и следить, чтобы они тестировали разные области, не повторяя одно и то же - такая вот “высокоинтеллектуальная управленческая задача”. Со временем в тестировании появилась узкая специализация, и теперь тестировщики решают разные задачи. Кто-то занимается тест-анализами и тест-дизайном, кто-то автоматизирует тесты, кто-то проводит ручное тестирование как по готовым скриптам, так и в свободном поиске, используя множество инструментов исследовательского тестирования. Соответственно, роль тест-менеджера также поменялась. Теперь он не просто распределяет задачи, а организует процесс, выделяет необходимые задачи для решения, объединяет людей с абсолютно разной квалификацией и целями, чтобы на выходе получить прекрасный результат. И тут, внимание, вопрос: а что же такое прекрасный результат в тестировании?
Автор: Джеспер Оттосен (Jesper Ottosen) Оригинал статьи Перевод: Ольга Алифанова
В классических тест-техниках и подходах тестирование – редкий ресурс. Из-за временных и финансовых ограничений всегда требовалось учитывать риски, чтобы свести концы с концами. Теперь у нас есть инструменты и подходы, увеличивающие доходность тестирования за счет большего количества тестов и их частого и более раннего прогона.
Автор: Виктор Славчев (Viktor Slavchev) Оригинал статьи Перевод: Ольга Алифанова
Хотите, я расскажу вам рождественскую сказку? Кто-то, возможно, скажет, что Рождество давно прошло, но знаете, что не пройдет никогда? Глупости, которые делают люди и называют это рабочим процессом. Не слышали, как разработчики (а может, и тестировщики) говорят "Надо поправить CI-билд, чтобы все тесты прошли"? Или что-то вроде "Мой CI-билд снова упал, как быть с этими плавающими, нестабильными тестами?" Знакомо звучит? Мне кажется, разработчики убеждены, что цель билда – быть вечно зеленым. Я называю это "вечнозеленым CI-билдом" (и поэтому это рождественская сказка), или, чтоб покороче, Эвергринчем. Эвергринч – это на самом деле монстр, который хочет украсть ваше качество и убить ваш проект. Это жуткая рождественская сказка.
Автор: Роберт Сабурин (Robert Sabourin) Оригинал статьи Перевод: Ольга Алифанова
Что делать, если в вашем тестовом проекте поджимает время? Когда код запаздывает? Когда дедлайны приближаются? Играете ли вы в "если бы только"? "Если бы только у нас было больше автотестов", или "если бы только наши тесты были устойчивее, чтобы нам не пришлось прогонять такое количество тестов для выявления багов". Проблема с этой игрой в том, что если вы начали в нее играть – уже поздно что-то менять.
Доводилось ли вам самостоятельно разрабатывать стратегию тестирования? Не доводилось — не беда! Агеева Нина, автор курса «Погружение в тестирование. Jedi Point» подробно расскажет, что такое стратегия и с чем ее «едят»: от подготовительных этапов и сбора информации до полезных мнемоник и эвристик, помогающих написать стратегию тестирования.
