Меню

Що таке тестування програмного забезпечення? 100+ безкоштовних навчальних посібників із ручного тестування

what is software testing

Спробуйте Наш Інструмент Для Усунення Проблем

Повний посібник із тестування програмного забезпечення із 100+ підручниками з ручного тестування з визначенням тестування, типами, методами та деталями процесу:

Що таке тестування програмного забезпечення?

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

Що таке ручне тестування?

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

Що ви дізнаєтесь:

Перелік підручників із тестування програмного забезпечення, проведених вручну

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

Ця серія навчальних посібників збагатить ваші знання та, у свою чергу, покращить ваші навички тестування.

Відпрацюйте наскрізне ручне тестування Безкоштовне навчання на живому проекті:

Підручник No1: Основи ручного тестування програмного забезпечення
Підручник No2: Введення проекту в прямому ефірі
Підручник No3: Написання сценарію тесту
Підручник No4: Напишіть документ плану тестування з нуля
Підручник No5: Написання тестових справ із документа SRS
Підручник No6: Виконання тесту
Підручник No7: Відстеження помилок і тестовий вихід
Підручник No8: Курс тестування програмного забезпечення

Життєвий цикл тестування програмного забезпечення:

Підручник No1: STLC

Веб-тестування:

Підручник No1: Тестування веб-додатків
Підручник No2: Перехресне тестування браузера

Управління тестовими кейсами:

як вирішувати складні ситуації на роботі

Підручник No1: Тестові кейси
Підручник No2: Зразок шаблону тестового кейсу
Підручник No3: Матриця простежуваності вимог (RTM)
Підручник No4: Покриття тесту
Підручник No5: Тест управління даними

Управління тестами:

Підручник No1: Тестова стратегія
Підручник No2: Шаблон плану випробувань
Підручник No3: Тестова оцінка
Підручник No4: Засоби управління тестами
Підручник No5: Підручник з HP ALM
Підручник No6: Джира
Підручник No7: Підручник з TestLink

Технічні випробування:

Підручник No1: Тестування випадків використання
Підручник No2: Тестування державного переходу
Підручник No3: Аналіз граничних значень
Підручник No4: Розбиття на еквівалентність
Підручник No5: Методології тестування програмного забезпечення
Підручник No6: Спритна методологія

Управління дефектами:

Підручник No1: Життєвий цикл помилок
Підручник No2: Повідомлення про помилки
Підручник No3: Пріоритет дефекту
Підручник No4: Підручник з Bugzilla

Функціональне тестування

Підручник No1: Одиничне тестування
Підручник No2: Перевірка розумності та диму
Підручник No3: Регресійне тестування
Підручник No4: Тестування системи
Підручник No5: Прийомне тестування
Підручник No6: Інтеграційне тестування
Підручник No7: Тестування прийому користувачів UAT

Нефункціональне тестування:

Підручник No1: Нефункціональне тестування
Підручник No2: Тестування продуктивності
Підручник No3: Тестування безпеки
Підручник No4: Тестування безпеки веб-додатків
Підручник No5: Тестування юзабіліті
Підручник No6: Тестування сумісності
Підручник No7: Тестування встановлення
Підручник No8: Перевірка документації

Типи тестування програмного забезпечення:

Підручник No1: Види тестування
Підручник No2 : Тестування чорної скриньки
Підручник No3: Тестування бази даних
Підручник No4: Тестування від кінця до кінця
Підручник No5: Пошукове тестування
Підручник No6: Додаткове тестування
Підручник No7: Перевірка доступності
Підручник No8: Негативне тестування
Підручник No9: Бекенд-тестування
Підручник No10: Альфа-тестування
Підручник No11: Бета-тестування
Підручник No12: Альфа проти бета-тестування
Підручник No 13: Гамма-тестування
Підручник No14: Тестування ERP
Підручник No15: Статичне та динамічне тестування
Підручник No16: Adhoc тестування
Підручник No17: Тестування на локалізацію та інтернаціоналізацію
Підручник No18: Тестування автоматизації
Підручник No 19: Тестування білої скриньки

