30.06.2017 08:35 |
Автор: Роман Буданов, специалист по тестированию компании "Лаборатория качества"
Оригинальная публикация: http://quality-lab.ru/unbelievable-fuckup-stories/ Мальчишки и девчонки! А также их родители! Рассказы про «факапы» Послушать не хотите ли?
Идеальных людей не существует – следовательно, все мы рано или поздно допускаем ошибки. От ошибок не застрахован никто, но это еще не значит, что нужно опустить руки и отдаться на волю случая. Наша задача – научиться сводить к минимуму число решений, приводящих к печальным последствиям (о способах борьбы с «факапами» можно прочитать здесь). Самый же распространенный метод обучения основан на исследовании своих и чужих ошибок, поэтому сейчас я расскажу вам несколько историй «о том, как делать не надо».
История первая: «Тараканище»
Когда-то я работал в небольшом филиале крупной компании, выпускающей игрушки для мобильных устройств. К сожалению, тестирование в фирме было налажено, мягко говоря, не лучшим образом. Команда тестирования на тот момент состояла из 4 джуниоров (мой стаж, например, не превышал полугода). Тестовой документации у нас не было от слова совсем, не считая общего списка функциональностей, а про тестовое покрытие и методики тестирования в компании просто не слышали. Да, с тестированием в той компании все было очень и очень грустно. |
Подробнее...
|
29.06.2017 08:00 |
Седьмая конференция разработчиков Урала DUMP прошла 14 апреля в Екатеринбурге. Хотим поделиться с вами записями выступлений секции тестирования. Наши коллеги говори об инструментарии, тест-кейсах и специфике работы тестирования в геймдеве, обсуждали тестирование распределенных систем, делились опытом о том, как как превратить рутину в рост, а несколько специалистов открыли тайну, какими были их первые шаги в профессиональной деятельности. |
Подробнее...
|
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). Обычно это примерно следующий перечень:
- Я единственный тестировщик, и работаю с несколькими разработчиками (или один из тестировщиков, и в нашей команде много разработчиков).
- Я очень сильно ограничен по времени. Постоянно приходят новые билды, и мы релизимся каждую неделю-две.
- Продукт(ы), который я тестирую, очень сложен сам по себе.
- Между модулями продукта (или между разными продуктами) множество взаимозависимостей.
- Я вижу, что ряд проблем возникает именно из-за этих взаимозависимостей – небольшое изменение в одном модуле может повлечь за собой катастрофу в другом.
- Я считаю, что для отлова подобных багов нужно прогонять полный регресс для каждого нового билда.
- Я стараюсь справиться с задачей, используя автотесты, но сложность продукта затрудняет автоматизацию тестирования – "якоря" для автотестов минимальны или отсутствуют, а частые изменения продукта усложняют поддержку автоматизации.
- На поддержку автотестов уходит приличное время, и я не успеваю заняться тестами, которые хотел бы прогнать.
- Все это сильно выматывает, но я пытаюсь справляться.
|
Подробнее...
|
23.06.2017 08:29 |

Оригинальная публикация Автор: Юлия Багрий, ведущий специалист по тестированию компании "Лаборатория качества" Не так давно в нашем блоге рассказывалось об освоении тестирования через REST API. Я же хочу поделиться опытом тестирования SOAP, «старшего брата» REST.
SOAP (Simple Object Access Protocol) является стандартизированным протоколом передачи сообщений между клиентом и сервером. Обычно он используется совместно с HTTP(S), но может работать и с другими протоколами прикладного уровня (например, SMTP и FTP).
Тестирование SOAP с точки зрения техник тестирования ничем принципиально не отличается от работы с другими API, но для его проведения требуются предварительная подготовка (в плане теории протокола) и специальные инструменты для тестирования. В данной статье я хотела бы сформулировать небольшой чек-лист необходимых знаний и навыков, который будет одинаково полезен как тестировщику SOAP (зачастую не представляющему, «за что хвататься» после постановки задачи), так и менеджеру, вынужденному оценивать знания тестировщиков и разрабатывать планы по обучению. |
Подробнее...
|
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. И в их среде кнопка работает нормально. Соответственно, баг отклоняют за невозможностью воспроизведения и комментарием: «Может быть, проблема в вас?» Вы, как порядочный тестировщик, перепроверяете ошибку, находите ее и переоткрываете баг. Чем все закончится — непонятно.
Естественно, проблема в том, что вы забыли упомянуть используемый браузер. Именно с такими последствиями тестировщик сталкивается каждый раз, когда забывает указать ключевую информацию о проблеме. |
Подробнее...
|
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. |
Подробнее...
|
19.06.2017 09:55 |
Автор: Барт Ванхерк (Bart Vanherck).
Оригинал статьи: http://www.bartvanherck.be/2017/01/12/testers-can-learn-from-the-hunger-games/
Перевод: Ольга Алифанова
Недавно я прочитал первую часть трилогии "Голодных игр" Сьюзан Коллинз. Книга, если задуматься, крайне интересная. Что можем мы, как тестировщики, вынести из Голодных игр?
1. Исследуй свое окружение
Когда Китнисс, главная героиня книги, входит в виртуальный мир, она понятия не имеет, что он из себя представляет. Каждый год игры проводятся в новом виртуальном пространстве. Что это значит для нее? Ей нужно познакомиться с этим пространством. Где находится вода, где можно найти еду, и так далее. Как она это делает? Исследуя мир вокруг себя.
В мире тестировщиков все аналогично. Каждый новый продукт или даже новый билд содержит какие-то нововведения. Тестировщику нужно исследовать этот новый билд. Как это работает? Какие ошибки тут можно допустить? Если я сделаю вот так, что случится дальше?
Как и Китнисс, тестировщик должен помнить, как система себя вела в определенных ситуациях. Иногда кнопки могут появляться и исчезать в зависимости от состояния приложения. Ищите эти состояния, ищите мелкие изменения, которые могут и не произойти. |
Подробнее...
|
|
|