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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

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