Кар'єра тестування програмного забезпечення:

Підручник No1: Вибір кар’єри тестування програмного забезпечення
Підручник No2: Як отримати роботу з контролю якості - Повний посібник
Підручник No3: Варіанти кар'єри для тестувальників
Підручник No4: Перемикач для тестування програмного забезпечення, що не стосується ІТ
Підручник No5: Почніть свою ручну кар'єру тестування
Підручник No6: Уроки, отримані за 10 років тестування
Підручник No7: Виживання та прогрес у галузі тестування

Підготовка до співбесіди:

Підручник No1: Підготовка резюме до контролю якості
Підручник No2: Тестування запитань на співбесіду вручну
Підручник No3: Питання інтерв’ю для автоматизації тестування
Підручник No4: Запитання щодо інтерв’ю щодо якості
Підручник No5: Опрацюйте будь-яке співбесіду
Підручник No6: Отримайте роботу для випробування як свіже

Тестування додатків різних доменів:

Підручник No1 : Тестування банківських додатків
Підручник No2: Тестування заявок на охорону здоров’я
Підручник No3: Тестування платіжного шлюзу
Підручник No4: Система тестового пункту продажу (POS)
Підручник No5: Тестування веб-сайтів електронної комерції

Тестування сертифікації якості:

Підручник No1: Посібник із сертифікації тестування програмного забезпечення
Підручник No2: Керівництво з сертифікації CSTE
Підручник No3: Посібник із сертифікації CSQA
Підручник No4: Посібник ISTQB
Підручник No5: ISTQB Advanced

Теми розширеного ручного тестування:

Підручник No1: Цикломатична складність
Підручник No2: Тестування міграції
Підручник No3: Хмарне тестування
Підручник No4: Тестування ETL
Підручник No5: Метрики тестування програмного забезпечення
Підручник No6: Веб-сервіси

Будьте готові поглянути на перший підручник у цій серії ручного тестування !!!

Вступ до тестування програмного забезпечення вручну

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

І звідки ви дізнаєтесь, яка очікувана поведінка?

Ви дізнаєтесь це, уважно прочитавши чи вислухавши вимоги та зрозумівши їх повністю. Пам’ятайте, що розуміння вимог повністю є дуже важливим.

Запити sql практикують питання з відповідями

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

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

Крім того, вимога не обов'язково повинна бути документально підтвердженою. Ви можете дуже добре знати функціональність програмного забезпечення, або навіть здогадуватися, а потім тестувати покроково. Ми зазвичай називаємо це спеціальним тестуванням або дослідницьким тестуванням.

Давайте подивимось поглиблено:

По-перше, давайте зрозуміємо факт - Незалежно від того, чи порівнюєте ви тестування програмного забезпечення чи чогось іншого (скажімо, транспортного засобу), концепція залишається незмінною. Підхід, інструменти та пріоритети можуть відрізнятися, але основною метою залишається ТЕЖЕ, і це ПРОСТО, тобто порівняння фактичної поведінки з очікуваною.

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

Але які якості має успішний тестувальник? Ви можете прочитати про них за посиланням нижче:

Прочитайте тут => Якості високоефективних тестувальників

Я настійно рекомендую переглянути цю статтю, перш ніж продовжувати цей підручник. Це допоможе вам порівняти ваші характеристики з тими, які очікуються в ролі Тестера програмного забезпечення.

Для тих, хто не встигає переглянути цю статтю, ось короткий зміст:

“Ваша допитливість, уважність, дисциплінованість, логічне мислення, пристрасть до роботи та вміння розбирати речі мають велике значення, щоб бути деструктивним та успішним випробувачем. Це спрацювало для мене, і я твердо вірю, що це спрацює і для вас. Якщо ви вже маєте ці якості, то справді це теж спрацювало у вас '.

