Меню

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

manual automation testing challenges

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

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

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

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

що таке активація портів проти переадресації портів

Проблеми, пов

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

Отже, ми йдемо до основних викликів:

# 1) Тестування повної заявки
Це можливо? Думаю, неможливо. Існує мільйони тестових комбінацій. Неможливо протестувати кожну комбінацію як у ручному, так і в автоматичному тестуванні. Якщо ви спробуєте всі ці комбінації, ви ніколи не відправите товар ;-)

# 2) Нерозуміння процесів компанії
Іноді ви просто не звертаєте належної уваги на те, що таке визначені компанією процеси, і для яких цілей. У тестерах існують міфи про те, що вони повинні поєднуватися лише з процесами компанії, навіть якщо ці процеси не застосовуються для їх поточного сценарію тестування. Це призводить до неповного та невідповідного тестування заявок.

# 3) Відносини з розробниками
Великий виклик. Потрібен дуже кваліфікований тестер, щоб позитивно впоратись із цим відношенням і навіть виконавши роботу тестерами. Просто є сотні виправдань, які розробники або тестувальники можуть зробити, коли вони не погоджуються з деякими пунктами. Для цього тестер теж вимагає Гарне спілкування , Вирішення проблем та аналізуючи вміння.

# 4) Регресійне тестування
Коли проект продовжує розширювати роботу з регресійного тестування, це просто стає неконтрольованим. Тиск на обробку поточних функціональних змін, попередні перевірки робочої функціональності та відстеження помилок.

# 5) Відсутність Кваліфіковані тестувальники
Я називатиму це «неправильним управлінським рішенням» під час відбору або навчання тестувальників для виконання їх проектних завдань. Ці некваліфіковані співробітники можуть внести більше хаосу, ніж спрощення тестової роботи. Це призводить до неповного, недостатнього та спеціального тестування протягом усього періоду Тестування життєвого циклу .

який найкращий безкоштовний брандмауер - -

# 6) Тестування завжди за обмеженням часу
Гей, тестере, ми хочемо доставити цей продукт до цих вихідних. Чи готові ви до завершення? Коли це замовлення надходить від начальника, тестер просто зосереджується на виконанні завдання, а не на охопленні тесту та якості роботи. Існує величезний перелік завдань, які потрібно виконати протягом зазначеного часу. Це включає написання, виконання, автоматизацію та перегляд тестових випадків.

# 7) Які тести виконати першими?
Якщо ви стикаєтесь із викликом, зазначеним у пункті 6, то як ви приймете рішення, які тестові справи слід виконувати та з яким пріоритетом? Які тести важливі над іншими? Для цього потрібен хороший досвід роботи під тиском.

# 8) Розуміння вимог
Іноді тестери відповідають за спілкування із замовниками для розуміння вимог. Що робити, якщо тестер не розуміє вимог? Чи зможе він протестувати заявку належним чином? Безумовно, ні! Тестери вимагають хороших можливостей прослуховування та розуміння.

# 9) Тестування автоматизації
Багато підзадач - Чи слід автоматизувати тестування? До якого рівня автоматизації слід робити? Чи маєте ви достатні та кваліфіковані ресурси для автоматизації? Чи допустимий час для автоматизації тестів? Рішення про автоматизацію або ручне тестування потребує врахування плюсів і мінусів кожного процесу.

# 10) Рішення про припинення тестування
Коли припиняти тестування? Дуже важке рішення. Потрібне суттєве судження процесів тестування та важливості кожного процесу. Також потрібна здатність приймати рішення на льоту.

# 11) Одна тестова група за кількома проектами
Складно стежити за кожним завданням. Виклики спілкування. Багато разів призводить до провалу одного або обох проектів.

# 12) Повторне використання тестових скриптів
Методи розробки додатків швидко змінюються, що ускладнює управління інструментами тестування та тестовими сценаріями. Тестова міграція або повторне використання є дуже важливим, але складним завданням.

шаблон матриці простежуваності вимоги з прикладом

# 13) Тестери, зосереджені на пошуку легких помилок
Якщо організація винагороджує тестувальників на основі ряду помилок (дуже поганий підхід до оцінювання Продуктивність тестерів ), тоді деякі тестувальники концентруються лише на пошуку простих помилок, які не потребують глибокого розуміння та тестування. Важка чи тонка помилка залишається непоміченою у такому підході до тестування.

# 14) Щоб впоратися з виснаженням
Збільшення заробітної плати та виплат змушує багатьох працівників залишати компанію через дуже короткі проміжки часу. Керівництво стикається з важкими проблемами, щоб впоратись із показником виснаження. Виклики - Нові тестери вимагають підготовки проектів з самого початку, складні проекти важко зрозуміти, затримка дати доставки!

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

Додаткові посилання та докладні рішення цих проблем див. У книзі 'Виживання десяти викликів тестування програмного забезпечення', написаній Вільямом Е. Перрі та Рендаллом Райсом.

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

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

^