Home

Оригинальная публикация: 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 методологий убежденные “отщепенцы” стали понемногу замещаться фидбеком и тестированием пользователей.

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

Автор: Майк Токс (Mike Talks)

Оригинал статьи: http://www.testingcircus.com/four-simple-steps-to-becoming-the-best-tester-you-can-be/

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

Кажется (благодаря рекламной политике Youtube), что каждый раз, когда мне хочется посмотреть клип, я должен насладиться какой-нибудь жуткой рекламой вроде «Привет… сейчас я открою вам секрет, как изменить свою жизнь за пять простых шагов». Я терпеть не могу грубую рекламу «Я выучил магический секрет, как стать миллионером, и поделюсь им с сотней людей на своем семинаре… по 10 000 долларов с человека». Надо признать, в душе я слегка корыстен, и в какой-то момент я подумал «хм, а ведь я могу сделать что-то похожее для тестирования». Проблема в том, что бассейн тестирования и так полон акул, и прибавление в семействе никак не помогает сообществу.

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

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

До второй Международной конференции по тестированию и QA TestCon Moscow 2018, которая пройдет в Москве 18-19 апреля, осталось чуть больше месяца.

С программой предстоящей конференции можно ознакомиться здесь.

А пока мы публикуем видеозапись доклада Анастасии  Асеевой (Альфа-Лаборатория) “Резиновый кластер для динамического selenium grid” с прошедшей конференции.

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

Оригинальная публикация: http://www.developsense.com/blog/2017/11/the-end-of-manual-testing

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

Тестировщики! Когда мы обсуждаем ручное тестирование, мы помогаем “тонуть кораблю”.

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

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

Оригинальная публикация: http://www.networkworld.com/article/2944686/software/are-you-over-testing-your-software.html

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

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

Тестирование релиз-кандидатов отнимает слишком много времени.

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

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

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

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

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

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

Такое заключение сделала компания-лидер отрасли на основании своего нового исследования, спонсором которого является организация, ответственная за поддержание и актуализацию списка действительных доменных имен, International Corporation for Assigned Names and Numbers (ICANN) (Международная организация по распределению номеров и имен). Задача так называемой Координационной группы по вопросам всеобщего признания новых доменов (Universal Acceptance Steering Group), членами которой являются представители огромного числа интернет-компаний (например, Microsoft и GoDaddy), - мотивировать разработчиков ПО и владельцев сервисов производить обновления своих систем в отношении валидации набора символов справа от точки в имени домена или e-mail адреса, т.е. в домене верхнего уровня.

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

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

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

Ветки

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

Вот как выглядит модель тестового покрытия после чтения спецификации и разговора с разработчиком:

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