Треба розповісти що вам подобається та чим ви займаєтесь

Розкажіть про вашу мотивацію з якою ви рухаєтесь до посади тестувальника

Процес, де ми досліджуємо програму чи документацію цієї програми з певною метою (знайти баг, підтвердити, що продукт готовий до релізу тощо).

• Виявити дефекти до того, як їх виявлять користувачі.
• Надання актуальної інформації про стан продукту зараз.
• Перевірка на відповідність ПЗ всім заявленим вимогам.

• Testing shows the presence of defects, not their absence (Тестування демонструє наявність дефектів, але не гарантує їх відсутності).
• Exhaustive testing is not possible (Вичерпне тестування неможливе).
• Early testing saves time and money (Тестування слід починати на ранніх стадіях життєвого циклу розробки програмного забезпечення, щоб знайти дефекти якомога раніше).
• Defects cluster together (Накопичення дефектів. Принцип Паретто: для багатьох явищ 80 відсотків наслідків спричинені 20 відсотками причин).
• Beware of the pesticide paradox (Парадокс пестициду. Якщо повторювати ті самі тести знову і знову, то в певний момент цей набір тестів перестане виявляти нові дефекти).
• Testing is context dependent (Тестування залежить від контексту).
• Absence of errors is a fallacy (Відсутність знайдених дефектів під час тестування не завжди означає готовність продукта до релізу).

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

