Укр Рус
5 критичних помилок QA інженерів-початківців

5 критичних помилок QA інженерів-початківців

  • 25 березня
  • читати 10 хв
Вячеслав Сахаров
Вячеслав Сахаров Release Manager у Customertimes, Викладач Комп'ютерної школи Hillel.

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

Сьогодні я хотів би озвучити ті нюанси, які вам варто пам'ятати, починаючи свою кар'єру QA, щоб не облажатися.

Неправильне ставлення до помилок

Найстрашніший гріх для людини, чия робота пов'язана з цим неприємним феноменом.

Спотворене сприйняття помилок — часта проблема і з боку тестувальників, і з боку розробників.

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

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

Для цього завжди пам'ятайте ваше головне завдання: ваша місія — не зламати продукт і ткнути інших людей носом у їхні помилки, а допомогти продукту стати кращим!

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

Рекомендуємо публікацію по темі

Неправильне розміщення пріоритетів

Ця помилка частково випливає із попередньої.

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

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

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

Відсутність навички роботи з часом та обсягом завдань

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

Найголовніше, що вам варто засвоїти: немає вичерпного тестування. Але воно нікому й не потрібне.

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

Рекомендуємо публікацію по темі

Недбалість у веденні документації

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

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

Будь-які завдання стають менш гидкими, якщо знайти в них особисту користь. Саме вам ведення документації корисно з таких причин:

  1. Все у пам'яті не вберегти. Документування виконаної роботи убереже вас від повторень. Робити те саме кілька разів, бо забув результат або взагалі забув, що вже це робив — невдячна праця.
  2. Коли ви прийдете на проект і побачите чиюсь дбайливо оформлену вам документацію, яка стане для вас опорою і підтримкою в непрості часи адаптації до нового проекту — запам'ятайте це почуття і подаруйте його вашим послідовникам. Ставтеся до цього як до робочої етики — це неминуче і необхідно для вас, для ваших колег — для всіх!
  3. Послідовний, стабільний та продуктивний робочий процес неможливий без документації та моніторингу. Хаос і плутанина накриватимуть вас хвилею термінових справ, відбираючи будь-які шанси викроїти час на саморозвиток, навчання, креативність та впровадження покращень.

Загалом, вибирати вам: вести документацію та тримати її гаразд — зрілий вибір. Ви або почнете це робити з самого початку, або потім до цього все одно прийдете.

Але я радив би вже зараз починати виробляти цю звичку.

Переоцінка кінцевих результатів

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

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

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

Рекомендуємо курс по темі

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

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