Home

Автор: Оливер Эрлевайн (Oliver Erlewein)

Оригинал статьи: http://hellotestworld.com/2016/02/23/every-tester-is-a-performance-tester/

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

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

Больше всего тестировщиков производительности бесит, когда обнаруженные в тестируемом коде проблемы можно было заметить и на глаз (ну ладно, больше всего их бесит, когда функционал не работает, но не суть). Вот где в игру должны вступить вы как их коллега.

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

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

Поздравляем тестировщиц с самым нежным весенним праздником - 8 марта!

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

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

 Нажми на открытку, чтобы скачать версию для печати в .pdf

Автор: Джейк Бартлетт (Jake Bartlett).

Оригинал статьи: http://www.ministryoftesting.com/2016/02/6-questions-to-ask-before-releasing-software/

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

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

Как вы определяете, что вы можете выпускать ваше детище в релиз? Кто скажет "Поехали" и махнет рукой? Что именно нужно обязательно сделать перед релизом?

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

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

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

Чем лучше вы и ваши клиенты готовитесь к релизу, тем счастливее вы станете.

Вот на что стоит обратить внимание, когда релиз не за горами:

8 апреля в Екатеринбурге пройдёт конференция DUMP (Development. Usability. Management. Practice) — самая масштабная конференция для разработчиков на Урале. Третий год подряд, будет секция, посвященная тестированию. Ниже — обзор докладов 2014-го и 2015-го годов.

Секция «Тестирование-2015»

• Эльвира Соболева (СКБ Контур) рассказала, как тестировщику держать руку на пульсе команды и помогать менеджеру разработки решать проблемы на оперативном уровне. И, в общем-то, захватить кусочек власти — стать менеджером итерации.

• Антон Вдовиченко (СКБ Контур) показал, как подарить вторую жизнь документации и сделать пользователей счастливее. Разные подходы к решению проблемы, полезные источники информации, примеры — всё в докладе.

• Максим Захаров (Яндекс) поделился своими переживаниями о скоропостижно покинувших профессию. Многие знают, почему тестировщики уходят на другие должности, а у нас есть ответ на вопрос «как и почему стоит остаться». И при этом не отказывать себе в бутерброде с икрой.

• Алексей Лупан дал советы по работе с требованиями — хорошими и не очень. Четко и по делу.

• Кроме докладов, программные директора секции организовали необычный интерактив с участниками: сначала на вопросы отвечали слушатели, а потом на эти же вопросы отвечал один из известнейших тестировщиков Джеймс Бах (ответы были записаны заранее). Как видится профессиональный рост тестировщика на другом конце света, чему учиться ручному тестировщику и как не устать от профессии — ответы гуру тестирования можно посмотреть или почитать.

Секция «Тестирование-2014»

Автор: Тревор Аткинс (Trevor Atkins)

Оригинал статьи: http://thinktesting.com/articles/mobile-application-testing-all-about-devices/

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

При разработке стратегии тестирования мобильных приложений важно учитывать, что, конечно, устройства - это еще не все, но вам придется учесть ВСЕ устройства!

Суть в том, что протестировать абсолютно все комбинации устройств и операционных систем просто невозможно. И что теперь, не тестировать? Тоже не вариант.

Вот немного визуализации:

§ http://opensignal.com/reports/2015/08/android-fragmentation/

§ https://www.fiksu.com/resources/ios_trackers

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

Нам нужно подходить к ней с умом.

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

Посмотреть выпуск можно по ссылке.

Автор: Джастин Рорман (Justin Rohrman)

Оригинал статьи: http://blog.smartbear.com/automated-testing/managing-testing-workflow/

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

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

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

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

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

Как управлять тестированием и поддерживать работоспособность ваших тестировщиков? Я расскажу о некоторых фишках, сработавших лично для меня.

Автор: Мааике Бринкхоф (Maaike Brinkhof).

Оригинал статьи: http://blog.xebia.com/mapping-biases-to-testing-the-anchoring-effect/

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

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

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

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