Как искать баги на сайтах
Перейти к содержимому

Как искать баги на сайтах

  • автор:

Где искать баги начинающему тестировщику

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

Но где лучше искать баги?

  1. Первый способ ー старое доброе тестирование карандаша. Ну, или стула, например. В общем, чего угодно абстрактного.

Вот вам задание: попробуйте протестировать стул. Не забывайте о первом шаге: выяснить, для чего этот стул вообще нужен. Может, он для первоклашек? Или для офисной работы? Разные цели ー разное тестирование.

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

  1. Лучше всего проверить себя на настоящих проектах. Это ближе к условиям, в которых вам придется работать.

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

Хотя… может быть, вы найдете баги и там ��

  1. Поэтому следующий способ ー протестировать какой-нибудь популярный ресурс. Можно тестировать и веб-сайты, и мобильные приложения. Что именно лучше проверять в «тренировочных» продуктах, которые уже вышли на рынок? Чаще всего ーфункциональность и юзабилити, но не только.

Опытом делится Полина Жукова, тестировщица Лаборатории Качества:

«Приведу примеры из тестирования мобильных приложений.

  • функциональное тестирование: это обязательно бизнес-функции, например, корзина. В 90% случаев при прохождении регресса там находятся баги. Как критические краши, так и незначительные миноры.
  • тестирование юзабилити: в моем опыте это обычно связано с жестами (свайпы, скроллы, долгие тапы), так как это один из главных способов навигации и просмотра контента в приложении. Также стоит проверить статус-бар на экране (самая верхняя панелька, где отображены время, зарядка, wi-fi и прочее), изменение ориентации экрана.
  • также очень часто находятся баги, связанные с прерыванием приложения. Не всегда такие кейсы учитывают при разработке, и каждый пользователь по-своему работает с приложением в совершенно необычных иногда условиях �� Прерываем всеми возможными способами: звонками, SMS, пушами, сворачиванием приложения, блокированием экрана, при перезапуске, работе в других приложениях, при открытом экране долгое время, отключении интернета».

Роман Буданов, специалист по тестированию:

Все еще не понимаете, с чего начать тестирование? Теория, взятая из разных статей и книг, мешается в голове? Приходите на курс ПОИНТ ー мы расставим по полочкам знания и уделим много времени практике! Наши преподаватели ー действующие тестировщики. С их помощью вы станете уверенным джуниор-тестировщиком за два с половиной месяца!

Узнать о программе курса можно здесь.

Как искать и находить баги? (подія в архіві)

Описание:
Вы уже освоили основные техники тест-дизайна? Отлично! Значит, Вы — квалифицированный тестировщик. Но куда двигаться дальше? Что делать, чтобы стать высококвалифицированным тестировщиком? Как научиться находить баги, которые не находят другие тестировщики, несмотря на то, что они знают те же самые техники? Освоение техник — это лишь первый шаг на пути к мастерству. Как нотная грамота и гаммы для музыканта. Как умение держать ракетку и наносить удары слева и справа для теннисиста. Как знание дебютов и эндшпилей для шахматиста. Разумеется, техники надо знать. Но для осмысленного, а тем более творческого их применения требуется ещё кое-что — нужны дополнительные профессиональные навыки.

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

Почитайте внимательно статьи и учебники про техники тест-дизайна. Они правильные, и они работают. Но в них не хватает чего-то неуловимого. Откуда берутся пропущенные баги, которые тестировщик «не заметил»? Почему не заметил? Техники не виноваты. В них ничего не говорится о том, как надо проверять результат. Просто не хватило наблюдательности.

Почему в продуктив попадают баги, для которых тестировщик «не придумал» подходящего теста? Техники не виноваты. Просто неверно выбрана модель или техника применялась не там и не так.

В описаниях техник уделяется много внимания тому, как анализировать входные данные, как строить комбинации, какие последовательности нужно выполнять. Но там не написано главного — как понять, что вы нашли баг? Как его узнать? Наконец, как понять, правильно или неправильно вы применяете ту или иную технику? Ответы на эти вопросы, игры, упражнения, соревнования, и конечно — реальное тестирование, всё это будет в программе тренинга.

