Еще несколько лет назад к организации автоматизированного тестирования предъявлялось, по сути, лишь одно требование — исключить из большинства рутинных проверок труд человека. Активнее всего автоматизацию внедряли крупные компании, для которых производительность и скорость прохождения тестов редко являлись критическими показателями. Они без особых проблем могли «залатать» деньгами любую дыру в структуре тестов, подключив несколько дополнительных мощных серверов или расширив парк тестовых устройств.
Но рынок быстро меняется: число профессиональных автоматизаторов растет с каждым днем, поэтому не удивительно, что у многих QA-компаний появились выгодные предложения для среднего и малого бизнеса. Сегодня заказать создание 100-200 автотестов могут позволить себе владельцы практически любого небольшого приложения или сервиса. А вот заставить их работать эффективно, не «проглатывая» дорогостоящие ресурсы и не тратя десятки часов на выполнение, — и есть настоящий вызов. В этой статье мы поделимся двумя историями из нашей борьбы за производительность, не упуская трудностей, с которыми столкнулись во время путешествия сквозь мрачный лес прожорливых автотестов.
В рамках сдвоенного доклада мы проговорим проблему построения Архитектуры решений Автоматизации «от обратного» - систематизируем классические Архитектурные недочеты, в том числе процессного происхождения, сформулируем варианты решения каждой рассмотренной проблемы, критерии выбора решения, и конечно условия перехода проблемы из не идеальной, но промышленно приемлемой, в потенциально опасный для проекта прецедент.
«Как начать автоматизировать» - первая тема в серии статей. Так как я обещал, я разъясню как для себя, так и для читателей, то, что я знаю про автоматизацию как специфически направленную деятельность со своими целями, поддерживающую тестирование.
Эта серия статей будет:
Короткой, примерно 5 минут на чтение, хотя это очень сложно для меня.
Практической – без воды, только эмпирические, полезные советы.
Основанной на личном опыте и плохих решениях. Я думаю, это очень полезно.
Как все начиналось: группа QA-инженеров с многолетним стажем решила понять, каких знаний от тестировщиков-новичков сегодня ждут заказчики. Набралось более 40 тем, которые мы объединили в 17 полноценных образовательных модулей. Добавили к ним одиннадцать тренеров-экспертов, трех методистов и восемь помощников, готовых до ночи разбирать домашние задания студентов. Так родился ПОИНТ, наш ответ на вопрос: «Как стать инженером по тестированию, а не обезьянкой, умеющей нажимать на три кнопки и где-то услышавшей, что в тестирование берут кого угодно».
И мы рады, что люди, записавшиеся на первый запуск нашего курса, с первых же занятий поняли это и сразу влились в работу. Пока мы выложили 6 вебинаров из 17, но уже активно собираем данные о наших любимых студентах, просим их поделиться первыми впечатлениями, не скрывать от нас тревоги и недовольства, делиться мыслями и мечтами.
И сегодня, набравшись смелости и заручившись поддержкой наших студентов, мы готовы поделиться с вами пятью фактами о ПОИНТ. Надеемся, что некоторые из них удивят вас не меньше, чем удивили нас (а некоторые, если честно, и вовсе шокировали).
Регрессионное тестирование– это набор тестов, направленных на обнаружение дефектов в уже протестированных частях приложения.
Не секрет, что скорость регресса является важным элементом общего процесса:
Во-первых, от нее зависит, как быстро мы пофиксим найденные баги;
Во-вторых, она влияет на общую скорость релиза;
В-третьих, высокая скорость уменьшает общий бюджет проекта.
Именно поэтому на своих проектах мы непрерывно работаем над сокращением срока проведения регрессионного тестирования. Например, в мае мы проводили очередную итерацию ускорения на проекте по тестированию страхового ПО и теперь можем гордиться достигнутым результатом.
В трансляцию блогов регулярно добавляются новые блоги. Их количество уже давно перевалило за отметку 100. Ну а мы продолжаем знакомить Вас с новыми блогами.
«Аплана» — лидирующий поставщик услуг тестирования и обеспечения качества информационных систем, а также управления жизненным циклом приложений. Компания на рынке уже 17 лет, в штате более 700 специалистов, общее количество проектов превысило 1500.
Теперь мы запустили блог. В нем будут публиковаться экспертные материалы наших специалистов, информационные статьи, новости компании и рынка, аналитика, разбор кейсов и многое другое.
Коллега как-то попросил меня ввести его в суть исследовательского тестирования. Я сделал список полезных статей в блогах, которые, на мой взгляд, пригодятся новичку. Он среагировал в ключе "да это же целый вводный курс". Я так не думал, но тот список был недалек от совершенства.
С тех пор я добавил в него еще ссылок и подумал над упражнениями, чтобы сделать это настоящим вводным курсом. Теперь я могу сразу отправлять этот список интересующимся.
Это настоящая кроличья нора – статьи ведут на другие статьи, а те, в свою очередь, на еще большее количество источников. Приятного чтения!
Автор: доктор Vu Nguyen, преподаватель, директор Инженерной службы KMS Technology
Перевод: Колесникова Виктория, инженер-тестировщик компании Bercut, Telegram: t.me/lifeoftesting
Определяющий фактор для успешного применения автоматизации тестирования программного обеспечения - выбор и использование правильного набора средств автоматизации тестирования. Это сложная задача, особенно для тех, кто раньше не сталкивался с автоматизацией тестирования, поскольку на рынке существует очень много инструментов, каждый из которых имеет разные сильные и слабые стороны. Нет инструмента, который бы соответствовал всем требованиям автоматизированного тестирования. Это затрудняет поиск подходящего решения. Узнайте, как правильно выбрать средство автоматизации для вашего проекта из приведенного ниже подробного сравнения Katalon Studio с другими популярными инструментами для автоматизации тестирования на рынке.
Если концепции, которые я демонстрировала на примере, вам незнакомы, то это нормально, и я полагаю, что приведенные ниже шаблоны помогут вам тестировать. Они объединяют уроки, полученные мною в процессе тестирования API.
1. Фокус: работа с ограниченным пониманием
Тестируя исследовательским методом, вы нацелены на предоставление ценности путем наименьших затрат. Так как вы изучаете продукт последовательно, послойно, слои нужно выбирать с умом. На вопрос, с чего начать тестировать, нет единственно верного ответа, но для этого существуют неплохие кандидаты.
Участники нашего 
