ПРИВАТНЕ АКЦІОНЕРНЕ ТОВАРИСТВО
ВИЩИЙ НАВЧАЛЬНИЙ ЗАКЛАД
"МІЖРЕГІОНАЛЬНА АКАДЕМІЯ УПРАВЛІННЯ ПЕРСОНАЛОМ"
ФАКУЛЬТЕТ КМОП’ЮТЕРНО-НФОРМАЦІЙНИХ ТЕХНОЛОГІЙ
ЗВІТ
Про виконання програми переддипломної практики
Васильєв Богдан
Шифр групи: Т27-10-16-БЗПП(2,6з)
Спеціальність "Програмна інженерія"
Кваліфікаційний рівень "Бакалавр"
База практики "МАУП ІКІТ Кафедра КІСТ"
Міжрегіональна академія управління персоналом
Факультет комп'ютерно-інформаційних технологій
| Керівник практики від бази практики | Керівник практики від навчального закладу |
| _______________________ | ______________________ |
| | доцент, к.т.н. |
| | Дуднік А.С. |
Звіт захищений
" " вересня 2019 року
_______________________
(підпис)
К и ї в - 2019 р.
РЕФЕРАТ
Об’єкт розробки – стратегія розробки та тестування сайту за методиками Scrum та Agile.
Мета дипломного проекту – розробка сайту інтернет-магазину комп'ютерної техніки з метою його тестування методами Scrum та Agile.
В процесі роботи, було розроблена стратегія розробки та тестування сайту за методиками Scrum та Agile . В результаті чого виявилося, що методологія Scrum є більш ефективною та економить більше часу розробника.
Результати роботи можуть бути використані при розробці програмних засобів призначених для тестування веб-сайтів.
Розробка та дослідження проводилися під управлінням ОС Windows 7. Розробка програми проводилася у середовищі Borland C++ Builder 6.0, на мові програмування C++ ,MySQL, PHP, HTML.
ABSTRACT
Explanatory note to the diploma project "Means testing web sites based on the methodology Scrum»: 82 p., 40 fig., 12 information sources.
MEANS TESTING WEB SITES BASED ON THE METHODOLOGY SCRUM.
The property development - strategy development and testing site Scrum and Agile methodologies.
The aim of the degree project - development of the site online store computer equipment for its testing methods Scrum and Agile.
In the process, was developed strategy development and testing site Scrum and Agile methodologies. As a result, it was found that Scrum methodology is more efficient and saves more time developer.
The results can be used to develop software intended for testing websites.
Research and development were conducted running Windows 7. Development of the program was carried out in the environment Borland C ++ Builder 6.0, the programming language C ++, MySQL, PHP, HTML.
Зміст
ПЕРЕЛІК ПРИЙНЯТИХ СКОРОЧЕНЬ 5
Вступ 6
Розділ 1. 8
Аналіз основних параметрів при тестуванні веб-сайтів 8
1.1 Загальні параметри тестування веб-сайтів 8
1.2 Аналіз індивідуальних параметрів при тестуванні сайтів інтернет-магазинів 16
Висновок 20
ПЕРЕЛІК ПРИЙНЯТИХ СКОРОЧЕНЬ
ER – модель Сутність-Зв’язок;
БД – база даних;
ІЗ – інформаційне забезпечення;
ОС – операційна система;
ПЗ – програмне забезпечення;
СУБД – система управління базами даних.
Вступ
Інтернет-магазин — веб-сайт, що рекламує товар чи послугу, приймає замовлення на покупку, пропонує користувачу вибір варіанта розрахунку, способу отримання замовлення та виписує рахунок на оплату.
Вибравши необхідні товари або послуги, користувач має змогу на сайті вибрати метод оплати та доставки. Сукупність відібраних товарів, спосіб оплати та доставки представляє собою кінцеве замовлення, що оформляється на сайті шляхом повідомлення мінімально необхідної інформації про користувача (покупця). Інформація про покупця може зберігатися в базі даних магазина, якщо бізнес – модель магазина розрахована на повторні покупки або відправлятися разово. Згідно даних опитування порталу mail.ru необхідність реєстрації при замовленні товару або послуги часто заважає користувачам здійснювати покупки в інтернет – магазині.
В інтернет – магазинах , що розраховані на повторні покупки, також ведеться стеження за поверненнями покупця і історія покупок. Стеження ведеться за допомогою методів веб – аналітики. Також часто надається можливість при оформленні замовлення надається можливість повідомити деякі додаткові побажання від покупця продавцю.
Інтернет – магазини створюються із застосуванням схем систем управління контентом сайту, які оснащені необхідними модулями. Відомі інтернет – магазини працюють на спеціально розроблених або адаптованих для них систем управління. Середні та малі магазини використовують типове комерційне або вільне програмне забезпечення.
Система управління контентом сайту інтернет – магазину може бути коробочним продуктом, що самостійно встановлюється на хостинг – площадку, може бути приватною розробкою веб – студії, що нею і обслуговується або може бути програмним сервісом з абонентською платою.
Потреби адміністраторів інтернет – магазину в складському, торговому, бухгалтерському та податковому обліку забезпечуються невидимою для користувачів частиною інтернет – магазину – бек-офісом. Економічно ефективною практикою створення інтернет – магазину є застосування спеціалізованих систем обліку.
Після відправки замовлення з покупцем зв’язується продавець та уточнює місце і час, коли потрібно доставити замовлення. Доставка реалізується або власною кур’єрською службою, компанією, що надає послуги доставки, по почті – посилкою або бандероллю.
Електронні товари, такі як програмне забезпечення або ключі до них, тексти, статті, фотографії, коди доступу або поповнення можуть передаватися електронними каналами – електронною поштою, доступом по FTP, доступом в захищену частину сайта. Але в цьому випадку слід бути обережним, так як довести неотримання товару електронним шляхом значно важче, ніж у випадку фізичної доставки.
Сучасні інтернет – магазини часто завантажують свої товарні пропозиції в системи порівняння та підбору товарів, що дозволяє заохотити додатковий потік покупців.
Враховуючи актуальність даного напрямку, в якості теми для курсового проекту була прийнята тема «Інтернет – магазин» та мова програмування PHP, в якості базової для реалізації.
Розділ 1.
Аналіз основних параметрів при тестуванні веб-сайтів
1.1 Загальні параметри тестування веб-сайтів
Так як сьогодні веб-сайти мають важливе значення для будь-якого бізнесу, питання правильного тестування сайтів заслуговує все більшої уваги з боку компаній-якого розміру і профілю. Тестування сайтів допомагає розробнику виявити слабкі місця проекту, і побачити, чи може робота сайту (а, отже, і враження користувача) бути поліпшена.
Загалом, є два основних аспекти роботи сайту. По-перше, це функціональність (включаючи інтерфейс, за допомогою якого користувачі отримують доступ до контенту і сервісів). По-друге, це доступність (включаючи доступ до сайту і швидкість завантаження сторінок). У більшості випадків, ці аспекти взаємозалежні: деякі операції, наприклад, покупка через Інтернет-аукціон, сильно залежить від часу завантаження сайту, в той час як час завантаження сайту безпосередньо залежить від відвідувачів, які використовують різні функції і створюють навантаження на сервер.
Багато розробники не мають достатнього терпіння, не можуть дочекатися того моменту, коли їх дітище почне працювати, і тому занадто поспішно починають запускати віддані сайти відразу після того, як буде створено базовий каркас. Часто трапляється так, що поспішність і брак попереднього тестування сайти призводить до непідготовленості, веб-сайт не витримує трафік, і це може бути причиною дуже важких наслідків. Тут все залежить від першого враження, виробленого сайтом на користувачів - у сайту буде поганий рейтинг, якщо він не почне завантажуватися в перші кілька секунд. Ще гірше, якщо сайт не почне завантажуватися взагалі. Хоча тест на функціональність можна проводити вручну вже на початкових стадіях розробки сайту, тестування доступу вимагає від розробників виконання більш складних дій. В основі тестування лежить проста ідея перевірки сайту і його різних параметрів в різних умовах навантаження на сервер. Щоб провести тестування доступу, необхідно мати тисячі відвідувачів, що використовують різні браузери для огляду Інтернету, які проводять огляд з різною швидкістю Інтернету і знаходяться в різних країнах. Безсумнівно, проведення цього тестування вручну зажадає занадто великої кількості ресурсів, тому краще проводити тестування автоматично.
Існує безліч різних віддалених служб, які зроблять це для вас. Однак, як вже було сказано вище, дві сторони тестування сайту не можуть бути розділені. Щоб переконатися в тому, що результати правильні і точні, вам потрібно розробити власні сценарії тестування веб-сайту і виправляти їх по ходу дії. Сценарії тестування сайтів повинні включати всі дії, які тільки можна виконати, тому що використання різних функцій призводить до відкриття нових сторінок, що впливає на серверну навантаження і роботу сайту, в цілому.
Деякі з сьогоднішніх утиліт тестування сайтів, наприклад, Testing Master від Novosoft, мають інструменти запису поведінки, які дозволяють записувати поведінку користувачів під час відвідування сайту. Ця особливість несе в собі безліч переваг - у більшості випадків, процес тестування може бути проведений однією людиною! Запис поведінки - це найбільш швидкий і ефективний спосіб для створення сценаріїв тестування сайту. Більше того, розробник може виконувати цю операцію, одночасно тестуючи особливості сайту. Після цього потрібно буде визначити кількість користувачів, які будуть діяти у відповідність з цим сценарієм і запустити програму. Програма буде симулювати справжніх відвідувачів сайту і збере статистичні дані, дотримуючись певних правил.
Програми для тестування сайтів можуть мати різний інтерфейс і особливості. Але основний принцип їхньої роботи залишиться тим самим: вони створюють велике навантаження на додатки сервера і, таким чином, виявляють всі слабкі місця сайту. Завдяки цьому, розробник знає, над чим ще потрібно попрацювати. Крім тестування поточних параметрів, деякі утиліти дозволяють передбачати майбутню роботу, період, коли сайт стане популярним і зможе привернути більшу кількість відвідувачів.
Тестування сайтів призначено для того, щоб зробити процес відвідування сайтів приємніше - отже, тестування має велике значення. Воно являє собою поєднання людського управління і можливостей комп'ютера. Тестування дозволить вам створити якісний і оптимізований сайт, який обов'язково стане популярним і визнаним веб-ресурсом.
У процесі створення сайту, на етапі розробки, дуже важливо перевірити працездатність сайту перед його розміщенням на хостингу. Для перевірки працездатності сайту проводиться спеціальне тестування. Що ж включає тестування сайту?
Під час тестування сайт перевіряється на відповідність технічному завданню, перевіряються його технічні характеристики. Залежно від вихідного технічного завдання в процесі тестування можуть здійснюватися такі перевірки:
перегляд сайту на різних моніторах. Перегляд сайту на моніторах різних розмірів і при різному дозволі дозволяє оцінити як буде виглядати дизайн сайту на комп'ютерах потенційних відвідувачів: чи з'являється горизонтальна смуга прокручування на маленьких екранах, чи не зміщаються елементи при різному дозволі й т.д.
перегляд сайту в різних бразузерах. Перегляд сайту в різних інтернет-браузерах і їхніх версіях, дозволяє перевірити кросбраузерність сайту;
перевірка часу завантаження сайту на різній швидкості інтернет-підключення. Як швидко завантажуються сторінки сайту на мінімальній і на максимальній швидкості підключення;
перевірка працездатності гіперпосилань на сайті. Є чи на сайті «биті» посилання або посилання, що ведуть не на ті сторінки. Після виявлення таких посилань їх необхідно усунути або виправити;
перевірка коректного відображення кольорів на сайті при різних настроюваннях колірної палітри монітора. Дозволяє довідатися, як будуть відображені кольори сайту на моніторах потенційних відвідувачів;
перевірка відображення шрифтів, анімації й графічних зображень. Дозволяє знайти й усунути можливі проблеми із правильним відображенням зображень, анімаційних роликів і шрифтів на сайті;
перевірка властивостей кожної сторінки сайту: заголовків, ключових слів, описи або інших мета-тегів;
перевірка змісту кожної сторінки на відповідність вихідним матеріалам замовника й перевірка правопису на кожній сторінці.
Крім того, сайт важливо протестувати на сервері. Для цього сайт завантажується на сервер, де він багаторазово перевіряється за вищеописаними критеріями.
Для проведення різних перевірок при тестуванні сайту існує безліч спеціальних програмних інструментів. Наприклад, HTML-валідатори перевіряють html-код сторінок сайту на відповідність стандартам мови HTML. А аналізатори непрацездатних (битих) посилань і зображень, наприклад, Semonitor, дозволяють автоматизувати процес перевірки сайту на працездатність гіперпосилань і коректне відображення картинок, фотографій і т.д.
Тестування доступності Web є підмножиною тестування юзабіліті, коли користувачі, що розглядаються, мають функціональні обмеження, які впливають на те, як вони використовують Web. Кінцева мета як юзабіліті, так і доступності, полягає у виявленні, наскільки легко люди можуть використовувати Web-сайт, і використанні цієї інформації для поліпшення майбутніх конструктивних рішень та реалізацій.
Зазвичай, оцінка доступності більш формалізована, ніж тестування юзабіліті. Закони та громадська думка несхвально ставляться до дискримінації людей із функціональними обмеженнями. Щоб бути справедливим по відношенню до всіх, уряд та інші організації намагаються дотримуватися різних стандартів доступності Web, таких як законодавство Section 508 федерального уряду США та Рекомендації по доступності контенту Web (WCAG) консорціуму W3C.
Однак, важливо розрізняти підпорядкування стандарту і максимізацію доступності Web-сайту. В ідеалі вони повинні співпадати, але будь-який даний стандарт може не працювати, тому що:
Розглядає потреби людей з усіма недоліками.
Намагається вирівняти потреби людей з різними вадами.
Підганяє ці потреби під оптимальні методи.
Використовує обмежену мову для вираження потреб або методів.
Перш ніж починати оцінку проекту щодо доступності, необхідно визначити, які ключові вимоги існують для цього проекту, з урахуванням його робочого середовища, передбачуваної аудиторії і ресурсів. Деякі вимоги будуть задаватися незалежними сторонами, такими як уряд і клієнти, деякі ви зможете вибрати самостійно.
Важливо отримати як можна більш чітке уявлення про зовнішні вимоги. Деякі стандарти доступності мають більше одного можливого рівня або типу відповідності, тому особливо важливо визначити, що потрібно. Наприклад, WCAG 1.0 має три рівні відповідності:
Люди з деякими фізичними вадами “не зможуть отримати доступ до інформації” в документі, який не пройшов рівень “A”.
Люди з деякими фізичними вадами “будуть відчувати труднощі при доступі до інформації” в документі, який не пройшов рівень “Double-A”.
Люди з деякими фізичними вадами “будуть відчувати іноді труднощі при доступі до інформації” в документі, який не пройшов рівень “Triple-A”.
Чорновий варіант WCAG 2.0 також має три рівні, але можливості відповідності більш складні. Коли ресурс є частиною послідовності ресурсів, що представляють процес (наприклад, пошук продукту, вибір, підрахунок вартості і підтвердження покупки для онлайнового магазину), то рівень відповідності для всіх ресурсів у послідовності визначається ресурсом з самим слабким рівнем.
Вимоги відповідності повинні грунтуватися на технології, яка “підтримує доступність” контенту. Така технологія має:
Продемонструвати свою роботу з допоміжною технологією користувачів.
Мати агентів користувачів (браузери, модулі, тощо), які працюють з допоміжною технологією користувачів і будуть доступні користувачам з фізичними вадами не дорожче ніж для користувачів без недоліків.
Відзначимо, що в мережі інтернет можна гарантувати, що такі агенти користувача будуть доступні користувачам, в той же час це неможливо гарантувати в Web. Наприклад, додаток може використовуватися без будь-якої комерційної технології, але бути доступним для зчитувачів екрану з комерційним модулем,що підключається, для якого організація має ліцензію. Ця програма могла б відповідати WCAG 2.0 при розгортанні в інтернет організації, але не відповідати при розгортанні в публічній Web.
WCAG 2.0 допускає також більш обмежені заяви про відповідність. Недоступний ресурс може інформувати, якщо надається доступна альтернатива. Видавці можуть робити заяву про часткову відповідність, коли контент формується з інших джерел.
Розглянемо особливу важливість створення доступного інтерфейсу користувача Web-сайту. Навіть якщо контент недоступний у відповідній формі, доступний інтерфейс користувача може допомогти користувачам ідентифікувати контент, що цікавить, і знайти зовнішню допомогу для перетворення його в ту форму, яку вони можуть використовувати.
Наприклад, людина, яка погано чує, може бути спрямована на відеозапис розмови на сайті відео без субтитрів. Так як URL унікальним чином визначає це відео, і так як він може, тим не менш, використовувати плеєр для перегляду відео, то він може відправити її третій стороні, такій як безкоштовна служба Project readOn, для створення субтитрів.
Якщо потрібно вибрати стандарт доступності, щоб управляти проблемами доступності Web в команді чи просто для деяких орієнтирів під час тестування, я порадив би використовувати проект стандарту WCAG 2.0, так як він:
Створений на основі базових потреб людини, що застосовно до технологій відмінним від HTML і CSS (таким як Flash).
Ретельно документовано обгрунтування кожного критерію відповідності.
Запропоновані практичні методи для задоволення критеріїв відповідності з допомогою поточних технологій.
Гарантує, що кожне положення особи тестуємо.
Містить більш сучасні дослідження, ніж наявні в даний час альтернативи.
Створений для широкої сумісності з існуючими стандартами доступності.
Буде міжнародним стандартом.
WCAG 2.0 допускає також більш обмежені заяви про відповідність. Недоступний ресурс може інформувати, якщо надається доступна альтернатива. Ви можете посилатися на відповідність специфічному чорновому варіанті WCAG 2.0, а проте для цілей маркетингу краще також знайти крім чорнового варіанту відповідність з готовим стандартом, таким як Section 508 і WCAG 1.0.
Існує чотири компоненти для експертного тестування:
Інструментальна оцінка: коли інструментальний засіб шукає проблеми сумісності та надає їх оцінювачу (це включає засоби перевірки доступності та інструменти перевірки коду).
Скринінг: коли експерт моделює роботу кінцевого користувача з Web-сайтом. Часто не потрібно занадто поглибленого розгляду, щоб виявити проблеми доступності. Ви можете тільки завантажити сторінку в свій браузер і помітити, що текст дуже важко прочитати.
Інструментальна інспекція: коли оцінювач використовує інструмент для дослідження того, як різні частини Web-сайту працюють разом.
Огляд коду: коли оцінювач переглядає код та активи Web-сайту, щоб виключити можливі проблеми.
У той час як початківці оцінювачі можуть бути особливо залежними від інструментальної оцінки, оцінювачі будь-якого рівня підготовки можуть отримати користь від кожного компонента. Навіть початківці можуть помітити елементи imgбез текстового еквіваленту в розмітці HTML, а з отриманням додаткового досвіду ви станете швидше виявляти проблеми, перш ніж переходити до більш строгого тестування. Для експертів у великих проектах може бути неможливо вручну переглянути весь клієнтський код або проінспектувати всі частини Web-сайту, але інструментальна оцінка може виявити області, які викликають особливу тривогу, які заслуговують більш ретельного розгляду. Люди оцінювачі можуть також переглянути речі, які помітить машинна оцінка.
На жаль, хоча існує безліч інструментів доступності, більшість із них є неповноцінними тим чи іншим чином. Наприклад, один інструмент, який перераховує заголовки в документах HTML, робить помилку, не включаючи весь текст з елементів img. Також як ви повинні пам’ятати про сенс закону щодо відповідності стандартам, ви повинні пам’ятати про це при використанні інструментів. Перш ніж повідомляти комусь про проблему доступності, перевірте, що це дійсно проблема, а не помилка інструменту.
Коли очевидні проблеми будуть виправлені, наступним кроком було б непогано піддати сторінку перевірці за допомогою напівавтоматичного засобу контролю доступності. При оцінці відповідності певному стандарту ви, ймовірно, захочете вибрати один із таких інструментів, створений для використання з цим стандартом.
При оцінці відповідності Section 508 або WCAG 1.0, інструмент Cynthia Says є розумним вибором. Під час тестування згідно з німецьким BITV 1.0 Level 2, італійським Stanca Act, або чорновим варіантом WCAG 2.0 єдиним наявним варіантом є експериментальний засіб ATRC Web Accessibility Checker
Такі інструменти мають значні обмеження. Не існує такої речі, як повністю автоматизоване тестування доступності. Наприклад, враховуючи примітивну природу сучасного штучного інтелекту, комп’ютерна програма не може остаточно сказати, чи буде деякий текст справжнім еквівалентом фотографії в контексті. Навіть в областях, які можуть бути теоретично повністю автоматизовані, програмісти засобів перевірки можуть помилятися у своїй інтерпретації рекомендацій щодо доступності і втрачати сенс закону серед його літер.
Хороші інструменти перевіряють сторінку на наявність проблем доступності і створюють список того, що вони вважають помилками, й інший список того, що вони вважають заслуговуючим перевірки людиною. Наприклад, якщо програма Cynthia Says знаходить елемент img з alt = "", вона створює попередження (не помилку!), інструктуючи користувача “перевірити, що це зображення використовується тільки для інтервалу або дизайну, і не має ніякого значення”. Якщо правильним текстовим еквівалентом для цього зображення є порожній рядок, потрібно буде просто перейти до наступної помилки або попередження.
Можливо, найбільша перевага засобів перевірки доступності полягає в тому, що якщо вибрати одне з них, таке як TAW 3, яке може виконуватися на декількох URL, то можна знайти сторінки у великих сукупностях, які вимагають, мабуть, більш ретельної перевірки.
1.2 Аналіз індивідуальних параметрів при тестуванні сайтів інтернет-магазинів
Показником зручності користування різними сайтами є юзабіліті, і за допомогою так званого юзабіліті тестування (юзабіліті-аудиту) можна даний показник оцінити. Юзабіліті тестування може проводитися як на етапі розробки сайту, так і протягом усього життєвого циклу сайту.
Юзабіліті аудит допомагає дізнатися, чи потребує сайт редизайну або перепроектування інтерфейсу користувача. Такий аудит необхідний всім сайтам, але особливо його потребують інтернет-магазини, оскільки даний тип сайтів працює «напряму» з потенційними покупцями. Для інтернет-магазинів юзабіліті-аудит допомагає вирішити наступні завдання:
дізнатися, чому рівень продажів нижчий, ніж очікувалося;
визначити, на якому етапі взаємодії у відвідувачів найчастіше виникають проблеми;
виробити рішення для виявлених проблем.
Перш ніж проводити юзабіліті аудит інтернет-магазину, та й будь-якого іншого типу сайтів теж, необхідно спочатку якомога конкретніше визначити його цільову аудиторію. Для цього зазвичай складають портрет типового користувача сайту, який демонструє:
вік і матеріальне становище;
інтереси і властиву поведінку;
професійні навички;
рівень навичок інтернет-користувача.
Юзабіліті тестування може бути якісним і порівняльним. При якісному юзабіліті тестуванні вивчається поведінка і дії користувачів при роботі з сайтом, що тестується, а при порівняльному вивчаються дії користувачів при роботі відразу з декількома сайтами: тим, що тестується.
Необхідне обладнання для юзабіліті тестування сайту включає найчастіше власне комп'ютер користувача з доступом в інтернет, а також записувальну (реєструвальну) апаратуру для фіксації дій і поведінки респондента у час проведення тестування. У якості такої апаратури застосовуються зазвичай відеокамери або ж диктофони, ще може підійти для цієї мети веб камера (необхідно вести запис потоку даних, що передається камерою).
Останнім часом для проведення юзабіліті тестів стала використовуватися технологія eye tracking (айтрекінг) — технологія, що дозволяє визначити, як і куди по сторінці сайту рухається погляд користувача. Для застосування подібної технології потрібен спеціальний прилад eye tracker (айтрекер): за допомогою інфрачервоних променів цей прилад фіксує положення очей при перегляді і потім отримані дані наносять на спеціальні карти. Технологія айтрекінга дозволяє отримувати дуже точні дані, однак вона досить дорога.
Щоб провести юзабіліті аудит, слід відібрати певну кількість респондентів (5-8 буде достатньо), що відповідають портрету типового користувача сайту, підготувати обладнання. Також необхідно правильно сформулювати завдання для респондентів і скласти сценарій їх взаємодії з сайтом, що тестується. Крім того, слід визначити перелік метрик, за якими буде проводитися аналіз зібраних у ході тестування даних.
Під час проведення юзабіліті тестування важливо дати респондентам зрозуміти, що перевіряється саме сайт, а не вони самі, тому боятися зробити якусь помилку не потрібно. При тестуванні респонденти повинні обов'язково промовляти свої зауваження, емоції при взаємодії з сайтом, адже це теж характеризує рівень комфорту роботи з сайтом: якщо респондент супроводжує свої дії незадоволеними коментарями або ж злиться, то це може свідчити про те, що користування сайтом доставляє йому велику незручність.
Юзабіліті аудит не закінчується просто фіксацією даних про виявлені проблеми або помилки в роботі сайту. Після збору даних настає черга аналізу — мабуть, найскладнішого етапу у всьому тестуванні. Фахівці з юзабіліті повинні вивчити всі отримані дані, систематизувати їх і на їх основі зробити висновки про те, чи вимагає сайт доопрацювання або перепроектування.
Окремо юзабіліті тестуванням займаються компанії, що спеціалізуються на даному напрямку. Також юзабіліті аудит часто проводиться і веб-студіями при розробці або редизайні сайтів. Зокрема, студія веб-дизайну WebStudio2U під час розробки сайтів, а також розробки веб-дизайну або редизайну сайтів використовує дані юзабіліті-аналізу для створення рішень, що повною мірою відповідають сучасним вимогам до юзабіліті.
Реєстрація клієнтів
Перше, що ви могли б зробити - це спробувати зареєструватися у власному інтернет-магазині як клієнт. Перейдіть в розділ реєстрації та подивіться як побачить початковий інтерфейс вашого магазину ваш майбутній клієнт. Пройдіть всі кроки реєстрації, щоб отримати доступ в клієнтський особистий кабінет, який створюється для кожного клієнта.
Клієнт робить запит менеджеру
Ви можете спробувати відразу зробити запит менеджеру (для підбору запчастин по VIN-коду) і замовити зворотний дзвінок. Надалі, коли ви зайдете в адміністративну частину вашого сайту, ви зможете там побачити цього зареєстрованого клієнта і його звернення до менеджера (тобто ті дії, які ви самі зробили, тестуючи магазин). Це допоможе вам зорієнтуватися в інтерфейсі адміністративної сторінки.
Налаштування сайту
Дуже важливо відразу виконати базові налаштування вашого інтернет-магазину, які дозволять автоматично генерувати рахунки на оплату, отримувати коректні повідомлення, розраховувати розмір знижок і націнок. В адміністративній частині сайту перейдіть в розділ «Налаштування сайту» і, пройшовши по всіх сторінках, виконайте всі настройки, які вам зрозумілі. Якщо настройка якихось параметрів викличе у вас утруднення, будь ласка, зверніться в нашу службу підтримки, вам обов'язково пояснять, що і як потрібно зробити.
Як перевірити роботу пошуку запчастин
Щоб клієнти могли оцнювать запчастини та інші товари у вашому інтернет-магазині, вам необхідно завантажити свої прайс-листи і підключити сервіси веб-Проценки ваших постащиков. Зайдіть в адміністративну частину сайту і перейдіть в розділ «Прайс-листи». Там ви побачите доступні вкладки «Прайс-листи» і «Постачальники».
Перший розділ дозволяє завантажувати файли, що містять перелік ваших товарів. Після обробки завантаженого файлу, всі позиції даного прайс-листа будуть доступні для вибору вашими клієнтами. Перед тим, як завантажувати файл прайс-листа обов'язково ознайомтеся з «Вимогами до прайс-листів», розміщеними на тій же сторінці.
Другий розділ «Постачальники», дозволяє підключитися до серверів ваших постачальників і отримувати їх ціни та наявність в автоматичному режимі.
Як зробити замовлення
Після того як ви залили прайс-листи та / або підключили постачальників, ви можете знову зайти на клієнтську частину вашого інтернет-магазину і виконати пошук запчастини. Далі всі дії виконуються звичним чином як в будь-якому інтернет-магазині: ви ставите потрібний товар у кошик та оформляєте замовлення. Оформлений замовлення надходить на обробку менеджеру (ви побачите дані про замовлення в адміністративній частині магазину, також менеджер отримає повідомлення на e-mail про надходження нового замовлення). Показником зручності користування різними сайтами є юзабіліті, і за допомогою так званого юзабіліті тестування (юзабіліті-аудиту) можна даний показник оцінити. Юзабіліті тестування може проводитися як на етапі розробки сайту, так і протягом усього життєвого циклу сайту.
Висновок
Для проведення різних перевірок при тестуванні сайту існує безліч спеціальних програмних інструментів. Наприклад, HTML-валідатори перевіряють html-код сторінок сайту на відповідність стандартам мови HTML. А аналізатори непрацездатних (битих) посилань і зображень, наприклад, Semonitor, дозволяють автоматизувати процес перевірки сайту на працездатність гіперпосилань і коректне відображення картинок, фотографій.
Перш ніж починати оцінку проекту щодо доступності, необхідно визначити, які ключові вимоги існують для цього проекту, з урахуванням його робочого середовища, передбачуваної аудиторії і ресурсів. Деякі вимоги будуть задаватися незалежними сторонами, такими як уряд і клієнти, деякі ви зможете вибрати самостійно.