На главную Software-Testing.Ru - портал специалистов по тестированию и обеспечению качества ПО http://software-testing.ru/component/content/frontpage Mon, 22 Jan 2018 08:10:04 +0000 Joomla! 1.5 - Open Source Content Management ru-ru Мастер-класс по заведению дефектов от Ольги Назиной http://software-testing.ru/library/testing/bug-tracking/2721-bugs http://software-testing.ru/library/testing/bug-tracking/2721-bugs В рамках прошедшей онлайн-конференции для тестировщиков КоТэ было проведено несколько мастер-классов.

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

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

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

Задание

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

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

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

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

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

]]>
barancev@gmail.com (Administrator) frontpage Fri, 19 Jan 2018 08:45:56 +0000
Эксперименты с обеспечением качества в Atlassian http://software-testing.ru/library/around-testing/processes/2720-test-experiment http://software-testing.ru/library/around-testing/processes/2720-test-experiment Автор: Панна Черукури (Panna Cherukuri)

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

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

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

]]>
barancev@gmail.com (Administrator) frontpage Thu, 18 Jan 2018 08:08:41 +0000
Аудит на небольшом проекте. Best practices http://software-testing.ru/library/around-testing/processes/2706-audit-on-a-small-project http://software-testing.ru/library/around-testing/processes/2706-audit-on-a-small-project Автор: Айжан Нургалиева, ведущий тестировщик компании "Лаборатория качества"

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

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

Введение

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

]]>
barancev@gmail.com (Administrator) frontpage Tue, 16 Jan 2018 20:00:00 +0000
Мобильные приложения и их тестировщики: all you need to know http://software-testing.ru/library/testing/mobile-testing/2713-mobile-test http://software-testing.ru/library/testing/mobile-testing/2713-mobile-test Автор: Максим Железный, QA инженер, www.linkedin.com/in/maxzheleznyy, twitter.com/MaxZheleznyy

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

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

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

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

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

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

]]>
barancev@gmail.com (Administrator) frontpage Mon, 15 Jan 2018 20:00:00 +0000
Все наши тесты всегда должны завершаться успешно http://software-testing.ru/library/testing/general-testing/2719-all-our-tests-should-always-pass http://software-testing.ru/library/testing/general-testing/2719-all-our-tests-should-always-pass Автор: 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. Тесты устарели. При том, что автотесты выполняют разрабатываемый код, нужно учитывать, что они необязательно выполняют проверки таким же способом, каким будут взаимодействовать с продуктом ваши клиенты.  Возможно, в тестах используется неподдерживаемый способ запуска или методы, которые зарекомендовали себя не лучшим образом.
]]>
barancev@gmail.com (Administrator) frontpage Mon, 15 Jan 2018 09:38:19 +0000
Конференция SQA Days 23, Минск, 25-26 мая. Скидка для наших читателей http://software-testing.ru/events/2718-sqa-23 http://software-testing.ru/events/2718-sqa-23 25-26 мая 2018 г. в Минске пройдет 23-я международная конференция в области обеспечения качества ПО «Software Quality Assurance Days» - крупнейшая в СНГ международная конференция для специалистов в области качества программного обеспечения.

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

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

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

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

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

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

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

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

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

]]>
barancev@gmail.com (Administrator) frontpage Fri, 12 Jan 2018 08:25:17 +0000
Тестирование требований. Особенности http://software-testing.ru/library/around-testing/requirements/2705-testing-requirements http://software-testing.ru/library/around-testing/requirements/2705-testing-requirements

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

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

Введение

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

Тестирование требований направлено на то, чтобы уже на начальных этапах проектирования системы устранить максимально возможное количество ошибок. В перспективе, это позволяет:
]]> barancev@gmail.com (Administrator) frontpage Thu, 11 Jan 2018 20:00:00 +0000 Видео лучших докладов онлайн-конференции для тестировщиков КоТэ http://software-testing.ru/events/review/2717-kotekonf-best http://software-testing.ru/events/review/2717-kotekonf-best В конце сентября 2017 года прошла первая онлайн-конференция для тестировщиков КоТэ.