Ми говорили про основні передумови стати тестувальником програмного забезпечення. Тепер давайте розберемося, чому ручне тестування існувало і мало б існувати самостійно із зростанням автоматизації тестування чи без нього.

Чому потрібно ручне тестування?

Чи знаєте ви, що найкраще в тому, щоб бути тестером, це теж тестувальник у ручному режимі?

Справа в тому, що тут ви не можете залежати лише від набору навичок. Ви повинні мати / розвивати та вдосконалювати свій процес мислення. Це те, чого ви не можете купити за кілька доларів. Ви самі повинні над цим працювати.

Вам доведеться виробити звичку задавати питання і вам доведеться запитувати їх щохвилини, коли ви тестуєте. Більшість випадків ви повинні задавати ці питання собі, аніж іншим.

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

Давайте подивимось на цей простий потік:

  • Ти щось робиш ( виконувати дії ), поки ви спостерігаєте це з певним наміром (порівняно з очікуваним). Тепер ваш спостереження навички та дисципліна для виконання речей тут з’являється картина.
  • Вуаля! Що це було? Ви щось помітили. Ви це помітили, тому що давали ідеальне увага до деталей перед тобою. Ви не відпустите це, бо є допитливий . Це не було у вашому плані, що трапиться щось несподіване / дивне, ви це помітите і дослідите це далі. Але зараз ви робите це. Ви можете відпустити це. Але ви не повинні відпускати це.
  • Ви щасливі, ви з’ясували причину, кроки та сценарій. Тепер ви належним чином і конструктивно повідомите про це команді розробників та іншим зацікавленим сторонам у вашій команді. Ви можете зробити це за допомогою якогось інструменту для відстеження дефектів або усно, але ви повинні переконатись, що є передаючи це конструктивно .
  • Ой! Що робити, якщо я так роблю? Що робити, якщо я вводжу власне ціле число як вхідне, але з пробілами? Що коли? … Що коли? … Що коли? Це не закінчується легко, це не повинно закінчитися легко. Ти будеш уявіть багато ситуацій та сценаріїв, і справді у вас виникне спокуса виконати їх також.

Наведена нижче схема представляє життя випробувача:

Життя випробувача

Прочитайте ще раз ці чотири пункти, згадані вище. Ви помітили, що я тримав його дуже коротко, але все ж виділив найбагатшу частину того, що я тестував вручну? І чи помітили ви сміливе виділення протягом кількох слів? Це саме найважливіші якості, які потрібні ручному тестеру.

Тепер, чи справді ви думаєте, що ці дії можна повністю замінити чимось іншим? І гаряча тенденція сьогодні - чи може вона коли-небудь бути замінена на автоматизацію?

У SDLC з будь-якою методологією розвитку мало що завжди залишається незмінним. Як тестувальник ви будете споживати вимоги, перетворювати їх у сценарії тестування / тестові кейси. Потім ви виконаєте ці тестові кейси або безпосередньо автоматизуєте їх (я знаю, що це роблять кілька компаній).

Коли ви автоматизуєте його, ваш фокус постійний, що автоматизує написані кроки.

Повернемося до формальної частини, тобто виконання тестових кейсів, написаних вручну.

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

Наведене нижче зображення зображує спрощення написання тестового кейсу:

Спрощене написання тестових кейсів

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

На жаль, я випадково натиснув клавішу 'Enter'. Дозвольте мені перевірити, що сталося. АБО є кнопка надсилання, я збираюся двічі клацнути на ній. Не задоволений. Клацаю кілька разів, занадто швидко.

Ви помітили? Існує дуже багато можливих дій користувача, як передбачуваних, так і непередбачених.

Вам не вдасться написати всі тестові кейси, які на 100% охоплюють вашу заявку на тестування. Це має відбуватися дослідницьким способом.

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

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

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

