18 и 19 апреля 2018 года в Москве пройдет уже вторая Международная конференция, посвященная вопросам тестирования и качества программного обеспечения - TestCon Moscow 2018.
17 апреля будут организованы практические мастер-классы от экспертов международного уровня, где Вы сможете получить глубокие практические знания.
До 28 февраля на все билеты действует скидка в 30%. Особое предложение – FULL PASS, 1 билет на двухдневную конференцию и 1 билет на мастер-класс по вашему выбору за еще более привлекательную цену.
Конференция TestCon Moscow 2018 охватит широкий спектр профессиональных вопросов в области тестирования и обеспечения качества ПО. Своими знаниями с вами поделятся признанные международные эксперты из таких стран, как Голландия, Швейцария, Израиль, Великобритания, и др. Ключевые вопросы конференции:
инструменты, методики и методологии тестирования ПО
инновационные техники
тенденции и профессиональный опыт
культура и передовая практика
Почему надо принять участие в конференции TestCon Moscow 2018?
Потому, что во время конференции:
Вам не нужно будет ехать заграницу для того, чтобы услышать выступления более 30 тщательно отобранных спикеров таких известных компаний, как RED HAT, Volvo, CloudBees, Capgemini и многих других;
3 параллельных потока каждый день предложат Вам широкий спектр тем, чтобы каждый участник конференции смог составить свою личную программу совершенствования;
Вы получите возможность принять участие в дискуссии с настоящими экспертами, обновить уже имеющиеся контакты и завязать новые полезные знакомства среди более, чем 400 профессионалов в области тестирования из разных стран.
Мир профессионалов в области тестирования и обеспечения качества программного обеспечения постоянно меняется и каждый день приносит интересные возможности, повышает планку и заставляет расширять кругозор. Конференция поможет вам обновить уже имеющиеся знания, расскажет об инновационных подходах и методологиях, откроет новые горизонты и предоставит возможности карьерного роста. Для начинающих – это отличный шанс приобрести новые полезные знакомства в профессиональной среде.
Эмоции управляют людьми, а управление эмоциями людей – мечта каждого маркетолога. Как правило, все нововведения основаны на субъективном «мне кажется, что так будет красивее/удобнее». Гораздо реже под конкретное изменение проводится анализ мнения клиентов. Надеяться на субъективную оценку маркетолога можно, но рискованно. Собирать фокус-группу – затратно. Просто ввести изменение и посмотреть, что же произойдет по прошествии определенного времени, – не научно.
Так как же все-таки определить пользу изменений без потери клиентов и времени? Этот вопрос решает A/B тестирование. Его использование ведет к увеличению трафика клиентов и степени конверсии сайта, к росту количества продаж, кликов и лайков.
…несмотря на то, что он кое в чём неполон, содержит много сомнительного или,
во всяком случае, вопиюще неточного, он имеет два важных преимущества:
во-первых, он немного дешевле, [...], а во-вторых, на его обложке большими
и приятными для глаз буквами написаны два слова «Без паники!»
— The Hitchhiker's Guide to the Galaxy
Перед запуском нового курса я задумался, о каких инструментах стоит рассказать ученикам. Прошерстил Рунет и англоязычный Интернет в поисках сравнительных статей, но, как ни странно, не нашёл подходящего источника информации. И тогда я решил создать его сам.
Я преследовал три цели:
Классифицировать инструменты в стеке автотестирования, чтобы стали понятны их иерархия и сочетаемость.
Показать, какие инструменты популярны сегодня на рынке.
Рассказать про самые популярные инструменты каждого типа и сравнить их по нескольким параметрам.
Результатом моих трудов стал этот путеводитель по наиболее популярным и простым в освоении инструментам автотестирования мобильных приложений.
Доводилось ли вам задумываться о том, кто такой "самый ценный тестировщик"? Какие показатели его работы отличаются от "простых смертных"? Что он делает по-другому, какие техники использует, какие задачи решает?
Заинтересовавшись этим вопросом, Олег провёл полноценное исследование среди различных участников процесса разработки. Полученная статистика наглядно демонстрирует ожидания от тестирования и даёт понимание, как стать лучше, ценнее, востребованнее.
При написании статьи были использованы материалы Владимира Беленя, подготовленные в рамках внутреннего обучающего семинара проектной команды Лаборатории качества «User story & friends».
Процесс тестирования прикладного ПО всегда имеет свои особенности и тонкости. Зная о них и правильно определив целевую аудиторию и ее потребности, специалист может провести проверку быстрее и качественнее. Одной из таких «тонкостей» является техника User story. В нашей статье мы постараемся выяснить, что это за техника, и почему она не только применима, но и удобна в тестировании страховых продуктов, а также наметим способы обнаружения критичных багов функционала с ее помощью.
User story
Для начала определимся, что же такое User story. Пользовательские истории (англ. User Story) – способ описания требований к разрабатываемой системе, сформулированных как одно или несколько предложений на повседневном или деловом языке пользователя. Пользовательские истории – это один из самых быстрых способов документирования требований клиента (цель документирования состоит в том, чтобы оперативно и без затрат реагировать на возникающие изменения).
Начиная с девяностых годов, Кем Кейнер, Джеймс Бах и Брет Петтикорд начали формулировать свою концепцию «школ тестировочной мысли». Они самоидентифицировались как принадлежащие к школе «тестирования, управляемого контекстом», и описывали другие способы мышления, с которыми они сталкивались в течение своей карьеры, как фабричную школу, аналитическую школу, и школу качества. Позднее они добавили пятую школу – школу Agile. Такая организация научной мысли давала новый способ разобраться в различиях мнений о «хорошем» тестировании [1].
С тех пор определения школ развились от изначально задуманной перспективы (определенной работой Томаса Куна про способы развития сводов знаний) в нечто куда более расплывчатое. Противоречия множились, так как концепция школ использовалась для того, чтобы категоризировать и даже демонизировать людей, а не идеи (Джошуа Рейн писал об этих аспектах школ в декабрьском выпуске Testing Trapeze). В какой-то момент дискурс вокруг школ даже описывал их как нечто религиозное. Разговор вокруг школ начал включать элементы, схожие с теми, которые встречаются в дискуссиях о политике (как минимум тут, в США – язвительность, личные атаки, укоренившиеся взгляды). Однако никто не бывает прав в 100% случаев, и ни одна группа не может всегда владеть единственно верной перспективой по отношению к определенной проблеме. Сейчас меня беспокоит, что люди говорят, не слушая друг друга, вместо того, чтобы совместно развивать отрасль. Наши дискуссии приносят больше вреда, чем пользы.
Давайте подразумевать под кодированием выявление тест-идей из неявных ментальных моделей, а также явно и точно описанные тест-кейсы. Кодирование означает явное выражение идей в форме какого-либо кода (например, текста или ПО). Культура тест-кейсов настаивает на кодировании тестирования до такой степени, что неохваченными останутся только тривиальные аспекты процесса. Эта культура гласит, что кодирование практично и нужно – более того, необходимо, и что его отсутствие говорит о безответственности. Но это не так. Кодировать тестирование невозможно.
Идея, что тестирование можно закодировать, не поддерживается ни научной, ни инженерной литературой. Несмотря на годы поисков, авторы так и не нашли исследований, подтверждающих, что тестирование должно быть зафиксировано письменно – они даже не нашли подтверждения, что это в принципе возможно сделать. На самом деле верно ровно обратное. См. «Sciences of the Artificial», написанную нобелевским лауреатом Гербертом Саймоном – он глубоко изучает этот вопрос. Саймон демонстрирует, что идеальная рациональность доступна нам только в простейших ситуациях, и изучает природу процесса дизайна как «ограниченно рациональную», требующую эвристических решений. Прочитать стоит и «Introducton to general systems thinking» Джеральда Вайнберга, который показал, что наблюдение и описание систем требует их упрощения, и что алгоритма, позволяющего, как сделать нечто, ничего не потеряв, не существует.
Всем привет, меня зовут Александр, и я занимаюсь QA (обеспечением контроля качества) разрабатываемой нами продукции. Наши контрагенты-фабы в юго-восточной Азии, особенно китайцы — ребята резкие, шустрые, и готовы сделать много, быстро, но вот с качеством выходит не всегда. Как мы с этим боремся, попутно экономя деньги компании — написано под катом.
Печать и компоновку наших печатных плат далеко не всегда реалистично или целесообразно делать в нашей стране, поэтому часто производство выполняется там, где это проще, дешевле и быстрее, то есть в Китае и на Тайване. А когда речь заходит о больших партиях и массовом производстве, то выбор площадки производства становится всё более очевидным. Однако что для нас большая партия, для китайцев не такая уж и большая, поэтому и внимания в плане качества и его обеспечения уделяется меньше. Под каждого небольшого по их меркам заказчика методики тестирования и тестовые стенды разрабатывать китайским коллегам не хочется.
«Система последовательной интеграции», не уверен, что перевод правильный – лучше называть система непрерывной интеграции (continuous integration).
С ними первый раз я столкнулся в начале своей работы, когда 5-7 программистов усиленно писали код и тесты, меняли конфигурационные файлы и лили все свои результаты в trunk/master. В итоге частенько (так частенько, что аж бесило) в основной ветке появлялось нечто нерабочее. Причём выявлялось это тогда, когда нужно было развернуть тестовый стенд, что сильно замедляло работу группы тестирования (ждали исправления) и разработчиков (соответственно исправляли). Т.е. работоспособность кода не контролировалась после помещения его в репозиторий.
кроме того через его интерфейс можно было отслеживать кто какие коммиты вносил, как со временем менялось покрытие тестами, за какое время осуществлялась сборка и прогон тестов и самое главное — из-за кого был сломан билд.
«Мы ищем начинающего тест-аналитика для написания и выполнения тест-кейсов, чтобы убедиться, что клиенты получают качественный продукт…»
«Обязанности: помогать со сбором требований и разработкой тест-кейсов, удовлетворяющих требованиям»
«Для успешной работы в этой роли необходимо следующее: …Уметь писать ручные тест-кейсы и прогонять их… Подтвержденный опыт создания условий тестирования и сценариев тестирования… Выполнение кейсов и отчетность о результатах».
Из объявлений о найме, опубликованных на seek.co.nz 24 января 2014.
Наша область больна тест-кейсами, как чумой. Создание кейсов поминается в описаниях вакансий так часто, как будто это основная обязанность тестировщика. Тестировщики, обращающиеся к нам за советом, тоже чересчур часто упоминают «мои тест-кейсы» в смысле «моя работа как тестировщика». Этот фокус на тест-кейсах был невинен и образовался с хорошими намерениями, но теперь он отравляет нам жизнь и мы, авторы статьи, убеждены, что это одна из причин нехватки уважения к тестированию. Тест-кейсы сдерживают нас.
Настало время вмешаться в вопрос. В этой статье мы критически исследуем понятие тест-кейса и культуру, зачастую окружающую его. Мы продемонстрируем, почему тестирование невозможно закодировать тест-кейсами, и предложим альтернативную точку зрения, основанную на том, что тестирование – это человеческая деятельность, а не артефакты.
