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'і щодня нагадував про програний бій.