Що таке "добрі локатори" на web-сторінках

Писання автоматизованих тестів для web GUI складається, великою мірою, не тільки з логіки перевірок та вигадування моделі тестових даних, як під час тестування API, а ще й із прив’язування логіки тесту до правильних елементів на сторінці, тобто - побудови локаторів.
Окрім усім очевидних методів пошуку елемента за id чи ім’ям класу (class name), іноді у нагоді стають css-selector'и та xpath'и, що дозволяють вкласти певну логіку у спосіб пошуку, та значно полегшити код самої перевірки, звівши її до простої присутності елемента за зазначеним локатором. Але який локатор вважати добрим?

Як читають багрепорти?

Головною і чи не єдиною загальновживаною метрикою ефективності тестерів є кількість баг-репортів. Ну а якість цих звітів - головний результат роботи тестувальника.
Основні елементи баг-репорту приблизно однакові, незалежно від системи відстежування дефектів. Але у кожному конкретному випадку найбільш доречними для заповнення можуть бути різні поля. І, на мою думку, об’єм необхідної інформації у звіті залежить від порядку, в якому наша "цільова аудиторія" (ПО, кодер чи інші тестери) читають звіти.
Отже, як читають баг-репорт:

1. Summary

   Опис дефекту - те саме, що тема у листа. Він або викличе цікавість, і читач одразу його відкриє, щоб дізнатись деталі; або читачу стане і так все ясно.
   В Джірі (Jira) на дошці перегляду беклогу на 17’’ моніторі видно від 30 до 56 символів Summary. Цим екраном зазвичай користується ПО (Product Owner), пріоритизуючи задачі. Це не привід обмежуватись 50-ма символами. Просто треба поставити найважливішу саме для ПО інформацію на початок опису, як то: назву функціональної області чи функції, наслідки цього дефекту для функціональності.                                                                                                                  Наприклад: Player: Video played slower than Real time [приблизна межа видимості] when played from the middle

1. Screenshots

   Нотаріально завірені скріншоти - друге, на що дивиться зацікавлений описом читач. Відкривши ваш звіт, він хоче якнайшвидше переконатися, що баг таки присутній у системі, чи принаймні у тестовому середовищі. Скріншоти, тобто візуальна інформація, дуже корисні для швидкої оцінки "звинувачень".
   Я раджу вставляти їх завжди, адже функціонал може змінитися, кроки - стати не актуальними, а скріншоти - залишаться єдиними свідками колишніх "фаталів".

2. URLs

   Після швидкого перегляду візуальних доказів, наш приголомшений читач спішить-перекидається побачити усе на власні очі. Тому він швидко сканує текст звіту, шукаючи посилання, що якнайшвидше забере його туди. (Тут я згадую себе, коли мені скидають критичний баг-репорт з продакшону :-Е )
   Найчастішою відмазкою, щоб не вставляти URL-адреси є те, що, мовляв, перевіряємо на тестовому середовищі, чий вік вимірюється якщо не годинами, то днями. І за тиждень клікнувши на посилання, ви отримаєте "Server not found". Але навіть таке посилання - дуже корисне, бо насправді ім’я сервера можна легко поміняти на існуюче. Якщо Ви соромитесь вставляти неробочі URL'и, можете написати перед ним "e.g.", або вставити адресу без імені сервера.
   

3. Expected result vs. Actual result

    А поки посилання відкриваються у сусідній ўкладці, наш нетерплячий читач з’ясовує, що ж звітовник очікував на тій сторінці побачити, і у чому саме відмінність від реальності.
   

4.  Preconditions & Steps, Environment, Severity

   Ну і, нарешті, тільки якщо вся вищеозначена інформація виявилася марною для осягнення глибини тестувальної думки, доходить черга до передумов та кроків, і, власне, відтворення дефекту.
   Не пишіть багато кроків, крім випадків, де це необхідно. Чим їх більше, тим менша імовірність, що їх хтось із цих ледацюг буде виконувати.
   

TeamCity для дому та офісу

Працюючи вдома чи на невеличкому проекті, на який навіть наймолодшого адміна смикати соромно, все ж виникає бажання зробити парочку щоденних перевірок, чи то у базі даних, чи просто автотестиків, чи запуск будь-якого скрипта з командного рядка. Можна все, звичайно, руками запустити, але із своїм домашнім CI (Continuos Integration Server) було б приємніше. 

