Home

Александр Хозя (автор блога Записки мобильного тестировщика) представляет очередную подборку ссылок.

Уголок разработки, тестирования и распространения приложений:

1. Доклад Игоря Бондаренко "Безопасность мобильных приложений. Что тестировать?" c SQA Days 17. OWASP Mobile Security Project, Mobile App Security Testing от uTest

2. CrashMonkey - тулза для monkey/stress тестирования Основана на UIAutoMonkey, в issue есть решение для нескольких проблем ;) Для Android можно сделать все намного удобнее и приятнее гораздо меньшими усилиями

3. Обновился Calabash Android до версии 0.5.10 - починена сборка и подписывание на языках отличных от английского

4. Дайджест интересных материалов для мобильного разработчика #106 (1-7 мая)

Топ 5 статей для меня:

• Разработка игр для умных часов — проблемы и их решение

• Firebase от Google начал оффлайн-работу на iOS и Android

• Apple изменила секцию «Игры» в App Store, увеличив фокус на контент от редакторов

• Заработать на разработке. Рассказ одинокого разработчика игр

• Радар для пальцев изобрели в Google

5. Awesome iOS Классный курируемый список отличных библиотек, фреймворков, туториалов, компонентов, гайдов для iOS. Поделен на категории, например: фреймворки, компоненты, тестирование...

6. Remote позволяет контролировать Ваш iДевайс из XCode в отдельной вьюшке. Есть ограничения, например, не поддерживаются UIAlertView, пикеры выглядят некорректно

7. 6 cоветов по запуску игры на KakaoTalk

Авторы: Джеймс Бах, Майкл Болтон

Оригинал: http://www.satisfice.com/blog/archives/1509

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

Изначально никто не разделял исследовательское тестирование и тестирование по сценариям. Джерри Вейнберг определяет тестирование как исследовательское по своей природе в своей книге "Основы программирования" 1961 года издания, и предостерегает от излишней формализации тестирования. "Конечно, сложно заставить машину проверять, насколько программа соответствует изначальным целям программиста, не скармливая ей достаточное количество информации об этих целях. Если бы предоставление такой информации машине было легким делом, с тем же успехом можно было бы поручать машине сам процесс программирования. Не следует забывать, что сложные логические операции выполняются путем комбинации простых инструкций, выданных компьютеру, а не в результате предположений компьютера о том, чего хотел программист", - пишет Джерри.

Джерри хорошо понимал, чем отличается человеческий труд от машинного. Однако за ним пришли формализаторы и всех запутали. Официально формализация тестирования началась в 1972 году, когда была опубликована книга "Методы тестирования приложений". Книга концентрировалась не на сути, а на форме тестирования – то есть на словах, изображениях, строках кода, файлах, таблицах, диаграммах и прочих точно определенных формах и моделях. Эти формы и модели можно увидеть, прочитать, указать на них, переместить их, сосчитать, хранить, воспроизводить,  и поэтому так прельщает возможность определить их как "тестирование". Но тестирование – это не модели и артефакты. Тестирование - это использование артефактов человеком. Артефакты тестирования без участия людей похожи на суперсовременные клиники без докторов или медицинских сестер: как минимум – практически бесполезны, как максимум – опасны для несведущих, пытающихся их использовать.

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

Джеймс Бах ввязался в этот бой в 1987 году и попытался разложить ситуацию по полочкам. Наблюдая процесс тестирования, он обнаружил, что ad hoc тестирование хорошо работает для поиска багов, а сценарное – нет (Примечание: Мы не пытаемся показать, что обнаружить это было легко и просто. Мы хотим сказать, что неочевидные истины тестирования присутствуют вокруг нас, и их можно осознать, если отложить фольклор о моделях и сценариях и присмотреться к тому, как на самом деле работают люди). Джеймс начал рассказывать о своем опыте и писать о нем. Когда он проработал тест-менеджером несколько лет (в основном тестируя компиляторы и другие инструменты разработки), до него дошла информация, что Кем Кэнер придумал термин "исследовательское тестирование" как антоним сценарного. В своей небольшой статье Кем не дал точного определения и только кратко наметил суть понятия, но он был первым, кто заговорил о создании тестов во время их исполнения.

Так появилось то, что мы называем "Исследовательским тестированием 1.0".

