Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Оценка времени на тестирование, тренды в инструментарии мобильных приложений, как заводить дефекты хорошо, и многое другое: рассылка тестирования за начало января 2018
25.01.2018 11:31

Вышел выпуск рассылки за начало января, его содержание доступно по ссылке.

Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Подписаться на рассылку можно по ссылке.

Обсудить в форуме

 
Тестирование на фабрике: «Чёрный ящик» и короткий цикл тестирования
20.12.2017 17:32
Китайские рабочие

Автор: Алексей Старцев

Оригинальная публикация: https://habrahabr.ru/company/yadro/blog/336822/

Всем привет, меня зовут Александр, и я занимаюсь QA (обеспечением контроля качества) разрабатываемой нами продукции. Наши контрагенты-фабы в юго-восточной Азии, особенно китайцы — ребята резкие, шустрые, и готовы сделать много, быстро, но вот с качеством выходит не всегда. Как мы с этим боремся, попутно экономя деньги компании — написано под катом.

Печать и компоновку наших печатных плат далеко не всегда реалистично или целесообразно делать в нашей стране, поэтому часто производство выполняется там, где это проще, дешевле и быстрее, то есть в Китае и на Тайване. А когда речь заходит о больших партиях и массовом производстве, то выбор площадки производства становится всё более очевидным. Однако что для нас большая партия, для китайцев не такая уж и большая, поэтому и внимания в плане качества и его обеспечения уделяется меньше. Под каждого небольшого по их меркам заказчика методики тестирования и тестовые стенды разрабатывать китайским коллегам не хочется.

Подробнее...
 
В разрезе: новостной агрегатор на Android с бэкендом. Система последовательной интеграции
23.01.2018 00:00

imageАвтор: Фёдор Малышкин

Оригинальная публикация: https://habrahabr.ru/post/334730/

Вводная часть (со ссылками на все статьи)

«Система последовательной интеграции», не уверен, что перевод правильный – лучше называть система непрерывной интеграции (continuous integration).
С ними первый раз я столкнулся в начале своей работы, когда 5-7 программистов усиленно писали код и тесты, меняли конфигурационные файлы и лили все свои результаты в trunk/master. В итоге частенько (так частенько, что аж бесило) в основной ветке появлялось нечто нерабочее. Причём выявлялось это тогда, когда нужно было развернуть тестовый стенд, что сильно замедляло работу группы тестирования (ждали исправления) и разработчиков (соответственно исправляли). Т.е. работоспособность кода не контролировалась после помещения его в репозиторий.

Тогда на помощь нам пришёл Hudson (http://hudson-ci.org/) (сейчас более известен как Jenkins (https://jenkins.io/), хотя формально сам Hudson остался, но не так популярен и не так активно развивается) – он осуществлял множество дел:

  • выполнял сборку и запуск модульных тестов после каждого коммита;
  • после коммита в ветку с релизами убивал старый и запускал новый тестовый стенд для команды тестировщиков;
  • генерировал отчёты по исходным кодам (покрытие тесами, показатели соответствия стандартам тестирования);
  • генерировал документацию для wiki.
  • кроме того через его интерфейс можно было отслеживать кто какие коммиты вносил, как со временем менялось покрытие тестами, за какое время осуществлялась сборка и прогон тестов и самое главное — из-за кого был сломан билд.
Подробнее...
 
Тест-кейсы – это не тестирование: движение к культуре производительности тестирования, часть 1
22.01.2018 12:26

Автор: Джеймс Бах (James Bach), Аарон Ходдер (Aaron Hodder)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=30

Перевод: Ольга Алифанова

«Мы ищем начинающего тест-аналитика для написания и выполнения тест-кейсов, чтобы убедиться, что клиенты получают качественный продукт…»

«Обязанности: помогать со сбором требований и разработкой тест-кейсов, удовлетворяющих требованиям»

«Для успешной работы в этой роли необходимо следующее: …Уметь писать ручные тест-кейсы и прогонять их… Подтвержденный опыт создания условий тестирования и сценариев тестирования… Выполнение кейсов и отчетность о результатах».

Из объявлений о найме, опубликованных на seek.co.nz 24 января 2014.

Наша область больна тест-кейсами, как чумой. Создание кейсов поминается в описаниях вакансий так часто, как будто это основная обязанность тестировщика. Тестировщики, обращающиеся к нам за советом, тоже чересчур часто упоминают «мои тест-кейсы» в смысле «моя работа как тестировщика». Этот фокус на тест-кейсах был невинен и образовался с хорошими намерениями, но теперь он отравляет нам жизнь и мы, авторы статьи, убеждены, что это одна из причин нехватки уважения к тестированию. Тест-кейсы сдерживают нас.

Настало время вмешаться в вопрос. В этой статье мы критически исследуем понятие тест-кейса и культуру, зачастую окружающую его. Мы продемонстрируем, почему тестирование невозможно закодировать тест-кейсами, и предложим альтернативную точку зрения, основанную на том, что тестирование – это человеческая деятельность, а не артефакты.

Подробнее...
 
Мастер-класс по заведению дефектов от Ольги Назиной
19.01.2018 12:45

В рамках прошедшей онлайн-конференции для тестировщиков КоТэ было проведено несколько мастер-классов.

Мы публикуем мастер-класс по заведению дефектов от Ольги Назиной, на котором разбирались типичные ошибки оформления багов на реальных примерах.

Ольга Назина - автор многочисленных статей и курсов по тестированию, таких как Школа начинающих тестировщиков, Интенсив для начинающих тестировщиков.

Суть мастер-класса → когда работает аудитория, поэтому участникам было предложено до начала конференции выполнить домашнее задание.

Задание

1. Провести тестирование указанного функционала

2. Оформить найденные баги в гуглодоке
Функционал тестируем конкретный. Так проще (не надо тестировать все) и интереснее — кто больше багов найдет? =) Тестируем:
  1. Поиск товара — https://www.wildberries.ru/ (регистрироваться не надо, исследуем только поиск)
  2. Поиск аптеки — http://papteki.ru/apteki/
  3. Общение на форуме. Создание новых тем не тестируем, только переписка внутри этой. Создать свое сообщение, процитировать чужое итд. Да, тут придется зарегистрироваться =)
  4. Баг-трекер Багзиллу — http://bugzilla.testbase.ru/. Да да, мы тестируем реальный баг-трекер! Заведение дефектов, редактирование, прикладывание аттачей... 
    Зайти в багзиллу можно с данными
    логин — mail.for.testbase@yandex.ru
    пароль — 12345678

