- тестування
- Організація роботи
- Selenium
Доброго вам дня!
Є невелика компанія в якій є два види співробітників - розробники і впроваджувачі. Розробники роблять конструктор, впроваджувачі налаштовують його для замовника, який бачить тільки веб-інтерфейс.
Розробники роблять рев'ю коду друг у друга, намагаються на новий функціонал і на виправлення помилок писати модульні тести. Після накопичення набору змін він передається на тестування внедренцем. Вони його пробують і відчувають і якщо видимих помилок більше немає, то випускається реліз конструктора, який можна передавати замовнику після настройки.
Найбільш часті місця виникнення помилок: стик підсистем і веб-інтерфейс.
Ми вважаємо, що для того що б все стало добре, систему треба покрити інтеграційними тестами. Ми думаємо в сторону селеніума (був би вдячний, якщо в коментарях порадите щось ще), що б він просто робив те ж саме, що зараз роблять впроваджувачі - протиківал інтерфейс і якщо реакція очікувана, вважаємо що все добре (зрозуміло, ми розуміємо, що тести не дають гарантію відсутності помилок).
Бачимо такі проблеми при організації нового підрозділу:
1) Величезна різноманітність варіантів побудови продуктів з блоків конструктора - що працює у одного замовника, може не спрацювати в іншого з різних причин. На якій конфігурації конструктора проводити тести?
2) До конструктору немає чіткої специфікації (і не буде в даний момент), лише список завдань в баг-трекері, а значить тестувальникам незрозуміло що тестувати. Можна спробувати писати тести на нові завдання і поступово вони покриють всі, потихеньку додавати тести на функціонал, який не потрапляє в нові завдання. Чи спрацює?
3) Перевищення повноважень підрозділи з підтримки тестів в актуальному стані. Швидше надумана проблема, але тим не менш, може вийде так, що тестів стане занадто багато і при виході нової версії продукту тестувальники не встигатимуть актуалізувати тести під змінену платформу?
"1) Величезна різноманітність варіантів побудови продуктів з блоків конструктора - що працює у одного замовника, може не спрацювати в іншого з різних причин. На якій конфігурації конструктора проводити тести?"
Якщо ви збираєтеся створювати нормальну команду тестувальників, які будуть робити тести, а не тестувати (тобто писати автоматизацію), то яка різниця скільки варіантів - тестируйте все. Головне щоб вистачило ресурсів на потрібну кількість віртуалок.
2) До конструктору немає чіткої специфікації (і не буде в даний момент), лише список завдань в баг-трекері, а значить тестувальникам незрозуміло що тестувати. Можна спробувати писати тести на нові завдання і поступово вони покриють всі, потихеньку додавати тести на функціонал, який не потрапляє в нові завдання. Чи спрацює?
В першу чергу потрібно налагодити процес тестування в тому сенсі, що б додаток розгорнулося, пройшов якийсь sanity тест, і про це пішло повідомлення далі по CI. Коли система буде працювати, можна буде додавати тести, оновлювати тести. Але подібну систему спроектувати і налагодити повинен досвідчений QA - лід, який спершу розбереться в продукті і зможе зробити досить гнучку систему, в яку згодом можна буде запізхнуть всі тести і все конфігурації.
3) Перевищення повноважень підрозділи з підтримки тестів в актуальному стані. Швидше надумана проблема, але тим не менш, може вийде так, що тестів стане занадто багато і при виході нової версії продукту тестувальники не встигатимуть актуалізувати тести під змінену платформу?
Повинні бути тести, які мало залежать від версії. Повинна бути можливість швидко відключати неактуальні тести. Тести не є самоціллю, вони є додатковою метрикою якості продукту і спрощення розробки за рахунок автоматизації. Адже можна щось не тестувати, а при цьому воно буде працювати, тому що пройшло перевірку розробником в юніттестіровані.
Ну і зрозуміло, що з досвідом прийде розуміння скільки і що потрібно тестувати, щоб встигали. Буде багато - відкине некритично частина.
Досвід показує, що незважаючи на всілякі юніттести - покриття UI тестами - необхідно. Те, що поверне функція - ще не означає, що frontend це відобразить і відобразить правильно)
Evgeniy _. У чому проблема написати автоматичні UI тести?
Saboteur. Це у вас написано "Адже можна щось не тестувати, а при цьому воно буде працювати, тому що пройшло перевірку розробником в юніттестіровані.". Не в мене.
Test automation developer
перша думка яка прийшла в голову: якщо проблеми на стику компонентів виникають, може спершу над архітектурою попрацювати?
Тестування адже всього-лише знаходить вияв помилок. А бажано усувати причини призводять до їх виникнення. Інакше ви будете витрачати все більше грошей на те щоб знаходити помилки, реліз буде відкладатися, клієнти будуть незадоволені затримками оновлень.
Почитайте багтрекер на предмет, які причини знайдених помилок. Як правило є кілька коренів зла. Ось на це і варто звернути увагу.
У нас наприклад ModelView шар програми видає мінімум третину помилок, ми робимо автоматизацію, це дорого, а треба просто нахрен викинути той інструмент яким ми робимо UI і перейти на що-небудь, що буде затверджувати у розробника на комп'ютері а не завтра вранці на сервері після повної збірки. Інша справа що на такий крок начальство піти не може, вони в рабстві у вендора цього інструменту. Тобто міграція можлива але не раптом.