В течение трех дней докладчики делились знаниями и опытом в различных сферах тестирования.

А у участников была возможность оценить каждый из докладов и выбрать наиболее понравившиеся.

Мы публикуем лучшие доклады прошедшей конференции.

Наибольшее количество голосов получил доклад Анастасии Смирновой "Как организовать погружение новичков в команду?"- о том, как найти точки соприкосновения между интересами новоприбывших сотрудников и потребностями проекта, и как обеспечить непрерывное развитие команды.

С небольшим отрывом за ним следует доклад Нины Агеевой "Итоговый отчёт по проведённому тестированию", в рамках которого рассматриваются все ключевые аспекты создания качественных финальных отчётов.

И также доклад Александра Филиппова "Экстренное тестирование: Один за всех!", в котором докладчик рассказывает как выстроить наиболее оптимальный процесс тестирования на новом или уже действующем проекте.

]]>
barancev@gmail.com (Administrator) frontpage Wed, 10 Jan 2018 20:00:00 +0000
Опрос по инструментам автоматического функционального тестирования мобильных приложений http://software-testing.ru/library/testing/mobile-testing/2716-mobile-interview http://software-testing.ru/library/testing/mobile-testing/2716-mobile-interview Автор: Арсений Батыров

Готовясь к первому запуску курса “Автоматизированное тестирование Android-приложений”, я задался вопросом: какие инструменты функционального автотестирования для мобильных приложений сейчас наиболее популярны, что стоит выбрать для знакомства новичков с этой темой?

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

Поэтому я разместил простой опрос из трёх пунктов на нескольких крупных сообществах QA в FB, Telegram и Skype. За несколько дней я получил ответы от 36 человек, что уже подходит под критерии большой статистической выборки. Конечно, этот опрос не претендует на звание серьёзного исследования рынка, но помогает понять основные тренды.

]]>
barancev@gmail.com (Administrator) frontpage Wed, 10 Jan 2018 07:30:59 +0000
Размышления об оценке тестирования http://software-testing.ru/library/testing/general-testing/2700-thoughts-around-test-estimation http://software-testing.ru/library/testing/general-testing/2700-thoughts-around-test-estimation Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: https://testerkiwi.blogspot.ru/2013/12/thoughts-around-test-estimation-irony.html

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

Сарказм просьбы оценить время на тестирование не только в том, что он походит на просьбу оценить, сколько времени понадобится на поиск всех-всех-всех пасхальных яиц на Пасху. Зачастую момент, когда тестирование останавливается, просто от нас не зависит.

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

]]>
barancev@gmail.com (Administrator) frontpage Mon, 08 Jan 2018 20:00:00 +0000
Бесконечное путешествие: обучение, тестирование, изучение http://software-testing.ru/library/testing/general-testing/2698-test-travel http://software-testing.ru/library/testing/general-testing/2698-test-travel Автор: Адам Ховард (Adam Howard)

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

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

Вот экзамен для вас как для тестировщика: научите кого-нибудь тестировать за три дня. Эта задача встала передо мной, Катриной Клоки, Аароном Ходдером, Джорджией Чанн в январе 2014 года. Нас попросили трое суток поучаствовать в выпускной программе Assurity, которая дала миру немало тестировщиков.

Ответственность была высока, и все мы волновались. В конце концов, это было первое, что десяток выпускников узнают о тестировании. Некоторые из них изучали программирование, но большинство было новичками не только в тестировании, но и в IT в целом. К счастью, трое суток пролетели как стрела, выпускникам все понравилось, мы много веселились, но самое главное – птенцы нашего гнезда действительно узнали что-то о тестировании. Как мы этого добились?