Александр Хозя (автор блога Записки мобильного тестировщика) представляет очередную подборку ссылок.

Уголок разработки, тестирования и распространения приложений:

1. Android-дайджест на DOU.UA #6. Тестирование и контроль качества
2. Обновился Calabash:

• iOS до версии 0.14.3
• Android до версии 0.5.9

Так же обновился Appium до версии 1.4.1

3. Очередной раз напоминаю о Testing Criteria от AQuA. Поможет идеями для новых тестов

• Testing Criteria for Android Apps
• Summary of the Tests within the Testing Criteria for Android Apps
• Testing Criteria for iOS Apps
• Summary of the Tests within the Testing Criteria for iOS Apps

4. Дайджест интересных материалов для мобильного разработчика #105 (25-31 мая)

Топ 5 статей для меня:

• Google I/O 2015: день первый, день второй
• Что дает перевод описания и кейвордов для мобильного приложения. Результаты большого эксперимента
• Нововведения в Cordova 5.0
• Отображение контента iOS-приложений в результатах Поиска Google и другие приятные новости
• Обзор новой системы аналитики от Apple: Конверсия страниц App Store и оценка эффективности ASO

5. Подкаст AppTractor: новости мобильной разработки №37

6. Открылся опрос developer economics для второго квартала А пока - developer economics за первый квартал :)

7. Как эти 5 приложений угодили пользователям с помощью In-App сообщений Ничего сверхкрутого нет, но даже такой чуть более приятный "what's new" скрин меняет восприятие

Обсуждение, организованной Татьяной Писчасовой, о Мире без тестировщиков на конференции CodeFest 2015.

В черном-черном городе.. на черной-черной горе.. в черном-черном офисе.. черные-черные разработчики.. писали черные-черные программы...
И САМИ ИХ ТЕСТИРОВАЛИ!!!!

Каждый тестировщик будучи junior-ом слышал такую страшилку от старших товарищей.

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

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

И как жить тестировщикам, которых "оставили без работы".

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

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

В результате нас ждут проблемы с договорённостями, в команде царит недопонимание. Зато, мы соответствуем своему абстрактному "хорошо" и "правильно"!

Для просветлённых тест-менеджеров, готовых отказаться от таких абстрактных правил, предлагаем вниманию 1-й вводный вебинар нового онлайн-тренинга Натальи Руколь Школа Тест-Менеджеров v 2.0.

На нём мы рассмотрим:

• Кто является внутренним заказчиком (пользователем) тестирования?
• Что от нас хотят?
• Как понять ожидания, когда их не могут сформулировать?
• Как сделать тестирование более полезным и подходящим вашему проекту?

Вебинар будет полезен тест-менеджерам и тестировщикам-оркестрам, самостоятельно определяющим "как будет проводиться тестирование на проекте".

Доклад Дмитрия Химиона, Performance Lab на конференции CodeFest 2015.

Вы — участник проекта, где релиз дополняется 20-ю патчами?
Вы — QA-менеджер и чувствуете, что разработчики «лукавят», говоря что «у них всё работает»?
Вы — тестировщик и думаете, куда бы развиваться и как еще можно повлиять на качество проекта?
Тогда этот доклад будет вам интересен и, возможно, полезен в работе. Я расскажу о работе с проблемой технического долга со стороны команды тестирования, что qa-team может в этой области, и как оно может выглядеть. Рассмотрим связь между ISO, зрелостью процессов, командой тестирования и проявлением технического долга.

После того, как мы опубликовали рассказ о четырёх способах упорядочения тестов, предлагаемых тестовым фреймворком TestNG, в комментариях неоднократно звучал вопрос -- не является ли создание зависимостей между тестами плохой практикой?

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

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

Итак,
Почему зависимости между тестами это плохо?
и
Почему иногда всё-таки можно делать зависимые тестовые методы?

Доклад Сергея Высоцкого (Spotify) на конференции CodeFest 2015.

Тестирование и отладка распределенных систем это ужасно. В первую очередь потому что они сложные. Но во многом еще и потому, что в мире, где существует больше одного компьютера очень часто происходят вещи о которых многие даже не задумываются. Я в свое время был немало удивлен увидев как ряд популярных FOSS (Free and OpenSource software) продуктов реагирует на Network Split. К счастью это все можно сильно упростить немного развив концепции применяемые в других областях тестирования.