преимущества и недостатки автоматизации тестирования — Лаборатория Качества

• 

Вы знали, что команда Amazon Web Services еще в 2015-м выпускала 50 миллионов релизов в год? Это чаще, чем один в секунду! Как у них так получалось? Свою продуктивность в Amazon объясняют использованием принципов DevOps и эффективной автоматизацией тестирования.

В свою очередь компания QASymphony опрашивала экспертов, среди которых, например, Энджи Джонс, ведущий инженер по тестированию Twitter. И все они согласны с тем, что рынок предъявляет все более жесткие требования к качеству программных продуктов и скорости их обновления. Поэтому одним из трендов эксперты называют сдвиг акцента с ручного тестирования на автоматизированное.

Но в своей оценке эффективности и применимости автоматизированного тестирования эксперты часто разделяются во мнениях где, как и в каких объемах его применять. Почему так происходит? Объясняем в этой статье.

Почему автоматизация не панацея: плюсы и минусы автотестов

Начнем с плюсов:

1. Неутомимость: автотесты аботают даже когда вы спите. Роботы запускаются автоматически, дистанционно, по расписанию. Они не отвлекаются, не забывают, и делают проверку столько раз, сколько нужно.

2. Скорость: робот в 99% случаев пройдет тест быстрее ручного тестировщика. В оставшемся 1% случаев не забывайте, что человек может устать, а робот нет.

3. Многофункциональность: это не просто перебор значений в формах. Автотесты могут быстро проверить функционал в разном окружении и при разных настройках тестируемого ПО.

4. Масштаб: автоматизация позволяет имитировать действия большого количества пользователей.

5. Экономия сил: автотесты освобождают ручных тестировщиков от рутины. Часто с помощью автотестов проверяется базовый функционал, а тестировщик сосредотачивается на тестировании новинок.

6. Экономия средств: основная задача автотестов в бизнесе — сокращение затрат на тестирование. И они отлично справляются с этой задачей, если были внедрены с умом и в нужном месте.

Теперь переходим к минусам:

1. Поломки: автотесты ломаются, иногда даже из-за незначительного изменения кода. На актуализацию нужно время.

2. Близорукость: Автотест проверяет только то, на что запрограммирован. Он не заметит ошибку, которую ему не поручали искать.

3. Трудно поддерживать: с ростом количества автотестов, время на их актуализацию и анализ старых, превышает время на разработку новых.

4. Не везде применимы: есть области тестирования, которые не поддаются автоматизации. Это юзабилити, проверка верстки и переводов, инсталляционное тестирование и другие подобные сферы.

5. Затратность: автотест это как промышленное оборудование, в него нужно сначала инвестировать, а потом смотреть на окупаемость. А если “станок” постоянно чинится и перепрошивается — он может и не окупиться.

Есть и спорные моменты

1. Выгода от автоматизации. С одной стороны – почти всегда время на разработку автотеста будет больше, чем время прохождения тестов «руками». Еще и специалист нужен более квалифицированный/высокооплачиваемый. С другой – если автотест не нуждается в реанимации и постоянной актуализации, то он работает практически бесплатно. Поэтому очень важно рассчитывать ROI автоматизации. И делать это регулярно! Мы в «Лаборатории Качества» рекомендуем проводить анализ окупаемости автоматизации тестирования еще до старта проекта.

2. Сложность анализа результатов. С одной стороны разработчик автотестов действительно может сделать так, что отчеты будут понятны только ему. С другой стороны, если грамотно подойти к стратегии логирования результатов, то даже новый тестировщик сможет понять на каком шаге упал автотест. Специалисты «Лаборатории Качества» всегда составляют четкие инструкции по своим автотестам и по желанию заказчика полностью передают их штатным специалистам.

Когда лучше ручное тестирование, а когда процесс требует автоматизации?

Ручное тестирование подойдет больше, если у вас:

• молодой проект с нестабильным функционалом;
• ручных тестов мало и они проходят быстро;
• нужно проверять верстку, переводы, юзабилити;
• нужно локализовать и описывать ошибки;
• нет времени на разработку автотестов.

О необходимости автоматизации тестирования говорят такие факторы:

• большое количество ручных тестов и не хватает времени на регулярное проведение полного регресса;
• большой процент пропуска ошибок по вине человеческого фактора;
• большой промежуток времени между внесением ошибки, ее обнаружением и исправлением;
• подготовка к тестированию (настройка конфигурации, генерация тестовых данных) занимает много времени;
• большие команды, в которых нужна уверенность, что новый код не сломает код других разработчиков;
• поддержка старых версий ПО, в которых нужно тестировать новые патчи и сервис-паки.

Как автоматизировать тестирование

Вот наши рекомендации по автоматизации, которые мы сформировали исходя из практики 155+ проектов.

1. Определите, чего вы хотите от автотестов. Кто-то ищет оптимизации расходов, кто-то хочет разгрузить ручных тестировщиков, кто-то хочет увеличить охват тестов. Регулярно проверяйте способствует ли автоматизация достижению вашей цели. Также цель позволяет определить что именно автоматизировать и что делать в первую очередь.

2. Регулярно рассчитывайте ROI автотестов и собирайте соответствующие метрики. Это позволяет узнать действительно ли вам нужны автотесты и при необходимости корректировать план автоматизации.

3. Проанализируйте сколько автотестов вам требуется. И как часто понадобится писать новые и актуализировать старые. Возможно, вам выгоднее сразу отдать автоматизацию на аутсорс и платить только за выполненные работы. В то время как наемный сотрудник будет сидеть без дела после выполнения основного объема работ на старте проекта.

Запросить анализ

4. Определите, что вы хотите видеть в отчетах. От этого зависит их полезность и ваша степень доверия к этому инструменту. Рекомендуем найти баланс между минимумом и максимумом данных, так чтобы автотесты приносили пользу, но не съедали ваши ресурсы. Собранная информация должна приносить пользу. Опытные автоматизаторы на аутсорсе могут посоветовать вам, что должно быть в отчете.

5. Позаботьтесь, чтобы тестировщики понимали что именно делает автотест. Только так после падения сценарий можно перепроверить вручную. Создайте четкие пошаговые инструкции. В случае, если вы отдали эту задачу на аутсорс компании, в которой есть и ручные тестировщики и автоматизаторы, попросите у них такие инструкции – на всякий случай, вдруг придется проверять самим.

6. Не стоит доверять начальный этап автоматизации программисту-джуну. Не забывайте, что автотесты – такой же программный продукт, как и все остальные. От классификации разработчика зависит эффективность, правильно выстроенная архитектура и легкость актуализации.

7. Последняя в списке, но не последняя по значению рекомендация – придерживайтесь пирамиды автоматизированного тестирования. Создавайте большое количество низкоуровневых автотестов (например, API) и меньшее количество высокоуровневых UI тестов. Просто поверьте нашему опыту, или напишите нам в комментариях, чтобы мы написали отдельную статью по этой теме. Поверьте, для этого хватит материала, с красочными примерами.

Выводы

Многим QA-специалистам очевидно, что вопрос «автоматизировать или тестировать руками?» звучит, как минимум, некорректно. Нельзя раз и навсегда выбрать что-то одно, а от чего-то отказаться. 

Все тесты автоматизировать нерентабельно, а порой и вовсе невозможно. Пока AIOps не достигли нужного уровня, ручное тестирование будет востребовано на проектах. Потому, квалификация руководителя проекта тут определяется скорее умением найти точный баланс между этими двумя подходами. Определить, где автотесты будут максимально эффективны и внедрять их именно в этой сфере.

