Home

Автор: Пехов Алексей

Периодически, на всем протяжении моей работы в сфере тестирования, я, как и многие из нас, старался найти как можно больше информации в своей области, дабы облегчить и оптимизировать процесс поиска дефектов. Так уж получилось, что по части тестирования экономических программ, в частности 1С Предприятие, такой информации я, увы, не нашел, как ни старался. Теперь же, набравшись определенного опыта, хочу поделиться своими наработками и впечатлениями. Речь пойдет о тестировании системы на базе 1С Предприятие 8.1, однако жесткой привязки к производителю нет. Например, насколько я могу судить,  в Microsoft Dynamix AX много похожих моментов. Говорить буду больше не о базовой конфигурации, а о разработке конфигурации с нуля для некой компании по персональным требованиям.

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

1. Основное по работе

Самое главное, на мой взгляд, это запомнить по крайней мере 2 вещи:

1) Если и верна теория о том, что в любой программе от рождения содержатся ошибки, то это как нельзя лучше относится именно к экономическим программам. Очень часто у каждого участника проекта своя точка зрения на каждую строчку ТЗ , во многом из-за того, что разработка требует специфических знаний в бухгалтерии и финансах, что не всегда свойственно программистам в полной мере.

2) Багаж знаний. Это наше лучшее орудие в баталиях с… да вообщем-то со всеми коллегами, так как кроме тестировщика, желания, чтобы все сломалось, ни у кого нет.J Отчасти это шутка, конечно, но с большой долей правды. Кроме того, знания в предметной области как нельзя лучше помогут в профессиональном росте.

А знать приходится не мало, методологи и аналитики тоже не зря деньги получают и слепо верить в ваши святые намеренья по оптимизациям их детища, ака ТЗ, не будут. В общем, знание основ бух. учета и ООП вам явно не помешают. Более подробно обсудим это далее.

2. Приемы в работе

а) Выделенная база для тестирования.

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

Общая суть идеи такова. Разработчик после окончания реализации скидывает вам конфигурацию своей БД (*.cf файл) со всей проделанной работой. Эта процедура занимает 10 секунд и особой сложности не представляет. После чего данная конфигурация загружается в TesterBase и проводятся плановые работы по проверке.

Какие плюсы дает такой подход:

• Независимость от программистов при проверке. Вас никогда не попросят выйти из базы, чтобы обновиться или если нужен монопольный режим.
• Позволяет создать комплект тестовых данных, которые никто не сотрет и не изменит.
• Обеспечит актуальность тест кейсов в дальнейшем. Через полгода, если понадобится, можно будет выполнить кейс на уже готовых данных.
• Даст площадку для ваших экспериментов, развития навыков программирования

В общем, плюсов масса. Тут конечно может возникнуть ряд затруднений в виде пассивности программистов, места под БД, дополнительного времени на весь процесс и т.д. Но оно того стоит.

б) Автоматизация. Углубление в белый ящик.

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

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

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

Например, согласно ТЗ, реализована обработка, удаляющая определенный вид сделок, скажем с префиксом “art”. Сколько у вас этих сделок в системе? Сколько помеченных на удаление? Сколько проведенных? Что если их более 300000? Функционала для экспорта в Excel нет, да и не вместит он столько. Далеко не всегда можно получить ответы на все вопросы, используя только штатные средства. Такие задачи решаются написанием небольших обработок с запросами или отчетов. Это и интересно, и полезно, и дает какие-то гарантии качественно выполненного тестирования.

К слову о запросах. Синтаксис запросов 1С практически идентичен обычным запросам SQL, так что, освоив их, можно будет с большой долей уверенности говорить о том, что вы владеете SQL, что не будет лишним в вашем резюме.

Также вполне реально автоматизировать создание документов, справочников. Очень хорошей задачей автоматизации является сверка остатков.

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

Изучение других языков остается на ваше усмотрение. Если вам много приходится работать с отчетами и документами (в ОС), то может помочь знание скриптовых языков, например Ruby или Python. Я было практиковал Visual C++, но понял, что такой низкий уровень в моих задачах не нужен. Но это все на ваше усмотрение.

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

в) Составление персональной базы знаний.

В зависимости от серьезности и сложности проекта часто приходится держать в уме привязку пользовательского интерфейса к технической составляющей. То, что в интерфейсе называется примитивной «Датой», в реализации может оказаться XRealPaymentDate, которая рассчитывается по хитрой формуле из множества составляющих, и через пару месяцев с трудом кто-то вспомнит, почему формула такая. Довольно часто бывают наименования, которые одной логикой не объяснить, например поле «Период» в конфигураторе именуется XActualDate и это же имя используется в ТЗ. В общем, иногда то,  что очевидно сейчас, становится большой проблемой в будущем.

Такие вещи лучше не держать в уме, а записывать в специально отведенном для этого месте.Примерно в таком формате: Документ Сделка, поле Количество (остаток бумаг*номинал) в конфигураторе докCделка.ХКоличествоБумНом (спрСправочники.XAssetsID*Xdnom)

Также полезно учитывать порядок различных выгрузок/загрузок и другие тонкости, в зависимости от задач и реализации.

3. Основы взаимодействия в процессе разработки

В очередной раз хочу сделать акцент на необходимости знания внутренней логики системы. Я глубоко убежден, что хороший тестировщик должен быть на уровне аналитика по этому показателю. Большинство задач невозможно проверить без углубления в сущность проблемы, не задаваясь вопросами: «А зачем оно надо?», «Возможно ли что-то оптимизировать, иначе реализовать?» и т.д.

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

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

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

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

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

• Базовые знание основ бухгалтерии и МСФО. Это позволяет облегчить процесс общения с методологами и аналитиками. Одно дело с десятого раза понимать, что же написано в ТЗ, и совсем другое – общаться напрямую, а тем более пытаться отстоять свою точку зрения.
• Знание платформы разработки и ориентация в коде. Если вы освоили первый пункт, то с большой долей вероятности придется доносить его плоды до разработчиков или же наоборот что-то подчерпнуть от них.
• Проще говоря, если нам удалось убедить методологов/аналитиков в рациональности и обоснованности своих предложений по реализации, то нужно будет ввести в курс дела разработчиков или же выслушать их точку зрения относительно возможности такой реализации.

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

4. Заключение

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

Я убежден, что в большинстве случаев, это не останется незамеченным и оправдается в большем размере.

Так, например, данная статья является своеобразным планом и моим виденьем оптимальной организации процесса тестирования 1С Предприятие, к которому я продолжаю стремиться, чего и вам советую.

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