Маски тестировщика (вопросы для успешного перехода к тестерскому расстройству личности)

«Я делаю то, за что мне платят» — стандартный капиталистический подход к работе «на дядю» в Западной части нашего мира. В момент свет гаснет, станки останавливаются и все расходятся по своим делам. Интересно, что методологи в стиле Скрам и Канбан, которые говорят о командной работе, также жестко проводят черту между ролями и тем, кто, что и когда делает. Но это там! А у нас? А у нас роль в команде (буду говорить о тестировщиках (QA)) коррелирует со знаниями из разных сфер, важностью морального и душевного равновесия в коллективе и ответственностью за проделанную работу. Все это адаптирует методологии в командах немного под другим углом, отличным от запада.

В частности, тестировщики, которые несут самую большую ответственность за выпуск продукта, в случае, когда они работают не просто от звонка до звонка, а на улучшение качества и продукта в целом.Тестирование в классическом понимании общественности — это взять часть продукта или целиком продукт, который был сделан программистом и найти в нем ошибки, полагаясь на предполагаемое поведение пользователя. Почему это не может сделать программист? Конечно, может, но час работы программиста стоит несколько дороже, поэтому программист словно поточно-конвейерная линия пишет код, а тестировщик этот код в виде программ тестирует. Но нужно отдать должное тому, что хороший программист всегда за собой минимально протестирует, хотя бы соответствие минимальным функциональным требованиям.В общем счете, мнение общественности по данному вопросу правильное, но стоит понимать, что оно применимо к специалисту уровня Джун или слабому тестировщику.

Тестировщик программного обеспечения сегодня занимает ключевую позицию в выпуске продукта и вот почему. Если вы смотрели фильм Стекло, то непременно помните чудесного разнообразного персонажа Орда, страдающего расстройством личности. Так вот — чем опытнее, чем полезнее и чем профессиональнее специалист по тестированию, тем больше масок — личностей он может на себя примерить, но в отличие от бедняги Орды, способен ими управлять.
Сегодня я расскажу о некоторых из них с объяснением своей позиции и мнения. В конце статьи вы получите дополнительный список с базовыми вопросами для себя в каждой из описанных ролей для успешного перехода к тестерскому расстройству личности ( это шутка)
а начну я конечно же с:

Маска — пользователь!

Тут на самом деле все просто. Мы представляем себя пользователем и пишем тесты на базе которых и прогоняем программу. По факту это самый важный вид тестирования и чаще всего называется Дымовым, когда проверяются основные, базовые функции продукта на соответствие актуального результата ожидаемому. Если вы углубитесь в этот вопрос, то узнаете много других видов и уровней тестирования, но мы сегодня говорим больше про сам подход к тестированию.

Маска — саппорт менеджер

Продолжим — следующая роль-маска, которую должен уметь примерить на себя специалист по тестированию, это Тестировщик-саппорт менеджер. Почему именно роль этого специалиста? Да потому, что первый, кто столкнется с пользователем после выпуска продукта на рынок будет именно саппорт менеджер. Поэтому тестировщик всегда должен задавать себе вопрос, а сделал ли я все, что мог, чтобы после релиза Саппорт не лег (в том понимании, что нагрузка на саппорт вырастет так сильно, что он перестанет справляться с ней). Тут можно упустить простую деталь в документации к продукту (гайду). Даже не то, что что-то не будет описано, а то, что даже сам гайд может быть плохо продуман и исполнен. Подсказки к полям и кнопкам в приложении могут отсутствовать или не соответствовать действительности (устареть).
Саппорт менеджер очень трудная и психологически изматывающая работа и тестировщик имеет все шансы сохранить умиротворенное состояние коллеги на немного больший срок.

Маска — бизнес-аналитика

Следующая, как по мне, самая Важная — это роль Бизнес-аналитика. Самая важная она потому, что бизнес-аналитик предполагает, а тестировщик располагает и уже видит при тестировании гораздо больше, чем аналитик, который описал фичу в документации. Можно сравнить с покером: Бизнес-аналитик — это игрок, который знает правила, знает стиль игры других игроков, знает, что нужно делать, но не видит карт, в отличие от тестировщика, который пусть и не все знает, зато все карты видит. Ну и очевидно, что карманные карты у обоих одинаковые, а сидят они рядышком за покерным столом и играют как один — они ведь команда. Все вышесказанное сводится к тому, что непосредственно тестировщик должен быть вовлечен в процесс придумывание новых фич и улучшение старого функционала.

Маска — проджект-менеждер

Проджект-менеждер. Тестирование — это последний этап в разработке продукта перед релизом. Это значит, что тестировщик (хороший такой, прожженный) знает и коммуницирует со всеми членами команды, знает воркфлоу проекта, знает, как устроены все артефакты скрама в команде и в случае чего может их подхватить и применить, например, демо митинг или ретроспективу. Хороший тестировщик видит узкие места в процессах работы команды потому, что все они в итоге превращаю тестирование в слабое звено проекта. Например: плохая оценка задач это всегда аврал в конце спринта и почему релиз не готов — не успели протестировать, отсутствие код-фриза — это сбои тестирования и упущенные баги из-постоянного фарша в тестовой среде, кто упустил баги — тестировщики и т.д Тестировщик, самая ответственная позиция в команде, так как он одобряет продукт к выпуску, а, значит, он и несет ответственность за все, что будет происходить дальше (это я про всплывающие баги), в независимости от того, что послужило этому причиной. Поэтому, заботясь о себе, тестировщик заботится о команде.

Маска — психоаналитик

Тестировщик-психоаналитик (возвращаясь к вышеуказанному пункту) общается вплотную со всеми членами команды и теми, кто работает с командой косвенно. Он знает настроения в команде, знает боль и страдания ее членов и, конечно же, как губка прокачивает это все через себя. Получается, что мало того, что тестировщик сам всегда в зоне повышенного стресса, так еще именно он и становится подушкой для горьких слез своих коллег, что в результате и становится инструментом сближения сотрудников для дальнейшего повышения эффективности.
Вывод наклевывается достаточно простой — нужно уметь ставить себя на место других и если бы так могли и умели делать все члены команды разработки, такая команда отправляла бы людей на марс уже давным давно. Но вывод простой, а вот на практике применить это куда тяжелее. Мы все разные, команды разные, заказчики разные и тд. Но не стоит опускать рук, можно начать с обычного утреннего вопроса коллеге — как дела? как настроение?

Обещанный список вопросов

Вопросы — маска пользователь

• Что меня раздражает в том, что я вижу?
• Что мне не понятно?
• Могу ли я сделать так, как хочу (имеется в виду, последовательность степов)?

Вопросы — маска саппорт-менеджер

UX дизайн адекватен?

• Все ли подсказки и советы на месте?
• Актуальны ли подсказки и эффективны?
• Понятен гайд?
• Гайд актуален?
• Что про людей с ограниченными возможностями? (вопрос риторический — у нас к сожалению о них не задумываются)
• Есть ли демо версия разработанного продукта?
• Демо удобное и актуальное?

Вопросы — маска бизнес аналитик

• Чего мне может не хватить как пользователю?
• Что меня раздражало как пользователя и как это улучшить?
• Какие ресурсы могут быть затрачены на предполагаемые улучшения?
• Что предложить на известные проблемы?

Вопросы — проджект менеджер

• Почему скрам?
• Почему канбан?
• Почему не скрам или канбан?
• А что если отказаться от…… или внедрить….? (гибкие методологии на то гибкие)

Вопросы — психоаналитик

• Нет тут вопросов — можно выучить подбадривающие девизы и делать эгегей чтобы никто не унывал