Что касается вопроса отдавать ли автоматизацию на аутсорс или заниматься самому, то все нужно просчитывать применительно к своему бизнесу. Для того, чтобы делать автотесты самостоятельно, должно сойтись много факторов.

1. Как минимум, вы должны быть уверены, что автоматизация окупится и уметь правильно считать ROI. 
2. Плюс найти квалифицированного автоматизатора, что трудно с учётом их востребованности на рынке труда. 
3. А ещё вы должны загрузить его работой не только на старте проекта, но и на постоянной основе.
4. Ну и убедиться, что автотесты будут работать без этого специалиста. Иначе — начинай всё сначала.

Сильные QA-компании, предлагая свои услуги —  всегда инициируют процесс автоматизации с просчета его ROI и выбора наиболее прибыльной стратегии тестирования. 

Сама автоматизация должна строиться на имеющихся у QA-компании наработках и готовых библиотеках фреймворков, что экономит время и средства заказчика.

В конце проекта заказчику должны быть переданы гибкие автотесты, которые легко актуализировать и поддерживать своими силами. 

Не удалось до конца определиться — внедрять автоматизацию у себя на проекте или продолжать кормить армию ручников. Свяжитесь с нами. Посчитаем все за и против вместе.

Узнать подробнее

Мы предлагаем быстрый старт в рамках пилотного проекта со скидкой 50%. Мы выполним часть работ и покажем себя, вы сэкономите половину бюджета и время на раздумья.

quality-lab.ru

Статья на тему: Использование тестов в образовательном процессе: плюсы и минусы

 

О.В. Кореневская

Использование тестов в образовательном процессе:
плюсы и минусы

Тестовый контроль – это оперативная проверка качества усвоения знаний учащихся, которая дает возможность проверить уровень формирования основных навыков и понятий и своевременно восполнить пробелы. Также тесты дают возможность для определения некоторых индивидуальных характеристик учебной деятельности детей, таких, как их темп работы, умение сосредоточиться, степень развитости памяти, внимания.

Учитывая, что итоговая аттестация выпускников проходит в тестовой форме, учитель должен научить школьника правильно работать с тестами, распределять свое время с наибольшей пользой. Однако не всякое содержание поддается выражению в форме тестового задания. Доказательства, обширные вычисления, многословные описания не поддаются представлению в тестовой форме. Из этого вытекает важный вывод — тестовую форму нельзя рассматривать как универсальную, пригодную на все случаи проверки знаний.

Актуальность тестового метода объясняется его несомненными преимуществами перед другими педагогическими методами.

Пять основных преимуществ:

1.Высокая научная обоснованность самого теста, позволяющая получать объективированные оценки уровня подготовленности испытуемых;

2. Технологичность тестовых методов;

3. Точность измерений;

4. Наличие одинаковых, для всех пользователей, правил проведения педагогического контроля и адекватной интерпретации тестовых результатов;

5. Сочетаемость тестовой технологии с другими современными образовательными технологиями.

ОПРЕДЕЛЕНИЕ ПЕДАГОГИЧЕСКОГО ТЕСТА

педагогический тест определялся как система параллельных заданий равномерно возрастающей трудности, специфической формы, позволяющая качественно и эффективно измерить уровень и оценить структуру подготовленности учащихся.

Система означает, что в тесте собраны такие задания, которые обладают системообразующими свойствами. Здесь в первую очередь надо выделить общую принадлежность заданий к одной и той же системе знаний, т.е. к одной учебной дисциплине, их связь и упорядоченность.

Специфическая форма тестовых заданий отличается тем, что задания теста представляют собой не вопросы и не задачи, а задания, сформулированные в форме высказываний, истинных или ложных, в зависимости от ответов.

Определенное содержание означает использование в тесте только такого контрольного материала, который соответствует содержанию учебной дисциплины; остальное в педагогический тест не включается ни под каким предлогом.

Ответ на задание педагогического теста представляет собой краткое суждение, связанное по содержанию и по форме с содержанием задания. Каждому заданию ставятся в соответствие ответы правильные и неправильные. Критерии правильности заранее определяются авторами теста.

Виды тестов.

Существуют два основных вида тестов: традиционные и нетрадиционные.

Традиционный тест представляет собой стандартизованный метод выявления уровня и структуры подготовленности.

 В таком тесте все испытуемые отвечают на одни и те же задания, в одинаковое время, в одинаковых условиях и с одинаковыми правилами оценивания ответов. Главная цель применения традиционных тестов — установить отношение порядка между испытуемыми по уровню проявляемых ими знаний. И на этой основе определить место (или рейтинг) каждого на заданном множестве тестируемых испытуемых. Для достижения этой цели можно создать бесчисленное количество тестов, и все они могут соответствовать достижению поставленной задаче.

Тест обладает составом, целостностью и структурой. Он состоит из заданий, правил их применения, оценок за выполнение каждого задания и рекомендаций по интерпретации тестовых результатов. Целостность теста означает взаимосвязь заданий, их принадлежность общему измеряемому фактору. Каждое задание теста выполняет отведенную ему роль и потому ни одно из них не может быть изъято из теста без потери качества измерения.

Структуру теста образует способ связи заданий между собой. В основном, это так называемая факторная структура,

в которой каждое задание связано с другими через общее содержание и общую вариацию тестовых результатов.

 

Примером Нетрадиционного теста может служить интегративный тест, состоящий из системы заданий, отвечающих требованиям интегративного содержания с возрастающей трудностью заданий, нацеленных на обобщенную итоговую диагностику подготовленности выпускника образовательного учреждения. Диагностика проводится посредством предъявления таких заданий, правильные ответы на которые требуют интегрированных (обобщенных, явно взаимосвязанных) знаний двух и большего числа учебных дисциплин. Создание таких тестов дается только тем преподавателям, которые владеют знаниями ряда учебных дисциплин, понимают важную роль межпредметных связей в обучении, способны создавать задания, правильные ответы на которые требуют от учащихся знаний различных дисциплин и умений применять такие знания. Интегративному тестированию предшествует организация интегративного обучения.

СОДЕРЖАНИЕ ТЕСТА.

Содержание теста можно определить как оптимальное отображение содержания учебной дисциплины в системе тестовых заданий. Некоторые элементы проверяемых знаний (преимущественно по отдельным темам) используются только в текущем контроле. Другие элементы, охватывающие знания нескольких тем, используются в рубежном контроле, например, в конце учебной четверти. И, наконец, в итоговом контроле используются задания, правильные ответы на которые требуют знания многих, а и иногда и всех тем, изученных в течение учебного года.

Поэтому  содержание теста в первую очередь определяется целями тестирования. Это, пожалуй, самый главный принцип, который положен в основу разработки теста.

По одному и тому же учебному материалу тесты могут быть различной степени трудности, что расширяет возможности учителя в реализации дифференцированного подхода в обучении, а ребенку позволяет успешно проявить себя на уровне своих возможностей.

Основные цели тестирования:

-Контролирующая  (текущий, рубежный, итоговый, контроль остаточных знаний)

-Диагностирующая  ( мониторинг образовательного процесса)

-Обучающая

-Мотивация обучения (проведение рейтинга учащихся ).

