Team Lead/Python developer Олена Кузнецова висловила думку, що розробники теж мають бути серйозно включені в процес тестування власного продукту.
Team Lead/Python developer Олена Кузнецова висловила думку, що розробники теж мають бути серйозно включені в процес тестування власного продукту.
«Розробник має самостійно тестувати свій продукт. І продакт/бізнес аналітик — теж повинні бути залучені в цей процес, коли приймають бізнес-фічу. Відділ тестування — це не підтиратор дупи, який виловить усі баги за розробників, а люди, які відловлюють якісь дивні речі, залежно від кваліфікації налаштовують автоматизацію тестів, допомагають визначити якість продукту загалом, дають погляд збоку», — висловила вона свій погляд у дописі на LinkedIn.
Айтівиця вважає, що якщо відділ тестування є — це добре, але якщо його немає — це не повинно нічого особливо змінювати в роботі того, хто пише код.
«Так, це начебто додатковий час, але він буде виправданий розумінням, що людина робить і чому, тіснішим зв’язком із проєктом. Це дає більше шансів на ініціативу з боку розробників. Це дає більше дофаміну від розуміння того, що ти зробив щось матеріальне. Це дає міцні зв’язки між відділами, взаємну повагу. Відділ тестування не відчуває себе обслуговуючим персоналом (їм не віддають функціонал, який явно не працює, наче знущаючись). Відділ розробки не засипають полотном з багів, і вони не вороги (набагато простіше ненавидіти того, хто вказав тобі на твою помилку, навіть якщо це об'єктивно його робота)», — обгрунтувала Олена Кузнецова свою позицію.
Також, зі слів авторки поста, це прискорює цикл зворотного зв’язку, адже, на її думку, набагато простіше працювати, коли ти не чекаєш, коли код візьмуть на тестування, якщо, найімовірніше, «вони нічого не знайдуть критичного і термінового».
Інші представники ІТ-сфери також висловили своє бачення стосовно даної ситуації.
«Цілком згоден. Тут справа іноді в тому, що розробник вважає, що баг на проді — це провина тестувальника. Ну типу, самі винні, що не перевірили нормально, мають бути тестувальники. Інакше кажучи, розробник ділить або навіть передає відповідальність за помилку на того, хто тестує. Насправді, як на мене, наявність чи відсутність тестувальника не має нічого змінювати для розробника. Баг є баг, незалежно від того, потрапив він на прод чи ні», — каже ІТ-підприємець Олег Фролов.
Team Lead і Product Engineer Євген Туровець вважає це правильним, але дещо утопічним.
«Можу тільки підписатись під усім цим, і констатувати, що це дуже утопічно… Можливо, ситуація на ринку щось змінить, але дуже важко отримати гарний претест від розробника… Не буду лукавити, я і сам, буває, віддаю не суперзатестовану фічу, бо просто не встигаю або вона вже бісить мене! Найкраще тут для мене працює ретест на наступний день, коли тебе ще не втомили за день!», — поділився він власним досвідом.
Senior frontend developer Рустам М. повністю згоден з тим, що функціонал має бути відтестований самим розробником.
«Він мусить бути майже впевненим, що там немає багів, принаймні тих, що лежать прямо в тісному контексті із виконаною задачею. Такий підхід зекономить купу часу і нервів для самого ж розробника, не треба буде пригати між задачами і втрачати концентрацію», — каже він.
Але у випадку більш складного сценарію, зі слів айтівця, вступає в гру тестувальник.
«Він може приділити більше часу саме для пошуку проблем, а найголовніше — що це є гарант якості перед деплоєм. Тому, все що попало в прод — вже провина QA. Для QA це має бути виклик — знайти щось, а для розробника приємно, якщо не знайшли. Не буде цієї „пристрасті“, не буде і якісного результату, а буде вʼяле пересування таски взад-вперед», — робить висновки Рустам М.
Як писав dev.ua, automation QA Engineer Ольга Маркова поділилась добіркою інструментів, які допоможуть тестувальникам у створенні доступних вебсайтів, що мають бути придатним для використання людьми з додатковими потребами, зокрема з вадами зору, слуху, когнітивними чи фізичними вадами.