Мир удивительных открытий

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

]]>
barancev@gmail.com (Administrator) frontpage Thu, 28 Dec 2017 20:00:00 +0000
Новогодняя игра, стандарт баг-репорта, специфика исследовательского тестирования, применение DevTools в автотестах: новогодняя рассылка за конец декабря 2017 года http://software-testing.ru/news/2715-newsletter-december-2 http://software-testing.ru/news/2715-newsletter-december-2 Вышел выпуск рассылки за конец декабря, его содержание доступно по ссылке.

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

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

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

]]>
barancev@gmail.com (Administrator) frontpage Thu, 28 Dec 2017 06:34:14 +0000
Новогодняя игра: создай свое поздравление! http://software-testing.ru/news/2714-happy-new-year http://software-testing.ru/news/2714-happy-new-year Все мы ждем наступления Нового года, чтобы свершилось чудо. Этот обычай родом из детства, когда все загадывали желания под елочкой и писали трогательные письма Деду Морозу.

Сейчас мы уже взрослые, и пишем поздравления, пожелания своим близким, друзьям, коллегам, и сами зачастую становимся этими Дедами Морозами.

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

И чтобы окунуться немного в детство, да еще и повеселиться от души, мы решили сделать поздравление шуточным и немного поиграть.

Как это сделать: НАЖМИТЕ НА ССЫЛКУ, после чего ответьте на вопросы, нажмите кнопку Создай открытку и Вам откроется замечательная открытка с Вашим личным поздравлением!

Ее можно сохранить, поделиться в соц.сетях, обмениваться с друзьями, чтобы вместе улыбнуться над результатом Smile

Мы желаем Вам не только в праздник оставаться чуточку детьми, верить в сказку, верить в себя и свои силы, и пусть Новый год принесет Вам много радостных дней, волшебных мгновений и  новых открытий!

]]>
barancev@gmail.com (Administrator) frontpage Wed, 27 Dec 2017 07:08:04 +0000
Какая разница между тест-аналитиком, системным аналитиком и бизнес-аналитиком http://software-testing.ru/library/testing/general-testing/2704-what-is-the-difference-between-the-analysts http://software-testing.ru/library/testing/general-testing/2704-what-is-the-difference-between-the-analysts
Автор: Виктория Соковикова, аналитик компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/what-is-the-difference-between-the-analysts/

Здравствуйте. Меня зовут Виктория, и я аналитик.

Так я определила название своей профессии своего жизненного призвания пару лет назад, когда попытки отнести себя к тому или иному лагерю специалистов в очередной раз не увенчались успехом. Я работала на позициях аналитика, системного аналитика, руководителя группы разработки требований для массовых продуктов, начальника отдела разработки требований, руководителя продукта. Таких, как я, называют бизнес-аналитиками, системными аналитиками, менеджерами продуктов, проектировщиками, технологами, техническими писателями. Принимая сотрудника на одну из этих позиций, компании далеко не всегда понимают, что именно будет входить в его обязанности, и что будет являться результатом его работы. В итоге мы имеем такое многообразие вакансий, что бывает трудно сразу сообразить, по какому конкретно запросу нужно искать работу или сотрудника своей мечты.

Одного моего знакомого на собеседовании на позицию «Системный аналитик» спрашивали, знаком ли он с VBA и как хорошо пишет макросы. Технические задания он писал лучше :)

Аналитики редко играют одну роль на проекте, и рано или поздно каждый из них задает себе вопрос «Кто я?».
]]> barancev@gmail.com (Administrator) frontpage Mon, 25 Dec 2017 20:00:00 +0000 Тестирование «без» требований: поиск и организация информации http://software-testing.ru/library/around-testing/requirements/2702-no-requirements http://software-testing.ru/library/around-testing/requirements/2702-no-requirements Автор: Дженнифер Харрелл (Jennifer Hurrell)

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

Автор: Ольга Алифанова