Например, для проведения периодического мониторинга образовательного процесса в школе больше подходят тесты с детальным дифференцированием содержания учебной дисциплины в достаточно большой системе заданий. Такие тесты требуют содержательно-ориентированной интерпретацией результатов, где главной задачей становится выяснение — что из изученного содержания учебных программ усвоено каждым учащимся, а что потребует дополнительного изучения.

 Для проведения рейтинга учащихся требуются тесты с менее дифференцированным содержанием учебной дисциплины, и соответственно, с меньшим числом заданий. Для этой цели больше подходят традиционные тесты.

Если нужно отобрать небольшое число школьников для участия в олимпиаде, то содержание заданий такого теста должно быть трудным. Если требуется отсеять, наоборот, самых слабых учащихся, то это лучше сделать с помощью сравнительно легких заданий; те ученики, которые не выполняют такие задания, и есть самые неподготовленные.

Применение заданий в компьютерных контрольно-обучающих программах позволяет учащимся самостоятельно обнаруживать пробелы в знаниях и принимать меры для их ликвидации. В таких случаях можно говорить об обучающем потенциале тестовых заданий.

ПРИНЦИПЫ РАЗРАБОТКИ СОДЕРЖАНИЯ ТЕСТА

Первый принцип разработки содержания теста — соответствие содержания теста целям тестирования

Второй принцип — определение значимости проверяемых знаний.

Третий принцип — взаимосвязь содержания и формы

Четвертый принцип — содержательная правильность тестовых заданий

Пятый принцип  — при разработке теста обращается внимание на полноту и достаточность числа заданий для аргументированного вывода о знаниях. Число заданий в тесте зависит, во-первых, от содержания проверяемого материала: чем больше объем проверяемых знаний, тем большее обычно требуется число заданий. Во-вторых, от вида тестов; интегративные тесты требует меньшего числа заданий, в силу того, что для правильного решения каждого задания надо обладать знаниями различных учебных дисциплин. И в-третьих, точность педагогических измерений зависит от числа заданий; в традиционном тесте точность измерения растёт по мере увеличения числа заданий

Шестой принцип — соответствие содержания теста уровню современного состояния науки.

Седьмой принцип — комплексность и сбалансированность содержания теста. Тест, разработанный для итогового контроля знаний, не может состоять из материалов только одной темы, даже если эта тема является самой ключевой в учебной дисциплине. Необходимо искать задания, комплексно отображающие основные, если не все, темы учебного курса

Восьмой принцип — системность содержания. Это означает формулирование такого содержания тестовых заданий, которое отвечало бы требованиям системности при проверке знаний. Помимо подбора заданий с системным содержанием важно иметь задания, связанные между собой общей структурой знаний.

Девятый принцип — вариативность содержания. После первого применения теста его содержание становится известным испытуемым. И если есть условия для передачи информации о содержании заданий другим учащимся, то это почти всегда делается. Испытанным в практике способом защиты тестовых результатов от возможных искажений такого рода является создание множества вариантов заданий одного и того же теста.

Десятый принцип — соответствие уровня трудности содержанию цели тестирования.

К заданиям в тестовой форме предъявляются следующие требования:

-краткость;

-технологичность;

-правильность формы;

-правильность содержания

-логическая форма высказывания;

-одинаковость правил оценки ответов;

-наличие определенного места для ответов;

-одинаковость инструкции для всех испытуемых;

-правильность расположения элементов задания;

-адекватность инструкции форме и содержанию задания

Тест не может быть пригодным для измерения знаний по любой учебной дисциплине, в любое время, у испытуемых с любым уровнем подготовленности. Таких тестов не бывает. Тест создается для определения уровня подготовленности учащихся, и его результаты интерпретируются в зависимости от степени достижения поставленной цели

Основные формы заданий.

Оптимальное отображение содержания учебного материала в тестовые задания требуемого уровня трудности предполагает возможность выбора подходящей формы.

 Содержание теста выражается в одной из четырех основных форм заданий. Это: 1) задания с выбором одного или нескольких правильных ответов из числа предложенных; 2) задания открытой формы, где ответ испытуемый дописывает сам, в отведенном для этого месте; 3) задания на установление соответствия, и 4) задания на установление правильной последовательности действий.

                                                     Оценка.

Одно из соображений, положенных в основу создания тестов — иметь инструмент быстрого и относительно точного оценивания больших контингентов испытуемых. Требование экономии времени становится естественным. Контроль ведется с помощью заранее шкалированных, по трудности, заданий. Предельное время тестирования тоже определяется заранее. Выделяются два основных вида оценивания — формирующее и итоговое.

 Цель первого — оказывать, посредством оценивания, формирующее влияние на текущий процесс обучения, в смысле его улучшения, за счет установления обратной связи от ученика к преподавателю.

 Цель второго — получить итоговые результаты обучения.

Пятибалльная шкала имеет своим главным преимуществом простоту и привычность, что объясняет ее широкую и длительную, по времени, распространенность. Но она имеет и недостаток – субъективность, большую зависимость от того, кто оценивает, и кого оценивают. Каждый преподаватель дает оценку на основе своего личного понимания.

Другой недостаток пятибалльной шкалы оценок касается ее слабой дифференцирующей способности. Она позволяет провести грубую классификацию только на четыре группы — отличников и тех, кто учится хорошо, удовлетворительно и неудовлетворительно. Более тонкое различение, особенно нужное при приеме в вузы и для эффективного управления качеством обучения, пятибалльная шкала не дает, и дать не может. Отсюда понятна необходимость совершенствования педагогических оценок на основе измерений.

Одно из важных требований при тестировании — наличие заранее разработанных правил выставления баллов. В общем случае применения тестов за правильный ответ в каждом задании принято давать один балл, за неправильный ответ — ноль. Сумма всех баллов, полученных испытуемым, дает число правильных ответов. Это число ассоциируется с уровнем его знаний и с понятием «тестовый балл испытуемого».

Качество знаний.

С точки зрения педагогических измерений полезно ввести два основных показателя качества знаний — уровень и структуру знаний.

Уровень знаний выявляется при анализе ответов каждого испытуемого на все задания теста. Чем больше правильных ответов, тем выше индивидуальный тестовый балл испытуемых. Обычно этот тестовый балл ассоциируется с понятием «уровень знаний» и проходит процедуру уточнения, на основе той или иной модели педагогического измерения. Один и тот же уровень знаний может быть получен за счет ответов на различные задания. Например, в тесте из тридцати заданий учащийся получил десять баллов. Эти баллы, скорее всего, получены за счет правильных ответов на первые десять, сравнительно легких заданий. Присущую для такого случая последовательность единиц, а затем нулей можно назвать правильным профилем знаний испытуемого.

Структура знаний оценивается на основе последовательности правильных и неправильных ответов на задания возрастающей трудности.

Мониторинг образовательной деятельности

Мониторинг — это система периодического отслеживания хода образовательного процесса, с использованием информативных показателей и современных технологий.

Мониторинг связан с:

— необходимостью иметь большое число заданий в тестовой форме;

— системой полного усвоения знаний;

— информатизацией учебного процесса;

— теорией и методикой управления образованием;

— тестированием и общей теорией построения показателей;

—  качеством и направленностью образовательной политики.

Цель мониторинга – получение информации об эффективности и качестве учебного процесса и улучшение его организации на основе получаемой информации.  Эта цель может быть достигнута посредством создания автоматизированной системы текущей оценки качества учебной деятельности.  

Среди ведущих задач мониторинга следует выделить  организацию процесса педагогической диагностики и организацию автоматизированного учёта учебных результатов.

