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

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



«Load Testing» — нагрузочное тестирование в переводе на английский. Синоним – тестирование производительности. Программно проводится имитация деятельности нескольких, определённого количества пользователей представляемого программного продукта (Performance Testing).

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

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

Нагрузочное тестирование — (load testing) в профессиональной среде тестирования ПО используется с целью принятия решения о возможности его окончательного запуска в эксплуатацию. Суть Лоад тестирования состоит в оценке производительности и быстродействия веб-ресурса (или его приложения) в условиях исскуственно созданной определенной нагрузки на систему. Главными индикаторами нагрузки для тестируемых интернет-ресурсов могут выступать ожидаемое количество его посетителей за конкретный интервал времени, заданное число операций, одновременно выполняемой на платформе веб-сайта.
Наиболее ожидаемым результатом нагрузочного тестирования является факт соответствия полученных результатов тем системным требованиями к работе веб-ресурса, которые разрабатывались на этапе формирования функционала веб-ресурса до начала разработки архитектуры программного обеспечения. Но учитывая тот факт, что заданные требования довольно часто могут быть не определены или недостаточно конкретизированы, используется вариант пробного нагрузочного тестирования (англ. exploratory load testing), которое предусматривает использование вероятностных вариантов ожидаемой нагрузки на систему.
Применение нагрузочного тестирования является оптимальным для определения производительности программного обеспечения веб-ресурса на этапе его ранней разработки, так как способствует выявлению состоятельности системы в целом.

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

Чем же занимается QA Engineer?

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

Уровни квалификации и опыта у Тестировщика (QA Engineer)

Обычно Тестировщиков делят на 4 основные категории:

Trainee QA Engineer

— это обычно человек, который не имеет опыта работы в этой профессии и только начинает свой путь в тестировании ПО

Junior QA Engineer

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

Middle QA Engineer

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

Senior QA Engineer

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

Читать дальше →

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

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

Пример того как выглядит список баг репортов в JIRA:


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

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

Читать дальше →

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

Приемочное тестирование (Acceptance testing)

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

Функциональное тестирование (Functional testing)

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

Смоук тестирование (Smoke testing)

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

Тестирование Безопасности (Security testing)

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

Читать дальше →

Что такое Тест Сьют и для чего он нужен?

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

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

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

Основные принципы в тестировании ПО

Из множества принципов, которые наверно для себя выделил каждый тестировщик занимающийся тестированием ПО есть основные по мнению сообщества тестировщиков, которые и хотелось бы выделить:

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

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

Читать дальше →

Черный ящик (Black box testing)

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

Серый ящик (Grey box testing)

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

Белый ящик (White box testing)

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

Читать дальше →

В Тестировании ПО можно выделить 4 типичных уровня Тестирования:

Модульное Тестирование (Unit Testing)

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

Интеграционное Тестирование (Integration Testing)

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

Читать дальше →

Очень часто Тестировщикам приходится тестировать те модули, которые уже были протестированы ранее. И это заняние заганяет в скуку и «замыливанию глаза» НО я считаю что Регрессия очень важна.

Регрессионное Тестирование

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

После того как вы нашли баг и программисты его пофиксили, следует проверить еще раз, а действительно ли баг пофикшен. Это правильно, но это не регрессионное тестирование а «Retesting», то есть Перетестирование. Если баг пофикшен и все в порядке, не делайте поспешных выводов. После перетестировании баги следует провести регрессионное тестирование задетого модуля, так как при исправленнии бага возможен импакт на этот мудуль.

Таким образом проведение Регрессионного Тестирования очень важно, для того чтобы обеспечить качество выпускаемого продукта на должном уровне

Убытки, связанные с киберпреступностью за прошлый год составили около $113 миллиардов долларов в год. Этих денег хватило бы на проведение 10 олимпиад, сопоставимых в олимпиадой в Лондоне в 2012 году.

Топ компаний, которые платят за найденные уязвимости:

— Microsoft. Средняя стоимость бага в Internet Explorer – $4 500
— Facebook. Минимальная стоимость бага — $500
— Google. Ошибка в Chrome стоит около $1 000
— Вконтакте выплатил украинским хакерам по $5 000 за найденную XSS-уязвимость
— Yahoo! $12.5 за уязвимость, платят купонами (на покупку кепок, ручек и маек в интернет-магазине Yahoo)

Читать дальше →