Когда-то давно я встретилась с потенциальным клиентом, чтобы обсудить тестирование его проекта. Вскоре после начала нашей встречи он, однако, осознал, что тестировать его проект нельзя, потому что полностью отсутствуют формальные требования. Короче говоря, они ничего не записывали. Он скептично отнесся к моему заявлению, что письменно зафиксированные требования необязательны для тестирования. «Но как же вы будете тестировать без требований? Как вы узнаете, баг это или не баг?» - «Спрошу».

Я пояснила свой ответ, объяснив, что зачастую я открываю для себя требования, не читая документацию по ним. Я, помнится, сказала, что он прав – я вполне могу не понять, баг это или не баг – поэтому я буду задавать кучу вопросов и обсуждать все несостыковки с проектной командой.

По пути домой я размышляла над нашим разговором и тем, как мне, как тестировщику, справиться с ситуацией, когда требования неясны или не записаны формально. Эта статья описывает процесс, который я использовала, чтобы выкопать и организовать информацию, нужную мне для тестирования, вне зависимости от доступности ее источников.

Что же такое «требование», и почему тестировщикам оно необходимо?

]]>
barancev@gmail.com (Administrator) frontpage Sun, 24 Dec 2017 20:00:00 +0000
Kirk + chrome devtools http://software-testing.ru/library/testing/testing-automation/2712-kirk-chrome-devtools http://software-testing.ru/library/testing/testing-automation/2712-kirk-chrome-devtools
chrome dev tool

Автор: Сергей Пирогов

Оригинальная публикация: http://automation-remarks.com/2017/kirk-chrome-devtools/index.html

Привет, друзья-айтишники. Сегодня хочу поделиться с вами очередной порцией полезной информации из мира автоматизации тестирования. Поговорим более детально о возможностях использования Сhrome developer tools во время прогонов автотестов.

Записывать видео мы уже давно научились, а вот использовать такой мощный инструмент, как devtools, пока еще нет.

Developer tools обладает обширным кругом возможностей. Мы с вами используем его каждый день: для поиска элеметов, для того, чтобы посмотреть в network, возможно, даже попытаться замедлить браузер, чтобы посмотреть на поведение вашего сайта.

Использование devtools в тестах было невозможно, пока на одной из конференций не был показан инструмент devtools proxy.

Сам прокси написан на Python, но это не ограничивает нас от использования его в Java проектах.

]]> barancev@gmail.com (Administrator) frontpage Wed, 20 Dec 2017 14:15:46 +0000 Где я? Подсказки для старта проекта http://software-testing.ru/library/around-testing/management/2699-test-project-start http://software-testing.ru/library/around-testing/management/2699-test-project-start Автор: Марк Толфтс (Mark Tolfts)

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

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

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

Начнем с ряда определений, которые я вынес из курса Rapid Software Testing Джеймса Баха и Майкла Болтона:

Миссия тестирования – результаты, которых от вас хотят заказчики. Покройте продукт тестами так, чтобы оценить риски, основанные на требованиях.

Тест-стратегия – набор идей, направляющих тест-дизайн и выполнение. Она описывает, как вы будете покрывать продукт, чтобы оценить его качество.

]]>
barancev@gmail.com (Administrator) frontpage Wed, 20 Dec 2017 20:00:00 +0000
Видеозаписи докладов с Avito Automation meetup http://software-testing.ru/library/testing/testing-automation/2708-avito-automation-meetup-2 http://software-testing.ru/library/testing/testing-automation/2708-avito-automation-meetup-2

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


26 августа прошёл первый Avito Automation meetup. Говорили о проблемах управления тестами, векторах развития систем автоматизации тестирования, эффективности каждого из тестов, инструментах для тестирования iOS-приложений и запуске тестов в Continuous Integration.


В рамках встречи прозвучали доклады:


1. Векторы развития систем автоматизации тестирования. Дмитрий Химион (Avito)

2. Прокачиваем WebDriverAgent, или Как тестировать iOS-приложения после ядерного взрыва. Алексей Махов (Avito)

3. Проблемы управления тестами, или Что мешает создавать дешевые и полезные тесты при наличии искреннего желания это делать. Федор Зволинский (Yandex)

