Такий перехід з нетехнічної спеціальності в бік інженерної є досить реалістичним і навіть перспективним. Бо компанії вигідно мати справу з тим, хто вже в контексті. Особливо коли продукт специфічний і знайти спеціалістів з досвідом нереально (це, до речі, про Embedded). З qa тестувальник курси кожним наступним етапом вартість виправлення дефекту стає все більшою. Якщо дефекти виявлені на етапі побудови дизайну, то для того, щоб їх виправити, треба не тільки змінити дизайн. Потрібно також переписати вимоги, адже вимоги й дизайн повинні відповідати одне одному.
При цьому середній вік колективу (команди) навряд чи буде перевалювати за тридцять років. Крім того, потрібно вміти працювати в команді, взаємодіяти з програмістами, менеджерами, колегами (багато з них англомовні), мислити аналітично, продумувати і складати різні плани і метрики. Уважність до деталей та вміння аналізувати оточення та систему на “надійність” в цілому є невіддільними рисами тестувальника. Розбиття додатку на невеликі, керовані частини допомагає командам розробників зрозуміти загальну функціональність їхнього коду і зрозуміти, як зміни можуть вплинути на пов’язані частини. На початку базово вистачить, але в подальшому, щоб робити якісно, то мову треба знати не гірше за сусіднього девелопера.
Тобто спочатку запропонувати користувачу якийсь основний функціонал, який потім команда буде ускладнювати й доробляти. Це дозволяє вивести продукт на ринок якомога швидше і раніше, ніж це зроблять конкуренти. Проте якщо говорити про пошук, то тут ще потрібне вміння правильно шукати. Існують навіть курси того, як правильно ґуґлити (і це не так просто, як може здаватися).
На етапі тестування QA Engineer виконує написані тест-кейси. Якщо на проекті є автоматизація, то пишуться автоматизовані тести (ще одна програма, яка буде виконувати дії користувача, які ми прописали у тестових сценаріях). На етапі планування складається календарний графік робіт з реалізації функціоналу. На цьому етапі QA Engineer зі свого боку визначає, які дії будуть виконані для забезпечення якості. Багато людей досі плутають ці поняття, що, власне, і не дивно, беручи до уваги, що в нашій країні вони найчастіше можуть використовуватися для описання одних і тих же процесів.
Таким чином, табличка і приклади показують, що обидва методи взаємопов’язані, але різні своїми аспектами забезпечення якості. Закінчував магістратуру у Київському національному університеті імені Шевченка за спеціальністю «Прикладна фізика», і треба було обирати, куди рухатися далі. Я мав технічні знання, дипломну з моделювання фізичного процесу, але до програмування не тягнуло взагалі.
Як бачите, підхід до забезпечення якості тестування програмного забезпечення може використовувати будь-який з цих методів. Однак, щоб отримати повну цінність від QA-тестування, потрібно Agile/DevOps підхід. QA-тестування програмного забезпечення – це пошук балансу між якістю та швидкістю. Досягнення прийнятного рівня за обома критеріями вимагає надійного управління та делегування. На жаль, не всі продукт-менеджери справляються з цим завданням, що може призвести до дорогих затримок, неякісного програмного забезпечення або і того, і іншого.
І їм потрібно доводити свою цінність команді та менеджменту. Важливо не лише прийти до розробників та сказати їм, що щось потрібно переробити. Найважливіше, що треба зробити перед тим, як вести розмову, що таке Quality Assurance (QA), — це розібратися з термінологією. Більшість не розрізняє між собою терміни Quality Assurance (QA), Quality Control (QC) та просто Тестування та вважає їх синонімами. І, можливо, з самооцінкою, раз ви приклад поганого тестування (в особливості тестування, яке чатЖПТ не зробе) прийняли як особисту образу(або образу вашого телефону). На етапі визначення QA Engineer перевіряє вимоги до запланованого функціоналу, щоб вони були чіткими, однозначними та не суперечили одна одній.
Якщо ви світчер, раджу зважати на вже наявний досвід. Наприклад, людина має досвід у банківській справі й розуміється на фінансах. Якщо в команду потрібен спеціаліст, якому доведеться тестувати СRМ-систему, а ви в очі її ніколи не бачили, краще шукати іншу вакансію.
На це є кілька причин, починаючи від комерційного тиску і закінчуючи незнанням процесів тестування, а в деяких випадках – просто видаванням бажаного за дійсне. Надійне середовище тестування має вирішальне значення для якісного QA-тестування. Однак багатьом командам не вистачає далекоглядності, щоб надати QA-аналітикам правильні інструменти для роботи. Деякі ситуації, які можуть перешкоджати якісному QA-тестуванню, включають старе або застаріле обладнання, баги або ненадійні фреймворки для тестування і навіть проблеми з мережею. QA-тестування дає менеджерам сировину, необхідну для прийняття рішень на основі даних для покращення програмного забезпечення. Проведення тестування та за потреби внесення його результатів у систему.
Забезпечення якості – це складна сфера з безліччю нюансів. Однак, за умови правильної підготовки та обізнаності, це не повинно бути рутинною роботою. Ось кілька порад і найкращих практик, які допоможуть вам зробити збірку програмного забезпечення якомога кращою. Інженери з автоматизації QA та QA-тестери намагаються виявити помилки та дефекти до того, як вони потраплять до клієнтів. Переконайтеся, що ви підготували всі дані перед тестуванням, і налаштуйте всі облікові записи, які можуть знадобитися для тестування вашого продукту.
Спільна природа QA-тестування означає, що комунікація між тестувальниками, інженерами та зацікавленими сторонами – це те, до чого ви повинні ставитися серйозно. Встановлення відкритих ліній зв’язку та забезпечення чіткості та зрозумілості будь-якої документації може суттєво вплинути на усунення двозначності та плутанини в процесі тестування якості. Зберегти об’єктивність, особливо при перевірці роботи, виконаної вашими ж колегами, може бути складно. Навіть якщо цей фаворитизм відбувається на підсвідомому рівні, він може призвести до того, що помилки та дефекти залишаться неконтрольованими. Розробники програмного забезпечення перебувають під величезним тиском, щоб вкластися у стислі терміни. Деякі терміни є добре продуманими та обґрунтованими, інші – абсолютно нереальними.
Цей тип тестування також називається модульним тестуванням. Компонентний підхід до тестування передбачає тестування декількох блоків одночасно. Величезна частина забезпечення якості при розробці програмного забезпечення передбачає наявність стратегії контролю якості (детально описаної вище). Налагодження зворотного зв’язку між розробниками та тестувальниками може допомогти вивести ваш код на новий рівень точності та ефективності. Коли інженери знають, де виникають проблеми, вони можуть врахувати цей зворотній зв’язок у своїй роботі. Дійсно, тісна співпраця між усіма сторонами сприяє обміну знаннями та допомагає виявляти проблеми на ранній стадії і швидше їх вирішувати.
