В предыдущей статье мы рассмотрели особенности тестирования «серого ящика» по сравнению с «белым» и «черным». Давайте сегодня подробнее остановимся на «черном ящике» и выясним, где и когда его используют, а также какие у него достоинства и недостатки.
Так называемое «black-box тестирование» является методом тестирования программного обеспечения, внутренняя структура, дизайн и реализация которого неизвестна тестировщику (при подготовке тест-кейсов он опирается на требования и спецификацию). Хочу обратить внимание на то, что требования и спецификация не всегда существуют в письменном виде; тем не менее, при тестировании методом черного ящика мы можем опираться на устно описанные требования.
Что такое «черный ящик» согласно терминологии ISTQB?
Black-box тестирование – это функциональное и нефункциональное тестирование без доступа к внутренней структуре компонентов системы. Метод тестирования «черного ящика» – процедура получения и выбора тестовых случаев на основе анализа спецификации (функциональной или нефункциональной), компонентов или системы без ссылки на их внутреннее устройство.
До конференции Heisenbug 2017 Moscow осталось меньше месяца, а это значит, пришло время еще раз изучить программу и наконец принять решение об участии.
Напоминаем вам, что Heisenbug 2017 Moscow - это два дня хардкорных докладов по тестированию для тестировщиков, разработчиков, тимлидов и всех, кому не безразлично качество продукта. Минимум философских рассуждений и максимум практики. Будем изучать подходы к тестированию, полезные инструменты и фреймворки и всё, что может пригодиться при отладке ваших приложений.
Для всех, кто не может приехать на конференцию в Москву лично, есть онлайн-трансляция в высоком качестве с возможностью общаться со всеми участниками и спикерами в Telegram.
Все участники смогут получить материалы конференции сразу же после окончания. А кроме этого вас ждут памятные подарки от организаторов, розыгрыши от спонсоров, вечеринка и море живого общения с коллегами и экспертами со всего мира.
Читайте подробную программу и регистрируйтесь на Heisenbug. Скоро будем тестировать Москву!
Чтобы получить билеты по специальной цене, воспользуйтесь ключевой фразой SoftwareTestingPromo.
15 счастливчиков-победителей конкурсов КоТэ стали обладателями уникального пазла тестировщика, а также других подарков от организаторов конференции. К нам поступило множество приятных отзывов о призах, и вот лишь несколько из них http://prntscr.com/hd25gmhttp://prntscr.com/hd25uphttp://prntscr.com/hd26hd
Благодарим всех, кто принял активное участие в нашем мероприятии!
Есть ли разница между «security testing» и «penetration test»? С вопросом, ответ на который, как мне казалось, лежит на поверхности, я столкнулся на конференции для специалистов по тестированию Testing Stage в начале июня. И хотя выступал я с другой темой, именно этот момент вызвал интерес и резонанс публики. Для большей части моих коллег термины «security testing» и «penetration test» равнозначны. Так ли это на самом деле? Давайте разбираться!
В общем понимании «тестирование на проникновение» представляет собой продукт или услугу по санкционированной попытке обхода средств защиты информационной системы. Результатом теста является отчет, который может/должен содержать список обнаруженных уязвимостей, использованных векторов атаки, достигнутых результатов, рекомендаций по исправлению. Обращаю ваше внимание именно на термин «информационная система» в связи с тем, что это понятие включает в себя не только программное или аппаратное обеспечение, а также данные, персонал, организационные мероприятия, документацию и иные процессы. Т. е. результаты «пентеста» информационной системы зависят не только от качества и условий настройки и эксплуатации реализации программного обеспечения, а также от аналогичных метрик аппаратного обеспечения, корректности действий персонала, налаженности и согласованности операционных процессов и т. д. В то же время «security testing» — это итеративный процесс тестирования безопасности функционирования инфраструктуры в целом, который учитывает все этапы и контроли, и в этом случае «penetration test» — обязательный элемент общей модели «security testing».
C ростом команд неизбежно растет количество фич, а вместе с тем и тестовая модель и количество тест-кейсов, которые необходимо проверять при регрессионном тестировании. При этом количество команд растет не просто так, в нашем случае бизнесу хочется релизиться все чаще и чаще, не потеряв в качестве.
То, как мы в Альфа-Лаборатории решали проблему поиска баланса между скоростью, бюджетом и качеством, мы и рассмотрим сегодня на примере Альфа-Мобайла. Забегая вперед, ВНИМАНИЕ, СПОЙЛЕР!!! наше решение доступно на github: библиотека colibri-ui и шаблон colibri-ui-template для быстрого старта.
Сдвиг влево, происходящий благодаря таким процессам, как непрерывная интеграция и непрерывные релизы, приводит к растущей необходимости быстрой обратной связи от тестировщиков.
Проблема интерфейсных тестов в том, что они довольно медленные, и поэтому они – не лучший вариант, когда нужно быстро дать разработчикам знать, сломал ли их код новый билд. API-тесты куда быстрее и более надежны.
Прежде чем рассматривать инструменты тестирования API, давайте убедимся, что мы одинаково понимаем, что это вообще такое.
4 ноября в Санкт-Петербурге COMAQA провела большую конференцию выходного дня, посвященную автоматизации тестирования и сопутствующим вопросам обеспечения качества.
Конференция собрала почти 400 участников и более 2000 человек посмотрели YouTube трансляцию мероприятия.
Было представлено 20 докладов, посвященных автоматизации тестирования, тестированию производительности, тест-менеджменту и использованию человеческого капитала в тестировании.
Не секрет, насколько молоды профессии контроля и особенно обеспечения качества. Их значимость для IT индустрии давно обоснована. Но и сейчас, по мнению многих соискателей, это проходная ступень, которая не требует особых знаний и навыков. В моем багаже опыт работы с ПО из разных областей — ЖКХ, платежные терминалы, интернет-провайдер, retail и наконец игры. Во всех компаниях, на разных позициях, раньше и теперь я ручаюсь за качество продукта. Казус в том, что нигде я не получила убедительного ответа к какому именно «качеству» мы стремимся. Сегодня, на должности руководителя QA, я отвечаю на этот вопрос сама и хочу провести ликбез как можно шире.
Отмечу самые популярные требования к качеству.
— «Функционал должен соответствовать требованиям»
наличие настоящих требований и спецификаций роскошь, доступная не всем компаниям. И если требования есть, они целиком зависят от опыта аналитика, который к тому же может ошибиться в их структурировании и акцентировании из-за сыгравшего человеческого фактора. Не говоря уже о том, насколько шире и многообразней системы по сравнению со своими спецификациями.
— «Не должно быть багов в проде»
я не знаю ничего более относительного, чем «баг». При стремительном развитии рынка через полгода блокером может стать то, что раньше даже дефектом не считалось. Как часто фича в разработке, после выпуска воспринимается пользователем как дефект, заводится и исправляется соответственно.
— «После выпуска должно быть все хорошо/ удовлетворять пользователя»
по моему мнению это требование точнее остальных, проблема только в его неточности. В погоне за симпатией пользователя, тестирование становится необъятным, никогда не достаточно времени, чтобы убедиться в качественности и выпустить достаточно хороший продукт. Приходится выбирать наиболее критичное и смиряться с «кое-какерством». Это довольно грустно. И в этих условиях появляется привычка противопоставлять качество скорости.
Начнем с констатации факта: в тестировании грядут колоссальные перемены. Строго говоря, эти перемены серьезнее любых других изменений в индустрии, с которыми мы сталкивались ранее. Что за ними стоит? Чего ожидать тестировщикам?
За ответами на эти вопросы мы обратились к 12 уважаемым, опытным лидерам мнений в области тестирования:
"Несколько лет назад я начал замечать, что примерно раз в год приходится объяснять одни и те же вещи, причём речь не только о студентах, которых я учил, а и коллегам тоже. То, что мне казалось очевидным и давно понятным, для других оказывалось новостью.
В результате 1,5 года назад я сел и составил список таких вопросов, их оказалось 50. Тогда я сел ещё раз и написал небольшую книжку под названием "Software Testing Automation Tips", в которой описал все эти вопросы, придерживаясь нескольких правил:
1. Без привязки к какому-либо инструменту или языку 2. Минимум пространных рассуждений 3. Максимум полезной информации 4. Примеры из практики
И вот на днях книжку официально опубликовали, о чём я и хотел вам всем написать. Все эти 50 советов - результат более 10 лет работы со многими людьми, которые учили меня, которых учил я и просто с которыми работал. Это опыт не одного человека, а многих, просто собранный в одну книгу.
В общем, рекомендую всем, кто работает в автоматизации, особенно начинающим".
6 ноября вышла в свет книга Геннадия Алпаева