4. Запускаем тесты в Continuous Integration. Сергей Пак (JetBrains)

5. Добиваемся эффективности каждого из 9000+ UI-тестов. Максим Сахаров (Tutu.ru)

]]>
barancev@gmail.com (Administrator) frontpage Wed, 20 Dec 2017 07:39:09 +0000
Особенности организации работы распределенных тестовых команд http://software-testing.ru/library/around-testing/management/2703-features-of-organization-of-distributed-test-commands http://software-testing.ru/library/around-testing/management/2703-features-of-organization-of-distributed-test-commands

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

Оригинальная публикация: http://quality-lab.ru/features-of-organization-of-distributed-test-commands/

Распределенная команда – это возможность найти нужного специалиста без ограничений конкретной территории, а также сэкономить на рабочем месте. Конечно, в такой работе есть немало особенностей. Вот уже четвертый год я управляю распределенными командами. На это накладывается предыдущий опыт классической схемы «одна команда – один офис». За это время мной «собрано немало шишек» и подготовлено немало наработок.

Если вы уже стали руководителем распределенной команды, только задумываетесь над ее созданием или просто хотите узнать о нюансах работы в тесной связке на расстоянии – эта статья для вас. Я постараюсь разобрать вопросы организации работы, осветить распространенные проблемы и стандартные страшилки.
]]> barancev@gmail.com (Administrator) frontpage Tue, 19 Dec 2017 08:07:38 +0000 Исследуя исследовательский подход к тестированию http://software-testing.ru/library/testing/other-testing/2697-exploratory-testing http://software-testing.ru/library/testing/other-testing/2697-exploratory-testing Автор: Виктория Кузнецова (Viktoria Kuznetcova)

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

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

Исследовательское тестирование набирает популярность в последнее время. Это не может не радовать, однако я обнаружила, что люди, говорящие о нем, подразумевают совершенно разные вещи. Иногда эта разница довольно забавна, иногда шокирует и открывает глаза на то, что скрыто. Иногда – к примеру, когда ваш коллега отказывается пробовать что-то новое, утверждая, что «и так занимается исследовательским тестированием», это просто раздражает.

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

]]>
barancev@gmail.com (Administrator) frontpage Mon, 18 Dec 2017 06:53:11 +0000
Притягательная сила тестирования http://software-testing.ru/library/around-testing/job/2696-test-power http://software-testing.ru/library/around-testing/job/2696-test-power Автор: Alan Page

Оригинальная статья: http://angryweasel.com/blog/the-lure-of-testing/

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

Люди много говорят о том, как они оказались в тестировании (мне, например, говорили, что у меня задатки тестировщика, с первого дня моей работы в техсаппорте), но для тех из нас, кто работает в тестировании достаточно долго, не менее важно задуматься о том, почему мы остались работать в сфере тестирования или на других ролях, связанных с контролем качества.

Для большинства, я думаю, причина в том, что им просто нравится это и нет причин что-то менять. Для других же, включая меня, определяющими стали какие-то знаковые события, произошедшие в жизни, которые закрепили нас в этой области.

Я рассказывал эту историю несметное количество раз устно, но не уверен, что писал об этом в блоге, по крайней мере явно, и вот сейчас решил поделиться. В моей практике произошел случай, когда я снова заново влюбился в тестирование. В тот момент я осознал, что всегда буду связан с контролем качества. Вот моя история.

]]>
barancev@gmail.com (Administrator) frontpage Fri, 15 Dec 2017 07:26:59 +0000
Тестирование производительности, специфика юнит-тестов, чек-лист юзабилити и многое другое: самые интересные материалы по тестированию за начало декабря 2017 года http://software-testing.ru/news/2695-newsletter-december http://software-testing.ru/news/2695-newsletter-december Вышел выпуск рассылки за первую половину декабря, его содержание доступно по ссылке.

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

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

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

]]>
barancev@gmail.com (Administrator) frontpage Thu, 14 Dec 2017 07:38:56 +0000
Ты ж тестировщик или как правильно составлять Bug report http://software-testing.ru/library/testing/general-testing/2694-bug-report http://software-testing.ru/library/testing/general-testing/2694-bug-report Автор: Алексей Потемкин, QA engineer компании "JetRuby Agency"

