Тестувальник зобов’язаний переконатися, що програмне забезпечення робить саме те, що повинно, і саме так, як це передбачається. Ситуація, коли користувач натискає кнопку “Друк”, а документ замість того, щоб бути відправленим на принтер, просто зберігається, неприпустима для добре протестованого продукту. Компанії, що займаються QA-тестуванням, ретельно перевіряють додатки та вдосконалюють їх, щоб уникнути подібних проблем. Інженер з якості - це той самий тестувальник, але тільки відповідальний за якість продукту протягом усього циклу розробки. Давайте розглянемо типову схему такого циклу.

Як видно зі схеми, відділ розробки бізнес-вимог (BRDD) (Product Specialists) надає групі тестування (QA) і команді програмування (Development) два документи: BRD (Business Requirement Document), що описує бізнес-логіку створюваного продукту, і FDD (Functional Design Document), що описує функціональні вимоги до виробленого продукту. Після того, як програмісти вивчать цю документацію, вони створять ще один документ - TDD (Technical Design Document), який потім буде надісланий до відділу розробки бізнес-вимог та групи тестування. Після його розгляду та затвердження відділом розробки бізнес-вимог група тестування починає писати план тестування, тестові сценарії та тестові кейси, які слугують основою для подальшого тестування продукту. Тим часом програмісти пишуть вихідний код. Коли код стає відносно стабільним, його аналізує група тестування. Тести допомагають знайти дефекти, програмісти їх виправляють, і так триває доти, доки продукт не стане достатньо стабільним або доки не підтисне час. Це, власне, і є весь цикл секційної розробки. Послуги мобільного тестування дозволяють людям надавати чудовий цифровий досвід і радувати користувачів мобільних додатків. Відповідальність інженера з якості починається з читання BRD і FDD. В його обов’язки також входить не тільки тестування коду, і не власне його тестування, а перевірка якості всіх компонентів (і зокрема документації) даного програмного забезпечення, щоб переконатися, що бажаний рівень якості був досягнутий. Тобто, якщо BRDD пише щось явно нездійсненне або не зручне для користувача, інженер з якості повинен бити на сполох. Він відповідає за врахування TDD - якщо він знає, що користувачеві потрібно буде мати кілька відкритих вікон, кожне з яких має регулярно зчитувати/записувати базу даних, він повинен наполегливо порадити людині не використовувати такі трудомісткі речі, як Java Applets та JDBC в одному. Потрібно адаптувати програмне забезпечення під іноземний ринок? Ця мета майже недосяжна за допомогою сервісів тестування локалізації.