В этом тренинге по согласованию с Майклом Болтоном (автор книги и одноименного тренинга «Rapid Software Testing») используется методика и упражнения из всемирно известного тренинга Rapid Software Testing. Для подготовки к тренингу тренер Алексей Баранцев трижды провел совместные с Майклом тренинги в качестве ассистента и второго тренера.
После него вы вернётесь на своё рабочее место «намагниченным» и «заряженным» на поиск багов. И они это почувствуют, не сомневайтесь!

Специальное предложение: до 1 февраля 2014 г. стоимость курса — 3000 грн, после — 3 500 грн.

Цели:

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

Кроме того, слушатели освоят профессиональную работу с уже обнаруженными багами:
— как правильно описывать баги;
— как следить за судьбой описанного бага;
— как перепроверять якобы исправленные баги;
— как не уставать при регрессионном тестировании и перепроверках.

Помимо пойманных багов надо уметь также работать и с непойманными, поэтому слушатели научиться:
— подсчитывать тестовое покрытие и оценивать полноту тестирования;
— протоколировать результаты работы;
— писать хорошие тестовые отчёты;
— объяснять, почему же мы всё-таки пропустили этот баг.

Разбираемые темы:

День первый
1. Подготовка инфраструктуры, знакомство.
2. Тестирование учебной программы (упражнение и разбор), обсуждение на тему «Что важнее — техники или навыки?».
3. Тестирование новой программы, искусство задавания вопросов (упражнение и разбор).
4. Что делать, когда ты нашел баг? Глобализация и локализация (демонстрация и обсуждение).
5. Искусство описания багов (упражнение и разбор).
6. Регрессионное тестирование и перепроверка багов — как и зачем много раз выполнять одни и те же тесты?
7. Моделирование: умение смотреть на программу под разными углами (упражнение и разбор).
8. Тестирование юзабилити: поселите у себя в голове персонажей (упражнение).
День второй
1. Стратегия тестирования (обсуждение).
2. Сравнение двух программ: какая лучше? (упражнение и обсуждение).
3. HICCUPPSF: эвристики построения оракулов (демонстрация, упражнение и разбор).
4. Построение тестов для сложной функциональности (упражнение и разбор).
5. Тест-кейсы, чеклисты, тестирование методом свободного поиска — в каком соотношении смешивать? (обсуждение).
6. Тестирование методом свободного поиска (упражнение и разбор).
7. Регрессионное тестирование и перепроверка багов — как и зачем много раз выполнять одни и те же тесты? (обсуждение).
8. Автоматизация тестирования (демонстрация и обсуждение).
9. Завершение курса, подведение итогов.

Тренер — Алексей Баранцев.

В области тестирования программного обеспечения Алексей работает с 1994 г. Прошёл путь от рядового тестировщика до руководителя подразделения заказного тестирования, побывав по пути и разработчиком, и аналитиком, и консультантом, и менеджером проектов. Большую часть этого времени проработал в Институте системного программирования РАН, где занимался и аутсорсинговым тестированием, и разработкой новых инструментов тестирования.

Профессиональная деятельность
Оказывает консультационные услуги в области тестирования, читает лекции о тестировании студентам ГУ ВШЭ, проводит тренинги для тестировщиков, участвует в организации профессиональных конференций, обеспечивает поддержание и развитие крупнейшего русскоязычного сайта о тестировании Software-Testing.ru.

Специализация
Алексей специализируется в тестировании функциональности и производительности, а также в тестировании удобства использования и безопасности компьютерных программ.
Считает своей сильной стороной знания и опыт в автоматизации тестирования — понимание потребности в автоматизации, умение выбрать подходящий инструмент, хорошие навыки программирования, умение работать с различными видами интерфейсов: программными (API), сетевыми, пользовательскими (GUI).
Предпочитает пользоваться бесплатными инструментами тестирования, такими как Selenium, AutoIt, JMeter, не навязывая своим клиентам потребность в приобретении дорогостоящих лицензий на использование коммерческих инструментов автоматизации. Но если уже есть лицензия на какой-либо инструмент — готов использовать его.
Кроме того, готов взять на аутсорсинг сложные задачи по тестированию, как самостоятельно, при небольшом объёме работ, так и осуществляя руководство командой с многолетним опытом тестирования.

Стоимость:
до 01.11 — 3000 грн.;
после 01.11 — 3500 грн.