Во время конференции Ольга показывала заведенные баги (все анонимно!) и разбирала выявленные ошибки.

Просмотр записи мастер-класса имеет смысл, если Вы так же как участники сначала попробуете выполнить задание, а уже потом будете смотреть видео.

Обсудить в форуме

 
Эксперименты с обеспечением качества в Atlassian
18.01.2018 12:08

Автор: Панна Черукури (Panna Cherukuri)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=27

Перевод: Ольга Алифанова

Я работаю в Atlassian в качестве QA. Мы называем себя инженерами по обеспечению качества. Как QA, мы тесно сотрудничаем с нашей командой разработки, преследуя общую цель – «хорошее качество продукта». QA похожи на тренеров по качеству – мы фокусируемся на обучении и поддержке. Это значит, что обычно мы не тестируем самостоятельно – мы помогаем команде разработки определить, что должны тестировать они. Наша команда также занимается качеством процесса разработки. Хороший процесс должен быть эффективным, надежным, и простым в использовании. Команда QA разработала процессные метрики, которые помогают нам следить за качеством процессов. Мы боремся за постоянное развитие наших процессов, потому что этого требует наша организация. Мы работаем в Agile-окружении, и наша первостепенная задача – предотвратить появление багов. В процесс разработки мы встроили шаги, позволяющие предотвратить появление багов и намного раньше снизить риски.

Подробнее...
 
Аудит на небольшом проекте. Best practices
17.01.2018 00:00

Автор: Айжан Нургалиева, ведущий тестировщик компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/audit-on-a-small-project/

В некотором царстве, в некотором государстве жила маленькая команда тестировщиков. Жила не худо, не богато, выполняла свои обязанности, о завтрашнем дне не думала, прошлого не вспоминала. И вот однажды столкнулась она с неразрешимыми проблемами. Команду тихо засасывало болото релизов, задач и дедлайнов, а горизонт радужных перспектив и светлого будущего постепенно скрывался за горами текучки. Долго она думала, что же делать, пока не прознала, что в соседнем царстве тестировщиков приглашали гостя заморского, он им все проблемы разом и решил. А имя того молодца – «аудит ясно-солнышко». Маленькая команда зазвала молодца к себе и понеслось…

Введение

Так начиналась история нашего аудита на одном из проектов. Команда, как вы поняли, была немногочисленной и состояла всего из трех QA специалистов. Тестирование на проекте начиналось с одного тестировщика, но после увеличения штата команда ощутила острое непонимание вопросов «что происходит» и «куда двигаться дальше». Помог ли аудит? Расскажу в конце.

Подробнее...
 
Мобильные приложения и их тестировщики: all you need to know
16.01.2018 00:00

Автор: Максим Железный, QA инженер, www.linkedin.com/in/maxzheleznyy, twitter.com/MaxZheleznyy

Оригинальная публикация: https://habrahabr.ru/company/tdb/blog/337234/

Меня зовут Максим и я работаю в отделе QA компании Trinity Digital. В сфере обеспечения качества я уже более двух лет, люблю мобильные приложения, их сложность и динамичность. В этой статье я попытался сделать относительно небольшой список инструментов, источников информации и скилов, которые тестировщик мобильных приложений всегда должен иметь при себе.

Если разбить статью на части, то она будет выглядеть так:

  • Источники информации для максимально успешного тестирования
  • Инструменты для упрощения жизни тестировщика
  • Hint’ы
  • Доставка и анализ приложений
  • Куда расти дальше, если постигли дзен

