Общение на форуме. Создание новых тем не тестируем, только переписка внутри этой. Создать свое сообщение, процитировать чужое итд. Да, тут придется зарегистрироваться =)
Баг-трекер Багзиллу — http://bugzilla.testbase.ru/. Да да, мы тестируем реальный баг-трекер! Заведение дефектов, редактирование, прикладывание аттачей... Зайти в багзиллу можно с данными логин —
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
пароль — 12345678
Во время конференции Ольга показывала заведенные баги (все анонимно!) и разбирала выявленные ошибки.
Просмотр записи мастер-класса имеет смысл, если Вы так же как участники сначала попробуете выполнить задание, а уже потом будете смотреть видео.
Я работаю в Atlassian в качестве QA. Мы называем себя инженерами по обеспечению качества. Как QA, мы тесно сотрудничаем с нашей командой разработки, преследуя общую цель – «хорошее качество продукта». QA похожи на тренеров по качеству – мы фокусируемся на обучении и поддержке. Это значит, что обычно мы не тестируем самостоятельно – мы помогаем команде разработки определить, что должны тестировать они. Наша команда также занимается качеством процесса разработки. Хороший процесс должен быть эффективным, надежным, и простым в использовании. Команда QA разработала процессные метрики, которые помогают нам следить за качеством процессов. Мы боремся за постоянное развитие наших процессов, потому что этого требует наша организация. Мы работаем в Agile-окружении, и наша первостепенная задача – предотвратить появление багов. В процесс разработки мы встроили шаги, позволяющие предотвратить появление багов и намного раньше снизить риски.
В некотором царстве, в некотором государстве жила маленькая команда тестировщиков. Жила не худо, не богато, выполняла свои обязанности, о завтрашнем дне не думала, прошлого не вспоминала. И вот однажды столкнулась она с неразрешимыми проблемами. Команду тихо засасывало болото релизов, задач и дедлайнов, а горизонт радужных перспектив и светлого будущего постепенно скрывался за горами текучки. Долго она думала, что же делать, пока не прознала, что в соседнем царстве тестировщиков приглашали гостя заморского, он им все проблемы разом и решил. А имя того молодца – «аудит ясно-солнышко». Маленькая команда зазвала молодца к себе и понеслось…
Введение
Так начиналась история нашего аудита на одном из проектов. Команда, как вы поняли, была немногочисленной и состояла всего из трех QA специалистов. Тестирование на проекте начиналось с одного тестировщика, но после увеличения штата команда ощутила острое непонимание вопросов «что происходит» и «куда двигаться дальше». Помог ли аудит? Расскажу в конце.
Меня зовут Максим и я работаю в отделе QA компании Trinity Digital. В сфере обеспечения качества я уже более двух лет, люблю мобильные приложения, их сложность и динамичность. В этой статье я попытался сделать относительно небольшой список инструментов, источников информации и скилов, которые тестировщик мобильных приложений всегда должен иметь при себе.
Если разбить статью на части, то она будет выглядеть так:
Источники информации для максимально успешного тестирования
Инструменты для упрощения жизни тестировщика
Hint’ы
Доставка и анализ приложений
Куда расти дальше, если постигли дзен
//Алярма — ниже параграф для менеджеров и ценителей статистики
В этой статье я не буду рассказывать что такое iOS и Android, но нельзя не сказать, какую важную роль играют мобильные платформы в нашей жизни. Если обратиться к статистике по продажам PC и смартфонов, то мы можем увидеть, что с каждым годом количество мобилок растет, а вот PC все меньше пользуется спросом. Однако не стоит разводить полемику о смерти какой-либо из платформ. Как отлично было сказано в статье Пола Адамса — каждому бизнесу стоит найти свой идеальный баланс между мобильным и стационарным типом работы с информацией. А пока менеджеры убежали решать вопросы бизнеса, я продолжу. //Параграф для менеджеров закончился
Такие процессы как Continuous Integration и автоматизация тестирования требуют, чтобы написанные тесты были высокого качества и всегда завершались успешно. Не скажу, что я на 100% с этим согласен. Тесты, которые всегда проходят успешно, могут скрывать недостатки продукта, тем самым снижая его качество.
В любом пайплайне CI новые билды тестируются при помощи набора автоматизированных тестов. Такие инструменты как Chef или Jenkins хорошо справляются с организацией этих процессов и их управлением. Однако, они используют набор тестов, которые практически гарантированно будут выполнены. Если используются одни и те же тесты и они всегда выполняются успешно, это - повод задуматься над следующими вопросами:
Выполняют ли тесты именно те проверки, которые вы от них ожидаете? Тестируют ли они код, тестирование которого предполагаете вы? Не может ли быть такого, что они просто исполняют код, а не тестируют его? Остерегайтесь таких тестов, которые тестируют не то, что предполагаете вы.
Не расположены ли тесты и новый код продукта в разных средах? Если ваши тесты направлены на проведение регрессионного тестирования части продукта, которая не связана логически с новым выпускаемым кодом, может оказаться так, что продукт тестируется не полностью.
Опасайтесь “пестицидного парадокса”. Если долгое время используются одни и те же тесты, скорее всего, код “приобрел иммунитет” к тестам. Фрагменты кода, которые проверяются с помощью автотестов, скорее всего, со временем стали настолько хорошо написаны и отрефакторены, что вероятность внесения разработчиком ошибки в них крайне мала.
Тесты устарели. При том, что автотесты выполняют разрабатываемый код, нужно учитывать, что они необязательно выполняют проверки таким же способом, каким будут взаимодействовать с продуктом ваши клиенты. Возможно, в тестах используется неподдерживаемый способ запуска или методы, которые зарекомендовали себя не лучшим образом.
25-26 мая 2018 г. в Минске пройдет 23-я международная конференция в области обеспечения качества ПО «Software Quality Assurance Days» - крупнейшая в СНГ международная конференция для специалистов в области качества программного обеспечения.
Целевая аудитория – специалисты по тестированию разных уровней, руководители отделов тестирования, директора по качеству; а также все, кто по роду своей деятельности плотно вовлечен в сферу обеспечения качества ПО.
Планируемые тематики докладов:
Методики и инструменты тестирования ПО;
Автоматизация тестирования ПО;
Подготовка, обучение и управление командами тестировщиков;
Процессы обеспечения качества в компании;
Управление тестированием и аутсорсинг;
Совершенствование процессов тестирования и инновации.
В настоящее время организаторы конференции активно работают над составлением программы. Предложить доклад на конференцию можно на официальном сайте SQA Days. Для докладчиков участие в конференции бесплатно!
Прием докладов открыт до 04 марта 2018 г.
Как обычно для читателей нашего портала действует промокод на получение 10% скидки.
Зарегистрироваться и приобрести билет заранее по льготной цене можно здесь.
Требования – это первое, на что смотрит команда проекта, это фундамент для проектирования и разработки продукта. Допущенная в документации ошибка или неточность может проявиться в самый неподходящий момент. Очевидно, что гораздо проще устранить дефект в паре строк требований, чем позже «перелопачивать» несколько сотен (или даже тысяч) строк кода.
Тестирование требований направлено на то, чтобы уже на начальных этапах проектирования системы устранить максимально возможное количество ошибок. В перспективе, это позволяет:
В конце сентября 2017 года прошла первая онлайн-конференция для тестировщиков КоТэ.
В течение трех дней докладчики делились знаниями и опытом в различных сферах тестирования.
А у участников была возможность оценить каждый из докладов и выбрать наиболее понравившиеся.
Мы публикуем лучшие доклады прошедшей конференции.
Наибольшее количество голосов получил доклад Анастасии Смирновой "Как организовать погружение новичков в команду?"- о том, как найти точки соприкосновения между интересами новоприбывших сотрудников и потребностями проекта, и как обеспечить непрерывное развитие команды.
С небольшим отрывом за ним следует доклад Нины Агеевой "Итоговый отчёт по проведённому тестированию", в рамках которого рассматриваются все ключевые аспекты создания качественных финальных отчётов.
И также доклад Александра Филиппова "Экстренное тестирование: Один за всех!", в котором докладчик рассказывает как выстроить наиболее оптимальный процесс тестирования на новом или уже действующем проекте.
Готовясь к первому запуску курса “Автоматизированное тестирование Android-приложений”, я задался вопросом: какие инструменты функционального автотестирования для мобильных приложений сейчас наиболее популярны, что стоит выбрать для знакомства новичков с этой темой?
С одной стороны, инструмент должен быть достаточно прост в освоении и понятен людям без опыта. С другой – нет никакого смысла учить устаревшие или узкоспециализированные технологии. А учитывая, что стек технологий даже в двух похожих компаниях может различаться, привязываться к конкретным утилитам достаточно бессмысленно. Конечно, у меня было некоторое представление о популярности инструментов на рынке, однако не хотелось основывать курс только на своём мнении.
Поэтому я разместил простой опрос из трёх пунктов на нескольких крупных сообществах QA в FB, Telegram и Skype. За несколько дней я получил ответы от 36 человек, что уже подходит под критерии большой статистической выборки. Конечно, этот опрос не претендует на звание серьёзного исследования рынка, но помогает понять основные тренды.
Сарказм просьбы оценить время на тестирование не только в том, что он походит на просьбу оценить, сколько времени понадобится на поиск всех-всех-всех пасхальных яиц на Пасху. Зачастую момент, когда тестирование останавливается, просто от нас не зависит.
Тестирование – это эмпирическое техническое исследование, цель которого – позволить заинтересованным лицам принимать информированные решения, касающиеся качества (Кем Кейнер). Следовательно, вопрос «сколько времени уйдет на тестирование?» на самом деле звучит как «Сколько времени понадобится тем, кто принимает решения, чтобы получить достаточно информации для принятия информированного, основанного на рисках решения?»
Вот экзамен для вас как для тестировщика: научите кого-нибудь тестировать за три дня. Эта задача встала передо мной, Катриной Клоки, Аароном Ходдером, Джорджией Чанн в январе 2014 года. Нас попросили трое суток поучаствовать в выпускной программе Assurity, которая дала миру немало тестировщиков.
Ответственность была высока, и все мы волновались. В конце концов, это было первое, что десяток выпускников узнают о тестировании. Некоторые из них изучали программирование, но большинство было новичками не только в тестировании, но и в IT в целом. К счастью, трое суток пролетели как стрела, выпускникам все понравилось, мы много веселились, но самое главное – птенцы нашего гнезда действительно узнали что-то о тестировании. Как мы этого добились?
Мир удивительных открытий
Перед нами стояла задача впихнуть десятилетнюю мудрость и размышления в свеженьких радостных выпускников. Конечно, мы могли просто забросать их информацией – трех дней нам хватило бы. Наполни их идеями и надейся, что они хоть что-то запомнили. В конце концов, кто мы такие, чтобы знать, с какими проблемами они столкнутся, когда станут тестировщиками? Когда они начнут развиваться и расти как тестировщики, их окружение поддержит их, все они пойдут разными дорогами, получат различный опыт, столкнутся с различными ситуациями и проблемами.
25-26 мая 2018 г. в Минске пройдет 23-я международная конференция в области обеспечения качества ПО «
