Всем привет, меня зовут Таня и это моя первая статья на Хабре.
В начале декабря проходила конференция Heisenbug 2018 в Москве. Это событие было уже освещено многими: раз, два, три.
Я отметила для себя, что в основном были затронуты только положительные моменты, хотя были и отрицательные. Я хочу поделиться своим взглядом на это событие. Если кто-то не согласен с моим мнением, то пусть так и будет.
Читать полностью »
В последнее время все чаще встречаются упоминания о некоем волшебном средстве — тестировании на основе свойств (property based testing, если надо погуглить англоязычную литературу). Большинство статей на эту тему рассказывают о том, какой это классный подход, затем на элементарном примере показывают как написать такой тест используя какой-то конкретный фреймворк, в лучшем случае подсказывают несколько часто встречающихся свойств, и… на этом все заканчивается. Дальше изумленный и воодушевленный читатель пытается применить все это на практике, и упирается в то, что свойства как-то не придумываются. И к большому сожалению часто на этом сдается. В этой статье я постараюсь расставить приоритеты немного по другому. Начну все-таки с более-менее конкретного примера, чтобы объяснить что это за зверь такой. Но пример, надеюсь, не совсем типичный для подобного рода статей. Затем попробую разобрать некоторые проблемы, связанные с этим подходом, и как их можно решить. А вот дальше — свойства, свойства и только свойства, с примерами куда их можно приткнуть. Интересно?
Читать полностью »
Меня зовут Вадим, я ведущий разработчик в Поиске Mail.Ru. Я поделюсь нашим опытом проведения модульного тестирования. Статья состоит из трёх частей: в первой расскажу, чего мы вообще добиваемся с помощью модульного тестирования; во второй части описаны принципы, которым мы следуем; а из третьей части вы узнаете, как упомянутые принципы реализованы на Python.
Читать полностью »
При разработке продукта редко обращают должное внимание на его производительность при высокой интенсивности входящих запросов. Этим занимаются мало или не занимаются вообще – не хватает времени, специалистов или оправдываются типичной фразой: «У нас на проде и так всё быстро работает, зачем ещё что-то проверять?». В таких случаях может наступить момент, когда прекрасно работающий продакшн внезапно падает из-за нахлынувшего потока посетителей, например, под Хабраэффектом. Тогда становится ясно, что заниматься исследованиями производительности действительно необходимо.
Эта задача многих ставит в тупик, поскольку есть потребность, но нет ясного понимания, что и как надо измерять и как интерпретировать результат, порой даже нет сформированных нефункциональных требований. Далее я расскажу о том, с чего стоит начать, если вы решили пойти по этому пути, и объясню, какие метрики важны при исследовании производительности, и как ими пользоваться.
В Новый год многие подводят итоги, анализируя прошедший год, вспоминают все свои результаты и строят планы на будущее. В 12-ом выпуске нашего календаря Анастасия Ронжина, тестировщик сервиса Контур.Маркет, расскажет о том, почему стоит пробовать что-то новое, менять свои взгляды, подходы, ошибаться и снова пробовать.
У меня всё хорошо, я отлично работаю, меня хвалят, зачем мне что-то менять? Вполне логичный вопрос. В ответ цитата из книги «Алиса в Зазеркалье»:
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
Пока мы сидим и просто тестируем задачки, мир не стоит на месте. Джеймс Бах с Майклом Болтоном проводят очередное исследование и ищут подходы к тому, чтобы за короткое время тестировать с высоким качеством.
Эволюционирует место тестировщика в процессе разработки, да и сами процессы. Например, Максим и Ирина из нашей компании рассказывали про эволюцию автотестов, о том, как можно ускорить разработку с помощью тестов и изменении взглядов на то, кто и на каком этапе их должен писать. Лена и Илария рассказывали о том, что можно менять свои инструменты, подключаться к общению с пользователем, к подготовке ТЗ и прототипов, чтобы повысить качество продукта.
Мне очень грустно, когда я очередной раз слышу мнение, что тестировщик может достичь своего предела за 1,5 года, а дальше либо в автоматизацию, либо смена роли на менеджера, аналитика, разработчика и т. п. Когда твой каждый день — это просто повторение алгоритма: почитал аналитику, посмотрел прототипы, потестировал, запостил баги, перепроверил баги — то легко понять, почему ты устаёшь и разочаровываешься в профессии. Это же просто скучно!
Совсем недавно прошёл Heisenbug 2018 Moscow. Под одной крышей собрались не только тестировщики, но ещё и программисты, специалисты по автоматическому и нагрузочному тестированию, менеджеры команд и все остальные, для кого тестирование является важнейшей частью жизни. Этот пост — фотоотчёт, в котором мы еще раз оглянемся на то, как это было (осторожно, трафик). Фотки в действительно хорошем качестве приедут чуть позже, а это — то, что мы наснимали сами по ходу дела. В конце будет пара слов о следующем Heisenbug 2019 Piter и том, как на него подать свой доклад.
Отдел обеспечения качества (QA) занимается поиском багов в ПО. Методы отличаются в разных компаниях, но обычно этим занимаются сотрудники, знакомые с программным обеспечением. Они используют его различными способами и пытаются найти баги, которые упустили разработчики.
Термин QA может относиться к самому процессу, к организации, а также к отдельному тестировщику в рамках этой организации. Обычно тестировщиков в организации по обеспечению качества называют “QA”. В этой статье для единообразия будем использовать общую аббревиатуру QA вместо более точного «тестировщик отдела обеспечения качества».
В разных компаниях отличается степень ответственности QA за общее качество продукта. Иногда термин «обеспечение качества» не совсем применим к этому отделу, если он только ищет баги и подсчитывает их количество.
Читать полностью »
Когда приходишь на конференцию как зритель, может показаться, что за её программой стоят очень конкретные правила: организаторы однажды решили, какие доклады подходят конференции, и можно не соглашаться с их мнением, но оно всегда определённое и не меняется со временем.
А на самом деле сколько в программном комитете человек — столько и мнений. Конкретно сформулированный формат (например, «о тестировании не только для тестировщиков») задаёт направление, но всё равно можно по-разному расставлять приоритеты, и возникают разные точки зрения, порой даже взаимоисключающие. И в итоге программа конференции рождается на стыке разных взглядов.
В преддверии Heisenbug 2018 Moscow (6-7 декабря) мы расспросили участников программного комитета о программе, и их ответы в чём-то тоже различались. Поэтому каждое отдельное мнение — лишь часть картины, но вместе они позволяют многое понять о том, что можно будет услышать в четверг-пятницу на конференции.
Читать полностью »
На днях я буду делать внутренний доклад, на котором расскажу нашим разработчикам про неприятные ошибки, которые могут возникнуть при написании юнит тестов. Самые неприятные с моей точки зрения ошибки — когда тесты проходят, но при этом делают это настолько некорректно, что лучше бы не проходили. И я решил поделиться примерами таких ошибок со всеми. Наверняка ещё что-нибудь подскажете из этой области. Примеры написаны для Node.JS и Mocha, но в целом эти ошибки справедливы и для любой другой экосистемы.
Чтобы было интереснее, часть из них оформлена в виде проблемного кода и спойлера, открыв который, вы увидите, в чём была проблема. Так что рекомендую сначала смотреть на код, находить в нём ошибку, а затем открывать спойлер. Решения проблем указано не будет — предлагаю самим подумать над ним. Просто потому, что я ленивый. Порядок списка не имеет глубокого смысла — просто это очерёдность, в которой я вспоминал про всякие реальные проблемы, которые доводили нас до кровавых слёз. Наверняка многие вещи покажется вам очевидными — но даже опытные разработчики могут случайно написать такой код.
Меньше недели осталось до конференции Heisenbug 2018 Moscow: она пройдет в «Славянской Рэдиссон» 6-7 декабря.
По традиции прямо на YouTube будет открыта бесплатная онлайн-трансляция первого зала (ссылка спрятана под катом). Между докладами будут вестись интервью с ключевыми спикерами конференции.
В открытую трансляцию попадёт только первый день и первый зал. Чтобы получить доступ ко всем материалам, нужно или приобрести билет на полную онлайн-трансляцию, или прийти вживую. Для тех, кто пойдёт вживую, хочется напомнить несколько дополнительных фишек.