(Пам'ятаємо про принцип №3 – раннє тестування (Early testing)).

Software development lifecycle – період часу, який починається з моменту ухвалення рішення про необхідність створення програмного продукту та закінчується в момент його повного вилучення з експлуатації.

• Планування та аналіз вимог
• Написання вимог
• Дизайн архітектури продукту
• Розробка продукту (програмування)
• Тестування продукту
• Розгортання продукту (реліз)
• Супровід

Entry criteria (критерії входу в тестування) визначають умови, які мають бути виконані до початку робіт. Наприклад, визначені вимоги, графік, встановлено програму, що тестується.

Exit criteria (критерії виходу з тестування) визначають, які умови мають бути виконано, щоб завершити рівень тестування або набір тестів. Наприклад, закрито всі завдання і баг репорти, досягнуто певного відсотку пройдених тестів.

Quality Assurance (QA) – QA забезпечує правильність процесу тестування, підходить до контролю якості глобально, стежить за нормалізацією процесів. (Займається тестуванням програми у всіх фазах життєвого циклу програмного забезпечення. Найбільше уваги в роботі приділяє процесам, але також займається тестуванням продукту.)

Quality Control (QC) – QC передбачає контроль за дотриманням вимог. (Займається тестуванням програми у фазах розробки та тестування. На роботі займається продуктом (додатком, сайтом).

• Waterfall
• V-модель
• Ітераційна, інкрементальна модель (відмінність: в ітераційній моделі ідея проєкту спочатку маленька, але потім з’являються додаткові функції. В інкрементальній моделі ідея проєкту від самого початку велика)
• Спіральна модель
• Модель хаоса
• Гнучка модель( Agile: Scrum, Kanban)

Waterfall Model – відома послідовним проходженням стадій, кожна з яких має завершитись повністю до початку наступної. 

Найчастіше використовується в медичних та військових проєктах. 

Переваги: вартість і дедлайни визначені заздалегідь; розробка відбувається швидко; хороший результат лише у проєктах із чітко та заздалегідь визначеними вимогами.

Недоліки: неможливо повернутись на попередню фазу або повторити фазу; неможливо змінити вимоги під час розробки.

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

Цінності Agile:

• Люди та співпраця важливіші за процеси та інструменти Працюючий продукт важливіший за вичерпну документацію Співпраця із замовником важливіша за обговорення умов
• контракту
• Готовність до змін важливіша за дотримання плану

Суть Agile маніфесту:

• Вся робота над проєктом розділяється на короткі цикли (ітерації) і ведеться поетапно;
• В кінці кожної ітерації замовник отримує готовий мінімально робочий продукт чи його частину, яку вже можна використовувати;
• Протягом всього робочого процесу команда співпрацює з замовником;
• Будь-які зміни в проєкті вітаються і швидко інтегруються в роботу.

Підхід передбачає взаємодію кожного етапу розробки ПЗ, як команди розробників (Delivery Team), а й самого замовника (Product owner), і навіть Scrum-майстра.

Суть даного фреймворку:

• Робота ділиться на спринти тривалістю 1-4 тижні
• Перед початком спринта команда сама формує список задач на ітерацію
• Під час кожного спринта створюється продукт чи послуга, які можна продемонструвати клієнту
• Після виконання спринту проводиться ретроспектива. Це мітинг, мета якого отримати фідбек від кожного учасника команди, виявити поточні успіхи та проблеми, тобто оцінка та аналіз виконаної роботи.
• Кожен наступний етап нарощуватиме функціонал проєкту, доки всі функції не будуть реалізовані.
• Мітинги, які допомагають в процесі роботи: Щоденний стендап, Планування, Ретроспектива та Sprint Review.
• Обов'язкові ролі: Scrum-master (допомагає вирішити блокери, слідкує за дотриманням скраму) та Product Owner (виставляє пріоритети і цілі спринта)

Software testing life cycle – це послідовність дій, які проводяться в процесі тестування, за допомогою яких гарантується якість ПЗ та його відповідність вимогам.

Етапи STLC циклу: 

• Планування
• Моніторинг і контроль
• Аналіз і дизайн
• Імплементація
  
• Виконання
  
• Репортинг
  
• Завершення тестування

1. Тест стратегія, тест план, тест полісі, вимоги, тест кейс, чек ліст, тест сьют, баг репорт, тест репорт (Test Run Result, тест самері репорт).

Це документ в якому описується що програма має робити і як. Види: software requirements specification, product requirement document, user stories, acceptance criteria.

Це неформальні вимоги, що пишуться в один рядок і складаються з трьох частин: “Як …, я хочу …, щоб …”. Також Юзер сторі - це формат завдання в Джирі, який має підзавдання.

Це інструкція з тестування, яка складається з кроків для відтворення та очікуваного результату.

Тестові дані, пріоритет, тип (категорія), номер, назва, preconditions, steps to reproduce, designer, дата створення, очікуваний результат. Можуть бути скріншоти. Може бути модуль до якого відноситься test case - test suite.

Це список, який скл з 3 колонок: ID кроку, назва,статус (passed, failed, blocked, in progress, skipped), тестові дані.

Чек ліст простіший, тест кейс об'ємний і детальніший.

Тестовий документ, який описує як буде відбуватись процес тестування.  

Описуємо як ми будемо тестувати, що будемо/не будемо тестувати, які рівні/техніки будемо використовувати. Описуємо ролі, обов'язки (roles and responsibilities), ризики та способи їх знизити. Entry, exit критеріїю. Графік, environment.

1. Тест план це документ який описує тестування на маленькому рівні: продукту, релізу, спринту, юніту, фічі. Стратегія описує тестування на рівні проєкта. Тест полісі- документ, який описує тестування на рівні організації. 

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

Невідповідність до вимог, недолік в програмі.

Баг-репорт-документ, який описує баг. Дефект - формальна назва багу.

Докладна покрокова інструкція для відтворення помилки

ID, назва, Preconditions, Steps, Actual/Expected result, Severity, Priority, Type, людина, які зробила цей баг-репорт, людина, яка має його виправити, статус, середовище, скріншоти, відео

Пріоритет - це як швидко треба виправити цей баг, і як він впливає на авторитет компанії. Северіті - ступінь впливу, показує наскільки баг ламає програму.

Не можливість перейти за посиланням в  інсту на якомусь веб сайті. Зазвичай якщо ми маємо високе severity, то і пріоритет теж буде високим або середнім. Бо такі баги це велика рідкість. 

New, Open, Assigned, In progress. Duplicate - якщо такий баг вже є. Deferred - якщо баг не терміновий, то його можна перенести на наступний спрінт. Fixed, verified (перевірено), reopened- якщо щось невірно пофіксили. Closed.

Шукати вимоги в Юзер Сторіз (завдання в Джирі), і там може бути опис задачі. Шукати в конфлюенсі. Пробувати гуглити. Якщо такого нема, спитати Продакт Овнера. Якщо його нема, то лишається здоровий глузд, аналіз конкурентів.

В останню чергу після гугла і конфлюенса. Спочатку питати колегу, потім якщо він не знає то ліда, потім продакт овнера.

Позитивне\негативне, мануальне\автоматизоване, статичне\динамічне, чорний\білий\сірий ящик, функціональне, нефункціональне і пов’язане зі змінами.

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

Validation - визначення відповідності розробленого ПО очікуванням та потребам користувача, вимогам до системи. (перевірка кінцевого результату. Чи вийшов продукт таким яким хотіли?)

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

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

Білий ящик - протилежність чорному, тобто є  доступ до коду, бази даних та документації АПІ.

Сірий ящик - щось середнє між чорним та білим. Не маємо доступ до коду, але є доступ до інших тех. областей. Яскравий приклад - тестування API використовуючи Postman.

Позитивне тестування - коли ми вводим валідні дані і очікуєм на хороший результат. Негативне - коли ми вводимо завідома не коректну інформацію і очікуєм на помилку.

Тільки одне поле заповнюєм негативнвою інформацією, всі інші - позитивними. Так легше локалізувати дефект.

Мануальне тестування - це тестування з використанням клавіатури і миші, а автоматизоване - це коли інженер написав код, який виконує тестування.

1. Component testing,
2. Integration testing,
3. System testing,
4. Acceptance testing

Перфрманс група (пов’язані з навантаженням): Load, Performance, Stress, Recovery, Volume, Scalability, Endurance etc.; UI, UX\Usability, Localization, Internationalization, Configuration

Smoke testing, Sanity testing (перекладається як “розсудливість”, на співбесідах не люблять коли кажуть “санітарне тестування” ), Regression testing,  Re-testing або Confirmation testing

Smoke - перевіряємо критично важливий шлях, функціонал. 

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

Smoke - перевіряємо критично важливий шлях, функціонал. Зазвичай вважається “поверхнім” тестуванням.

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

Регресія: Перевірка, чи новий код не порушив вже наявні функції. Тестування старого коду після внесення змін.

Реліз: Випуск нової версії програмного продукту для користувачів. Оновлення з новими функціями або виправленнями.

Code freeze: Зупинка внесення змін у вихідний код. Зазвичай перед релізом для стабілізації програми.

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

Що таке Monkey testing?

Monkey testing є методом тестування програмного забезпечення, при якому тестові дані та вхідні параметри генеруються випадковим чином без спеціального планування чи знань про внутрішню структуру програми. Цей метод також відомий як "random testing" або "fuzz testing".