Сегодня расскажу ̶с̶о̶к̶р̶о̶в̶е̶н̶н̶у̶ю̶ ̶т̶а̶й̶н̶у̶ поведаю про заблуждение четвертое
Про предыдущие три можно почитать
тут Заблуждение №1
и тут Заблуждение №2
и вот тут Заблуждение №3
Встречайте, заблуждение номер четыре.
Тестировщик - это мозг проекта и человек-оркестр заодно
Ага, а ещё на гитаре сыграть может, сфотографировать товары и написать продающий пост.
В общем, многие думают, что тестировщик на проекте должен всё знать, за всё отвечать, и вообще "ты в первой статье писала, что тестировщик должен со всех сторон".
Должен, но как всегда, есть нюансы.
В данном случае разговор идёт про то, что все знания на проекте у тестировщика в голове. В бедном мозгу, итак нагруженном всяким-разным. И только там.
Такое и правда бывает. С одной стороны, это хорошо, когда тестировщик всё знает. Тогда вам тестер и про функционал всё расскажет-покажет и нового сотрудника введёт в курс дела и даже объяснит, что и почему работает так как работает. Просто потому что он уже старичок и сидит на этом проекте эдак с годик.
Но есть два огромных минуса, почему полагаться только на знания в голове тестировщика очень плохой вариант.
Тестировщик может покинуть проект
И тогда все его знания уйдут с ним.
Я работала на таком проекте - когда никого не осталось из старичков и все знания приходилось клещами вытягивать из программистов и архитектора. И если программисты отвечали в общем нормально и понятно, то архитектор умудрялся отвечать так, что было как в анекдоте про мышь, сыр и мышеловку. То бишь вроде ответил, а понятнее не стало ни разу.
Вот чтобы избежать подобных ситуаций очень рекомендую вести внутреннюю базу знаний. Этакую википедию по проекту.
Для этого есть масса инструментов, например, Confluence. Дорого Confluence, тогда можно завести статьи в Google Docs. Или вообще завести облако и хранить там текстовые файлы на худой конец.
Что угодно, лишь бы знания хранились и были доступны не только локально (а то умрет компьютер с этими знаниями и привет).
⠀
И второй минус. Даже если тестировщик уйдет временно, например, на другой проект внутри одной компании.
Человеческая память не абсолютна
Мы помним часто используемые штуки, мы помним сильно повлиявшие, зацепившие эмоциями и переживаниями вещи. И нет никакой гарантии, что вернувшись на старый проект через год, тестировщик вспомнит, что там к чему.
Опять же, такой пример был в моей практике. Меня попросили вернуться и проверить новый функционал ровно через год.
Я конечно, примерно помнила что к чему. А вот вещи сугубо прикладные, какие запросы отправлять, какие параметры в этих запросах и т.д. - уже нет.
Спасло меня то, что когда я пришла на проект и пытала программистов и архитектора - все знания записывала в тот самый Confluence. Так что достаточно было просто почитать свои же руководства, вспомнить что к чему и приступить к работе. Заняло это буквально день.
Сколько времени было бы потрачено зря, не будь этих статей, страшно даже представить.
А время (тем более рабочее, тем более для серьезного продукта) - деньги.
Вообще, всё то, что я тут понаписала, актуально не только для тестировщиков.
На любом проекте может случиться что угодно . И чем больше общих, понятных всем знаний лежит в местной вики, тем лучше.
У ведения вики есть ещё один приятный плюс. Как только заводятся внутренние статьи, начинает заводиться и документация. Даже если плохонькая и для своих, но она хотя бы есть.
А там, глядишь, и аналитики от сырости заведутся ;)
⠀
Всем спасибо, с вами была Вселенная тестирования.
P.S. Если вам понравилась статья, ставьте лайк и подписывайтесь на канал.
А ещё есть канал в телеграме
А для тех, у кого телеграма нет, теперь есть канал и в аське