Уявімо, що ви недосвідчений QA-інженер, який щойно почав працювати у швидкозростаючій компанії, що займається розробкою програмного забезпечення. Але проблема в тому, що ви перший найнятий тестувальник. Ви єдиний, хто відповідає за розробку QA-процесу в цій ІТ-сфері. І хоча ви новачок, всі у вашій компанії розраховують на вас і очікують, що ви завжди і всюди будете робити все правильно. Така ситуація вимагає величезної відповідальності.
Далі в статті ми поговоримо про пастки, які відкриваються в повсякденній роботі тестувальників. Вони будуть надзвичайно корисними для тих, хто керує процесами тестування та організовує роботу QA. Навіть якщо комусь ці поради здадуться поверхневими, вони можуть допомогти вам тестувати програмне забезпечення набагато краще.
Тестувальник - не рятувальник
Абсолютно хибною є думка, що тестування програмного забезпечення - це відповідальність лише команди QA. Як тільки частина веб-продукту готова, її починають тестувати, і нічого більше!
В ідеалі QA-інженер повинен завжди шукати рішення для покращення процесів розробки, щоб програмне забезпечення містило менше дефектів. Щоденна допомога програмістам та евристики тестування - найефективніший спосіб гарантувати, що ретельно протестовані функції не містять дефектів і можуть бути безпечно запущені у виробництво.
Якщо QA-консультанти позиціонують себе як рятувальники якості, це неодмінно є приводом для їхньої гордості та непохитного відчуття власної значущості. Але коли відділ розробки, менеджери проектів та інші зацікавлені члени робочої групи також опиняються в такій ситуації, якість програмного забезпечення піднімається на інший рівень, досягти якого поодинці вкрай проблематично.
Автотести слід використовувати з розумом
Автоматизоване тестування програмного забезпечення - найбільш недооцінена річ в інженерії. Будь-яке автоматизоване тестування може бути універсальною системою безпеки, особливо в проектах, які неможливо ретельно протестувати вручну.
Але варто добре попрацювати над універсальною стратегією автоматизації, врахувавши думки всієї команди проекту і попередньо отримавши їхнє технічне схвалення.
Ви не можете протестувати все: слідкуйте за часом
Немає нічого поганого в тому, що QA інженер працює над двома або навіть трьома проектами одночасно. Звичайно, кожен з цих проектів має свої дедлайни та актуальні пріоритети.
Щоб не заплутатися в тому, що перевірити вранці, а що можна відкласти на вечір, потрібно щодня розставляти пріоритети.
Якщо є якісь сумніви щодо Проекту Х, зосередьтеся на ньому повністю! Адже час - найважливіший і найцінніший ресурс. Оскільки ви не можете з упевненістю сказати, що в Х немає дефектів, не соромтеся тестувати його до нескінченності (в межах розумного).
Часу ніколи не вистачає, щоб протестувати все, тому важливо ефективно розподіляти свій час. Тестуйте те, що ви вважаєте важливим: найпоширеніші сценарії, критичні точки та добре функціонуючі сценарії, і використовуйте свій час з розумом!
Наприклад, такі техніки, як тести класів еквівалентності або граничних значень, дозволять вам мінімізувати кількість тестових кейсів, зберігаючи при цьому високі стандарти якості веб-продукту. Хороший тестувальник знає не тільки те, що потрібно тестувати, але й те, що не потрібно тестувати.










0 коментарів