Вже маючи трохи досвіду із Jenkins'ом, можу сказати що TeamCity краще: простіше у налаштуванні, приємніший інтерфейс. Розробники з JetBrains - як завжди молодці. Є обмеження безкоштовної ліцензії, але коли ваш проект виросте за їхні межі, думаю, і девопса можна буде долучити.
Єдине, про що варто потурбуватися перед встановленням - щоб ця машина мала доступ до всіх ресурсів, які ви збираєтеся перевіряти.

Отже, тут невеличкий список кроків для запуску TeamCity на Ubuntu у домашніх умовах.

Рівні інтеграції коду та об’єм тестів

Тестування, як вчать книжки, відбувається на трьох рівнях:

• Integration testing
• System testing
• Acceptance testing

Класична V-модель рівням тестування ставить у відповідність стадії розробки ПЗ. Але у теперішніх умовах саме таку відповідність можна робити хіба що для певних продуктових проектів.
Більшість компаній (принаймні, мені відома) все ширше використовують agile, зокрема scrum, де розробка проходить ітераціями, коли на виході кожної має з’являтися "potentially shippable product increment" - готовий до випуску приріст фунціональності, як би самостійна частина ПЗ. Всюди панує Git Flow, модульність, де кожну фічу розробляють незалежною, із можливістю її повного вимкнення на продакшені.

Таким чином, часто кожна фіча вже є окремим продуктом, що пройшов усі стадії розробки. І усі ці рівні тестування відбуваються, або мали б відбуватися, щодня.

Тому, логічніше поставити у відповідність рівням тестування - стан коду, що перевіряється, тобто гілку у системі контролю версій:

• (Feature) Integration testing  ->  feature code branch
• System (Integration) testing  ->  develop code branch
• (System) Acceptance testing  ->  master code branch

Мої нотатки до тренінгу з дослідницького тестування від Андрія Дзині та XP Injection

(Дослідницьке) тестування складається із ітерацій:
Do - Analyze - Learn (Document the new knowledge)

Усі пропозиції щодо будь-яких змін мають бути арґументовані на основі фактів, підкріплені користувацькими даними.

Обираючи наступний тест для перевірки, пріоритети мають бути явно розставлені, спираючись на факти.

MCOASTER heuristics для звіту про тестову сесію:
Mission
Coverage
Obstacles
Audience
Status
Techniques
Environment
Risk

This is a list of ideas to consider when reviewing the software development process at your project. It gives you a base-line to compare to what you already have, and simplified understanding of what you may improve.

Стратегія Тестування.
Як на мене, подібні списки ідей потрібні, щоб посидіти й поміркувати, чи все у вас на проекті так добре працює, як хотілося б, і одразу побачити шляхи покращення у кожній фазі процесу розробки.

Testing Strategy Template

Purpose

Testing is a continuous and integrated process where all parties in the project are involved. The purpose of this Test Strategy is to create a shared understanding of the overall targets, approach, tools and timing of (not only) test activities. The objective is to achieve higher quality and shorter customer request lead times with minimum overhead, frequent deliveries, close teamwork with team and the customer, continuous integration, short feedback loops and ability of frequent changes of the design. Test strategy guides us through the common obstacles with a clear view of how to evaluate the system. Lets us look at the development process as a whole.

 

This is a list of ideas to consider when reviewing the software development process at your project. It gives you a base-line to compare to what you already have, and simplified understanding of what you may improve.

Стратегія Тестування.
Як на мене, подібні списки ідей потрібні, щоб посидіти й поміркувати, чи все у вас на проекті так добре працює, як хотілося б, і одразу побачити шляхи покращення у кожній фазі процесу розробки.

Testing Strategy Template

Purpose

Testing is a continuous and integrated process where all parties in the project are involved. The purpose of this Test Strategy is to create a shared understanding of the overall targets, approach, tools and timing of (not only) test activities. The objective is to achieve higher quality and shorter customer request lead times with minimum overhead, frequent deliveries, close teamwork with team and the customer, continuous integration, short feedback loops and ability of frequent changes of the design. Test strategy guides us through the common obstacles with a clear view of how to evaluate the system. Lets us look at the development process as a whole.

