Чи повинні програмісти допомагати тестерам у розробці тестів?

Наскільки програмісти повинні допомагати тестерам у розробці тестів?

Я не думаю, що вони взагалі повинні допомагати. Я хвилююсь, що якщо вони допоможуть тестерам у розробці тестів для власного коду, вони "заразить" тестерів власними забобонами та сліпими плямами щодо цього коду.

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

Не всі, кого я знаю, згодні з цим (і я певно розумію деякі їхні точки). Що думають з цього приводу інші? Це десь обговорюється в літературі?

Я згоден. Програмісти можуть допомогти тестувальникам зрозуміти функціональні характеристики, знайти ресурси для дослідження, але не повинні забруднювати розум тестувальників власними уявленнями про те, як підійти до тестування.

Я думаю, що розробникам та тестерам є місце для мирного співіснування у царині якості. :)

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

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

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

Я також великий прихильник тестерів, що допомагають розробникам - я багато разів в своїй кар’єрі замислював дизайнерські ідеї з розробниками, і разом з ними виправляв помилки (і вказував на помилки та пропонував виправлення), і не думаю, що я ' я коли-небудь помазував розробника тестером.

Якщо ви не вважаєте це спільним зусиллям, вам просто доведеться код "перекинути через стіну" від розробника до тестування ... і ви отримаєте більш низьку якість. Це правда в моєму світі, але (звичайно), ymmv.

Як я бачу, це те, що перевірка мого коду не є завданням QA. Завдання тестера - переконатися, що мій код відповідає всім вимогам цього завдання.

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

На моїй останній роботі ми з самого початку займалися QA. Це було засіданням сесій, нарад проектів та дизайнерських нарад. Вони слухали і задавали питання, і поки розробники писали код, вони писали свої тестові плани. Це вийшло чудово, і ми спіймали багато питань, які, ймовірно, проскочили б.

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

"Забруднення" не було, якщо ваш код - це сира каналізація, і це було б зовсім з іншої причини.

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

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

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

Команда QA, ймовірно, побачить області, які мають великий комбінаторний тестовий обсяг, ніж вимоги збирачів або розробників системи, але вони, можливо, не знають про компоненти системи, які мають більш тонкий вид крихкості, який виграє від усвідомлення дизайну або впровадження системи.

На мій досвід, співпраця між QA та Development виробляє продукцію кращої якості. Я б ніколи не рекомендував робити лише передачу в чорний ящик.

Як тестер, я взагалі не заперечую проти програмістів, які пропонують тестові випадки (хоча це не означає, що я буду дотримуватися лише тих тестових випадків) або описувати деталі впровадження. Іноді може бути дуже корисно, щоб хтось сказав: "Я думаю, що цей біт може бути ризикованим, мені б дуже хотілося, якби ви досить ретельно випробували цей шматочок". Знання деяких деталей впровадження допомагає мені застосувати багаторічний досвід вибору тестів, які, на мою думку, є найбільш невдалими. Іноді лише коротка згадка означає, що кілька тестів раптом збільшують праворуч мій список пріоритетів.

Мене це неприємно? Мені якось лоскоче ідея програмістів, які завзято намагаються зберегти чистоту мого тестера, але насправді - ні, це міф. Більше інформації зазвичай викликає ще більше питань для мене, а не менше. Я думаю, що це розум - я не знаходжу помилок, тому що я необізнаний, я знаходжу проблеми, тому що я скептичний, недовірливий тип, який просто надто упертий, щоб повністю взяти щось на довіру. У кожній тестованій системі я виявив, що знаходжу більше проблем, і чим «цікавіші», тим глибше я розумію це.

Мені подобається переглядати плани тестів і пропонувати додаткові тестові випадки, про які КВ, можливо, не думав. Я не впевнений, як це може «заразити тестерів моїми забобонами».

Я виявив себе в цьому дивному становищі, що мені потрібно впроваджувати та писати тестові випадки в Selenium згодом, оскільки нам не вистачає співробітників з QA. Я вважаю, що розробка тестів була б дуже корисною, але вона ще не адаптована в моєму магазині.

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

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

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