Решающими условиями качественного мониторинга является открытость его результатов, периодичность оценивания, своевременная коррекция учебной деятельности, организация образовательного процесса как совместной и целенаправленной деятельности учащихся и педагогов по развитию личности, приобретению подготовки, необходимой для успешной жизни граждан и общества.

Каждое учебное заведение должно стремиться, в первую очередь, к формированию правильных индивидуальных структур знаний, в которых не было бы пробелов (разрывов в знаниях), и на этой основе повышать уровень подготовки. Уровень знаний в значительной степени зависит от личных усилий и способностей учащихся, в то время как структура знаний заметно зависит от правильной организации учебного процесса, от индивидуализации обучения, от мастерства педагога, от объективности контроля.

ВЫВОДЫ

1. Применение заданий в тестовой форме, в сочетании с новыми образовательными технологиями позволяет обеспечить  кардинальное улучшение учебного процесса за счёт активизации обучающей, контролируюшей, организующей, диагностирующей, воспитательной  и мотивирующей функции таких заданий.

2. Мониторинг учебного процесса много лучше однократного тестирования.

Результаты мониторинга могут быть использованы для организации самостоятельной работы на основе модульной технологии,  а также для введения в  школах  уровневого образования.

3.Навыки работы с тестами позволяют учащимся уверенно чувствовать себя на экзамен и грамотно распределять свое время.

nsportal.ru

Тестирование пользователями и специалистами: плюсы и минусы

Оригинальная публикация

Автор: Вероника Латипова

Перед каждым разработчиком ПО рано или поздно встает задача оценки качества выпускаемого продукта. Зачастую руководители небольших проектов считают непозволительной роскошью прибегать к услугам профессиональных тестировщиков. Ведь, на первый взгляд, кто, если не сам разработчик или пользователь может наилучшим образом найти недостатки в программе? По сути, в этом случае все исследование сводится к бета-тестированию («Бе́та-тести́рование (англ. betatesting) – интенсивное использование почти готовой версии продукта (как правило, программного или аппаратного обеспечения) с целью выявления максимального числа ошибок в его работе для их последующего устранения перед окончательным выходом (релизом) продукта на рынок, к массовому потребителю»).

Практика использования клиентов – потребителей продукта в качестве тестировщиков в последнее время стала достаточно популярной. Мы постараемся оценить очевидные на первый взгляд плюсы и минусы бета-тестирования и тестирования специалистами. Все ли из них оказываются «плюсами» или «минусами» при ближайшем рассмотрении?

Плюсы и минусы бета-тестирования

Плюсы:

1. Обратная связь.
Неоспоримым достоинством бета-тестирования является получение реальной обратной связи с пользователями продукта. Для этого применяются различные инструменты: сбор отзывов, анкетирование, периодическое вовлечение реальных бизнес-пользователей в процесс тестирования.

Действительно, в ряде случаев только пользователи могут провести проверку ПО на выявление наиболее удобных, наиболее интересных или, наоборот, наиболее неприемлемых модулей и функций. Получив такие отзывы, разработчики могут оперативно доработать продукт с учетом высказанных пожеланий: поменять логику системы, отредактировать тестовые сценарии.

Дефекты ПО также выявляются при использовании редко встречающихся окружений. Таким образом, при выборе стратегии бета-тестирования следует учитывать, что наилучший результат будет достигнут при условии привлечения большого количества пользователей с разным окружением. Прекрасным примером такой работы является стратегия известной компании Google. Используя мощное оборудование, компания систематизирует и классифицирует отзывы десятков тысяч пользователей, доводя свои программные продукты до совершенства.

2. Экономия средств.
Плюсом бета-тестирования, на первый взгляд, является его невысокая стоимость. Действительно, в идеале мы получаем тестовое покрытие без дополнительных вложений. Чаще всего метод бета-тестирования используется в области игровой индустрии. Опыт многих фирм-разработчиков подтверждает экономическую целесообразность этого метода. Снижение общих затрат компании может быть достигнуто и при использовании бета-тестов в качестве инструмента продвижения системы. Бесплатное тиражирование бета-версий обеспечивает повышенный интерес конечных пользователей к итоговой версии продукта.

Но всегда ли всё складывается так удачно? Как показывает практика, отсутствие грамотной стратегии бета-тестирования может привести к печальным результатам. Рассмотрим это на реальных примерах.

Не так давно некая компания, выпускающая компьютерные игры, разместила бета-версию в свободном доступе. Целью акции было получение баг-репортов от пользователей. Дело сразу не заладилось: отзывов поступало очень мало. Разработчикам пришлось предложить бонусы в виде необходимых внутриигровых артефактов за каждый оставленный баг-репорт. Только после этого шага была, наконец, получена необходимая информация.

В результате такой «беспроигрышной» стратегии компания потратила гораздо больше времени, чем планировала. Более того, она понесла дополнительные расходы на «содержание» всей команды разработки во время ожидания результатов.

Другой свежий пример: один японский разработчик выдал в бета-тестирование широко известную игру для мобильных устройств. Каково же было удивление пользователей, когда оказалось, что у них не всегда получалось даже просто запустить игру на своих устройствах. Мало того: участники бета-тестирования преждевременно распространили в сети информацию об игре, что нарушило планы кампании. Фактически, «экономия» привела к коммерческому провалу запуска игры. При этом компания, как и в предыдущем случае, потратила сверхплановые время и средства.

Описанные ситуации показывают, что бета-тестирование, спланированное без привлечения опытных специалистов, далеко не всегда приводит к экономии средств.

Минусы:

1. Низкая квалификация тестировщиков.

Важно помнить, что основные участники бета-тестирования – это добровольцы из числа обычных пользователей будущего продукта. Эти люди не всегда обладают даже минимальными техническими навыками, позволяющими дать качественную оценку ПО. Конечно, о чёткой локализации и понятном описании бага при бета-тестировании можно даже не вспоминать – этим всё равно понадобится заниматься штатным тестировщикам.

2. Неполное тестовое покрытие.

Некую аналогию бета-тестирования можно увидеть в легендарном фильме «Операция «Ы»…». По сюжету перед «бандой» стоит задача – инсценировать ограбление склада, на котором «все уже украдено до вас». В качестве «тестового стенда» используется гараж, переоборудованный так, чтобы получить характеристики реального склада («Продуктив»). Банда подбирает отмычки и проводит «тестовые сценарии» по проникновению и имитации ограбления. В целом, операция должна пройти успешно, НО… «Трус», натренированный «на кошках», в ответственный момент натыкается на альтернативный сценарий: «А где бабуля?» – «Я за нее». В итоге операция «Ы» оказывается проваленной. Практика показывает, при тестировании непрофессионалами часть функционала всегда остается не охваченной.

Плюсы и минусы тестирования специалистами

Теперь постараемся сформулировать основные плюсы и минусы работы с профессиональными тестировщиками.

Плюсы:

Плюсов работы с опытной командой – великое множество, мы остановимся лишь на некоторых из них.

1. Комплексный подход к тестированию.

Очевидно, главный плюс, интересующий всех, – это высокое качество тестирования, достигаемое с помощью максимального охвата всех стадий работы. Дефекты, пропущенные в таких приложениях, как, к примеру, десктопное или мобильное ПО, приводят к огромным финансовым потерям как самого разработчика, так и его клиентов. Возможность составления планов и согласования тестового покрытия с бизнес-аналитиками дает уверенность в минимизации материальных рисков. Тестировщики участвуют в процессе определения состава релиза, проверяют надежность процедуры как полного отката версии, так и частичных изменений и преобразования данных.

