ЧЗВ
Следват най-често задаваните въпроси от общността Guru99
- Не можете да видите видеоклипове?
- Не получих имейл за проекта
- Ако имам грешка в приложение, кой ще реши сериозността и приоритета на грешката?
- Какво ще направите, ако няма Funct.Spec/никакви документи, свързани със системата?
- Какво може да направи един тестер, ако открие проблем със спирането на шоуто няколко дни преди пускането?
- Защо избирате областта на осигуряване на качеството на софтуера?
Не можете да видите видеоклипове?
Всички видеоклипове на този сайт се хостват на YouTube и вграден тук...
Вие сте вероятно достъп до уебсайта от място, където YouTube е забранен (вашата компания, колеж или държава, в която YouTube е забранено)
Опитайте да получите достъп до видеоклиповете от неограничена среда.
Можете да направите НЕ трябва да се регистрирате, за да видите видеоклиповете.
Не получих имейл за проекта
Моля, имайте предвид, че имейлите за проекти се изпращат на интервал от 24 часа. Така че, ако сте се абонирали в 10:10 ч. в четвъртък, ще получите следващия имейл в XNUMX:XNUMX ч. в петък.
Моля, проверете своите нежелана поща или спам Mailкутия. Ако използвате gmail, проверете Promoции Tab
Нашата система няма функция за повторно изпращане на имейли. Ако все още не проследите имейлите, абонирайте се с друг имейл адрес, за да получите съдържанието.
Ако имам грешка в приложение, кой ще реши сериозността и приоритета на грешката?
Тежест на дефект се определя от лицето, което идентифицира проблема (тестер), докато приоритетът се определя от лицето, което участва в отстраняването на проблема (разработчици).
Като тестер можете да приоритизирате дефектите, които обикновено се преглеждат от водещия тест. Разработчиците след анализ ще решат дали това е дефект с висок или нисък приоритет. През повечето време се прави от разработчика, но тестерът може също да се включи в него, за да обясни сериозността му. След обсъждане, водещите ще стигнат до заключение.
Сериозността е основно свързана с функционалността на приложението или продукта. Въпреки че приоритетът е как незабавно разработчикът може да поправи тази грешка или дефект. Приоритетът е динамичен по природа и ще се променя според сценария, докато тежестта е статична по природа.
Какво ще направите, ако няма функционални спецификации/никакви документи, свързани със системата?
- Първо се опитайте да разберете домейна с бизнес анализатори или МСП. Направете проучвателно тестване, за да разберете системата.
- Ако проектът няма Бизнес анализатор или МСП, говорете с хората, работещи по подобни системи.
- За да разберете бизнеса, говорете с потребителската общност
- Намерете подобна продуктова спецификация от интернет или PMO
- Потърсете същия тип приложен софтуер и разберете функциите
- Потърсете някои важни бизнес сценарии, алтернативни документи, статии за теми за кандидатстване
- Поискайте обяснение за всички модули на разработчиците
- Потребителски исторически данни, приложение и функции
- Не тествайте приложението технически, първо тествайте приложението си само от потребителска гледна точка
Какво може да направи един тестер, ако открие проблем със спирането на шоуто няколко дни преди пускането?
- Потвърдете и потвърдете повторно Дефекта отново и документирайте грешката или дефекта, въздействието и възможното решение, ако можете.
- Обърнете внимание на това на вашия мениджър и обсъдете с екипа, тъй като такъв спирач на шоуто да бъде непознат на екипа седмица преди пускането му не е добре.
- След като Дефектът достигне до вашия мениджър и по-високи органи за тестване, може да се наложи да изложите мнението си пред тях, така че бъдете изчерпателни с мнението си, тъй като това може да окаже влияние върху изданието.
- Ако дискусията ви подкрепя, време е да се издигнете и да блеснете. Ако не, имате научен урок за деня за вкъщи. Продължавай да учиш.
Защо избирате областта на осигуряване на качеството на софтуера?
За да предоставим качествени проекти на крайни потребители или клиенти, тестването е задължително, независимо какво кодиране включва. Софтуерната проверка на качеството не само регистрира грешките, но също така предоставя решения за тези грешки.
В областта на QA, тестерите трябва да са наясно с цялата функционалност на приложението, което ще се тества, което му позволява да знае за различни видове приложения, разработени в различни среди, дори някои основни концепции в програмирането. Знанието ще бъде по-широко, когато правим тестове, но ще бъде тясно, докато правим програмиране. Разработчикът може да разработва само малък сегмент от цялото приложение и може да не е наясно с приложението като цяло. В този случай смятам, че ролята на QA (тестер) е по-интересна.