17 вересня 2024 13:45
Доброго дня! Пишу враження після спроби податися на вакансію QA більше місяця тому. Саме зараз, бо бачу знов ту вакансію опублікованою повторно сьогодні. Тоді скринінг та англійська пройшли добре, застряг на наступному етапі — тестовому завданні. Завдання містило в собі єдиний скрін-шот форми, схожої на табличку excel, та невеликий абзац тексту, який пропонував занести в уявний баг-трекер усі помічені проблеми, немов я єдиний відповідальний за тестування, та нагадував, що після виправлення усіх дефектів наступним етапом відбудеться реліз. Виконання завдання я почав з великої нотатки про те, що для адекватного тестування будь-чого в першу чергу потрібна документація — техзавдання, специфікація, список вимог до продукту, тощо. Тестувальник в жодному разі не має засновувати свою роботу на власному «здоровому глузді». Тільки замовник повністю та вичерпно розуміє свої потреби, бізнес-аналітик з його слів створює технічне завдання, а тестувальник, маючи цю документацію, може якісно зробити свою роботу. Нагадую, тестове завдання не містило в собі жодної ознаки необхідної документації. Врешті решт, результат моєї перевірки складався з двох частин — списку питань для з’ясовування очікуваної поведінки (бо навіть тестувальник-джуніор знає, що без expected behaviour не можна заносити тікет в баг-трекер), та усього чотирьох багів, які були внесені як просто кричущі помилки, які не мали жодного логічного пояснення та сумнівів у очікуваній поведінці. Для неспеціалістів у тестуванні, які це читають, я акцентую увагу на тому, що не можна геть усі свої підозри репортити в баг-трекер як дефекти, бо процедурно якщо якийсь тікет потім закривається з резолюцією not a bug, то це значить, що я відволік розробника на безтолкову діяльність — впала моя та його продуктивність, це ніяк не GxP, і це на 100% моя провина як репортера. Настільки детально я пишу про це тому, що у відмові продовжувати розгляд моєї кандидатури була вказана саме низька кількість зарепорчених багів (на основі чого робився скептичний висновок про рівень моїх скілів), та вказана невідповідність формату виконання (з чим в принципі я погоджуюся, бо вимагалося саме оформлення дефектів, а не якісь мої нотатки або список питань до продакт-оунера). Загалом враження від тестового залишилося таке, ніби я був би механіком, прийшов влаштовуватися на СТО, а мені б дали зламаний гайковий ключ та погнуту викрутку зі словами «Ну давай, покажи, що ти вмієш». Чи взагалі можливо надати адекватні відповіді на неадекватні питання? Мою відповідь на це питання Ви вже зрозуміли. Дякую!
Юрко, дякуємо за ваш детальний відгук. Ми дуже цінуємо, що ви виділили час, щоб поділитися своїми враженнями про ваш досвід проходження тестового завдання.
Експертиза нашої компанії — це вирішення нестандартних задач, які поставлені нашими замовниками.
В наших проєктах виникають ситуації, коли вимоги до кінцевого продукту можуть змінюватися в процесі розробки. Це пов’язано з тим, що наші клієнти часто не мають чіткого технічного бачення на початку проєкту. Тому ми шукаємо фахівців, які можуть швидко адаптуватися до змін та пропонувати креативні рішення.
Саме ці особливості роботи ми заклали в зміст технічного завдання.
Розуміємо, що такі завдання можуть бути нестандартними і вимагати особливого підходу. Ми працюємо над тим, щоб вони були більш наближеними до реальних задач та давали кандидатам уявлення про роботу в команді.
Робота в нашій компанії — це можливість брати участь у створенні інноваційних продуктів та рішень. Саме тому мисленням out of the box є основною вимогою.
Цінуємо ваш інтерес до нашої компанії і сподіваємося, що ви якнайшвидше знайдете команду, яка повністю відповідатиме вашим очікуванням.
1 коментар
Підписатись на коментаріВідписатись від коментарівКоментарі можуть залишати тільки користувачі з підтвердженими акаунтами.