2. Отчётность о результатах тестирования.

По результатам работы специалистов заказчик получает не только список пройденных сценариев, но и набор отчетов, в которых содержатся заключения о качестве выпущенного продукта и узких местах ПО, а также предложения по доработкам. На основании таких отчетов производитель имеет возможность оперативно принимать дальнейшее решение по продукту. Все необходимые исправления и изменения излагаются так, что разработчики могут сразу приступать к их реализации.

3. Высокое качество тестирования, основанное на опыте специалистов.

Возвратимся к примеру «Операции «Ы». Квалифицированные специалисты никогда бы не упустили альтернативные сценарии, и исход мероприятия мог быть совсем другим. Опыт – великая вещь! При этом команда тестировщиков несет полную ответственность за свою работу, чего никак нельзя сказать об участниках бета-тестирований.

Минусы:

К минусам привлечения специалистов чаще всего относят «понятие двух «Д»: «дорого и долго». Далеко не каждая компания может себе позволить расширять штат и нанимать сотрудников-тестировщиков на постоянную основу, особенно если речь идет о стартапах. Поэтому в настоящее время большой популярностью пользуется аутсорсинг. Он дает возможность привлечь команду специалистов на конкретный проект.

Другая тенденция – переход от традиционных методов разработки и тестирования (Waterfall) к гибким (Agile). Джанет Грегори и Лиза Криспин опубликовали прекрасную работу, детально описывающую место разработчиков и тестировщиков в Agile-проектах. Однако, не следует забывать, что любой тестировщик должен обладать минимальными техническими навыками и уметь хорошо ориентироваться в предметной области.

С другой стороны, приведенные в этой статье примеры показывают, что надежды на экономию времени и средств от использования «усеченного» бета-тестирования зачастую оказываются несбыточными. А значит, «долго и дорого» – это всего лишь расхожий штамп, далеко не всегда подтверждаемый на практике.

Заключение

Итак, без качественного тестирования вы однозначно рискуете выдать клиенту продукт с багами. Но качественное тестирование также подразумевает получение информации о соответствии выпускаемого продукта ожиданиям конечных пользователей. Вам нужно самостоятельно принять решение о том, какой способ тестирования необходимо использовать на вашем проекте, либо применить стратегию, сочетающую оба подхода. Мы же надеемся, что эта статья поможет вам сделать грамотный выбор.

Обсудить в форуме

www.software-testing.ru

» Тестирование в школе. Плюсы и минусы

Тестирование учащихся в школе отнюдь не новомодное изобретение, как сейчас многие хотят представить. Периодически выполняемые школьниками контрольные и самостоятельные работы, фронтальные опросы и персональные задания также имели своей целью выявить уровень усвоения полученных знаний. С появлением в школах компьютеров работа по составлению и проверке тестов на самые различные темы по самым различным предметам намного упростилась. А вот сами тесты появились в школах гораздо раньше.

В чём плюсы и минусы тестирования как способа контроля

Многие преподаватели в своей работе использовали так называемые карточки с тестами. Каждая карточка представляла собой уникальное индивидуальное задание, раздавались они классу буквально на 10-15 минут. После этого карточки собирались и урок продолжался. Такие тестовые задания позволяли учителю определить полноту усвоения школьниками материалов предыдущего урока. Причем, на проверку таких карточных тестов требовалось очень мало времени – на одну карточку всего несколько секунд. В то же время на проверку одной самостоятельной работы учитель тратил не меньше пяти минут и то при условии, что ему приходилось прежде иметь дело с подобными заданиями.

Отношение к тестам в школе далеко не однозначное. Многие считают, что тесты не отражают реального уровня приобретенных учениками знаний. Отчасти это справедливо, поскольку полностью полагаться на результаты тестов, исключив все другие способы проверки знаний, ни в коем случае нельзя. Во время выполнения тестов ученики могут допустить какую-то незначительную оплошность, которая повлияет на результат или попросту поспешить и разнервничаться, да мало ли что еще. Но эффективность тестов как средств быстрой оценки успеваемости в классе отрицать нельзя. Вопрос только в том, что безоговорочно принимать все результаты тестов недопустимо, необходимо проверять результаты тестов и проводить дифференцированный анализ по каждому ученику в отдельности.

При проверке самостоятельной работы, например, по математике, учитель может увидеть ход вычислений ученика и выявить ту досадную опечатку, которая привела к ошибке. Может быть, кто-то отвлек ученика в этот момент, а времени на самостоятельную проверку у него не было. Опытный и объективный педагог никогда не посчитает это ошибкой, тем более, если и формулы и ход решения были абсолютно правильными. Тестирование же требует только правильного ответа. При выполнении тестов, в которых требуется выполнить какие-то действия, для получения ответа, ученикам рекомендуется сдавать свои черновики вместе с тестовыми карточками. Тогда и у педагога и у ученика будут основания пересмотреть результаты теста и поставить правильную оценку. Применение простых тестов, в которых надо, например, подставить в формулу нужное значение, ответить на вопрос однозначно «да» или «нет» либо назвать единицу измерения, наиболее точно отражают усвоение материала и не требуют уточнений. И применение таких тестов в школах должно проводиться как можно чаще.

Качество подобных тестов на сегодняшний день, увы, оставляет желать лучшего. Дело тут не только в том, что недостаточно исходного материала или средств выполнения самостоятельной разработки тестов, а еще и в том, что со временем и само отношение к тестам стало негативным и наработки прошлых лет оказались потеряны. А ведь тестирование в школе это не просто дань моде и нельзя ее воспринимать формально, как некую вмененную обязанность. Тестирование дает хорошую возможность ученикам увидеть наглядно свои пробелы в обучении и постараться их исправить. Ведь при поступлении в высшее учебное заведение, а особенно во время учебы студенту придется столкнуться с мнением педагогов, которые будут оценивать их знания объективно, невзирая на их предыдущие школьные заслуги. Очень важно с самого начала показать, что знания, полученные в школе, а главное стремление их получить, не прошли для студента даром.

Что учесть при разработке тестов

При разработке тестов необходимо учитывать несколько важных факторов. Первое, тесты должны быть составлены только на основе пройденного материала, дополнительный материал здесь учитываться не должен. Второе, время, отводимое на выполнение определенного тестового задания, должно быть рассчитано с учетом скорости выполнения подобных заданий не в среднем по классу, а по самому медлительному ученику, при необходимости таким детям следует дать дополнительное время без ущерба для усвоения нового материала. Третье, построение тестов должно идти от простого к сложному, чтобы ученик не запнулся на первых заданиях и не потерял драгоценное время. Четвертое, все тестовые задания должны быть выполнимы, то есть предварительно проверены на наличие опечаток. При несоблюдении хотя бы одного из этих требований говорить о полноценной и объективной оценке знаний невозможно.

Оцените статью: Поделитесь с друзьями!

paidagogos.com

Ручное и автоматизированное тестирование: плюсы и минусы подходов

Ручное и автоматизированное тестирование играют ключевую роль в процессе обеспечения качества ПО. Прежде всего, проверка кода позволяет удостовериться в качестве разрабатываемого продукта, что повышает репутацию приложения за счет положительных откликов пользователей.

Зачастую на объемных и сложных проектах тестировщики сталкиваются с применением как автоматизированного, так и ручного тестирования одновременно. А о том, почему часто нельзя обойтись только ручными или автоматизированными проверками, а также о некоторых плюсах и минусах каждого направления, мы поговорим в этой статье.

