Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Любопытство сгубило тестировщика
03.07.2017 09:59

Автор: Стив Кросс (Steven Cross)

Оригинал статьи: https://stevencrossblog.wordpress.com/2016/12/02/curiosity-killed-the-tester/

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

Итак, тестирование! Все мы его любим. Я точно знаю – мои друзья-приятели его обожают. Мы его понимаем, мы постоянно учимся новому, мы пытаемся улучшить свои подходы и методы, читаем книги, ходим на семинары и конференции… и я могу продолжать до бесконечности. Мы стремимся сделать мир лучше.

В наши дни (конечно, это громко сказано и очень зависит от контекста) конкретный набор требований, четко определенный список приемочных критериев и непротиворечивое, полное понимание, как же приложение должно себя вести – это нечто из мира розовых пони.

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

В ушах коллектива нынче набатным колоколом звучит манифест Agile, и личности и взаимодействия между ними находятся в центре внимания. Разговаривайте с людьми. Разговаривайте с собой (попытайтесь только не свихнуться). Встаньте из-за этого вашего залитого кофе стола и поболтайте с коллегой. Спросите его о чем-нибудь. Поработайте над чем-нибудь. Те, кто помнит Боба Хоскинса, помнят его знаменитую фразу "Разговаривать – это хорошо".

Подробнее...
 
Старые сказки на IT-шный лад, или Истории о фантастических «факапах»
30.06.2017 08:35

Автор: Роман Буданов, специалист по тестированию компании "Лаборатория качества"

Оригинальная публикацияhttp://quality-lab.ru/unbelievable-fuckup-stories/

Мальчишки и девчонки!
А также их родители!
Рассказы про «факапы»
Послушать не хотите ли?
 

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

История первая: «Тараканище»

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

Подробнее...
 
Подборка записей выступлений секции тестирования_DUMP 2017
29.06.2017 08:00

Седьмая конференция разработчиков Урала DUMP прошла 14 апреля в Екатеринбурге. Хотим поделиться с вами записями выступлений секции тестирования. Наши коллеги говори об инструментарии, тест-кейсах и специфике работы тестирования в геймдеве, обсуждали тестирование распределенных систем, делились опытом о том, как как превратить рутину в рост, а несколько специалистов открыли тайну, какими были их первые шаги в профессиональной деятельности.

Подробнее...
 
Automation QA — это отдельная команда?
28.06.2017 08:09

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

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

Так работали всегда

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

Компания понимает, что обойтись без страховочной сети нельзя, поэтому создается QA-отдел, который обычно не обеспечивает качество продукта, а лишь контролирует его. С QA-отделом разработчик может спокойно заниматься любимым делом — писать код, ведь ответственность за качество теперь несет выделенный отдел! Происходит классическое “перебрасывание кода через стену” в отдел тестирования:


Нажмите на картинку, чтобы увеличить изображение

Подробнее...
 
Применение искусственного интеллекта в тестировании ПО
27.06.2017 09:26

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

Автор: Артур Пачин

Да, у нас есть опыт применения ИИ

Инженеры Перфоманс Лаб постоянно исследуют возможности применения наиболее эффективных передовых технологий, позволяющих получать более качественные результаты в работе, в том числе искусственный интеллект. У нас имеется опыт использования технологий машинного обучения для системы HelpDesk. Технология применяется для автоматического заполнения различных полей входящих инцидентов. Для успешного предсказания значений в данных полях, искусственный интеллект предварительно обучался на заданной выборке заполненных инцидентов и с помощью алгоритмов машинного обучения строил модель. На основе построенной модели в дальнейшем делались предсказания значений полей.

Что грядет

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

Подробнее...
 
Проблемы тестирования – это результаты тестирования
26.06.2017 09:18

Оригинал статьи: http://www.developsense.com/blog/2011/09/testing-problems-are-test-results/

Автор: Майкл Болтон (Michael Bolton)

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

В курсе Rapid Software Testing я даю студентам такое упражнение: я прошу их перечислить все, что, с их точки зрения, усложняет или замедляет тестирование. Их ответы, как правило, однотипны – я регулярно слышу одни и те же вариации (пример таких ответов можно посмотреть, к примеру, в обсуждении на Stack Exchange). Обычно это примерно следующий перечень:

  • Я единственный тестировщик, и работаю с несколькими разработчиками (или один из тестировщиков, и в нашей команде много разработчиков).
  • Я очень сильно ограничен по времени. Постоянно приходят новые билды, и мы релизимся каждую неделю-две.
  • Продукт(ы), который я тестирую, очень сложен сам по себе.
  • Между модулями продукта (или между разными продуктами) множество взаимозависимостей.
  • Я вижу, что ряд проблем возникает именно из-за этих взаимозависимостей – небольшое изменение в одном модуле может повлечь за собой катастрофу в другом.
  • Я считаю, что для отлова подобных багов нужно прогонять полный регресс для каждого нового билда.
  • Я стараюсь справиться с задачей, используя автотесты, но сложность продукта затрудняет автоматизацию тестирования – "якоря" для автотестов минимальны или отсутствуют, а частые изменения продукта усложняют поддержку автоматизации.
  • На поддержку автотестов уходит приличное время, и я не успеваю заняться тестами, которые хотел бы прогнать.
  • Все это сильно выматывает, но я пытаюсь справляться.
