Можешь ли ты тестировать бесконечно

можешь ли ты тестировать бесконечно ?

Однажды в студеную зимнюю пору, мы разрабатывали небольшой кусочек функционала, на основе наших js библиотек. Эта история и не появилась бы на свет, если бы я случайно не вспомнил пример, когда писал первую статью о техниках тестирования. Перед нами и в самом деле замерцала перспектива тестировать бесконечно.

Мы разрабатывали фичу такого плана. Клиент хотел на основе нашей библиотеки, создать форму для онлайн конфигурации веб формы. Форма наполнялась похожими дроп-даунами, чекбоксами и инпутами и тд. Предполагалось, что к примеру, можно будет создавать тесты для прохождения — учениками или клиентами. Но ), задача была бы слишком тривиальной, если бы не одно, но. В такой конструктор добавлялся конструктор if/else ( а также условия равенства, неравенства, include текста в ответе и наоборот). Условий и равенств было больше 10, который в зависимости от ответа, мог ветвится по форме. Блочить другие части вопросов, показывать новые, изменять ветку по которой пойдет пользователь. И некоторые другие фишки, возможно не столь существенные, а возможность старость, и я не помню. 

Что мы тестировали бесконечно

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

Условно для понимания форм, можно посмотреть на форму гугл. Попытайтесь представить, сколько возможных вариаций тест-кейсов может быть. Только при прогонах в комбинациях “один вид полей с одним типом значений” это чисто огромно:

можешь ли ты тестировать бесконечно эту форму?

Тестировать бесконечно

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

Результаты Сизифового труда

И… естественно после демо менеджер вернулся с дергающимся глазом и списком дефектов, на которые обратил внимание клиент. Это не было провалом с точки зрения разработки проекта. Такой флоу с показом подразумевался в течении нескольких итераций. Но с точки зрения QA — у нас просто опускались руки. Каждый раз когда мы казалось бы испробовали все варианты — на деле оказывалось, что необходимое клиенту ворк флоу не работает должным образом. 

Я специально не упоминал об этом сразу. После прочтения документации мы сразу сделали запрос для клиента. В нем постарались узнать у него как и каким образом он планирует работать с приложением. Мы понимали что никакая комбинаторика здесь не поможет, не говоря об автоматизации. И кроме работы основных элементов и выдуманных нами кейсов, мы никак не сможем гарантировать приемлимое качество выпускаемого софта. Но от заказчика на тот момент пришел достаточно неприятный но честный ответ. А именно то, что он не может знать всех вариаций работы его клиентов, он ожидает продукт, за который платит, без багов.

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

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

Добавить комментарий

Ваш адрес email не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.