На выбор вида тестирования влияют такие факторы, как:

• объем исправлений, которые планируется внести;
• возможность добавлять к разработке дополнительную функциональность;
• возможность обновлять ПО в будущем.

Взаимосвязь и соотношение этих факторов влияет на продолжительность тестирования продукта.

Ручное тестирование

Зачастую ручное тестирование приложений – это трудоемкий и продолжительный процесс. Без сочетания с автоматизированным, такой вид проверок может применяться только на небольших, краткосрочных проектах.

Ручное тестирование – это прямое взаимодействие QA-инженера и приложения. В его процессе можно получить обратную связь о продукте, что невозможно, если использовать автоматизированное тестирование.

Кроме того, тестировщик сможет составить свой отзыв и рекомендации по улучшению ПО, а проведенное тестирование будет свидетельством сравнения ожидаемого и реального результатов.

Еще одна особенность ручного тестирования состоит в обратной связи по дизайну пользовательского интерфейса. На данный момент нет сервисов, которые бы сравнили желаемый результат с реальным. Только QA-инженер сможет обратить внимание на нюансы в цветовых тонах или несимметричном расположении полей и кнопок.

Плюсы ручного тестирования

• Отчет тестировщика – это первый отзыв потенциального клиента, который позволит понять, насколько продукт удобен для конечного пользователя.
• Обратная связь по UI. Протестировать общий дизайн приложения и выявить его недостатки представляется возможным только при ручном тестировании.
• Стоимость. Когда речь идет о небольшом проекте, внедрять ручное тестирование всегда менее затратно, чем автоматизацию.
• Гибкость. Тестирование несущественных изменений происходит сразу, без затрат на написание кода. Это особенно важно при быстром внедрении новой функциональности, когда нужно быть уверенным в ее корректной работе.
• Исследовательское тестирование и возможность импровизации позволяет проверить потенциал приложения в нетипичных сценариях и обнаружить существенные дефекты в короткие сроки.

Минусы ручного тестирования

• Человеческий фактор. Часть ошибок продукта может быть пропущена, а некоторые результаты проверки могут оказаться субъективными.
• Трудозатраты и продолжительность. Серия автоматизированных тестов позволяет протестировать программное обеспечение значительно быстрее.
• Отсутствие возможности моделирования большой нагрузки. При ручном тестировании невозможно смоделировать большое количество пользователей.

Автоматизированное тестирование

Автоматизация тестирования приложений основана на написании кода. Методика автоматизированного тестирования позволяет создать ожидаемый сценарий, а затем сравнить его с реальным и указать расхождения.

Автоматизация наиболее применима в сложных приложениях с большой функциональной частью. Особой популярностью пользуется автоматизация тестирования труднодоступных мест приложения, валидационных форм, базовых операций, часто используемой функциональности. Более подробно такие ситуации обсуждаются на курсах по автоматизации тестирования.

Плюсы автоматизированного тестирования

• Нагрузка на приложение. Когда используется автоматизированное тестирование, становится возможным моделирование большой нагрузки, которая приближена к реальной ситуации.
• Временной фактор. Ручное тестирование – это долгий и ресурсоемкий процесс, в то время как код для сценария пишется один раз.
• Повторяемость. Код автотестов может быть использован неоднократно, особенно при внедрении новой функциональности.

Минусы автоматизированного тестирования

• Отсутствие обратной связи. Автоматизированное тестирование не способно предоставить обратную связь относительно качества продукта – оно лишь выполняет запрограммированные сценарии.
• Отсутствие тестирования глазами пользователя. Иногда в приложении остаются ошибки, которые могут быть не покрыты автотестами.
• Отсутствие возможности тестирования цвета, дизайна и эргономики. Этот пункт не является первостепенным, но может значительно повлиять на качество продукта.
• Надежность. Автоматизированные тесты могут упасть по многим причинам, например, при большой загруженности тестовой машины или при проблемах с сетью.
• Стоимость. Для небольших проектов инструменты автоматизированного тестирования могут оказаться достаточно затратными, поэтому более рационально их использовать для долгосрочных проектов.

Резюмируем

Проведение автоматизации тестирования позволяет получить более точный результат. Ручные проверки – это более универсальный вариант, который рассчитан практически на любое приложение.

Грамотная комбинация методик тестирования поможет получить максимально качественный программный продукт. При этом доля ручного или автоматизированного тестирования будет зависеть от потребностей проекта, команды, сроков, а также бюджета.

qa-academy.by

Автоматизация тестирования: минусы / Habr

Автотест (автоматизированный тест) – это скрипт, имитирующий взаимодействия пользователя с приложением, цель которого – локализация ошибок в работе программного обеспечения.

Конечная цель автоматизации тестирования представляет собой некий набор автотестов, которые, при нажатии на кнопку «GO!», будут поочередно запускаться. Ну или всегда можно запустить какой-либо автотест отдельно, если для этого есть необходимость. Каждый такой скрипт проверяет правильность работы определенной части приложения и фиксирует ошибки в случае, если что-то работает не так.
О том, насколько выгоднее использовать автоматизированное тестирование чем ручное, а так же о плюсах автоматизированного тестирования хорошо написано в этой статье. Я же хочу описать возможные проблемы, с которыми может столкнуться тестировщик, решивший использовать автоматизированные тесты.

Отбор тестов для автоматизации

Проблемы возникают уже при выборе тест кейсов, которые необходимо автоматизировать. Не все тест кейсы поддаются автоматизации, и бывают ситуации, когда некоторые из них лучше оставить в ручном тестировании. Другими словами, если у вас есть 1000 тестовых сценариев, то очень мал шанс, что из них 1000 возможно автоматизировать. Очень редко удается перейти полностью от ручного тестирования к автотестам. Не стоит забывать что ручное и автоматизированное тестирование – это не взаимоисключающие, а взаимодополняющие методы.
Например, невозможно (читай: очень сложно) автоматизировать тестирование таких вещи как:

• установка операционной системы
• проверка напечатанного принтером документа
• проверка содержимого картинки, видео

Стоимость

Далеко не всегда оказывается, что разработка и сопровождение автоматизированных тестов будет дешевле ручного тестирования. Необходимо потратиться на среду разработки, системных администраторов, наем программистов, их информационную поддержку (имеется ввиду поддержка при возникновении вопросов относительно тестируемой системы и тест кейсов), обеспечить им рабочие места. Все это выльется в немалую сумму и окупится только при тестировании больших систем, когда есть возможность автоматизировать довольно большое количество тестов. После разработки скриптов их нужно кому-то запускать и анализировать результаты. Не получится проводить тестирование по схеме «запустил – подождал – получил конечный результат». Нужен человек, который сможет анализировать выполнение автотестов: определять, нужно ли отправлять тест на доработку, действительно ли существует ошибка, найденная автотестом, подготавливать данные для тестирования. На подготовку среды для разработки, саму разработку уйдет масса времени.

Отдельная статья расходов на автоматизацию – это поддержка автотестов.

Поддержка

Автотесты всегда требуют поддержки. Так как написание автотестов – это программирование, то чтобы изменить\исправить логику автотеста нужно лезть в исходный код. Для этого нужно нанимать дополнительных специалистов, которые будут сопровождать написанные скрипты. Это новые расходы, без которых не обойтись и которые значительно повышают стоимость автотестов. Есть 2 основных случая, при которых может понадобиться вмешательство в исходный код:

