Доклад посвящён эволюции методологии используемой для нагрузочного тестирования и основан на практическом опыте нескольких проектов. В начале пути была простая автоматизации нагрузочного тестирования. По-мере усложнения разрабатываемого продукта и изменения требований, возникала потребность в усложнения методологии и в заимствовании подходов хорошо зарекомендовавших себя для функционального тестирования. Кульминацией эволюции, в рамках доклада, будет рассказ об адаптации BDD (Behaviour Driven Develoment) практики для нагрузочного тестирования.
По ссылке выше вы можете узнать на каких принципах построен этот учебный курс, чем он отличается от наших предыдущих тренингов и от того, что предлагают другие учебные центры.
Данный тренинг направлен на то, чтобы помочь вам преодолеть первоначальные трудности, возникающие при тестировании мобильных приложений.
Во время прохождения курса вы узнаете, как организовать тестирование мобильных приложений, какое устройство выбрать для тестирования, получите представление о построении тестовых стратегий. Особый акцент сделан на работе с платформой Android, как с наиболее распространённой мобильной ОС на данный момент.
Что делать если требования нечеткие и постоянно меняются
Тестирование базируется на требованиях, но часто бывает, что сформулированных требований нет или они не полные. И на тестировщиков падает задача по сбору базиса для тестирования. Данный курс поможет понять, как правильно организовать процесс сбора, выявления и управления требований как в крупных проектах, так и для небольших команд гибкой разработки. Мы на примерах разберем все этапы работы с требованиями и проведем практические занятия в системе управления требованиями.
Автоматизация тестирования является важной и не неотъемлемой частью разработки современного ПО, но без правильного подхода нередко случается, что написание автотестов занимает слишком много времени, а их поддержка может требовать больше затрат чем просто ручная регрессия. Почему же так происходит и как этого избежать? В этой презентации, базируясь на своем опыте работы во множестве проектов, я хочу рассказать об основных ошибках и проблемах, с которыми приходится сталкиваться автоматизаторам и что нужно сделать чтобы их избежать (на примере фреймворка для автоматизации JDI)
Выступление Юлии Абрамовой на онлайн-конференции для тест-менеджеров и тест-лидов Chief ConfeT&QA.
«Как может править царством тот, кто не умеет играть в шахматы?» Сасанидский царь царей, Хосров II Парвиз Около 600 г. н.э.
Что общего у тестирования и шахмат? Это и комплексность входных факторов, и необходимая практическая подготовка, и огромная вариативность правильных ходов. Чему может научиться тест-менеджер у кандидата в мастера спорта по шахматам? Стратегии и тактике в борьбе с ошибками, комбинациям в ресурсах и жизни в постоянном цейтноте!
В своём докладе я расскажу про 10 параллелей игры в шахматы и построения процессов тестирования на трёх этапах:
Отрасль тестирования и обеспечения качества сильно эволюционировала за несколько последних десятилетий. С появлением конкуренции на рынке появилась необходимость в тестировании. Сначала это были тестировщики-мартышки, нажимающие на кнопки и нечаянно находящие некоторые ошибки в продуктах. После появились тестировщики-аналитики, создающие модели тестируемого ПО и обеспечивающие более высокие уровни тестового покрытия.
Но и этого оказалось мало для нужд рынка: стали появляться различные инженерные и процессные практики, направленные на обеспечение качества: TDD, Code Review, QA, Model-based testing, и т.д. В обеспечение качества оказалась вовлечена вся команда, а не только выделенные специалисты по тестированию.
В своём докладе я хочу рассказать о ступенях эволюции тестирования, уровнях обеспечения качества, и рассмотреть наиболее эффективные решения по обеспечению качества.
Доклад рассчитан не только на специалистов по тестированию, но и на всех вовлечённых в продуктовую разработку профессионалов. Только вместе мы делаем этот мир качественнее!
Иван Перл (ведущий инженер, Oracle), выступлениена конференции CEE SECR “Разработка ПО”.
Доклад о практиках, разработанных в компании Oracle, для генерации и повышения качества REST API документации. Применения этих практик привело к существенному улучшению качества документации, а также позволило проводить sanity тестирование REST API.
Что такое дефект? Лично мне нравится вот это определение:
"Дефект – это что угодно, угрожающее ценности продукта".
Прежде чем начать, давайте договоримся, что:
1. Мы не хотим сталкиваться с дефектами, угрожающими ценности нашего продукта.
2. Мы хотим, чтобы наши пользователи получали максимально возможную ценность от нашего продукта.
Если вы не согласны с утверждениями выше, дальше можно не читать.
Тестировщики в норме ассоциируются с поиском дефектов. Они зачастую яростно отстаивают найденные дефекты, а разработчики, напротив, сопротивляются дефектам, найденным в их коде. Пользователи не любят дефекты, разработчики не любят дефекты, менеджмент их тоже не любит – то есть, на сердце руку положа, любят их только тестировщики.
Почему это происходит? Да потому, что большинство тестировщиков фокусируется исключительно на поиске дефектов, и это именно то, за что им платят в большинстве компаний. Если вы, как тестировщик, любите найденные баги, вы можете не согласиться с дальнейшей информацией в этой статье, поэтому продолжайте чтение на свой страх и риск.
Выступление Елизаветы Батуриной на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA, весна 2013 года.
Несмотря на то, что RUP давно и широко шагает по планете, существует множество организаций, в которых при тестировании ПО не используются вообще или слабо используются тест-кейсы.
Кейс, с одной стороны, помогает понять, что должна делать Система, т.е., что ожидается. А с другой стороны, показывает что может сломаться в данной ситуации и как это выявить.
Основная проблема, с которой сталкиваются начинающие тестировщики: они не понимают зачем вообще нужны тест- кейсы, как правильно написать кейс и какие элементы кейса являются обязательными. Надо ли использовать определенную методологию или нет? Какой стандарт брать за основу? Как быстро и наглядно убедить заказчика, что действительно все основные сценарии проверены?
Тестирование, основанное на кейсах, является более объективным, чем исследовательское тестирование. Вторым достоинством является четкое понимание времени, которое надо на проведение тестирования.
С помощью кейсов нельзя выявить все-все ошибки, допущенные при разработке, но можно сократить их количество. В своем докладе я буду рассказывать о том, что дает использование кейсов, как можно использовать кейсы, из чего они должны состоять, как минимизировать затраты на написание кейсов и проведение проверок.
Выступление Таисии Рыбак на конференции CEE SECR “Разработка ПО”, осень 2016.
Основная проблема в переходе к CI- это неготовность людей и процессов к ускорению. В докладе рассмотрены примеры плавного перехода и внедрения процессов и приведены примеры набора инструментов, которые помогают плавно перейти от хаоса к непрерывной разработке.
15 декабря пройдет мини-конференция, посвященная двухлетию сообщества COMAQA.BY.