Ми наймаємо особу з питань якості, і я повинен придумати деякі питання інтерв'ю. Правда полягає в тому, що я не знаю багато про те, що повинен знати хороший інженер з питань якості, тим більше, що може стосуватися хороших питань інтерв'ю. Хтось має пропозиції?
Деякі відомості: середовище - це два окремих (але переплетені) веб-програми для стека Microsoft (ASP.NET, SQL Server, IIS).
Відповіді:
Якщо у вас немає великого досвіду роботи з тестерами, прочитайте перші кілька розділів "Тестування програмного забезпечення комп'ютера" Джема Канера, щоб відчути види термінів, які ви хочете почути: граничне тестування, тестування помилок, тестування щасливого шляху, функціональне, продуктивність, безпека, інтеграція тощо. Якщо ви не зможете розмовляти мовою, ви не зможете провести хороше інтерв'ю.
Дайте їм специфікацію для невеликого фрагмента вашої системи. Попросіть їх перевірити. Ви шукаєте організацію думки та їх здатність придумувати цікаві тести. Ви хочете, щоб вони впорядковано розбивали ділянки тестування, а потім детально вивчали кожну область, розробляючи все більш цікаві тестові справи. Дійсно хороші тестери можуть це робити годинами з усіма, крім самих тривіальних проблем, тому вам може знадобитися вирішити їх і змусити їх перейти до іншої категорії, щоб мати гарне відчуття того, як вони думають.
Опишіть поведінку, спричинену справжньою помилкою у вашій системі, яку було важко зрозуміти. Запитайте їх, що вони будуть робити, якби під час тестування побачили цю помилку. Тут ви шукаєте зменшення помилок - можливість знайти найпростіший набір обставин, здатних відтворити помилку. Це робить налагодження набагато простішим для розробників, оскільки вони краще здогадуються про те, що спричинило проблему, і демонструють чітку здатність вирішувати проблеми та чітке розуміння того, які фактори можуть взаємодіяти, викликаючи помилки. З вашим конкретним продуктом обговорення стану гонки може бути цікавим.
Дайте їм просту програму командного рядка, яку ви зламали разом (можливо, посіяли помилки) та просту специфікацію, і дозвольте їм сісти за комп'ютер і пограти з ним, з метою пошуку проблем. Тут ви шукаєте творчість та вміння орієнтуватися на проблемні місця. Вони повинні перевірити такі речі, як великі входи, невеликі входи, дивні входи, порожні входи. Якщо вони виявили помилку, попросіть їх спробувати і зрозуміти, коли саме ця помилка станеться (знову ж таки, зменшення помилки!).
Запитайте у них, що вони будуть робити, якщо SDE відповість на помилку за допомогою "No Repro" або "Won't Fix", якщо вони вважають, що помилка є важливою. Тут ти шукаєш когось, хто не буде просто поштовхом, але також не буде антагоністичним. Доцільні відповіді включають додавання прикладних сценаріїв, які чіткіше демонструють серйозність помилки, а потім повторно відкривають квиток, розмовляють з розробником, щоб спробувати зрозуміти, чому все вирішено таким чином перед закриттям тощо.
Поговоріть з ними про вашу заявку на високому рівні. Запитайте їх, які види тестування вони хотіли б виконати. Тут ви шукаєте загальні сфери тестування, як тестування функціональних компонентів, тестування інтеграції, тестування продуктивності, тестування безпеки.
Якщо це інженер SDET / автоматизації, дайте їм кілька запитань щодо співбесіди для розробників, які мають приблизно 1/3 до половини їхнього загального років досвіду.
Якщо це ваша перша особа із забезпечення якості, переконайтеся, що вона може самозапуститися. Запитайте їх, як вони уявляють собі перший тиждень на місяць роботи. Вони повинні сказати щось про збір вимог та налаштування інструментів, а потім описати розумний підхід до початку тестування. Ви шукаєте когось, кому не потрібен начальник, який підкаже їм, як розпочати тестування та вміти самостійно керувати. Якщо у вас вже є персонал із забезпечення якості, це менш важливо.
Що я роблю, коли опитував кандидатів з якості, - це попросити їх скласти стратегію тестування програми. Зазвичай я даю їм телефон і вибираю додаток з обмеженими можливостями - або дозволяю їм вибрати щось, з чим вони більш знайомі. Коли вони перераховують стратегію високого рівня (деякі не можуть), я можу попросити їх деталізувати та перелічити кілька тестових випадків.
Після закінчення я можу дати їм сценарій, коли у нас обмежені ресурси, і подивитися, як вони визначають пріоритети.
Я також запитую їх, коли програмне забезпечення достатньо добре для доставки, як вирішувати ситуації, коли PM або Dev не відчувають помилок, але це важливо. Типові сценарії розробки продукту.
Це для не кодуючих QA-позицій. Кодування позицій QA я даю їм комбі-інтерв'ю для розробників / тестів.
Запитайте їх, як вони склали б тестові плани. Запитайте їх, чи мають досвід використання регресійного тестування, і як вони це зробили, якщо так. Запитайте їх, як вони проходять тестування користувальницького інтерфейсу. Запитайте їх, як би вони пройшли тестування імпорту даних, які не проходять через користувальницький інтерфейс (якщо ви робите такі речі). Запитайте їх, як вони повідомлять свої проблеми розробникам та як вони перевірять на вирішення проблеми. Я б запитав їх про найцікавішу (або найскладнішу) помилку, яку вони знайшли, і як вони її знайшли.
Перш ніж почати співбесіду, знайдіть книжки про тестування та трохи погляньте на те, що повинна робити людина, що займається питаннями якості. Це допоможе оцінити їх відповіді.
Далі ви також шукаєте гарну форму особистості. Ви не хочете, щоб людина, яка перебуває у сфері якості, була поштовхом, але ви також не хочете хулігана або ривця. Але ви хочете, щоб хтось протистояв керівництву, коли все не так, а не просто схвалювати все, тому що керівництво хоче дотриматись терміну. Ви хочете, щоб хтось працював з розробниками ефективно і хто розумів вимоги тестування. Хтось із типом програми в тестовому додатку, який ви тестуєте, може бути хорошим. Тестер із досвідом охорони здоров’я знатиме речі для перевірки того, що хтось, хто приїжджає з іншої галузі, може не знати.
Я думаю, ви не можете очікувати, що вони будуть мати якісь серйозні знання про технологію - той, хто має, швидше за все, відмовиться працювати як приземлений тестер.
Найкраще, що ви можете зробити, це шукати загальні речі, такі як увага до деталей, допитливий розум, захоплення експериментами тощо.