Місія QA-тестувальника найвідповідальніша на проекті, адже від нього залежить
бездоганна якість сайту. А сьогодні у одного з наших тестувальників є ще одна місія,
адже ми попросили його розповісти про те, як на InternetDevels відбувається процес
тестування сайтів. Отже, інформація з перших рук, що завжди цінно ;)
Влаштовуємося зручно і читаємо про наступне:
Етапи процесу тестування сайтів
Вивчення сайту
Процес тестування починається з вивчення сайту. Ми заходимо на сайт і буквально натискаємо на всі кнопки, заповняємо всі форми, відкриваємо всі посилання, щоб пересвідчитися, що на сайті немає явних помилок. Крім того, ми «проганяємо» сайт через спеціальні аналізатори, які перевіряють його на відсутність «битих» посилань, проблем зі стилями чи JS, а також загальну швидкодію.
Якщо сайт передбачає реєстрацію — реєструємось і дивимось, чи система веде себе, як ми того очікуємо (ми очікуємо, що після реєстрації повинен прийти лист-підтвердження, або лист із одноразовим паролем/посиланням для входу в особистий кабінет). Заходимо в кабінет користувача та перевіряємо, чи приходить нам електронний лист. Якщо нічого не відбувається, то, можливо, ми знайшли проблему. Далі дивимось, як сайт виглядає в анонімному вікні браузера (перевіряємо, чи все так само, як і в неанонімному). Якщо є різниця, то потрібно встановити, чому так (можливо, різниця дійсно повинна бути).
Зазвичай багато багів можна знайти уже на етапі вивчення сайту, наприклад, якщо відкрити сайт на мобільному телефоні або ж в такому браузері, як Internet Explorer.
Список дій на сайті можна продовжувати, і вони залежать від конкретних випадків.
Збір інформації від клієнта (специфікації проекту, технічне завдання, звіти від розробників, макети і т.д.)
Для майбутньої роботи важливо визначити тип та масштаби проекту — наприклад, якщо це інтернет-магазин, то скільки в ньому товарів, категорій, сторінок, мов і т.д.
Щоб перевірити, чи відповідає сайт вимогам клієнта, нам обов’язково потрібно знати ці вимоги. Для цього ми вивчаємо технічну документацію клієнта по сайту — це може бути макет, технічне завдання (так звані «спеки») і т.д. Чим детальніша документація, тим точніший і якісніший результат. Якщо ж документації немає, то ми спілкуємось з замовником і створюємо її по ходу процесу. Дуже важливим є отримання всіх можливих доступів до адмінської частини сайту (логін /пароль до профілю суперадміна, SSH доступи до серверу, root-права на сервері, VPN доступи (якщо є), дампи баз даних, і.т.д). Ця вся інформація необхідна для більш точної оцінки масштабів роботи.
Планування робіт та оцінка на основі попереднього досвіду
Вивчивши сайт, наявну документацію і вимоги клієнта, ми плануємо все, що потрібно зробити, і приблизно оцінюємо, скільки часу на це піде. Виходячи з нашого попереднього досвіду, ми даємо приблизну оцінку в годинах на 1 людину (скільки годин знадобиться на всю роботу, якщо її виконуватиме один тестувальник). Наприклад, пишемо, що функціонал покупок буде тестуватися 50 годин, функціонал перекладу — 100 годин. Варто пам’ятати, що оцінка приблизна, саме тому що ми ще не знаємо, які інструменти ми будемо використовувати, які типи тестування ми будемо задіювати (автоматизоване чи ручне), яка кількість тестових середовищ буде доступна нам, скільки людей буде залучено до процесу тестування.
Надавши замовнику цю попередню оцінку, ми уточнюємо в нього деякі питання, які можуть виникнути точно виникнуть в процесі оцінки. Наприклад, чи потрібне замовнику тестування в усіх браузерах, чи лише в декількох, які важливі для нього. Постійно спілкуючись з замовником, можна значно заощадити час і кошти. З урахуванням усієї вище зібраної інформації ми можемо поставити більш точну оцінку.
Тест-середовище, тест-інструменти, розподіл ресурсів, розклад тестування
Далі визначаємось із тест-середовищем. Де ми будемо писати тест-кейси: скажімо, в ексельці, на папері від руки, на стіні печери, або, наприклад, в TestRails — спеціалізованій системі для запису тест-кейсів, яка добре допомагає структурувати інформацію (особливо якщо її багато).
Визначаємося з тим, на якому сервері тестувати сайт, і чи це буде сайт локально розгорнутий, чи на спеціалізованому тест-сервері, чи ми тестуватимемо всі зміни одразу на живому сайті (ніколи не повторюйте це в домашніх умовах :).
Залежно від потреб та бюджету замовника, ми обираємо тип тестування. Тестування може бути ручне або автоматизоване, або комбінуватися. В залежності від обраного типу — обираємо і відповідні інструменти.
Коли у нас уже є вся ця інформація, ми можемо порадитися із замовником і визначити, скільки людей ми можемо залучити до процесу тестування.
І тільки тепер — ми складаємо графік того, коли, що і в якому порядку ми будемо тестувати. На цьому етапі вже можна сформувати приблизні робочі спринти.
Збір інформації про процес роботи розробників
Варто зазначити, що ми розглядаємо схему роботи для випадків, коли сайт надходить нам лише на тестування. Більшість наших проектів ми розробляли і ми ж їх і підтримуємо. Проте, якщо проект потрапляє до нас вже на доопрацювання, і писався з самого початку не нами або й далі продовжує писатись не нами, нам якнайповніше потрібно зібрати інформацію про середовище і процеси розробки.
Ми вивчаємо, як організований (був організований) процес роботи розробників, які розробляють (розробляли) сайт. Спілкуємося з командою розробників, аби налагодити процеси співпраці. Це потрібно для того, аби «влитися» у їхній workflow та, по можливості, автоматизувати його — наприклад, налаштувати continuous integration (методологія розробки, яка дозволяє контролювати процес на будь-якій його стадії за допомогою часткової автоматизації цього ж таки процесу: білд-скріпти, автоматичні репорти, автоматизація роботи з Гітом) для кращої організації роботи команди.
Тест-дизайн (Тест-дані / Тест-сценарій / Тест-кейс)
Як архітектор сайту створює структуру сайту, так і тест-дизайнер (зазвичай senior-тестувальник) визначає структуру процесу тестування, — детальні особливості роботи з проектом. Це може бути виражено і задокументовано у плані робіт, або за допомогою чек-ліста.
Або ми просто збираємось командою і вирішуємо проблемні моменти, які можуть виникнути точно виникнуть протягом нашої роботи і документуємо наші рішення, таким чином, ми ніби попереджуємо проблеми ще до їх виникнення. Зазвичай, на цьому етапі розробляються тест-кейси — придумуються, складаються, нумеруються, оформляються за відповідними правилами, щоб їх могли зрозуміти всі учасники процесу.
Виконання тестів === Знайдення багів
Настає час втілювати в життя все те, що дизайнилось і продумувалось. Це етап, на якому ми виконуємо тести.
В процесі тестування ми знаходимо баги. Вони обов’язково знаходяться, яким би чудовим не був наш проект — інакше погано шукали.
Баг-репортинг розробникам
Далі потрібно зайти в баг-трекер (наприклад Jira) і зарепортити баг у відповідній задачі. Якщо задачі не було, її потрібно створити і вказати, де конкретно і який баг був знайдений і як його можна відтворити. Чим більше деталей містить баг-репорт, тим краще його зрозуміє розробник. Тут чудово працюють скріншоти, відео, покроковий опис.
Виправлення & Перевірка & Закриття
Знайшли — отже, будемо фіксити! Розробник отримує баг-репорт або задачу в баг-трекері (або поштового голуба), відтворює баг, шукає його причину і займається виправленням.
Потім розробник відправляє задачу тестувальнику на перевірку.
Тестувальник повинен бути суворим, але справедливим — перевіряти без жодних компромісів. Якщо тестувальник визначає, що баг пофікшений — чудово! Задача закривається і всі щасливі.
Якщо ж ні — то потрібно повернути її назад розробнику. І так далі — поки все не буде ідеально. В кінці роботи потрібно в структурованому вигляді описати все, що ми робили. Це може бути у вигляді ворклогу задач, або, якщо це TestRails, то у вигляді тест-ранів. Головне — щоб вся зроблена робота була детально задокументована. Це потрібно для наших спадкоємців, адже якщо проект великий і довгий, комусь обов’язково стане у пригоді те, що ми задокументували.
Автоматизація критичного бізнес-функціоналу
Якщо проект передбачає автоматизацію, то автоматизується, в першу чергу, лише критичний бізнес-функціонал. Наприклад, процес покупки та оплати в інтернет-магазині (перевіряємо чи все працює коректно, чи правильно знімаються кошти з картки клієнта і т.д.).
Автоматизація проходить за допомогою тих інструментів, з якими ми визначилися в пункті про Testing tools. Якщо є така необхідність — залучаємо додаткові ресурси і процес тестування сайту автоматизується повністю, або майже повністю. Насправді, в цьому майже завжди немає необхідності, адже це дорого і часозатратно. Ми завжди стараємося оптимізувати ресурси і не робити зайвого, якщо в цьому немає потреби.
Регресивне тестування
Може здатись, що тестування — це легкий, і в більшості випадків, непотрібний процес. Проте — це важливий етап розробки якісного продукту. І ми, в Internetdevels, приділяємо значну увагу всім деталям цього процесу. А тому, щоб забезпечити ідеальну роботу сайту і відловити можливі баги, які можуть виникнути в майбутньому (особливо при внесенні змін в код), потрібне регулярне регресивне тестування (ми проганяємо всі наявні тести знову і знову…, а потім повторюємо процес). Це може бути або запуск уже створених автоматичних тестів, або ж ручне тестування. В рамках регресивного тестування працюють ті самі етапи: Виправлення & Перевірка & Закриття.
Happy End!
Читайте також: