Здравствуй, Хабр! В этой статье хочется поднять наболевшую для большинства тестировщиков тему – это доступы к тестируемым программным продуктам. Не всегда доступы к ПО предоставляют тестерам здесь и сейчас. И именно поэтому сотрудники вынуждены ждать начало этапа STLC, относительно к этапам работ проекта именно из-за такой проблемы.

Время идет, сроки становятся все короче и короче, а тестировщику еще не предоставили возможности «познакомиться» с программой. Конечно, тестер задастся вопросом: «А как я успею изучить ПО и уж тем более протестировать, если у меня нет доступа к нему?». Здесь я вам отвечу, что изучить и протестировать – можно. Даже без входа в приложение.

И сразу предупреждаю, что проверить качество программы получится только при наличии нескольких условий:

1. Программное решение уже готово, но требуются значительные изменения или небольшие доработки;

2. Есть прямой контакт с заказчиком или с лицом, который имеет доступ к приложению.

Итак, начинаю свою историю в стиле сюжетной линии с завязкой, развитием действий, кульминацией развязкой и эпилогом (да, да, «как в фильмах»). И этот рассказ, думаю, должен быть познавательным для тестировщиков, которым необходимо закрыть таску по тестам без доступа к программе.

«Присаживайтесь поудобнее, начинаем».

Начало истории

«Да, я снова с этим столкнулась.»

Появился в моей рабочей жизни новый проект. Веб-приложение небольшое, сроки реализации короткие (2 месяца), сам проект был интересный, и его начало, как в классическом SDLC, радовало меня. Суть проекта состояла в том, что нужно переписать фронтовую часть ПО, используя бэкенд и базу данных заказчика.

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

И вот «прилетели» ко мне первые задачи – составить стратегию тестирования ПО и план демонстрации программы.

Таски усложняются именно тем, что доступ к исходному веб-приложению ограничен, а возможность выполнения задач принимают статус «Заблокирован». Конечно, в этой ситуации можно подождать, когда заказчик или администраторы зарегистрируют учетную запись в системе и предоставят все необходимые права для входа в программу (в моем случае – получить ноутбук заказчика уже с готовыми доступами), но ограниченные сроки не позволяют сидеть и ждать начала STLC.

Завязка истории

Настал день, когда команда разработки познакомилась с заказчиками. Провели онлайн-встречу, customer показал свое веб-приложение и как с ним работать, мы задали интересующие нас вопросы и записали встречу на видео. После митинга наша команда получила все необходимые документации, инструкций, руководства пользователя и исходники программы.

Мы приступили к работе. Моими начальными тасками (как вы помните) были – составить стратегию тестирования и план демонстрации готового решения от разработчиков. Совсем не просто создать такую тестовую документацию в условиях отсутствия доступа к исходной программе, находящиеся в ноутбуке заказчика, который еще даже не выслали. (Спойлер: ноутбук я получила спустя неделю).

Пока я находилась в режиме ожидания оборудования, приступила к изучению материалов, а, чтобы проще понять программный продукт, начала составлять mind-map (стандартный прием для ознакомления с тестируемым приложением), для более глубокого понимания, как работает функциональный модуль ПО, использовала диаграммы состояния-переходов. После всех манипуляций взялась за разработку «скелета» стратегии тестирования и плана демонстрации. По итогу написала шаблоны, которые осталось лишь заполнить, как только появится доступ к эталонной программе.

К этому моменту мне сообщили, что пришел ноутбук, и я поехала в офис его забирать (отдельное приключение о том, как я ждала пропуск на вынос ноутбука, который ждал меня).

Развитие действий

Спустя некоторое время наконец-то получила оборудование, забрала пропуск и поехала домой разбираться с устройством. Разместила поудобней ноут, включила его, вошла в учетку Windows с паролем, присланным от заказчиков, подключила Wi-Fi и пошла лазить в их программном модуле. Открыла браузер, ввожу логин и пароль – не проходит. Через несколько попыток пишу заказчику о неудачах со входом в программу. После долгих обсуждений пришли к такому

выводу, что доступы к программному продукту у меня нет вовсе из-за неправильной регистрации учетной записи в программе клиента. И тут руководитель проекта спрашивает меня: «Есть готовые тесты?».

Кульминация

После вопроса от менеджера проекта сразу появляется задача «Составить тесты к ПО». И, к тому же, эта таска должна быть выполнена уже вчера.

Конечно, в этой ситуации сложно исполнить такую работу, не имея самого основного инструмента под рукой. Но не стоит паниковать, так как моим выходом оказалось то самое видео со встречи с заказчиком.

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

И вот оно тестирование! Такие ошибки не должны войти в программное решение нашей команды. Поэтому отмечаю у себя (таску не завожу, так как тестирование эталона заказчика не входит планы моих работ), на что в первую очередь нужно обратить внимание во время тестирования программы от разработчиков. Второй пример ошибки был связан уже с бэковой частью – «дата создания» и «дата изменения» заказа ссылались на один и тот атрибут в таблице. А выяснилось это в переписке с заказчиком после моего вопроса: «В чем отличие столбцов «Дата создания» и «Дата» в таблице?».

Развязка

«Что в итоге с доступом?», спросите вы. Отвечу: на момент написания статьи доступ снова ограничен (сотрудники отдела безопасности заблокировали). Но работа на этом не стоит, так как команда разработки создали копию ПО заказчика уже на нашем сервере. К тому же клиенты, как понимающие люди в данной проблеме, выслали еще до решения проблемы со входом в эталонный модуль краткий чек-лист компонентов того, что нужно включить в тестирование. Этот документ принес значительную пользу в копилку не только в функциональном тестировании, но и в проверке нефункциональной части веб-приложения, а также помог распределить тесты «по полочкам» (можно сказать, что это читерство для тестировщика *тссс …*).

Программу «потрогать» мне удалось, а задачи «Составление стратегии тестирования», «Разработка плана демонстрации» и «Создание тестов к ПО» успешно закрыла (и даже обогнала программистов по скоупу своей работы). Тестирование решения от команды проходит без проблем к доступу. И даже стиль фронтовой части веб-приложения выглядит более современным. Не исключаю, что баги, принесенные с бэка заказчика, появились и на нашей стороне, но это уже совсем другая история, так как цель проекта – перенести фронт.

Эпилог

Какой опыт из этого хочется подчеркнуть? При помощи материалов можно начать тестировать программный продукт – даже если нет возможности самостоятельно изучить ПО.

«Но как можно протестировать недоступный ПО?». Легко: если внимательно посмотреть демонстрацию от заказчика, то можно заметить баги, которые не соответствуют не только требованиям (кстати, документации по требования от заказчика не было), но и инструкциям, и практическим описаниям ПО.

Конечно, такой способ тестирования вряд ли подойдет для бэкенда или для тестирования интеграции компонентов или системы в целом, но, если быть внимательным, то можно заметить баги и в этих областях.

P.S. Из-за того, что системные администраторы заказчика неправильно зарегистрировали учетную запись, пробыла я в ожидании решения проблемы чуть более двух недель (помните, что срок на разработку готового фронта – 2 месяца?). А вопрос с предоставлением доступа решился тем, что сотрудник из контакт-центра заказчика переустановил Windows.