У мене не відразу вийшло зрозуміти, де особисто для мене краще і приємніше працювати — на великому підприємстві, де все по стандартам, де високий рівень стабільності, де величезні масштаби; або в невеликій компанії, де є динаміка і гнучкість, де за формалізмом і бюрократією не губиться сенс, а безліч різнопланової роботи не дає занудьгувати. Думаю, кожному варто спробувати і те, і інше. В результаті особисто для мене сімейна атмосфера виявилася набагато більш привабливою, тут має значення кожна людина, а відкритість і оперативність на високому рівні. Я дуже радий тому, що я в Apex, і дуже вдячний всім, хто мені в цьому допоміг. Спасибі!
Доброго дня! Пишу враження після спроби податися на вакансію QA більше місяця тому. Саме зараз, бо бачу знов ту вакансію опублікованою повторно сьогодні. Тоді скринінг та англійська пройшли добре, застряг на наступному етапі — тестовому завданні. Завдання містило в собі єдиний скрін-шот форми, схожої на табличку excel, та невеликий абзац тексту, який пропонував занести в уявний баг-трекер усі помічені проблеми, немов я єдиний відповідальний за тестування, та нагадував, що після виправлення усіх дефектів наступним етапом відбудеться реліз. Виконання завдання я почав з великої нотатки про те, що для адекватного тестування будь-чого в першу чергу потрібна документація — техзавдання, специфікація, список вимог до продукту, тощо. Тестувальник в жодному разі не має засновувати свою роботу на власному «здоровому глузді». Тільки замовник повністю та вичерпно розуміє свої потреби, бізнес-аналітик з його слів створює технічне завдання, а тестувальник, маючи цю документацію, може якісно зробити свою роботу. Нагадую, тестове завдання не містило в собі жодної ознаки необхідної документації. Врешті решт, результат моєї перевірки складався з двох частин — списку питань для з’ясовування очікуваної поведінки (бо навіть тестувальник-джуніор знає, що без expected behaviour не можна заносити тікет в баг-трекер), та усього чотирьох багів, які були внесені як просто кричущі помилки, які не мали жодного логічного пояснення та сумнівів у очікуваній поведінці. Для неспеціалістів у тестуванні, які це читають, я акцентую увагу на тому, що не можна геть усі свої підозри репортити в баг-трекер як дефекти, бо процедурно якщо якийсь тікет потім закривається з резолюцією not a bug, то це значить, що я відволік розробника на безтолкову діяльність — впала моя та його продуктивність, це ніяк не GxP, і це на 100% моя провина як репортера. Настільки детально я пишу про це тому, що у відмові продовжувати розгляд моєї кандидатури була вказана саме низька кількість зарепорчених багів (на основі чого робився скептичний висновок про рівень моїх скілів), та вказана невідповідність формату виконання (з чим в принципі я погоджуюся, бо вимагалося саме оформлення дефектів, а не якісь мої нотатки або список питань до продакт-оунера). Загалом враження від тестового залишилося таке, ніби я був би механіком, прийшов влаштовуватися на СТО, а мені б дали зламаний гайковий ключ та погнуту викрутку зі словами «Ну давай, покажи, що ти вмієш». Чи взагалі можливо надати адекватні відповіді на неадекватні питання? Мою відповідь на це питання Ви вже зрозуміли. Дякую!