1. Изменение входных данных к тесту

Хорошо, если при выполнении нескольких итераций тестирования приложения можно всегда подавать автотестам на вход одни и те же данные. Например, проверка занесения записи в базу данных, или проверка открытия какого-либо меню, где входные данные вообще не требуются.
Но бывает и так, что перед каждым запуском автотестов данные нужно готовить заново. При большом количестве тестов подготовка входных данных может занять много времени. Например, при тестировании банковской системы могут потребоваться счета в рублях, долларах, евро; счета с разными суммами, принадлежащими как физическим лицам, так и организациям. После прогона серии автотестов на всех счетах может остаться нулевой баланс, некоторые из них будут закрыты, некоторые заблокированы. При последующем тестировании необходимо будет использовать другие счета. В некоторых случаях данные могут быть хардкодом прописаны в скриптах автотестов, и происходить это может не из-за того что разработчику было лень сделать свой скрипт более гибким, а просто потому что такого хардкода требовал тест кейс. Через некоторое время тест кейс изменится (например название банка изменится с «хабрабанк» на «хабракредитбанк»), и потребуется изменение скрипта.

2. Изменение функционала

Особенно актуально для регрессионного тестирования – тестирования новых версий. При каждом обновлении интерфейса или функционала тестируемого ПО потребуется доработка автотестов. Автотесты не могут сами адаптироваться под новый интерфейс, и для продолжения их корректной работы приходится все изменять вручную. Чем больше количество тестов, и чем больше произошло нововведений в ПО, тем больше времени понадобится на актуализацию.
Пример: в старой версии программы было меню «Файл -> Опции», в новой версии этот пункт разделили на два: «Файл -> Настройки» и «Файл — > Параметры». Автотест по прежнему будет искать пункт «Опции», и хоть ты тресни, не найдет «Настройки».
Либо может измениться например время загрузки тестируемой страницы. Если раньше она загружалась моментально, то теперь на это уходит минута. Допустим, теперь скорость соединения слабая, или база тормозит. Автотест же этого не знает, ждет загрузки страницы 10-15 секунд и выдает сообщение «Ошибка: страница не загрузилась». Опять же понадобится доработка исходного кода скрипта.

В обоих случаях многое зависит от разработчиков: процесс написания автотестов требует не меньших знаний и усилий чем процесс создания любого другого ПО. Следовательно, тут проявляются все проблемы, связанные с разработкой: сложность контроля качества и надежности, перенос сроков, изменение бюджета и многие другие.

И всё-таки

Эти минусы не означают, что нужно избегать автотестов любой ценой. От них тоже есть польза.
Как видно из графика, использование автоматизации дает лучшие результаты при тех же затратах. Но, еще раз повторюсь, эти результаты будут лучшими только при автоматизации тестирования больших проектов.

Еще несколько плюсов автоматизации:

• Автотесты работают быстрее, чем человек
• Автотесты выполняются с большей точностью
• Автоматизация тестирования позволяет повысить качество продукта
• Автоматизация может использоваться практически во всех процессах тестирования
• Автотесты могут выполняться ночью

habr.com

Нагрузочное тестирование — плюсы и минусы профессии

Нагрузочное тестирование — плюсы и минусы профессии

Осень в работе инженера тестирования – это то самое время года, на которое чаще всего приходится пик работ (High Season), когда все наши клиенты резко вспоминают про нагрузочное тестирование и хотят срочно быстро до нового года все успеть. Соответственно возникает резонный вопрос: «А кто же все это будет делать?». Рабочих рук не хватает, и надо их как-то где-то добыть. Кто такой нагрузочный тестировщик, что означает работа в Перфоманс Лаб, почему стоит идти именно в нагрузочное тестирование?

Вопрос: «Почему люди не стремятся в НТ, а хотят непременно в разработку?»

При том, что задачи, которые мы решаем, бывают часто и сложнее, и динамичнее.

Рассмотрим все плюсы и минусы профессии нагрузочного тестировщика.

Начнем с минусов

---

Недооцененность

Простой вопрос: почему одна работа приносит удовольствие, а другая кажется каким-то невнятным убийством времени? Человеку всегда приятно чтобы работа, которую он делает, была оценена по достоинству, т.е. если то, что ты делаешь, не ценится другими людьми, то и удовольствия это не приносит. Зачастую работа нагрузочного тестировщика недооценена, т.к. не может быть представлена наглядно. Понимание, что без проведения нагрузочных тестов любая критичная ИТ система подвергается серьезному риску, и какая сложная стоит работа за, казалось бы, простыми тестами, бывает далеко не у всех заказчиков. Частенько о НТ вспоминают в самый последний момент, или просят провести «для галочки». Конечно, в таком случае слабая вовлеченность Заказчика или общая ситуация на проекте не позволяет раскрыть потенциал нагрузочного тестирования.

Борьба

Имеются и другие минусы: часто приходится сталкиваться с ограничениями, т.е. когда проект по НТ превращается в борьбу с внутренней бюрократией, включая выпрашивание доступов, вымаливание стендов, постоянные задержки при предоставлении логов или применении настроек. Да, в больших проектах НТ иногда не столько времени тратится на само тестирование, сколько на организационную работу. И если ты не являешься гуру деловой переписки и не знаешь кунг-фу эскалации проблем, может показаться, что никто тебя не понимает.

Сроки

Проблема номер три по частоте появления – нереальные сроки. В этой ситуации перфекционист внутри тебя говорит: «Нет, это надо сделать или хорошо или никак!», а сроки настолько сжаты, что можно сделать только как-нибудь. Тут приходится впрягаться по полной, иногда работать по вечерам и ночам.

Технологический взрыв

Иногда мы встречаемся с ИТ-системами, написанными на таких технологиях, что можно ужаснуться, как же это может работать в продуктивной среде? Как это поддерживалось и развивалось? И самая актуальная проблема: как это тюнить и исправлять? Собственные СУБД, самодельные протоколы, мертвые языки, отсутствие хоть какого-то понимания работы интеграции, отсутствие документации это – реальность.

Регресс

Но вот мы победили систему, дракон повержен, модель готова, НТ работает как часы. И начинаются серые будни, нужно катать одни и те же тесты, релиз за релизом, месяц за месяцем. Мы уже все знаем про систему, все ее слабые стороны и типичные глюки, все бизнес-процессы и вообще все. И хочется чего-то нового, но релизы идут и идут. Тут впору и заскучать.

Теперь про плюсы

---

НЕХ

Как это нагрузить? Как сделать этот эмулятор? Как подменить сертификат и обмануть сервер? Как деперсонализовать базу? В чем тут может быть проблема? Как это профилировать? Поначалу эти вопросы ставят в тупик даже ведущих инженеров, но к любой системе можно найти подход. Да, приходится погружаться, приходится импровизировать, постоянно пробовать новые инструменты. Это и хорошо, так как расширяет кругозор и позволяет двигаться вперед.

Разные заказчики — разные правила

Внутри нашей компании всегда можно сменить проект. Когда ты понимаешь, что эта система тебе «надоела» или этот заказчик тебя «достал» ты можешь сказать им: «Пока-пока!», и взять другой проект. Часто проекты по НТ достаточно короткие, но позволяют заглянуть за кулисы крупных корпораций и понять, что там за банка с пауками вместо рабочей обстановки. Я поработал примерно в 50-ти наших банках и крупных компаниях, и теперь к сказкам из HR отдела отношусь весьма скептически. Реально нормальных компаний, где были бы профессионалы и фанаты своего дела, а не менеджеры по объявлению, играющие в богов, исключительно мало.

