Home

Оригинальная публикация: http://blog.tentamen.eu/oracle-exercise-on-real-example/

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

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

Дисклеймер: здесь не идёт речи о каком-то новомодном фреймворке для тестирования. Это статья об искусстве тестирования в чистом виде.

Вы еще здесь после прочтения дисклеймера? Отлично!

Оракулы – это принципы или механизмы, благодаря которым мы распознаем проблему.

Тестирование миграции данных – неклассическая задача инженеров по тестированию ПО, но с повсеместным распространением «больших данных» она встречается все чаще.

В данной статье команда A1QA расскажет на примере реального проекта, как подойти к тестированию миграции данных, какие подводные камни могут встретиться на пути, как оптимизировать выполнение проверок и завершить тестирование не просто в срок, а даже раньше.

Итак, начнем.

Миграция данных – перенос данных на новый ресурс/окружение.

Казалось бы, что может быть проще, чем перенести данные из системы А в систему Б? Но на деле часто оказывается, что системы А и Б имеют разную архитектуру и функциональность. Данные различия, в свою очередь, вызывают потерю данных, перенос нерабочих компонентов, нарушение прав доступа.

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

Автор: Надежда Князева

Тип 1. Баги, связанные с устаревшими устройствами и программами

Если вы делаете продукт в 2018 году, нет смысла добавлять специальную верстку для Internet Explorer 6 или подстраиваться под iPhone 4. Конечно, это почти абсурдные примеры, но человек в здравом уме вряд ли будет поддерживать старое устройство или древнюю версию браузера, так как их аудитория уменьшается с каждым днем и однажды просто исчезнет.

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

Оригинальная публикация: http://automationpanda.com/2017/10/14/bdd-101-unit-integration-and-end-to-end-tests/

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

Существует много видов ПО тестов. Практики BDD можно применять в любых аспектах тестирования, но BDD фреймворки используются далеко не во всех типах тестов. Поведенческие сценарии, по сути, являются функциональными тестами - они проверяют, что тестируемый продукт работает корректно. Для тестирования производительности могут использоваться инструменты, в то время как BDD фреймворки не предназначены для этих целей. Задача данной статьи, в основном, состоит в описании роли BDD автоматизации в Пирамиде Тестирования. Прочитайте статью BDD 101: Manual Testing для того, чтобы понимать как BDD применяется при ручном тестировании. (Всю информацию по BDD можно найти на странице  Automation Panda BDD page)

Автор: Джошуа Рейн (Joshua Raine)

Оригинал статьи: http://www.testingcircus.com/assumptions-necessary-or-evil-in-testing/

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

Оспаривая допущения

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

В детстве мое знакомство с допущениями началось с расхожей фразы, которую я до сих пор довольно часто слышу – «Когда ты предполагаешь, ты делаешь осла и из себя, и из меня» (игра слов – when you assume, you make an ass out of U and Me – прим. переводчика). Очевидно негативная коннотация и забавная игра слов заставили эту фразу застрять в голове, но если задуматься, неужели допущения – это так плохо? Исходя из фразы, любое предположение будет по умолчанию плохим и иметь негативные последствия. Это было мое первое и единственное знакомство с термином, на основе которого выстроился внутренне отрицательный взгляд на предположения. Причиной, объясняющей это, всегда было то, что предположения – это упражнения в лени, которые тебя в итоге погубят – лучше спроси, чем додумывай.

Автор: Кудинов Илья, Lead QA Engineer, Badoo Development

Оригинальная публикация: http://habrahabr.ru/company/badoo/blog/345478/

Здравствуйте. Меня зовут Илья Кудинов, мне 27 лет, и я тестировщик.
Все: Здравствуй, Илья!

Мы уже много писали о том, как здорово мы в Badoo тестируем наши продукты. А сегодня я (внезапно!) расскажу о том, как круто тестировать ВООБЩЕ. И когда я встречаю представителей нашей профессии, которые не разделяют эту точку зрения, я всегда стараюсь открыть им глаза на истину. Например, этой самой статьёй.

О чём она будет? Я поделюсь своим личным опытом, расскажу, как развивалась индустрия в течение шести с небольшим лет, что я за ней наблюдаю, и опишу своё видение карьерного пути тестировщика. Устраивайтесь поудобнее, настало время (неразборчиво, зачёркнуто) занимательных историй…

Дисклеймер

Всё, что я напишу в этой статье, основано на моём личном восприятии, опыте и информации, которую я почерпнул на QA-конференциях и митапах. Статья будет интересна начинающим специалистам и тем, кто мечтает работать в IT, но ещё не определился с профессией. И главным образом тем, кто считает, что тестирование — несерьёзная, скучная и рутинная работа.

Оригинальная публикация: http://steveo1967.blogspot.ru/2013/06/tacit-and-explicit-knowledge-and.html

Перевод: Иван Смирнов

"Мы знаем больше , чем можем выразить словами". - Майкл Полани (1966)

Читаю превосходную книгу «Явное и неявное знание” Гарри Колинза. Она оказала значительное влияние на мои представления о том, как мы учимся и записываем информацию (знания). Это непростая книга для чтения. Мне потребовалось несколько раз перечитать некоторые разделы, чтобы понять, что имел в виду автор.

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

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

Явные знания: Знания, которые кодифицируются и передаются другим через диалог, демонстрацию или другие носители информации (книги, рисунки, документы и т.п.).

Неявные знания: Глубоко личный опыт, способности, восприятие, озарения и ноу-хау, которые подразумеваются, но не выражаются — они принадлежат отдельным лицам и командам.

Автор: Алан Ричардсон

Оригинал статьи: http://blog.eviltester.com/2017/11/what-is-agile-testing.html

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

Когда мы работаем над Agile-проектом, нам требуется гигантская гибкость и возможность подгонки того, что мы делаем, под нужную форму.

Я могу сказать, чем Agile-тестирование не является. Существительным.

Поэтому когда мы спрашиваем, что такое Agile-тестирование – это не вещь. Нельзя купить пачку Agile-тестирования… Это глагол, это подход, это процесс.

Это то, как мы тестируем в Agile-проектах.

Это то, что мы делаем, и образ нашего мышления. Характерного для Agile-проекта.

Это кажется тавтологичным, очевидным, но по какой-то причине люди все усложняют, и началось это не вчера, как мы сейчас и выясним.

Оригинальная публикация

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

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

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

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

Ну что ж, начнем…

Оригинальная публикация: http://qablog.practitest.com/leading-by-example/

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

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

На заре времен разработки тестирование считалось незыблемым/неприкосновенным.

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

И хотя цели таких действий сводились к тому, чтобы оставаться беспристрастными сторонниками качества, с течением времени такая тактика приобрела конфронтационный и бюрократический характер.

С появлением и распространением agile методологий убежденные “отщепенцы” стали понемногу замещаться фидбеком и тестированием пользователей.

Тестирование в рамках традиционных больших команд было заменено на закрепление специалиста по тестированию за небольшой командой разработки.