Как всегда один раз в полгода наши тренера Наталья Руколь и Алексей Баранцев проводят очные тренинги по тестированию. В очном формате проводятся те тренинги, которые не удается переложить в онлайн-формат: тренинги в которых много групповой работы, в которых много интерактива и общения с тренером.
В это полугодии мы представляем всего три очных тренинга.
В зависимости от проекта, компании, продукта, команды, и многих других факторов, Вы можете использовать тестирование методом свободного поиска или более формальные, скриптовые подходы. Но вне зависимости от подхода к тестированию, оно должно быть планируемым, оптимизированным и управляемым. В противном случае неизбежны хаос, пропуски ошибок, нерациональная трата времени, ресурсов. Если Вы – тест-менеджер или ведущий тестировщик, и Ваша задача – поиск оптимального процесса тестирования, то Вам обязательно будет полезен этот тренинг. На нём мы не просто рассмотрим основные техники планирования, тест-анализа и организации процесса тестирования, но и потренируемся и сможем определить, какие подходы нужны именно Вам.
Наверняка многие из вас слышали про техники управления временем и повышения личной эффективности? Тестирование методом свободного поиска -- это подход к тестированию, который ставит перед собой аналогичные цели: как повысить эффективность работы каждого тестировщика, как избежать простоев, как увеличить отдачу от вложенных усилий. Для этого придуман ряд технических приёмов, которые мы будем учиться применять на этом тренинге. Тренинг будет полезен в первую очередь достаточно опытным тестировщикам, которые уже владеют техниками проектирования тестов, но хотели бы научиться ещё лучше делать свою работу, и добиться этого можно за счёт оптимизации использования рабочего времени.
Мы все знаем, как неприятно "пропускать" баги. Это случается время от времени, несмотря на то, что тесты проектируются по всем правилам науки. Почему же так происходит? Дело в том, что техники проектирования тестов подсказывают, как попасть в ситуацию, где высока вероятность обнаружить баг. Но что надо делать, чтобы заметить баг, когда он возник перед вами? Как понять, баг это или не баг? Как доказать это другим? Для этого требуются уже совсем другие навыки, про которые не пишут в учебниках по тест-дизайну. На этом тренинге мы будем учиться замечать баги, отличать баги от небагов, грамотно их описывать. А ещё я расскажу о том, как доказывать, что тестирование выполнено полностью, и что это вообще значит. Тренинг будет полезен опытным тестировщикам, которые уже владеют техниками проектирования тестов, но хотели бы научиться находить баги, которые не находят другие тестировщики, несмотря на то, что они знают те же самые техники.
До 25 сентября действуют льготные цены.
Для компаний мы готовы предложить проведение тренингов по тестированию в корпоративном формате на территории Заказчика. Напишите нам (
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
) и мы предложим очень выгодные условия.
Ну а те, кому интересны другие темы или нет возможности приехать в Москву или Санкт-Петербург могут посмотреть расписание ближайших онлайн-тренингнов по разным темам разных уровней.
29 августа в Минске прошла вторая полномасштабная конференция, посвященная автоматизированному и ручному тестированию, менеджменту команд и эффективному взаимодействию участников процесса разработки ПО, организованная сообществом автоматизаторов и сочувствующих COMAQA.BY при деятельной поддержке очень и очень многих небезразличных людей. На мероприятии с докладами выступили активисты сообщества, ключевые специалисты ведущих IT-компаний Беларуси. На конференции было представлено 15 докладов, разбитых на два потока и круглый стол, посвященный ряду наболевших вопросов тестирования ПО.
Темы прочитанных докладов:
«Принцип открытого кимоно как инструмент мотивации», … Антон Семенченко, COMAQA.BY,
«Внедрение автоматизации на проекте с действующим …» Вадим Зубович, COMAQA.BY,
“Codeception + PHP for QA Automation” Евгений Борисик, COMAQA.BY,
Представляем книгу Святослава Куликова «Тестирование программного обеспечения. Базовый курс.».
В основу книги положен десятилетний опыт проведения тренингов для тестировщиков, позволивший обобщить типичные для многих начинающих специалистов вопросы, проблемы и сложности. Эта книга будет полезна как тем, кто только начинает заниматься тестированием программного обеспечения, так и опытным специалистам — для систематизации уже имеющихся знаний и организации обучения в своей команде. Книга распространяется под лицензией Creative Commons.
Каждый год 9 сентября тестировщики отмечают свой профессиональный праздник.
И это очень хорошо, что он случается каждый год. Представляете -- наступает 9 сентября, а праздника нет! Вот это был бы баг!
Но даже если бы это вдруг произошло -- ничего страшного, через несколько дней, 13 сентября, в день программиста, разработчики бы пофиксили этот баг и мы всё равно смогли бы его отметить, хотя и со сдвигом сроков.
Впрочем, в этом году всё по плану, багов нет, празднуем сегодня. Ура!
Отдельно мы хотим поблагодарить всех наших читателей, всех кто был с нами весь год.
Для самых активных участников форума мы приготовили небольшой сюрприз.
10 самым активным участникам мы дарим наш IT-календарь 2016: типы багов. А чтобы не было обид и обвинений в необъективности выбора 10 участников (действительно выбрать сложно), то подарок мы отправим 30 участникам, которые с апреля по сентябрь активнее всего задавали вопросы и отвечали на форуме.
Запись доклада Екатерины Михеевой на онлайн-конференции Mobile ConfeT&QA, осень 2013
Все тесты прогнаны, регрессионное тестирование пройдено, кейсы заполнены, можно выкладывать новую версию вашего ПО? Казалось бы, да! Но нет! В своем докладе я расскажу про распространенные проблемы и ошибки, которые вызваны не самим ПО, а особенностями того или иного железа мобильных устройств на платформе Android.
Тестирование на эмуляторе и использование автотестов чаще всего не выявят эти хитрые ошибки, которые могут возникнуть у пользователя из-за многообразия устройств на платформе Android, в отличие, например, от iOS, для которой нет такого разброса. Поэтому я расскажу об основных особенностях мобильного железа:
как составить набор тестов;
что нужно учесть, чтобы покрыть основной список особенностей тех или иных устройств и сократить количество всевозможных ошибок, которые могут возникнуть у конечного пользователя: GPS, Печать, Передача данных, Фоточки, Проблемы ОС
2. Смотрите diff-ы каждой ветки/фичи и задавайте как можно больше вопросов разработчиков. Этим вы:
поднимите свой престиж как тестировщика - пытаетесь разобраться в коде и областях, которые затронуты этой фичей
начнете изучать язык программирования и начнете лучше понимать что происходит 'под капотом'
3. Изучите жизеннный цикл приложений. Activity 1, 2, 3 (Android) и ViewController 1, 2, 3 (iOS) для понимания из какого в какое состояние может переходить экран приложения и самое приложение.
4. Попросите выводить в лог все запросы к серверу и/или попросите удобную 'смотрелку логов' у сервер-side разработчиков, чтобы удобнее было анализировать запросы и выявлять дубликаты и/или находить более удобные способы обновления данных. Например, для обновления одной части профиля разработчик может перезапрашивать весь профиль вместо использования более легковесного запроса.
Сегодня День Знаний, и по всей стране школьники отправляются грызть гранит науки.
Наверное они верят, что вот ещё немного осталось до окончания школы -- и не надо будет больше учиться! Как бы не так. В школе вы учились учиться, а после её окончания вам предстоит учиться работать. А потом осваивать новые профессии, изучать новые технологии, повышать квалификацию. Но не стоит печалиться, ведь учиться так интересно!
Поэтому мы хотим поздравить с этим праздником всех тестировщиков, стремящихся к знаниям, но в первую очередь -- тестировщиков-джуниоров. А также их наставников, менторов, кураторов и прочих причастных.
С Днём Знаний, коллеги!
А для тех, кто постоянно развивается, мы предлагаем наше расписание тренингов на сентябрь-октябрь. Мы представляем тренинги разного уровня по разным областям тестирования.
Скоро 2016 год - яркий, наполненный бурными событиями, легкий и веселый — таким обещает быть год обезьяны.
Уже сегодня нужно задумываться о том, что подарить коллегам айтишникам на Новый год…
Мы сделали недорогой, но при этом красивый настольный календарь, сочетающий символику нового года и айтишную тематику. Мы надеемся, что он станет отличным подарком и порадует всех кто работает в it-сфере: программистов, тестировщиков, аналитиков, менеджеров.
В своей работе мы сталкиваемся с багами каждый день. Какие-то баги мы легко узнаем и ловим их, а на какие-то не обращаем внимания. Наш календарь напомнит о том, что баги бывают разные, а обезьяна, символ нового года, продемонстрирует их так, что даже ребенок это запомнит.
Доклад Ирины Ивановой на на встрече Tallinn DevClub.
Все люди время от времени склонны к когнитивным искажениям – так называемым, ловушкам мышления. Каждый род деятельности, в свою очередь, склоняет к тем или иным ловушкам в разной степени. При тестировании, например, можно легко найти зависимость или, наоборот, случайность там, где их нет. Или найти сложный критический баг, но пропустить простой.
Многим знаком инструмент Selenium. Это стандарт de facto (а вскоре и de juro) в области автоматизации веб-приложений и мобильных приложений. Невероятно популярный инструмент. Но удивительно то, что Selenium развивается без чёткого плана. С одной стороны, это вполне объяснимо – команда разработки представляет собой группу энтузиастов, работающих над проектом в свободное время. С другой стороны, непонятно, почему коммерческие вендоры не могут повторить этот успех. Вот вы верите в то, что такое возможно?
Концепцию предвзятости я понимал смутно, пока не прошел курс Джеймса Баха "RST". Смысл понятия в том, что зачастую мы видим то, что наш мозг, наша психика хотят видеть, а не то, что существует на самом деле.
В целом, такая профессия, как тестировщик, существует именно благодаря предвзятому отношению.
Представим разработчика, создающего страницу регистрации для нового приложения. Он регистрирует нового пользователя, вводя свое имя, почту, дату рождения, и получает сообщение "Добро пожаловать, Стюарт Кук!"."Все работает", заключает разработчик, и переходит к следующей интригующей задаче.
Можем ли мы сказать, что регистрация была протестирована? Разработчик ввел данные, увидел то, что и хотел увидеть - приветствие системы - и убедился, что все работает как надо.
Все мы попадались на эту удочку не раз (я, по крайней мере, попадался) - один тест ничего не доказывает. Осознание, что мы склонны делать вывод "все работает", исходя из одного-единственного подтверждения - ключевой момент курса "Быстрое тестирование".
Ввести данные и получить сообщение "Привет, Стюарт" - неплохой старт. Но до финиша еще далеко.
Вдруг это просто сообщение? Что, если учетная запись не была создана? Мы можем проверить базу данных, или попробовать войти в систему, чтобы убедиться, что учетную запись можно использовать. Если разработчик еще не создал страницу авторизации, придется ограничиться базой данных. Вы же собирались ее проверить, правда?
А если мы зарегистрируемся как Вася - мы тоже получим сообщение "Привет, Стюарт"? Мелочь, а неприятно. Что, если поля регистрации будут принимать значения любой длины? А если мы введем туда полную ерунду - удастся ли создать учетку?