Сегодня, в пятницу, 13-го, в 22 часа по московскому времени, состоится запуск новой лаборатории «Test lab», представляющей собой виртуальный банк, с присущей ему инфраструктурой и уязвимостями. Участникам предлагается произвести компрометацию всей ИТ-структуры банка.

«Test lab» — пентест-лаборатории, построенные на базе сетей реальных компаний

В отличие от CTF-соревнований, лаборатории тестирования на проникновение «Test lab» имитируют ИТ структуру настоящих компаний и имеют полноценную легенду. Созданные для легальной проверки и закрепления навыков пентеста, лаборатории всегда уникальны и содержат самые актуальные уязвимости, а участие в лабораториях бесплатно и требует хорошей практической подготовки.

Разрабатывая лаборатории «Test lab» мы стараемся охватить практически все области ИБ: безопасность сетей, систем и приложений. Участникам предлагается выполнить эксплуатацию различных уязвимостей, связанных с работой сетевых и веб-компонентов, криптографических механизмов, ошибками конфигурации и кода, а также с человеческим фактором. Подключение к лаборатории осуществляется через VPN-соединение.

Участники, выступающие в роли пентестеров, пытаются эксплуатировать уязвимости, и, в случае удачи, получают доступ к серверам и рабочим станциям, каждые из которых содержат токен. Победителем считается участник, первым собравший все токены. Работа в лаборатории осуществляется на основе методики «серый ящик»: перед началом исследования предоставляется информация об инфраструктуре «Test lab» в виде схемы и описания деятельности виртуальной компании. Собирая специалистов со всего мира, мы разрабатываем лаборатории «Test lab» для различных мероприятий, таких как всероссийский конкурс ПрофИТ-2013, ZeroNights'13, PHD IV.

Лаборатория тестирования на проникновение «Test lab v.8»

Предыдущая лаборатория (Test lab v.7) представляла собой виртуальную компанию, специализирующуюся на разработке систем ИБ.

Сегодня будет запущена очередная, восьмая по счету лаборатория PENTESTIT, разработка которой велась практически полгода. «Test lab v.8» будет представлять собой виртуальный банк c присущей ему инфраструктурой и уязвимостями. Кроме этого, отличительной особенностью текущей лаборатории будет являться активно используемая система противодействия атакам, поэтому участникам необходимо будет быть максимально «незаметными». Это прибавит атмосферности!

Предыстория

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

В то время, у нас, как у разработчиков, было два способа «расширить» Excel под нетиповые задачи:

• VBA (Visual Basic for Applications);
• VSTO (Visual Studio Tools for Office).

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

Введение

Как-то я начал осваивать новый инструмент — JМeter — и не смог найти какого-то полноценного руководства как руководства к действию. Постепенно, разобравшись по некоторым довольно полезным статьям и блогам, пользовательской документации, я начал что-то понимать. И решил, что, возможно, я не один ищу то, с чего можно начать работать. Освоить некоторые принципы построения и логику самого инструмента. Так что вот — статья о том, как начать.
Так что в этой статье мы рассмотрим пример создания скрипта для 3 пользователей, которые хотят:
1. залогиниться;
2. добавить в какой-нибудь альбом новую фотографию;
3. поменять аватарку.
Как таковой — это обычный бизнес процесс для какой-нибудь социальной сети.

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

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

Введение

Данная статья будет полезна для специалистов не только в тестировании, но и из других областей.
Я думаю, все понимают, что отчётность — это, зачастую, та часть, которая обязательна на проекте, но составлять ее всегда проблематично. Каждый, рано или поздно, сталкивается с проблемой «как это описать?», «что написать?» и главное «зачем и кто это будет читать?».
На самом деле, отчет — это важная и лаконичная форма передачи информации от исполнителя к заказчику. Это ответ на его технические требования и одновременно информация о проделанной работе.
Сегодня мы поговорим об отчетах в тестировании. В статье Вы найдет акценты на важные моменты при создании отчётов.

