Home

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

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

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

Почему тестирование нельзя закодировать

Давайте подразумевать под кодированием выявление тест-идей из неявных ментальных моделей, а также явно и точно описанные тест-кейсы. Кодирование означает явное выражение идей в форме какого-либо кода (например, текста или ПО). Культура тест-кейсов настаивает на кодировании тестирования до такой степени, что неохваченными останутся только тривиальные аспекты процесса. Эта культура гласит, что кодирование практично и нужно – более того, необходимо, и что его отсутствие говорит о безответственности. Но это не так. Кодировать тестирование невозможно.

Идея, что тестирование можно закодировать, не поддерживается ни научной, ни инженерной литературой. Несмотря на годы поисков, авторы так и не нашли исследований, подтверждающих, что тестирование должно быть зафиксировано письменно – они даже не нашли подтверждения, что это в принципе возможно сделать. На самом деле верно ровно обратное. См. «Sciences of the Artificial», написанную нобелевским лауреатом Гербертом Саймоном – он глубоко изучает этот вопрос. Саймон демонстрирует, что идеальная рациональность доступна нам только в простейших ситуациях, и изучает природу процесса дизайна как «ограниченно рациональную», требующую эвристических решений. Прочитать стоит и «Introducton to general systems thinking» Джеральда Вайнберга, который показал, что наблюдение и описание систем требует их упрощения, и что алгоритма, позволяющего, как сделать нечто, ничего не потеряв, не существует.

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

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

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

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

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

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

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

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

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

Автор: 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. Тесты устарели. При том, что автотесты выполняют разрабатываемый код, нужно учитывать, что они необязательно выполняют проверки таким же способом, каким будут взаимодействовать с продуктом ваши клиенты.  Возможно, в тестах используется неподдерживаемый способ запуска или методы, которые зарекомендовали себя не лучшим образом.

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

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

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

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

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

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

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

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

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

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

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

Оригинальная публикация: http://quality-lab.ru/user-story-as-one-of-the-features-of-insurance-products-testing/

При написании статьи были использованы материалы Владимира Беленя, подготовленные в рамках внутреннего обучающего семинара проектной команды Лаборатории качества «User story & friends».

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

User story

Для начала определимся, что же такое User story. Пользовательские истории (англ. User Story) – способ описания требований к разрабатываемой системе, сформулированных как одно или несколько предложений на повседневном или деловом языке пользователя. Пользовательские истории – это один из самых быстрых способов документирования требований клиента (цель документирования состоит в том, чтобы оперативно и без затрат реагировать на возникающие изменения).

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

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

Автор: Аарон Ходдер (Aaron Hodder)

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

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

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

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

Автор: Адам Ховард (Adam Howard)

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

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

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

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

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

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

Автор: Алексей Потемкин, QA engineer компании "JetRuby Agency"

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