Отрасль тестирования и обеспечения качества сильно эволюционировала за несколько последних десятилетий. С появлением конкуренции на рынке появилась необходимость в тестировании. Сначала это были тестировщики-мартышки, нажимающие на кнопки и нечаянно находящие некоторые ошибки в продуктах. После появились тестировщики-аналитики, создающие модели тестируемого ПО и обеспечивающие более высокие уровни тестового покрытия.
Но и этого оказалось мало для нужд рынка: стали появляться различные инженерные и процессные практики, направленные на обеспечение качества: 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- это неготовность людей и процессов к ускорению. В докладе рассмотрены примеры плавного перехода и внедрения процессов и приведены примеры набора инструментов, которые помогают плавно перейти от хаоса к непрерывной разработке.
Если вам приходилось профессионально заниматься тестированием, вы наверняка слышали про сертификацию International Software Testing Qualifications Board, и вполне вероятно, вы слышали о Rex Black, одном из основателей этой организации и президенте компании RBCS.
Новость в том, что 10 декабря Rex выступит на конференции Гейзенбаг 2016 Moscow с докладом, в котором поделится своим 30-летним опытом решения сложных задач из мира тестирования: как тестировать сложные распределенные IT-системы и измерять метрики; какие ошибки чаще всего допускают в измерениях; что считать ошибкой при тестировании, а что нет.
Кроме Рекса, на конференции вы найдете еще 20 докладов от экспертов в области автотестирования, нагрузочного тестирования и от экспертов из Badoo, Яндекс, Deutsche Bank, Appium, SAP и других компаний.
Не стало неожиданностью, что JMeter там сильно оторвался от других инструментов. Для тех, кто хочет освоить этот инструмент совсем скоро у нас стартует курс Тестирование производительности.
Приближается масштабная юбилейная 20-ая международная конференция для специалистов в области обеспечения качества - SQA Days, которая в этот раз пройдёт в Минске. В этом году мне удалось войти в Программный комитет конференции и принять участие в отборе докладов и подготовке докладчиков.
Как говорится в официальном пресс-релизе: “Доклады, представленные на конференции, прошли не просто серьезный, а можно сказать, суровый отбор.” т.е. большое количество выступлений пришлось отсеять или серьёзно переформатировать.
Одна из тем, на которую было подано целых четыре заявки можно собирательно назвать - “Как делать правильную автоматизацию”. Во многих из докладов рассказывалось про конкретный опыт, набитые шишки, сотни пройденных граблей! Но, как писали в советских методичках, закаленного инженера такие преграды не устрашат.
Чтобы не потерять полезный опыт и изложить сообществу практические советы коллег, было решено написать эту статью.
15 декабря пройдет мини-конференция, посвященная двухлетию сообщества COMAQA.BY.
