Home

Автор: Людмила Лихогляд

Оригинальная публикация

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

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

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

И швец, и жнец, и в дуду игрец, или как получить полмиллиона на ровном месте

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

Мы пришли на помощь, перевоплотившись в бухгалтеров, посмотрели технические требования с формулами, взяли калькуляторы, открыли электронные таблицы и подсчитали, сверили, проанализировали ВСЁ! Удивительно, но в графах «Приход продажи» и «Расход» итоговые суммы сошлись! Можно было бы закончить тестирование. Но мы решили копать глубже и проверили, все ли продажи попадут в отчет, если смену закрыть после полуночи.

Интуиция нас не подвела: информация после 24:00 не учитывалась. Это была уже явная и серьезная проблема: учет средств потерял актуальность, невозможно стало оценить остатки товаров и эффективно спланировать их пополнение, появился риск злоупотреблений со стороны сотрудников. Тестирование помогло выявить потенциальную зону риска, дать клиенту возможность оптимизировать отчетность и избежать возможных убытков. Ведь деньги очень любят счёт!

Дополнительно мы проверили смены, где проводились продажи со скидками. Для скидки 9,99% был создан отчет по смене с одним чеком. И вновь суммы в отчете не совпали с результатами пересчета по продажам. Обернувшись математиками, мы нашли сразу несколько причин:

• в отчете использовалось математическое округление, в чеке — банковское;

• в чеке скидка применялась к цене единицы товара, в отчете же — к сумме всего чека;

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

Потеря копейки в одном чеке — казалось бы, небольшая утрата. Но для сети из 2000 киосков с 3 кассовыми аппаратами в каждом, в среднем совершающими 300 продаж в день, потери составляли 540 000 рублей в месяц. И как тут не сказать, что копейка рубль бережёт! Так, с помощью тестирования нам удалось выявить упущенную прибыль заказчика в размере более полумиллиона рублей.

Что забудется, то не сбудется, или как сберечь усилия и нервы пользователя

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

Все мы люди — все мы ошибаемся, или как учесть человеческий фактор

Важно помнить, что пользователь может устать, заболеть, отвлечься и случайно нажать, например, кнопку «Удалить накладную». Как ему быть? Срочно звонить в техподдержку, требовать восстановить документ, писать объяснительные? Всё это время, нервы и сбои в работе.
В таких ситуациях мы, тестировщики, даем рекомендации по доработке интерфейса. В рассматриваемом случае рекомендация заключается в том, чтобы на экран выводилось окно с подтверждением выполнения операции. После внедрения решения в интерфейс вероятность случайного удаления или изменения исключается. Нельзя также забывать, что лень — самый сильный двигатель прогресса, и многие гениальные изобретения использовались для облегчения жизни человека. Не является исключением и программное обеспечение, предназначение которого — автоматизация определенных процессов, создание, хранение и обработка данных. Очень важно, чтобы пользователь был всегда уверен в достоверности информации.

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

Точность — вежливость королей, или как важно не упустить время

Однажды клиент обратился к нам с просьбой помочь с загадочной проблемой: при создании и публикации документов в некоторых случаях дата создания документа на сутки не совпадала с реальной. Например, акт создавали 1 января 2016 г, а в программе высвечивалась дата создания 31 декабря 2015 г. Ситуация осложнялась еще и тем, что речь шла о нормативно-правовых актах, для которых время вступления в силу определялось датой публикации. Соответственно, ошибка такого рода была критической.

При детальном анализе нам удалось выяснить, что баг возникал в том случае, когда часовой пояс пользователя отличался от московского. Ошибка крылась в форме представления времени. При создании дата сохранялась в формате DD.MM.YYYY hh:mm:ss, а в другую подсистему передавалась почему-то только как DD.MM.YYYY. То есть, точное время просто обнулялось. Далее из времени DD.MM.YYYY 00:00:00 вычиталась разница часовых поясов, и таким образом вычислялась новая дата — DD-1.MM.YYYY, ровно на сутки меньше первоначально введенной. С помощью проведенного тестирования была локализована серьезная проблема в работе системы строгой отчетности.

Вывод

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

Обсудить в форуме