Доклад Никиты Налютина на конференции SQA Days – 13, 26-27 апреля 2013 г. Санкт-Петербург, Россия

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

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

В течении своей работы в айти-сфере и тестировании я видела мало команд и проектов, где тестировщики реально используют code coverage в своей работе. Связано это на мой взгляд с двумя вещами:

1. Тем, что тестируем мы прежде всего требования;
2. Далеко не все понимают, как считать и использовать покрытие.

Интересующимся предлагаю свой взгляд на эти 2 пункта.

Завершив внедрение ТестЛинк в компании, где я сейчас работаю, решил рассказать про шаги, которые мне пришлось выполнить перед тем как начать создавать аккаунты пользователей (т.е. дать им доступ к системе). Хотелось, чтобы тестировщики увидели инструмент, создающий ощущение законченности и надежности.

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

Ниже вы узнаете о следующем:
1) Что запросить у того человека, который будет устанавливать TestLink.
2) Что желательно настроить (самому или кого-то попросить) после установки TestLink.
3) Как сделать перевод не переведенных элементов UI и использовать его в TestLink.
4) Как перенести тесты из XLS в TestLink.

В этой статье я не рассказал про следующие вещи, которые необходимо или желательно сделать при внедрении TestLink:
1) интеграция с bug (issue) tracking системами.
У себя я настроил интеграцию с Redmine именно со стороны TestLink (так как включение не протестированных нами плагинов в корпоративный Redmine было бы очень рискованно и долго).
2) создание своих шаблонов для отчетов (не делал пока).
3) использование TestLink в рамках бизнес-процессов вашей компании.
4) обучение работе с TestLink.

Перед тестированием всегда стояли и стоят две задачи – помочь команде поддерживать высокий уровень качества разработки и делать это, не задерживая весь процесс. И это справедливо не только для наших проектов в Яндексе, где мы работаем над очень большим количеством сервисов. Часто основная задача и вовсе формулируется как увеличение скорости тестирования при сохранении должного уровня качества. Скорость процесса разработки, приверженность ценностям частых и быстрых релизов – это основополагающие факторы для успеха любого продукта. У команды больше возможностей маневра, команда быстрее находит и исправляет ошибки, быстрее получает фидбек. Как же ускоряться, не теряя качества, как достичь дзена непрерывной доставки изменений?



Сегодня мы покажем, что Continuous Delivery — это просто и весело! А пользу от него можно получить, встроив его даже частично. Мы в тестировании Яндекса уже несколько лет используем подобный подход для наших библиотек с открытым исходным кодом — Allure Framework или Yandex QATools. Процесс прост, значительно масштабируем и может применяться как для огромных команд из одного человека, так и для маленьких командочек из десятков человек. А самое главное — весь инструментарий доступен в Open Source!

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

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

Добрый день!

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

Эта статья полезна не только для мануальных тестировщиков, желающих автоматизировать свои рутинные проверки, но и для бизнеса и HR-ов, которые ввиду отсутствия каких-либо общепринятых критериев, как правило, понятия не имеют кто есть QA Automation Engineer и в большинстве случаев принимают решение на основании «хороший человек».

Бывает ещё хуже – руководитель/PM/etc… приходят к своим мануальным тестировщикам и говорят: «слушай, а может мы автоматизируем наше тестирование – это сэкономит нам кучу времени и денег. Скажи, какие книги тебе нужны и какие курсы».

0. Начнём с ошибок, которые не надо допускать:

• Дайте мне книгу умную, которая всё за меня сделает
• Дайте мне курсы платные, которые всему меня научат
• Дайте мне форумы специализированные, которые ответят мне на все интересующие вопросы
• Дайте мне сертификацию полезную, с которой меня везде примут

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

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

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

Эта статья — вводная к матрице тестов, которой я на самом деле хочу поделиться и поделюсь во второй части.

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

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

Аннотация

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

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

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

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