Software QA Engineer та менторка Анастасія Дика звернула увагу QA-фахівців, що контекст часто вирішує все. Відповідно до нього, інколи те, що здається помилковим, насправді таким не є. Ось приклади такої поведінки, які можуть стати в пригоді навіть досвідченим тестувальникам.
Software QA Engineer та менторка Анастасія Дика звернула увагу QA-фахівців, що контекст часто вирішує все. Відповідно до нього, інколи те, що здається помилковим, насправді таким не є. Ось приклади такої поведінки, які можуть стати в пригоді навіть досвідченим тестувальникам.
«Бути хорошим QA — це не лише про те, щоб знаходити баги. Це про вміння розуміти наміри системи, бачити картину ширше», — підкреслює Анастасія Дика, і додає, що ключовим питанням в цьому процесі є «Чого саме очікували?».
Ось її приклади «багів», які насправді — фічі:
На малих екранах елементи свідомо зсуваються вниз, щоб не заважати читанню.
Висновок: це UX-рішення, не помилка.
Продукт орієнтується на швидкий флоу без зайвих попапів.
Наприклад, додавання до «Улюбленого» — просто змінюється іконка / підсвічується іншим кольором.
Висновок: візуальний індикатор є — значить, усе працює.
У фінансових, медичних чи юридичних продуктах дані можуть бути незмінними.
Висновок: це не дефект, а бізнес-правило.
Порада: Завжди уточнюй, що дозволено системою, перш ніж заводити баг.
Системи часто стартують для однієї країни, де інші вимоги до імен.
Висновок: Це не баг, а поточна валідація.
Пиши як improvement, а не як дефект.
Щоб уникнути подвійної оплати чи створення кількох заявок — кнопка блокується.
Висновок: це UX-рішення з міркувань безпеки.
Перевір: є loading-індикатор чи кнопка стає неактивною?
