Комментарии 12
В статье описаны типичные ошибки начинающего QA и неправильно построенного процесса разработки ПО. Если бы статья называлась что-то типа "Советы начинающим..", то ОК. А так все эти выдуманные проблемы взаимоотношений QA-Dev это от лукавого и попытка натянуть сову на глобус.. должен быть четкий рабочий процесс и нужно его следоват.
Исключительно из любопытства, какое количество тестировщиков-заложников вы удерживаете в своей компании? Судя по указанным "хотелкам" иначе их не назовешь..
С одной стороны, конечно, верные вещи описаны, с другой - для кого это пишется? Что за проблемы с наймом и/или процессами? + в довольно унизительно форме все описано, выглядит как попытка разработчика или мелкого менеджера что-то наболевшее вылить. Пока вы работаете и нанимаете тестеров, у вас проблемы на уровне понимания процессов взаимодействия будут. Научитесь для начала работать с QA и полиси строить относительно quality assistance, барахтаться в таких мелочах потребность отпадёт.
Думаю, что понимаю, почему у вас сложилось такое мнение об этой публикации. Наша компания практикует набор джунов, прошедших курс по тестировнию в компании, на перифирии до времен пандемии сложно было нанять тестировщика с высоким уровнем навыков. К тому же опыт показывает, что пока мы пока находимся в начальной точке взаимодействия с удаленными сотрудниками. Поэтому каждый тестировщик +/- наступает на все грабли, описанные в этой статье.
Расскажу историю про фразу, которая, наверное, стала самой важной в моей работе.
Я когда попал тестировщиком на свой первый проект, там у нас была самописная софтина для трассировки приложения. С каждым обновлением протокола обновлялся и трассировщик, и нужно было его проверять на регресс.
И вот однажды софтина дала сбой. Графическая оболочка при определенных действиях переставала реагировать на ввод. Я завел баг, и написал, что у программы "фриз".
Тогда инженер, который тут же прибежал разбираться, обьяснил мне, что это не "фриз", потому что сообщения в консоль продолжают писаться. И дал мне совет который я запомнил на всю жизнь: "Говори то, что видишь, а не то что ты думаешь [что ты видишь]"
Этот очень полезный совет научил меня "убирать тестировщика из тикета". В нужный момент превращаться в глаза и руки. Внимательно наблюдать, и воспроизводить не пытаясь интерпретировать. Это сильно добавило профессионализма моей работе, и уважения среди разработчиков.
Мне этот совет и до сих пор помогает когда, не знаешь с чего начать или как продолжить. Я говорю себе: "Просто пиши что видишь."
добавил бы к этому - после заведения дефекта по алгоритму "что ты видишь", следущим отличным шагом будет взглянуть с точки зрения "как так получилось". Ответ на этот вопрос оставить комментарием или дописать в описание дефекта с пометкой "Возможно/вероятно". Конечно не бездумно и на авось, а с логичным выводом.
Неонократно сильно экономило время. А в случае с белым ящиком - вплоть до указания строки кода, где ошибка или написания корректного куска уже в баге.
Если есть время копаться и доступ к исходникам - конечно стоит постараться размотать клубок дальше, и добавить деталей которые ускорят анализ для разработчика. То что наверняка доступно всем, это, протестировать ряд версий и точно установить с переходом с какой версии ошибка стала появляться. Тоже экономит поиск контекста для разработчика.
Также если есть какие-то замечания по воспроизведению, например в этой версии есть известный баг, который нужно аккуратно обойти чтобы добраться до нужного места. Не стоит думать что если баг "известный" то про него вспомнят во время воспроизведения другого сценария. А так есть вероятность, что потратят меньше времени. Все что экономит время разработчика стоит указывать. Иногда это могут быть на первый взгляд тривиальные вещи.
Есть мем про замечание открыть коробку пиццы перед едой. Но в тестировании это может быть важно, если есть другие способы добраться до пиццы. Указать каким именно путем ты добрался до нужного места в приложении. Вокруг и под приложения ведь такое наслоение других программ: библиотеки, фреймворки, браузер, плагины, операционка, другие программы, драйвера, железо. Можно ожидать любых отклонений в поведении при изменении одого из этих слоев.
Нужно стремиться выработать лаконичный стиль письма и тогда описание рутинных действий не будет утомительным.
В самом начале статьи:
сваливает кучу мелких багов в одну задачу, разработчика всё это только раздражает и демотивирует…
Далее по тексту советуете:
Объединять мелкие задачи в одну
Ожидаемый вопрос: в публикации разделила эти два пункта. Первый относится к случаю, когда идет проверка выполненной задачи разработчика и тестировщик все попутные замечания складывает в неё, хотя они к задаче не относятся. Второй: замечания близкие по контексту лучше объединить в новую отдельную задачу, если они нашлись в одно время.
в команде выработал немного другую стратегию. Однотипные минорные дефекты (например опечатки) складываются в один отдельный дефект. Но, как только их становится много или их исправление порождает новые (видна системная проблема), они уже заводятся отдельно, т.к. поддреживать в одном дефекте становится сложно.
И жили они долго и счастливо: как QA выстроить плодотворное взаимодействие с dev