БОНУС.
При регистрации 3 и более человек от одной компании скидка 10 %!

Целевая аудитория:
Тестировщики, тест-дизайнеры, тест-менеджеры.

Как искать баги

Приложение — незнакомый город.
Тестировщик — турист.

Исследуйте ПО так, словно это — незнакомый город

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

Как пользоваться методикой

Выбрать тур из списка ниже.
Изучить его цели.
Поставить таймер на 2 часа (час, полчаса).
Провести исследование системы строго по целям тура. Ни на что не отвлекаясь, только “миссия” тура.
При необходимости повторить.

В каждом туре есть описание автора (низкий поклон Джеймсу за разрешение перевода и публикации) в вольном переводе + собственные примеры. Для примеров взят сайт Дадаты — https://dadata.ru.

Отправляемся в путь!

Туры по деловому центру, Tours of the Business District

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

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

Тур по деловому центру фокусирует внимание на главных частях вашего приложения и показывает сценарии их использования вашими клиентами.

Туры по историческим районам, Tours Through the Historical District

Исторические районы — части города, содержащие старые здания и достопримечательности. В Бостоне они разбросаны по всему городу и соединены только пешеходными тропами. В Кёльне есть «старый город» — одна часть города, которая не тронута современной экспансией.

В ПО исторические районы могут быть также слабо соединены, как в Бостоне или сосредоточены в одном месте, как в Кёльне. Исторические районы в ПО представляют собой:

  • унаследованный код (legacy code);
  • функции, созданные в предыдущих версиях;
  • исправления багов.

Последние особенно важны, потому что баги существа социальные и любят скапливаться в одном месте. Бажные секции в коде надо тестировать особенно тщательно.

Туры по историческим районам проверяют старую функциональность и исправления ошибок.

Туры по развлекательным районам, Tours Through the Entertainment District

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

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

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

Туры по туристическим районам, Tours Through the Tourist District

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

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

Туры по отельным районам, Tours Through the Hotel District

Отель — убежище для туриста. Это место, куда можно сбежать из давки и суеты популярных мест для небольшого отдыха и расслабления.

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

Туры по захудалым районам, Tours Through the Seedy District

Это непривлекательные места, о которых расскажет редкий путеводитель. Они полны мошенников и сомнительных личностей, и лучше обходить их стороной. Тем не менее, они привлекают определенный класс туристов.

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

Туры от других авторов

Тур от моей студентки — для тестирования мобильного ПО

Большое спасибо Джеймсу Уиттакеру за разрешение на перевод и публикацию туров. Туры также опубликованы в блог-посте Ольги Назиной, и добавлены в ее книгу!

Баги в работе интернет-магазина

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

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

Некорректное отображение баннеров

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

Нарушенная верстка

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

Назойливые всплывающие окна

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

Читайте также

От раздражения до эффективности один pop-up: принципы использования всплывающих окон — Блог Хорошоп

Отсутствие автопроверки

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

Неработающая синхронизация остатков

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

Нет обязательных полей оформления заказа

Для оформления заказа интернет-магазину нужно три обязательных поля: имя, номер телефона и адрес доставки клиента. Этой информации будет достаточно, чтобы отправить товар покупателю. Но некоторые магазины забывают добавлять обязательные поля или же делают это частично. В итоге клиент может оформить заказ, например, не указав свое имя.

Сумма заказа не пересчитывается

Когда покупатель добавил товар в корзину и уже начал оформление заказа — он может передумать. Например, убрать одну из позиций в заказе или увеличить количество товара. В ответ на эти действия, сайт должен автоматически пересчитать сумму заказа. Если этого не происходит, то это введет клиента в заблуждение и может возникнуть неприятная ситуация.

Отрицательное количество товара

В некоторых интернет-магазинах можно добавить в корзину и купить отрицательное количество товара. Говорят, что от этого бага в свое время страдал даже Amazon, но это не повод держать его у себя для достижения успеха.

Не работает кнопка «Купить»

Кнопка «Купить» едва ли не самая важная в интернет-магазине и если после ее нажатия ничего не происходит, то это серьезная проблема. Кнопка не должна работать через раз или добавлять товар только после обновления страницы. Товар должен добавляться в корзину с первого раза, а сайт — уведомлять об этом покупателя.

Вывод

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *