FAQ
Нижче наведено найпоширеніші запитання спільноти Guru99
- Не бачите відео?
- Я не отримав електронну пошту для проекту
- Якщо я отримав помилку в програмі, хто визначить серйозність і пріоритет помилки?
- Що ви будете робити, якщо немає Funct.Spec/будь-яких документів, пов’язаних із системою?
- Що може зробити тестувальник, якщо він виявить проблему з припиненням показу за кілька днів до випуску?
- Чому ви обираєте сферу забезпечення якості програмного забезпечення?
Не бачите відео?
Усі відео на цьому сайті розміщені на YouTube і вбудовано тут...
Ви ймовірно доступ до веб-сайту з місця, де YouTube заборонено (ваша компанія, коледж або країна, де YouTube під забороною)
Спробуйте отримати доступ до відео з необмеженого середовища.
Це можна зробити $NOT для перегляду відео необхідно зареєструватися.
Я не отримав електронну пошту для проекту
Зверніть увагу, що електронні листи про проекти надсилаються з інтервалом у 24 години. Отже, якщо ви підписалися о 10:10 четверга, ви отримаєте наступний електронний лист о XNUMX:XNUMX у п’ятницю.
Будь ласка, перевірте свій небажаний або спам Mailкоробка. Якщо ви використовуєте gmail, перевірте Promotions Tab
Наша система не має функції повторного надсилання електронних листів. Якщо ви все ще не можете відстежити електронні листи, підпишіться з іншим ідентифікатором електронної пошти, щоб отримати вміст.
Якщо я отримав помилку в програмі, хто визначить серйозність і пріоритет помилки?
Серйозність Дефект визначається особою, яка ідентифікує проблему (тестером), тоді як пріоритет визначається особою, яка бере участь у вирішенні проблеми (розробниками).
Як тестер, ви можете визначити пріоритетність дефектів, які зазвичай перевіряє провідний тестувальник. Розробники після аналізу вирішать, чи є це дефект високого чи низького пріоритету. У більшості випадків це робить розробник, але тестувальник також може залучитися до цього, щоб пояснити його серйозність. Після обговорення лідери прийдуть до висновку.
Рівень серйозності в основному пов’язаний із функціональністю програми чи продукту. Хоча пріоритетом є те, як негайно розробник може виправити цю помилку чи дефект. Пріоритет має динамічний характер і змінюватиметься відповідно до сценарію, тоді як серйозність має статичну природу.
Що ви будете робити, якщо немає функціональних специфікацій/будь-яких документів, пов’язаних із системою?
- Спочатку спробуйте зрозуміти сферу діяльності з бізнес-аналітиками або представниками малого та середнього бізнесу. Проведіть пошукове тестування, щоб зрозуміти систему.
- Якщо в проекті немає Бізнес-аналітик або МСП, поговоріть з людьми, які працювали над подібними системами.
- Щоб зрозуміти бізнес, поговоріть із спільнотою користувачів
- Дізнайтеся схожу специфікацію продукту в Інтернеті або в PMO
- Шукайте прикладне програмне забезпечення такого ж типу та ознайомтеся з функціями
- Шукайте кілька важливих бізнес-сценаріїв, альтернативних документів, статей для тем програми
- Запитуйте роз'яснення щодо всіх модулів у розробників
- Історія користувачів, програми та функції
- Не тестуйте програму технічно, спочатку перевірте свою програму лише з точки зору користувача
Що може зробити тестувальник, якщо він виявить проблему з припиненням показу за кілька днів до випуску?
- Підтвердьте та ще раз підтвердьте Дефект і задокументуйте помилку або дефект, вплив і можливе рішення, якщо можете.
- Зверніть на це увагу свого менеджера та обговоріть з командою, оскільки таке шоу-стопування невідоме команді за тиждень до його випуску – це погано.
- Коли Дефект дійде до вашого керівника та вищих органів тестування, можливо, вам доведеться висловити їм свою точку зору, тому будьте ретельні, оскільки це може вплинути на випуск.
- Якщо дискусія підтримує вас, настав час піднятися та сяяти. Якщо ні, у вас є урок, який ви засвоїли на цей день. Продовжуйте вчитися.
Чому ви обираєте сферу забезпечення якості програмного забезпечення?
Щоб надати якісні проекти кінцевим користувачам або клієнтам, тестування є обов’язковим, незалежно від кодування, яке воно передбачає. Програмне забезпечення якості не тільки реєструє помилки, але й надає рішення для цих помилок.
У сфері забезпечення якості тестувальники повинні бути обізнані про всі функціональні можливості програми, що тестується, це дає йому змогу знати про різні типи програм, розроблених у різних середовищах, навіть деякі базові концепції програмування. Знання будуть ширшими, коли ми проводимо тестування, але вони будуть вузькими під час програмування. Розробник може розробляти лише невеликий сегмент усієї програми та не знати про програму в цілому. У цьому випадку я відчув, що роль QA (тестера) більш цікава.