Подробнее...
 
Освоение тестирования SOAP API
23.06.2017 08:29


Оригинальная публикация: http://quality-lab.ru/soap-api-testing/

АвторЮлия Багрий, ведущий специалист по тестированию компании "Лаборатория качества" 

Не так давно в нашем блоге рассказывалось об освоении тестирования через REST API. Я же хочу поделиться опытом тестирования SOAP, «старшего брата» REST.

SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).

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

Подробнее...
 
Как рассчитать время на тестирование, приручить юнит-тесты и тестировать серым ящиком: новости тестирования за июнь 2017
22.06.2017 16:04

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

Как всегда в выпуске рассылки собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Подписаться на рассылку можно по ссылке.

 
Как писать хороший баг-репорт
22.06.2017 08:23

Оригинальная публикацияhttp://bytextest.ru/2017/02/15/bug-report-kak-pisat/#more-4457

Вы когда-нибудь видели под вашим багом комментарий “it is not reproducible”? Чувствовали, как екает сердце от статуса “waive requested”? Иногда команда разработчиков «разворачивает» баг, который вы так трепетно лелеяли и выхаживали. Ну, может не так уж и трепетно, раз его все таки не смогли воспроизвести.

Нажмите на картинку, чтобы увеличить изображение

Представьте ситуацию, когда, например, баг был заведен в Mozilla Firefox. Допустим, на сайте не работает кнопка «login». Так и запишем, попутно забыв указать в STR (шагах воспроизведения) — какой именно браузер и какую его версию мы использовали. А вот разработчик использует, допустим, Edge. И в их среде кнопка работает нормально. Соответственно, баг отклоняют за невозможностью воспроизведения и комментарием: «Может быть, проблема в вас?» Вы, как порядочный тестировщик, перепроверяете ошибку, находите ее и переоткрываете баг. Чем все закончится — непонятно.

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

Подробнее...
 
Debug-панель в тестировании мобильных приложений
21.06.2017 07:26

Видео выступления на конференции DUMP-2017 автора и тренера курса "Тестирование мобильных приложений", Арсения Батырова.

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

Для ускорения этого процесса уже достаточно давно используется debug-консоль, которая позволяет быстро сформировать нужное состояние приложения и заниматься тестированием сразу. В своём докладе я расскажу об опыте использования таких панелей на популярных ОС: Android, iOS и Windows Phone, а также на паре непопулярных. Мы рассмотрим варианты решений для клиента и сервера, как защитить этот режим от попадания в руки пользователя и как убедить разработчиков в его необходимости. Ну, и пара фейлов, конечно же, куда без них.

Подробнее...
 
Андрей Сатарин, Яндекс: "Самая главная ошибка — непонимание системы"
20.06.2017 09:38

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

Текст предоставлен JUG.RU Group – организаторами конференции по тестированию Гейзенбаг. Ближайшая конференция Гейзенбаг 2017 Moscow состоится в декабре в Москве. Подробности: https://heisenbug-moscow.ru/

При тестировании распределенных систем нефункциональные требования выходят на первое место, а для обнаружения сложных дефектов приходится применять специальные методы. Мы уже говорили о них с Андреем Сатариным в предыдущем интервью и сегодня попытаемся развить эту тему.

Андрей Сатарин занимается тестированием распределенных систем в Яндексе. Принимал участие в совершенно разных проектах: тестировал игру в Mail.ru, систему облачного детектирования в Лаборатории Касперского, а также систему расчета валютных цен в Deutsche Bank.

— Отказоустойчивость — одно из важнейших нефункциональных требований к распределенным системам. Как проводится тестирование отказоустойчивости? 

Андрей Сатарин:
Сбои можно эмулировать в тестовой среде, так работает известный инструмент Jepsen, созданный Кайлом Кингсбери (Kyle Kingsbury). Второй подход предполагает внедрение сбоев в продуктивном окружении и обычно ассоциируется с Chaos Monkey компании Netflix, из которого выросло целое движение — хаос-инжиниринг. Он избавляет нас от проблем с повторением продуктовой среды и дает высокую уверенность в работоспособности системы, но более опасен и требует определенной зрелости продукта. 

Есть и третий подход, позволяющий проверить работоспособность алгоритмов еще до написания кода с помощью специальных инструментов, таких, например, как TLA+. Два наиболее известных примера его использования: разработка Amazon Web Services и Azure Cosmos DB.

Подробнее...