Технологии

В нашей компании, к технологическим наработкам относятся очень трепетно. Мы их храним, систематизируем, причесываем и пытаемся повторно использовать. Конечно в нагрузочном тестировании не так много чистой разработки, и мы не увлечены погоней за «чистотой кода» и правильными моделями разработки, но собственные плагины, эмуляторы, связки инструментов и всякие «маленькие» хитрости, конечно, имеются. Практически постоянно идут разные исследовательские работы, некоторые интересные идеи удается реализовать в реальных проектах, некоторые умирают, но мы всегда на острие и стараемся на несколько шагов обгонять наших конкурентов.

Инструменты

Все мы знаем, что для разработки есть огромное количество всяких IDE, бессчётное количество фреймворков и библиотек, а что же у нагрузочного тестировщика? Неужели это тот парень, который освоил LoadRunner и больше ничего ему знать не надо? На самом деле инструментов много, даже очень много, т.е. гораздо больше чем один человек способен освоить и испробовать. Каждый ведущий инженер в нашей компании знает и профессионально владеет не менее чем 2-мя инструментами НТ. А обычно 3-4 инструмента. На самом деле это интересно, через некоторое время работы в НТ, у каждого формируются предпочтения. Но наша отрасль не стоит на месте, появляются новые версии и инструменты совершенствуются, появляются облачные сервисы и новые методологии. Постоянно приходится изучать и использовать новые «фишки», например, нагрузочное тестирование IVR, тестирование мобильных приложений или разбор терминальных протоколов.

Методология

Что касается теоретической части, она, как обычно, в процессе разработки. Вообще, на русском языке мало информации по нашей теме, но мы стараемся заполнять информационный вакуум: переводим интересные статьи и книги. Недавно пробовали участвовать в разработке международной системы сертификации нагрузочных тестировщиков, но пока в отрасли нагрузочного тестирования много «тумана». Регулярно организуем курсы, участвуем в тематических конференциях, проводим «круглые столы» по нашей тематике. Также занимаемся развитием QA в России: проводим аудит процессов тестирования и разработки, консультируем клиентов. Таким образом, если вы занимаетесь нагрузкой, привыкайте к тому, что вам придется проповедовать, объяснять и продвигать вашу профессию.

Творческий Рост

Вообще в НТ попадают разные люди, но склад ума должен быть особенный. Совсем не обязательно быть true-программистом, иногда это даже будет мешать, но скилл копания в коде и любви к программированию необходим. Чаще всего мы берем человека после института и учим-учим-учим-учим. Это обучение проходит в боевой обстановке на реальных проектах. В среднем, от стажера до позиции ведущего инженера проходит 4-5 лет, за это время человек успевает поучаствовать в десятках различных проектов. По итогам такого обучения наш специалист знает о тестировании, ИТ-архитектуре, разработке и техническом пресейле, т.е. он в разы круче аналогичного специалиста заказчика, который просидел все это время на одном-двух проектах.

Комфорт работы

Для чего мы работаем? Чтобы добыть денег? Это, скажу по правде, плохой стимул. Хороший стимул – это когда ты занимаешься чертовски интересным делом, тебя окружают друзья, и за это ещё и платят. Многие называют это корпоративной культурой, наверное это так. Мы выросли из стартапа который занимался НТ, и по сути направление нагрузки у нас осталось первостепенным. Конечно, в компании из 300+ человек уже нельзя обойтись без бюрократии, но если вы работали когда-нибудь в крупной компании, то знаете, что большая часть усилий тратится не на работу, а на проворачивание шестеренок внутренней бюрократической машины. В этом плане наше производство – это услуги, и если появляется какая-то инновация, мы всегда идем навстречу сотрудникам и всячески их поддерживаем.

Американская тема

Не секрет, что последние пару лет наша ИТ отрасль плавно загибается, денег нет, но мы держимся. Наша компания держится не только на крупных российских заказчиках, но и пытается работать на международном рынке. Это довольно тяжело: сказывается разница во времени, отсутствие хорошего разговорного английского у технарей, другие методологии и стандарты работы, удаленка и проблемы с оценкой трудозатрат. Но мы потихоньку осваиваемся, уже есть команды работающие с американскими заказчиками на постоянной основе. Вообще наша цель «Захватить мир» становится на полшага ближе. Так что, если хотите подтянуть язык, попробовать геораспределенные проекты – это к нам.

R&D

Каждый айтишник в глубине души мечтает сделать свою соцсеть, и потом стать Цукербергом ну или Дуровым, на худой конец. Мы тоже всегда мечтаем, и хотим сделать, сделать свой, идеальный инструмент нагрузочного тестирования. Что-то свое собственное, то, что удобнее и подходит для нас и наших проектов лучше всего. В разные годы эта мечта облекалась в разную оболочку, и получались разные инструменты. Некоторые из них выдержали проверку временем и используются как ноу-хау у наших клиентов. Если посмотреть на http://www.performance-lab.ru/testing-utilities, то там десятки разных полезных утилит. У нас постоянно идет внутренняя разработка, поэтому страничка регулярно обновляется.

Сезонность

Да, у нас в IT есть сезонность, как бы странно это не звучало. Зима — спим, весна — просыпаемся, лето — разминаемся, осень — работаем как черти. Обычно это зависит от наших заказчиков, т.к. чтобы внедрить что-то к новому году, надо очень активно тестировать, и пик приходится на октябрь-ноябрь. Но случалось, что и 31-го декабря, когда обычные люди уже собираются накрывать на стол, я проверял отчеты по нагрузочному тестированию перед отправкой клиенту. Осень — горячая пора в госсекторе (и не только), когда надо успеть обосновать бюджет на следующий год (эффективно распределив выделенные средства по текущим проектам), а для банков и ритейла важно успеть в пик продаж, возникающий перед новогодними праздниками. За полторы-две недели до нового года обычно наступает фриз, но QA все равно не дают отдохнуть, ведь длинные новогодние праздники – это отличный повод, чтобы отключить систему и внедрить какое-нибудь адское обновление.

Технический пресейл

Это тоже к нам. Да, каждый из ребят нашего направления понимает из чего состоят проекты, как их оценивать, и как их продавать, а также как проводить интервью с клиентом, как сформулировать цель тестирования, как определить трудоемкость и стоимость. То есть у нас нет такого, что мы не понимаем, что же мы продали и как теперь делать проект. Поэтому каждый инженер по производительности участвует в подготовке коммерческих предложений. А иногда он же и является потом исполнителем, и отвечает за качество перед заказчиком.

Итог

Итак, подводя итог, хочется сказать, как напутствие тем, кто только выбирает свое призвание в мире IТ. Любая работа интересна и важна, и по большей части ценны не какие-то конкретные навыки и конкретные технологии, а умение быстро в эти технологии погружаться и кругозор. Если вы хотите преуспеть – вам надо быть чертовски работоспособным, не бояться потратить часть энергии впустую, не боятся браться за сложную работу, не боятся браться за то, что не умеешь, и то, что поначалу кажется каким-то адом, через полгода будет восприниматься сущей ерундой. Ведь за что, по большому счету, человеку платятся деньги – за опыт, ответственность и работоспособность. И все эти три пункта не прокачиваются в тепличных условиях.

И да, у нас тяжело и весело, приходите к нам!

www.performance-lab.ru