//Алярма — ниже параграф для менеджеров и ценителей статистики

В этой статье я не буду рассказывать что такое iOS и Android, но нельзя не сказать, какую важную роль играют мобильные платформы в нашей жизни. Если обратиться к статистике по продажам PC и смартфонов, то мы можем увидеть, что с каждым годом количество мобилок растет, а вот PC все меньше пользуется спросом. Однако не стоит разводить полемику о смерти какой-либо из платформ. Как отлично было сказано в статье Пола Адамса — каждому бизнесу стоит найти свой идеальный баланс между мобильным и стационарным типом работы с информацией. А пока менеджеры убежали решать вопросы бизнеса, я продолжу.
//Параграф для менеджеров закончился

Подробнее...
 
Все наши тесты всегда должны завершаться успешно
15.01.2018 13:38

Автор: Will Yates

Оригинальная публикация: http://www.test-talk.info/2017/02/all-our-tests-should-always-pass.html

Перевод: Анна Радионова

Такие процессы как Continuous Integration и автоматизация тестирования требуют, чтобы написанные тесты были высокого качества и всегда завершались успешно. Не скажу, что я на 100% с этим согласен. Тесты, которые всегда проходят успешно, могут скрывать недостатки продукта, тем самым снижая его качество.

В любом пайплайне CI новые билды тестируются при помощи набора автоматизированных тестов.  Такие инструменты как Chef или Jenkins хорошо справляются с организацией этих процессов и их управлением. Однако, они используют набор тестов, которые практически гарантированно  будут выполнены. Если используются одни и те же тесты и они всегда выполняются успешно, это - повод задуматься над следующими вопросами:

  1. Выполняют ли тесты именно те проверки, которые вы от них ожидаете? Тестируют ли они код, тестирование которого предполагаете вы? Не может ли быть такого, что они просто исполняют код, а не тестируют его? Остерегайтесь таких тестов, которые тестируют не то, что предполагаете вы.
  2. Не расположены ли тесты и новый код продукта в разных средах? Если ваши тесты направлены на проведение регрессионного тестирования части продукта, которая не связана логически с новым выпускаемым кодом, может оказаться так, что продукт тестируется не полностью.
  3. Опасайтесь “пестицидного парадокса”. Если долгое время используются одни и те же тесты, скорее всего, код “приобрел иммунитет” к тестам. Фрагменты кода, которые проверяются с помощью автотестов, скорее всего, со временем стали настолько хорошо написаны и отрефакторены, что вероятность внесения разработчиком ошибки в них крайне мала.
  4. Тесты устарели. При том, что автотесты выполняют разрабатываемый код, нужно учитывать, что они необязательно выполняют проверки таким же способом, каким будут взаимодействовать с продуктом ваши клиенты.  Возможно, в тестах используется неподдерживаемый способ запуска или методы, которые зарекомендовали себя не лучшим образом.
Подробнее...
 
Конференция SQA Days 23, Минск, 25-26 мая. Скидка для наших читателей
12.01.2018 12:25

25-26 мая 2018 г. в Минске пройдет 23-я международная конференция в области обеспечения качества ПО «Software Quality Assurance Days» - крупнейшая в СНГ международная конференция для специалистов в области качества программного обеспечения.

Целевая аудитория – специалисты по тестированию разных уровней, руководители отделов тестирования, директора по качеству; а также все, кто по роду своей деятельности плотно вовлечен в сферу обеспечения качества ПО. 

Планируемые тематики докладов:

  • Методики и инструменты тестирования ПО;
  • Автоматизация тестирования ПО;
  • Подготовка, обучение и управление командами тестировщиков;
  • Процессы обеспечения качества в компании;
  • Управление тестированием и аутсорсинг;
  • Совершенствование процессов тестирования и инновации.

В настоящее время организаторы конференции активно работают над составлением программы. Предложить доклад на конференцию можно на официальном сайте SQA Days. Для докладчиков участие в конференции бесплатно!

Прием докладов открыт до 04 марта 2018 г.

Как обычно для читателей нашего портала действует промокод на получение 10% скидки.

Зарегистрироваться и приобрести билет заранее по льготной цене можно здесь.

Промокод для получения 10% скидки - s-t.ru

Обсудить в форуме

 
Тестирование требований. Особенности
12.01.2018 00:00

Автор: Александр Филиппов, ведущий тестировщик компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/testing-requirements/

Введение

Требования – это первое, на что смотрит команда проекта, это фундамент для проектирования и разработки продукта. Допущенная в документации ошибка или неточность может проявиться в самый неподходящий момент. Очевидно, что гораздо проще устранить дефект в паре строк требований, чем позже «перелопачивать» несколько сотен (или даже тысяч) строк кода.

Тестирование требований направлено на то, чтобы уже на начальных этапах проектирования системы устранить максимально возможное количество ошибок. В перспективе, это позволяет:
Подробнее...