Потреба в ручному тестуванні, коли навколо автоматизація:

Автоматизація тестування має свою частку слави в наші дні і матиме ще більше в найближчі роки, але вона просто не може замінити ручне тестування якості (читайте тестування на людину / дослідження).

Ви, мабуть, чули раніше- Ви не автоматизуєте тестування, а автоматизуєте перевірку ’. Це речення багато говорить про те, де ручне тестування якості перевіряється з автоматичним тестуванням. Багато відомих імен по всьому світу писали та говорили на цю тему, тому я не буду особливо наголошувати на цьому.

Автоматизація не може замінити тестування людини, оскільки:

  • Це вимагає судження про час виконання всього, що відбувається перед вашими очима (під час тестування), а в деяких випадках і за кадром.
  • Це вимагає чіткого і постійного спостереження.
  • Це вимагає допит.
  • Це вимагає розслідування.
  • Це вимагає міркувань.
  • Це вимагає незапланованих дій, як це вимагається під час тестування.

Тестування можна замінити інструментом / машиною, яка зможе поглинати деталі, обробляти їх, керувати діями та виконувати їх, як людський розум та людина, і все це під час виконання та у всіх можливих контекстах. Цей інструмент знову повинен бути схожий на всіх можливих людей.

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

Окремою заміткою, навіть якщо це дійсно трапляється через кілька сотень років, я уявляю картину напевно страшного світу. Вік трансформерів. :)

= >> Рекомендована література - Найкращі компанії, що здійснюють ручне тестування

Як автоматизація доповнює ручне тестування?

Я вже говорив і ще раз кажу, що автоматизацію вже не можна ігнорувати. У світі, де безперервна інтеграція, безперервна доставка та постійне розгортання стають обов’язковими умовами, безперервне тестування не може простоювати. Ми повинні з’ясувати шляхи, як це зробити.

Здебільшого залучення все більшої кількості робочої сили не допомагає в довгостроковій перспективі виконувати це завдання. Отже, Тестер (керівник тесту / архітектор / менеджер) повинен обережно вирішити, що саме автоматизувати, а що все-таки слід робити вручну.

Надзвичайно важливим є написання дуже точних тестів / перевірок, щоб вони могли бути автоматизовані без будь-яких відхилень від початкових очікувань та використані під час регресії продукту як частини „Постійного тестування”.

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

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

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

Приклад:

Скажімо, є дефект блокатора, через який я не можу увійти до Facebook.

Тоді функціональність входу повинна бути вашою першою автоматизованою перевіркою, і ваш набір автоматизації не повинен запускати наступну перевірку, де вхід є необхідною умовою, наприклад, розміщення стану. Ви дуже добре знаєте, що це обов’язково зазнає невдачі. Тож зробіть це швидше невдалим, опублікуйте результати швидше, щоб дефект можна було швидше вирішити.

Наступне - це знову те, що ви, напевно, вже чули раніше - Ви не можете і не повинні намагатися автоматизувати все.

Виберіть тестові кейси, які в автоматичному режимі матимуть значну користь до людських тестерів і має хорошу рентабельність інвестицій. Щодо цього, існує загальне правило, яке говорить, що вам слід спробувати автоматизувати всі свої тестові критерії пріоритету 1 і, якщо можливо, то пріоритет 2.

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

Висновок

Я сподіваюся, що ви вже зрозуміли, чому і наскільки погано потрібно ручне / людське тестування, щоб поставити якісну продукцію, і те, як автоматизація робить це компліментом.

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

У наших майбутніх підручниках з ручного тестування ми розглянемо загальний підхід до проведення ручного тестування, те, як воно буде співіснувати з Автоматизацією та багато інших важливих аспектів.

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

найкраще розширення спливаючих вікон хром - -

Ми хотіли б почути від вас. Не соромтеся висловлювати свої думки / пропозиції у розділі коментарів нижче.

Рекомендована література

^