Другий тестатон GoIT у Global Logic

Організатори чудово попрацювали! Дуже вдячний команді GoIT, GlobalLogic, Саші Майданюку та Марині Шевченко із Ciklum.
І ми, тобто суддівська колегія, теж впоралися непогано. На перевірку пішло всього трохи більше 5 годин. Порівняно з минулим разом, це дуже швидко.
Тестатон був командний, десь по 3 людини. На Web-частину, звичайно, припала більшість команд, близько 10.
І суддів цього разу було більше, по 2 на Android та iOS, та 4 на Web. Тому оцінювання йшло швидко і бадьоро.

 Дякую моїм колегам - суддям Web-номінацій: Жорі, Саші та Олегу! Ви найкращі!

Scrum та невідкладні задачі серед спринта

Усі, хто читав книжки по Scrum'у, знають про правило непорушності обсягу спринта: Усе, що включили до спринт-беклогу на плануванні, має робитись; і не можна допускати жодних змін під час самого спринта!
У той же час усі, хто працював чи намагався працювати по Scrum'у, відчули, що виконання цього правила іноді коштує дуже багато зусиль, а бува - і добрих стосунків із ПО. Особливо важко буває коли треба і підтримувати вже випущений продукт, і одночасно робити нову функціональність.
Повз мене пройшли сотні "Великих Битв за Спринт", де енергійний, щойно просвітлений еджайлом скрам-майстер, зіштовхувався з не дуже начитаним, але дуже переконливим ПО. Часом перемагав скрам-майстер. Він (чи вона) тоді виглядав героєм: тепер команда може працювати без страху, що зараз таски втратять усю бізнесову цінність.
Але коли перемагав ПО, годі було шукати людину більш розгублену, ніж щойно впевнений у майбутньому скрам-майстер. У цьому випадку або треба було скасовувати весь спринт та влаштовувати нове планування, або продовжувати старий "зіпсований" спринт. І тоді лише горбочок на burn-down chart'і щодня нагадував про програний бій.

Звіт з Тестатону GoIT 18.04.15

Присвятив цілі вихідні цій дуже цікавій для мене події. Посвітив писком. Познайомився з чудовими людьми і тестерами.

До ночі і з пригодами перевіряли з Жорою роботи учасників. Було дуже цікаво подивитись на роботу тестера з іншого боку. А конкурсна основа події підкреслила: тестити можна ефективно, а можна - неефективно.

Зі свого боку велику увагу ми приділяли тому, чи правильно учасники визначили северіті баґа. Кумедні випадки були, коли та сама вада в одного була помічена як Minor, а в іншого - Blocker.
Вова - це найбільший ґуру ґуґл-доків, якого я зустрічав! Зробити автоматичну систему попереднього оцінювання результатів, тобто дошку лідерів - це круто!

Ще раз дякую усім!
Далі перепост звіту від Лесі Ісаєнко http://goit.com.ua/blog/1st_testathon/

Мої RSS підписки про Тестування. Березень 2015

Назва блоґу	Адреса	Коментар
James Bach’s Blog	http://www.satisfice.com/blog	Гуру
Developsense Blog	http://www.developsense.com/blog	+
John Ruberto	http://blog.ruberto.com	+
Maverick Tester	http://mavericktester.com	+
Notes to Self	https://kristjanuba.wordpress.com	+
testjutsu	http://testjutsu.com	+
thoughts from the test eye	http://thetesteye.com/blog	+
UX Movement	http://uxmovement.com	Свіжі погляди на дизайн користувацьких інтерфейсів
QA Club Kiev	http://www.qaclubkiev.com/	Київська спільнота тестерів
QA Hates You	http://qahatesyou.com/wordpress	Веселий блог американського тестера-фрілансера
Uncharted Waters	http://itknowledgeexchange.techtarget.com/uncharted-waters	Чудовий блог про різні аспекти роботи і ІТ
Cartoon Tester	http://cartoontester.blogspot.com/	Тестування у малюнках
Testowanie oprogramowania i zapewni...	http://www.testerzy.pl/component/content/?view=featured	Польська спільнота тестерів (для знавців польської)