Как стать QA? На что стоит обратить внимание выбирая этот путь
Привет всем! Стал замечать, что с завидной периодичностью на DTF проскакивают вопросы «как стать QA?» не так часто как про телевизоры, но всё же. Поэтому я хотел бы высказать пару мыслей: кто же такой QA и можно ли так легко влететь в эту профессию. Для этого нужно понять, что должен знать человек и какими качествами обладать, чтобы его карьера в Q…
В целом перекликается с предыдущим пунктом. Если первой мыслью человека при появлении проблемы будет «пойду на DTF, напишу вопрос» — у меня для вас плохие новости. Это не лучшее поведение для QA. Нужно уметь искать и находить информацию самостоятельно.
Ага, потраченное на это время куда списывать? Вообще пункт слишком размыт и не совсем понятно о чем идет речь. О поведении продукта которое должно быть описано (сложно найти информацию в документации по продукту? ) или каких то общих вещах вроде работы ОС или других приложений которые не являются объектом тестирования (низкий скилл тестровщика или специфика работы которая тоже должна быть описана в общей документации?).
Важно оперировать юзкейсами и контролировать поведение системы прежде всего при стандартном поведении пользователя.
Ага, это манагеры (разных уровней) думают что знают какое стандартное поведение пользователя. А потом читаешь обращения которые попали в команду разработки и тестирования пройти 3 линии техподдержки и думаешь "а зачем пользователь это сделал?".
молодец (нет) если весь день потратишь на попытку воспроизвести краш и в итоге напишешь баг в 15 шагов который в реальной жизни недостижим адекватным юзерфлоу…
Крайне херовый совет. По крайней мере если речь идет не о разработке какой-то инди-игры за пол-пачки лапши. Креш это всегда плохо и не выяснив его root-cause нельзя гарантировать что это не какая-то более серьезная проблема которая может стрельнут в другом месте, просто её еще не нашли. Лучше уж 15 шагов по которым 100% есть воспроизведение, чем 3 шана по которым стреляет 1 раз из 1000. Особенно если пользователей много (разные проблемы в Windows тому прекрасная иллюстрация).
Комментарий недоступен
По трекингу времени: тут на каждом проекте по своему. И можно долго рассуждать.
По юзкейсам - "не стоит недооценивать предсказуемость тупизны" как говорили в фильме Большой куш.
С крэшем я конечно неудачно привёл пример. Но его в любом случае нужно репортить. Зачастую по стэктрейсу разработчик гораздо быстрее поймёт в чем была проблема и как её проще воспроизвести.
Комментарий недоступен