Головна мета цієї статті - допомогти подолати страх, який виникає у тестувальників ПЗ (як початківців, так і досвідчених) до майбутнього інтерв'ю у зв'язку з незнанням майбутнього.
Другорядна мета - зібрати воєдино основні питання, які, найімовірніше, будуть поставлені на співбесіді. Як у початківця тестувальника, у мене вже накопичився певний досвід підготовки до співбесід на дану посаду, і я можу зауважити, що навіть спеціалізовані QA форуми не справляються з цією метою, а може і не ставлять її перед собою взагалі.
Перелік питань зрозуміло не остаточний і не претендує на зразковість, а виступає лише своєрідним орієнтиром при підготовці фахівців з тестування ПЗ.
Власне питання:
- Поясніть термін «життєвий цикл програмного забезпечення».
Життєвим циклом програмного забезпечення (SLC) є період часу, що починається з моменту появи концепції ПЗ і закінчується тоді, коли використання ПЗ більш неможливе. Життєвий цикл програмного забезпечення зазвичай включає в себе наступні етапи: концепт, опис вимог, дизайн, реалізація, тестування, інсталяція та налагодження, експлуатація та підтримка і, іноді, етап виведення з експлуатації. Дані фази можуть накладатися один на одного або проводитися ітераційно.
- Поясніть термін «життєвий цикл розробки програмного забезпечення».
Життєвим циклом розробки програмного забезпечення (SDLC) є концепція, яка описує комплекс заходів, що виконуються на кожному етапі (фазі) розробки програмного забезпечення.
- Поясніть перевагу використання моделі життєвого циклу розробки ПЗ (SDLC).
- забезпечення основи проекту (методології, активність...);
- забезпечення візуалізації ходу реалізації проекту;
- допомога компанії в ефективності та успішного завершення проекту (скорочення витрат, зменшення термінів розробки та тестування, підвищення якості кінцевого продукту);
- зменшення ризиків, пов'язаних з процесом розробки ПЗ;
- забезпечення спеціальним механізмом відстеження прогресу проекту.
- Які основні фази моделі життєвого циклу розробки ПЗ?
- Прийняття рішення (ідея) про необхідність створення ПЗ;
- Збір та аналіз вимог;
- Дизайн (Системи та ПЗ) на основі вимог;
- Кодування на основі дизайну системи;
- Тестування;
- Впровадження в середовище користувача;
- Супровід (у тому числі фіксація знайдених у користувацькому середовищі помилок);
- Вилучення з експлуатації (рідко);
- Поясніть, що таке Забезпечення якості (Quality Assurance)?
Забезпечення якості (QA) - це сукупність заходів, що охоплюють всі технологічні етапи розробки, випуску та експлуатації ПЗ і вживаються на різних стадіях життєвого циклу ПЗ, для забезпечення необхідного рівня якості продукту, що випускається.
Забезпечення якості визначено у стандарті ISO 9000:2005 "Системи менеджменту якості. Основні положення і словник "як" частина менеджменту якості, спрямована на створення впевненості в тому, що вимоги до якості будуть виконані ".
Менеджмент якості в цьому ж стандарті представлений як «скоординована діяльність з керівництва та управління організацією стосовно якості», а в примітці сказано, що він «зазвичай включає розробку політики і цілей в області якості, планування якості, управління якістю, забезпечення якості та поліпшення якості».
- Поясніть, що таке Контроль якості (Quality Control)?
Контроль якості (QC) - це сукупність дій, що проводяться над ПЗ у процесі розробки, для отримання інформації про його актуальний стан в аспектах готовності до випуску, відповідності зафіксованим вимогам та відповідності заявленому рівню якості цього ПЗ.
- Поясніть, що таке тестування ПЗ?
Тестування ПЗ - це процес, що містить в собі всі активності життєвого циклу, як динамічні, так і статичні, що стосуються планування, підготовки та оцінки програмного продукту і пов'язаних з цим результатів робіт з метою визначити, що вони відповідають описаним вимогам, і показати, що вони підходять для заявлених цілей і для визначення дефектів.
З цього визначення стає зрозуміло, що тестування ПЗ включає в себе два різні процеси:
Валідація (validation): доведене об'єктивними результатами дослідження підтвердження того, що вимоги для конкретного певного використання додатку були виконані. [ISO 9000]
Верифікація (verification): доведене об'єктивними результатами дослідження підтвердження того, що певні вимоги були виконані. [ISO 9000]
- Які основні цілі тестування ПЗ?
Мета тестування (test objective, test target) - це причина або мета розробки та виконання тесту.
Основні цілі:
- забезпечити очищення ПО від помилок (Ви не можете надати 100% покриття, але Ви повинні зробити все можливе, і гарантувати, що очевидні помилки виправлені);
- переконати, що ПЗ відповідає оригінальним вимогам і специфікації;
- забезпечити впевненість у ПЗ (користувачам, замовникам тощо).
- Коли слід починати тестувати ПЗ?
Проста відповідь - як тільки це можливо! Більш детально:
- коли тестування ПЗ проводиться на ранній стадії, ви можете з легкістю вплинути на дизайн, оскільки його зміна на цій стадії не настільки дорога ніж на більш пізніх стадіях;
- у свою чергу, чим раніше виявляється помилка, тим дешевше вона коштує компанії;
- також тестування може починатися до фактичного отримання ПЗ (статичне тестування), що дійсно важливо, оскільки знижує складність проводження динамічної стадії тестування. Існує думка, що багато помилок, які знайдені в стадії динамічного тестування, могли і повинні були зафіксовані в стадії статичного тестування;
- тестування на ранніх стадіях (вивчення вимог, специфікацій, бізнес випадків тощо) забезпечить тестувальнику більше знань про ПЗ, допоможе виявити логічні та технічні помилки, які б впливали на ПЗ, його кінцевий дизайн і вартість.
- Коли слід закінчувати тестування ПЗ?
Проста відповідь - управлінське рішення, яке найімовірніше буде прийнято на основі:
- тестового покриття;
- аналізу ризиків;
- погіршення тестування.
Більш детальному вивченню даного питання допоможе найкрутіша стаття Майкла Болтона в його блозі з різними там евристиками «піньяти» і «мертвого коня».
- Які основні рівні тестування ПЗ?
- Компонентне (component )/модульне тестування (module, unit testing) - це тестування окремих компонентів ПЗ [IEEE 610];
- Інтеграційне тестування (integration testing) - це тестування, виконуване для виявлення дефектів в інтерфейсах і у взаємодії між інтегрованими компонентами або системами.
Слід також розуміти що таке big-bang тестування, тестування «зверху вниз», що сходять та інкрементне тестування;
- Системне тестування (system testing) - це процес тестування системи в цілому з метою перевірки того, що вона відповідає встановленим вимогам;
- Приймальне тестування (acceptance testing) - це формальне тестування щодо потреб, вимог і бізнес процесів користувача, що проводиться з метою визначення відповідності системи критеріям прийомки (критерії виходу, яким повинні відповідати компонент або система, для того, щоб бути прийнятими користувачем, замовником або іншою уповноваженою особою) [IEEE 610], з чого слідують такі види, про які бажано не забувати:
- користувацьке приймальне тестування (user acceptance testing);
- виробниче приймальне тестування (factory acceptance testing) - це приймальне тестування, що проводиться на боці розробника програмного продукту і проводиться співробітниками компанії-постачальника з метою визначити, відповідає чи ні компонент або система як програмним, так і апаратним вимогам;
- стороннє приймальне тестування (site acceptance testing) - це приймальне тестування користувачами або замовником на своєму боці. Проводиться з метою визначити як відповідність бізнес-процесу, так і впевнитися, що дана система або компонент задовольняє потребам користувачів або замовника. Зазвичай включає в себе перевірку як програмного забезпечення, так і технічної бази;
- експлуатаційне приймальне тестування (operational acceptance testing) - це експлуатаційне тестування у фазі приймального тестування, що зазвичай виконується користувачем та/або співробітниками з адміністраторським доступом, у робочому середовищі (можливо, симульоване), фокусуючись на функціональних аспектах (відновлюваність, поведінка ресурсів, встановлюваність та технічна відповідність).
- Альфа-тестування (alpha testing) - це модельоване або дійсне експлуатаційне тестування потенційними користувачами/замовниками або незалежною командою тестування на боці розробників, але поза розробною організацією. Альфа-тестування часто застосовується до коробкового ПЗ як внутрішнє прийомне тестування;
- Бета-тестування (beta testing) - це експлуатаційне тестування потенційними та/або існуючими клієнтами/замовниками на зовнішній стороні ніяк не пов'язаними з розробниками, з метою визначення чи дійсно компонент або система задовольняє вимогам клієнта/замовника і вписується в бізнес-процеси. Бета-тестування часто проводиться як форма зовнішнього прийомного тестування готового програмного забезпечення для того щоб отримати відгуки ринку;
- Що таке критерії входу?
Критерії входу (entry criteria) - це набір загальних і специфічних умов для продовження процесу з певним завданням, наприклад, фаза тестування. Мета критеріїв входу - запобігання початку завдання, яке може вимагати більше (марних) зусиль, ніж на усунення не пройдених критеріїв входу.
Простіше кажучи для Вас, як майбутнього тестувальника, критерії входу слід розуміти як основні умови, які мають бути виконані до того, як Ви та Ваша команда можуть розпочати тестування.
- Наведіть кілька прикладів, які пояснюють критерії входу для тестування ПЗ.
- всі дефекти, які відносяться до ранніх стадій (проектування) закриті і перевірені;
- код перевірений за допомогою здійснення «Unit» тестів;
- основні функціональні можливості ПЗ готові для тестування;
- є документація, яка визначає вимоги;
- всі тестувальники ознайомлені з архітектурою ПЗ;
- всі тестувальники ознайомлені з цілями проекту;
- готове середовище тестування;
- доступні для використання білди;
- затверджено план тестування та/або тестові випадки.
- Що таке критерії виходу?
Критерії виходу (exit criteria) - це набір загальних і специфічних умов, узгоджених заздалегідь із зацікавленими сторонами, для того, щоб процес міг офіційно вважатися завершеним. Мета критеріїв виходу - запобігання можливості, коли завдання вважається завершеним, проте ще існують окремі незавершені частини завдання. Критерії виходу використовуються для звітності, а також планування того, коли зупинити тестування.
Простіше кажучи, як критерії входу визначають початок тестування, так і критерії виходу визначають його закінчення і ПЗ готове до наступного етапу життєвого циклу (впровадження тощо).
- Наведіть кілька прикладів, які пояснюють критерії виходу для тестування ПЗ.
- всі заздалегідь зумовлені області ПЗ як «ризикові» протестовані і такий статус знижений/видалений;
- всі помилки ретельно задокументовані і доведені менеджменту/акціонерам/замовникам;
- всі тести з високим пріоритетом пройдені і відповідно позначені як «Pass»;
- всі вимоги документації SRS (Специфікація вимог ПЗ);
- STR затверджено власником проекту;
- протестована архітектура ПЗ;
- жодна серйозна або критична помилки не залишаються відкритими;
- 90-95% всіх тестів зроблено.
- Наведіть декілька інструментів, які можуть використовуватися для автоматизації тестування.
- внутрішні інструменти автоматизації;
- серія програмних продуктів Selenium;
- MS VS;
- JUnit;
- Test Complete;
- LoadRunner;
- Testing Аnywhere;
На додаток - результати крутого опитування з автоматизованого тестування.
- Як ви поясните Bug/Defect/Error в ПЗ?
Будь-яка проблема/помилка в ПЗ, що викликана наступною поведінкою:
- поломка ПЗ або відображення недійсного повідомлення;
- ПЗ надає недійсні результати;
- ПО не вдалося виконати, як очікувалося (будь-яке відхилення від очікуваних результатів).
- Поясніть процес верифікації.
Реальне питання, на яке ми шукаємо відповідь: чи будуємо ми продукт правильно?
Процес верифікації (verification) виконується, щоб переконатися, що кожен етап життєвого циклу розробки ПЗ (розробка, тестування тощо) будується на основі зумовлених вимог (requirements) і специфікацій (specifications) і без будь-яких відхилень від них. (див. № 7)
- Опишіть різні заходи процесу верифікації.
- аналіз різних аспектів тестування (терміни, ресурси, персонал, вартість, інструменти тестування тощо);
- покриття операторів (statement coverage) - процентне відношення операторів, виконуваних набором тестів, до їх загальної кількості; покриття умов (condition coverage) - відсоток результатів умов, які були перевірені набором тестів. 100% покриття умов вимагає, щоб кожна окрема умова в кожному вираженні рішення була перевірена як Істина і Ложь; покриття альтернатив (decision coverage) - відсоток результатів альтернативи, який був перевірений набором тестів. Стовідсоткове покриття рішень передбачає стовідсоткове покриття гілок і стовідсоткове покриття операторів;
- рецензування (review) - це оцінка стану продукту або проекту з метою встановлення розбіжностей із запланованими результатами і для висунення пропозицій щодо поліпшення. Прикладами рецензування можуть служити: управлінське рецензування, неформальне рецензування, технічний аналіз, інспекція та розбір;
- розбір (walkthrough) - це покроковий розбір, що проводиться автором документа для збору інформації та забезпечення однакового розуміння змісту документа;
- інспекція (inspection) - це тип рівноправного аналізу, заснований на візуальній перевірці документів для пошуку помилок. Наприклад, порушення стандартів розробки та невідповідність документації більш високого рівня. Найбільш формальна методика рецензування і тому завжди ґрунтується на документованій процедурі.
- Наведіть приклади верифікації залежно від рівнів тестування. (див. № 11)
- Модульне тестування (unit testing):
-перевірка здійснення проектування програмного забезпечення.
- Інтеграційне тестування (integration testing):
-тестування на інтеграцію між усіма відповідними компонентами до того як ПЗ перейде до наступного рівня (system).
- Системне тестування (system testing):
-забезпечення відповідності системи зумовленим вимогам і специфікації.
- Приймальне тестування (acceptance testing):
- Заберіться, що система відповідає вимогам клієнта.
- Поясніть процес валідації.
Реальне питання, на яке ми шукаємо відповідь: чи будуємо ми правильний продукт?
Процес, що дозволяє тестувальнику оцінити ПЗ після стадії розробки до передачі його замовнику. У цьому процесі ми повинні переконатися, що ПЗ розроблено на основі потреб користувачів.
Пам "ятайте, валідація охоплює динамічну сторону тестування, де визначене ПЗ тестується та оцінюється всупереч заданій SRS документації.
- Наведіть кілька причин, які призводять до багів у ПЗ.
- людські помилки (процес проектування і процес реалізації);
- зміна вимог у той час як ПЗ під випробуванням;
- нерозуміння вимог і специфікацій;
- відсутність часу;
- погана приоритизація тестування;
- погана орієнтація у версіях ПЗ;
- складність самого ПЗ.
- Що таке процедура тестування (Test Procedure)?
Документ, який описує послідовність дій під час виконання тесту. Також відомий як ручний сценарій тестування.
- Що таке програмний компонент?
В основному, програмні компоненти - це дрібні айтеми ПЗ, які побудовані з ще дрібних одиниць, які в свою чергу інтегровані разом (класи, методи, збережені процедури, бінарні дерева тощо).
- Поясніть Покриття коду.
Покриття коду (code coverage) - це метод аналізу, що визначає, які частини ПЗ були перевірені (покриті) набором тестів, а які ні, наприклад, покриття операторів, покриття альтернатив або покриття умов.
- Поясніть Інспекцію коду.
Інспекція коду (code inspection) або перегляд коду (code review) - це систематична перевірка вихідного коду програми з метою виявлення і виправлення помилок, які залишилися непоміченими в початковій фазі розробки. Метою перегляду є поліпшення якості програмного продукту та вдосконалення навичок розробника.
У процесі інспекції можуть бути знайдені і усунені такі проблеми, як помилки у форматуванні рядків, стан гонки (race condition), витік пам'яті (memory leak) і переповнення буфера (buffer overflow), що покращує безпеку програмного продукту. Системи контролю версій дають можливість проведення спільної інспекції коду. Крім того, існують спеціальні інструментальні засоби для спільної інспекції коду.
Програмне забезпечення для автоматизованої інспекції коду спрощує завдання перегляду великих шматків коду, систематично скануючи його на предмет виявлення найбільш відомих вразливостей.
- Що означає фраза Код завершено?
Простий термін, що має відношення до конкретного етапу SDLC. Говорячи «код завершено», ми насправді маємо на увазі, що його реалізація завершена (вся функціональність ПЗ успішно реалізована). Хоча якщо навіть код буде повністю реалізований, завжди є нові помилки виявлені під час тестування.
- Що таке розбір (walkthrough) коду?
Розбір (walkthrough) - це методика тестування, що використовується для огляду ходу здійснення коду програмістом і командою тестування, під час розбору код виконується за допомогою декількох простих тестів, щоб визначити його якість і логіку.
- Що таке зневадження?
Зневаджування (debugging) - це процес пошуку, аналізу, і усунення причин відмов і помилок в ПЗ.
Щоб зрозуміти, де виникла помилка, доводиться:
- дізнаватися поточні значення змінних;
- з'ясовувати, яким шляхом виконувалася програма.
Існують дві взаємодоповнюючі технології налагодження.
- Використання зневаджувачів - програм, які включають користувацький інтерфейс для покрокового виконання програми: оператор за оператором, функція за функцією, з зупинками на деяких рядках вихідного коду або при досягненні певної умови.
- Вивід поточного стану програми за допомогою критичних точок програми операторів виводу - на екран, принтер, гучномовець або у файл. Вивід зневаджувальних відомостей до файлу називається журналом.
- Що таке емулятор і симулятор?
Емуляція - це відтворення роботи програми або системи (а не якоїсь її мізерної частини) із збереженням ключових її властивостей і принципів роботи. Емуляція виконує програмний код у звичному для цього коду середовищі, що складається з тих же компонентів, що і емулюваний об'єкт.
Симуляція - це відтворення роботи програми-оригіналу суто віртуально, на движку спеціальної програми (засіб розробки курсів, наприклад). Симуляція лише імітує виконання коду, а не копіює його, все віртуально на 100%, все «понарошку».
Отже:
Емулятор ПЗ - це повнофункціональний аналог оригінального ПЗ, або його версія, в якій може бути передбачена низка обмежень щодо функціоналу, можливостей і поведінки ПЗ.
Симулятор ПЗ - це модель оригінального ПЗ, в якій реалізується логіка роботи цього ПЗ (частково або повністю), імітується поведінка ПЗ, копіюється його інтерфейс.
Симулятор по повноті функцій/враховуваних параметрів вже, ніж емулятор. Емулюється об'єкт, а його властивості, функції або поведінка симулюються.
- Що таке специфікація ПЗ?
Специфікація (specifications) - це текстовий файл з описом того, що потрібно протестувати в тестових даних. У ній вказується які результати має отримати програма. Тестовий код знаходить реальні, вирахувані на живому коді результати. А тестовий движок проводить звірку специфікації та обчислених результатів.
Специфікацію отримуємо від замовника проаналізувавши, дослідивши його вимоги і перевівши їх на якісно новий, більш деталізований рівень, на якому ними і буде користуватися команда розробника.
- Що таке кодування?
Кодування (coding) - це процес написання програмного коду, скриптів, з метою реалізації певного алгоритму певною мовою програмування.
Деякі плутають такі поняття, як програмування і безпосередньо кодування. Кодування є лише частиною програмування, поряд з аналізом, проектуванням, компіляцією, тестуванням і зневадкою, супроводом (У вузьких колах кодування також може називатися «кодинг». Однак, якщо вірити Вікі, в літературі цей термін використовується рідко.).
- Що таке вимога?
Вимога (requirement) - сукупність тверджень щодо атрибутів, властивостей або якостей програмної системи, що підлягає реалізації. Створюються в процесі розробки вимог до програмного забезпечення, в результаті аналізу вимог.
Вимоги можуть виражатися у вигляді текстових тверджень та графічних моделей.
У класичному технічному підході сукупність вимог використовується на стадії проектування програмного забезпечення (ПЗ). Вимоги також використовуються в процесі тестування ПЗ, оскільки тести ґрунтуються на певних вимогах.
Етапу розробки вимог, можливо, передувало техніко-економічне обґрунтування, або концептуальна фаза аналізу проекту. Фаза розробки вимог може бути розбита на виявлення вимог (збір, розуміння, розгляд та з'ясування потреб зацікавлених осіб), аналіз (перевірка цілісності та закінченості), специфікація (документування вимог) та перевірка правильності.
- Що таке тестування стабільності?
Завданням тестування стабільності (stability )/надійності (reliability) є перевірка працездатності додатка при тривалому (багатогодинному) тестуванні із середнім рівнем навантаження. Час виконання операцій може відігравати в даному виді тестування другорядну роль. При цьому на перше місце виходить відсутність витоків пам'яті, перезапусків серверів під навантаженням та інші аспекти, що впливають саме на стабільність роботи.
- Розкажіть про критичність (серйозність) бага і загальноприйняті рівні такої критичності.
Критичність (severity) - це важливість впливу конкретного дефекту на розробку або функціонування компонента або системи.
Критичність помилки визначається тестувальником, який виявив порожній, але перед цим він повинен відповісти собі на такі запитання:
- Як ця помилка впливатиме на процес тестування?
- Як ця помилка впливатиме на клієнта?
- Як ця помилка впливає на систему?
- Як ця помилка впливає на терміни тестування?
- Чи блокує ця помилка інші тести?
- І т. д.
Кожна компанія може визначити свою власну шкалу для ступеня критичності (серйозності), але є кілька рівнів, які використовуються майже всіма командами:
- Blocker/show-stopper (блокування) - ПЗ або конкретний компонент не підходить для використання/тестування (повна відмова, краш системи тощо) і немає обходу.
Приклади: система впаде, коли користувач натискає кнопку «Пуск»; система не запускається після пошкодження інсталятора; відключення ПО, викликане апаратними збоями.
- Critical (критичний) - головна функціональність не працює як треба, є обхідний шлях, який може вплинути на цілісність випробувань.
Приклад: ПЗ може рандомно фарбуватися, використовуючи різні функціональні можливості; ПЗ виробляє суперечливі результати, основні вимоги не вдається підтвердити.
- Major (важливий) - поразка незначних функціональностей, немає впливу на інші компоненти, і є швидкий і діючий обхід.
Приклад: Користувач не може використовувати певну функціональність безпосередньо, але може використовувати її ж, скориставшись доступом до неї з різних додатків.
- Minor (другорядний, незначний) - незначний вплив на певному місці, немає необхідності створювати обхідний шлях, цілісність ПЗ не порушена.
Приклади: помилки правопису, покращення, запит на зміну
- Розкажіть про пріоритет бага.
Пріоритет (priority) - це ступінь важливості, що присвоюється багу. Іншими словами визначається, наскільки терміново це помилка повинна бути виправлена.
Пріоритет - інструмент менеджменту, і перед його визначенням останній повинен відповісти мінімум на такі запитання:
- Як це впливає на терміни?
- Як це впливає на процес тестування?
- Як він впливає на роботу інших тестувальників?
- Які витрати потрібні для усунення бага?
- Чи повинні ми змінити вимоги до ПЗ?
- Що таке Збірка?
Збірка (build) - підготовлений для використання інформаційний продукт. Найчастіше це виконуваний файл (двоїчний файл, що містить виконуваний код програми).
Припустимо, що номер версії збірки виглядає так: 1.35.6.2
- Перший ідентифікатор - основний номер версії.
- Другий ідентифікатор - додатковий номер версії.
- Третій ідентифікатор - номер збірки.
- Четвертий ідентифікатор - номер редакції.
- Чи можна починати тестування без робочого складання?
Безумовно - так! Адже існує два типи методології тестування (статичне та динамічне), які дозволяють тестувальнику починати працювати без робочого складання статичним методом, тим більше такий метод більш рентабельний ніж «динамічний».
- Що таке статичний аналіз?
Статичний аналіз (static analysis) - це аналіз прогру