Оригинальная публикация:https://jetruby.com/ru/blog/kak-napisat-bug-report/

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

Каналы поступления багов

Начнем с каналов поступления багов. Мы можем столкнуться с проблемами и получить информацию об их появлении следующим образом:

  • В процессе тестирования — функционального и нефункционального.
  • Обращение клиента (заказчика) с информацией о возникшей проблеме.
  • Баги, выявленные пользователями. Соответствующая информация может быть передана как разработчикам, так и заказчику.
  • Ошибки полученные при помощи систем мониторинга, например Sentry, Errbit, Crashlytics.

Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму. Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.

]]> barancev@gmail.com (Administrator) frontpage Wed, 13 Dec 2017 08:45:40 +0000 Юнит тесты. Первый шаг к качеству http://software-testing.ru/library/testing/general-testing/2693-unit-test http://software-testing.ru/library/testing/general-testing/2693-unit-test

Автор: Фомин Владимир, Инфосеть-С, Senior Javascript Developer

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

Однажды меня попросили рассказать о юнит тестировании в javascript, но прежде чем рассказывать о тестировании в мире front-end, надо было сделать небольшой обзор юнит тестирования как такового. В результате чего на свет и появилась эта статья, в которой я попытался рассказать о самых важных моментах в юнит тестировании.

Несмотря на различные трактовки юнит тестирования, есть несколько вещей которые объединяют этот термин.

Но есть моменты, в определении юнит тестирования, которые до сих являются спорными. В частности, что рассматривается под юнитом (единицей тестирования)? Подход ООП рассматривает класс как юнит, процедурный (или функциональный) подход, рассматривает одну функцию как юнит. Некоторые разработчики берут несколько классов и считают это юнитом, или берут набор методов в качестве юнита. Но на самом деле это ситуационная вещь, команда сама решает, что должно быть единицей тестирования в их системе.

]]>
barancev@gmail.com (Administrator) frontpage Tue, 12 Dec 2017 07:30:54 +0000
Могут ли тест-менеджеры снизить качество продукта, чересчур помогая ему? http://software-testing.ru/library/testing/test-management/2692-managment-help http://software-testing.ru/library/testing/test-management/2692-managment-help Автор: Ким Энджел (Kim Engel)

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

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

Я постоянно помогаю людям. Звучит, будто я хвастаюсь, потому что помощь другим – это хорошее дело, не правда ли? По моему опыту, позитивная помощь при работе с ПО приносит неплохие дивиденды, однако недавно я узнала, что чересчур ответственный тест-менеджер фактически подрывает качество релиза.

Присоединившись к проекту, я беру на себя личную высокую ответственность за выпуск пользователям качественного продукта. Когда я исследую различные риски качества, мне нужно больше знать о процессах разработки и релиза ПО в компании. Когда я разговариваю с другими менеджерами об их роли в релизе продукта, мы часто находим множество важных продуктовых проблем. Две из них я встречала в нескольких компаниях:

  • Автоматизированные юнит-тесты не проверяются неделями или месяцами.
  • Релизы для тестирования и для прода выполняются разными командами.

Это серьезные риски для качества продукта, которые тест-менеджер не может игнорировать. Я работала с выдающимися людьми в индустрии разработки ПО. Их тоже волновали эти риски, но ограничения по времени, ресурсам и бюджетам не позволяли им внедрять решения этих проблем. Каждый раз я соглашалась (и зачастую вызывалась сама) брать эти задачи на себя вместо того, чтобы принять их как данность.

]]>
barancev@gmail.com (Administrator) frontpage Mon, 11 Dec 2017 06:11:57 +0000