Пишу статью первый раз – НАКИПЕЛО:)
Итак, ВСТУПЛЕНИЕ
Почему я ЭТО пишу? Да просто по роду деятельности приходится проверять чужую работу, окошки, кнопочки и отчеты. И хочется, чтоб меня уважали и работа моя была УМНАЯ. Не люблю я садится за тестирование в предвкушении, а тут бабах и не открывается ничего и проверить – не могу. Не люблю видеть в работе других откровенную глупость и растрындяйство. Потому этот список – не для умудренных сединами программистов разработчиков, а для тех, кто только начал, но все таки хочет работать с другими людьми. Хочет, чтобы его работа отвечала минимальным критериям качества. Хочет уважения от людей, которые немного в этом понимают и работают рядом.
Поскольку работаю в одном из 1 франчайзи, и опыт работы у меня связан прежде всего с конфигурациями славной фирмы 1С, потому эти много буков предназначены прежде всего стажеру одинеснику.
ОСНОВНАЯ ЧАСТЬ
Будет содержать в себе несколько списков.
ПЕРВЫЙ СПИСОК, без выполнения пунктов которого просто не подходи и не говори, что работа сделана.
Если ты подумал, что ты завершил писать код, сохранил все что наделал, и хочешь показать это кому-то (тестировщице, тете Маше с бухгалтерии), то перед этим будь добр – ПРОВЕРЬ. Что я понимаю под словом ПРОВЕРЬ? Посмотри на свой труд глазами тети Маши.
1. Если сделал документ – проверь, чтоб он ОТКРЫВАЛСЯ.
2. И ЗАКРЫВАЛСЯ (его можно было записать и/или провести).
3. Не поленись и заполни ОДИН документ. Простые действия по заполнению полей не должны попадать в категорию необрабатываемых событий (простыми словами - не должны ошибки появляться).
4. Если в документе есть табличная часть, то попытайся создать хотя бы одну строку. И заполнить её. И записать. И провести.
5. Посмотри в документации (или спроси у тети Маши), сколько ролей пользователей будет использовать этот документ. Узнай, что они будут с ним делать (создавать, редактировать или смотреть). Для всех тех ролей, которые будут создавать документ и повтори для каждой роли все пункты от 1 до 4 этого списка. С остальными ролями попробуй сделать все, что они должны иметь право делать (например, просмотреть).
6. Если создал отчет, то проверь, открывается ли он.
7. В справочнике нужно что? Правильно, создать элемент, заполнив все поля.
8. Если у тебя все получилось, то честь тебе и хвала. И тестировщику останется проверить логику работы, а не искать бракодела.
Читающий умник скажет, что это и так понятно всем. И будет не прав. Да есть толпа, кому не понятно. НАДОЕЛО. Толпа, исправляйтесь!
ВТОРОЙ СПИСОК, в котором есть перечень того, что пользователь ждет от системы, если он надеется что система будет дружелюбна к нему. Наивный пользователь конечно не догадывается про то, что система что то ДОЛЖНА, но мы то хотим, чтобы программа соответствовала каким то стандартам, была комфортна и т.д. и т.п. В принципе, всего этого можно не делать, объявив «что в ТЗ такого нету», но всем известно, чем отличается работа мастера от работы дилетанта. И куда стремиться надо. Так давайте прочтем и будем стремиться.
1. Первый и главный пункт. В системе должны быть использованы одни и те же методы и приемы при обработке одних и тех же событий в разных местах (формах различных метаданных). Если мы создаем новый документ, то нам (пользователям) привычно нажать определенную кнопочку. Не надо нам новый способ. Мы хотим, так как мы привыкли. Конечно, для того чтобы знать, как система обрабатывает разные события, нужно знать дорабатываемую конфигурацию. Надеюсь это не станет препятствием на пути к совершенству. В конце концов – можно спросить как делать. Остальные пункты списка будут только частными случаями этого пункта, а именно вопиющими случаями, которых лучше бы не было, но они были, есть и будут, а мне как вы помните, НАДОЕЛО.
2. Нельзя чтобы документы и элементы справочника удалялись непосредственно. Если только Ваш только что созданный документ можно удалить непосредственно, а все остальные документы конфигурации нельзя, то наверно в этом есть какой то скрытый смысл. Наверно такой что если тетя Маша с бухгалтерии случайно удалит локтем документ, а в этом документе учтено денег 100 тысяч и 50 строк в табличной части, то это будет не приятно. Так сделаем пользователю приятно и безопасно. Запретим непосредственное удаление, даже если права полные (права то полные, но люди с полными правами тоже люди, с локтями). В экономическом ПО, где учитывают ДЕНЬГИ, делать так, чтоб можно тихонько удалить что-то и никто не заметит – НЕЛЬЗЯ.
3. Если есть функция для табличной части, которая чистит эту самую табличную часть или перезаполняет, или массово заполняет какие то реквизиты, то перед тем как ЭТО сделать, надо бы спросить у пользователя, а надо ли ему чистить и не случайно ли он нажал куда ни будь, и что может очистить 50 строк его накладной.
4. Если есть функция, которая заполняет табличную часть (например, импорт откуда то), то надо бы подумать, может стоит предварительно очистить эту самую табличную часть.
5. Если для табличной части нужно считать итоги, то это не должно быть поле, куда нужно посчитать итог и ручками вбить. И такое было тоже. Вообще – не делайте мне забавно:)
6. Если создаете документ с различными статусами, стадиями обработки, то проверь, с каким статусом документ оказывается, если его скопировали.
7. Список будет расширяться и продолжаться. Обещаю.
ТРЕТИЙ СПИСОК, для продвинутых, для тех, кто можно сказать архитектор, кому поручили что-то сделать, но не разжевали как.
1. Если твой документ делает + или – в какой то регистр, узнай что это за регистр и какая логика у него. Постарайся не нарушить внутреннюю логику системы. Если ты со своим документом делаешь + то кто и почему делает – ? И может когда то должен быть ноль? В этом может быть скрыт важный смысл. ЗРИ В КОРЕНЬ, и попробуй понять, для чего работала толпа людей до тебя или прямо сейчас возле тебя.
2. Если ты проектируешь интерфейс, то постарайся не ставить отборы в табличных частях и не делать скрытыми реквизиты, из которых потом формируешь движения и проводки. Даже если ты уверен, что совершенно точно туда записываешь то, что надо. Все ошибаются, даже ты. А проверить тебя будет тяжело – спрятал все. А пользователь, он существо сомневающееся. Будет смотреть в документ, видеть, что там все как ему надо и счастливо проводить неизвестно что. Другой более ответственный пользователь увидит, что там в движении неизвестно что, но в документе то - нормально. Опять посмотрит в документ, и снова посмотрит движения. Скоро ему покажется, что он слишком много работает на этой безрадостной работе и что у него не все в порядке со зрением/головой. Но у него то все в порядке… Так что представь беднягу пользователя и будь осторожен со скрытыми реквизитами.
3. Попытайся использовать простые решения. Конечно, не всякая система проста. Бывают и действительно сложные решения, но если делаешь сложно, то это должно быть оправдано. Что я подразумеваю под СЛОЖНО?
• Большая гибкость в настройках (большая гибкость практически всегда обозначает большой бардак или большую работу по ограничению прав к доступу к настройкам и по работе над автоматизацией контроля над всеми кто гибко пользуется)
• Тысяча настроек, чтобы заполнить один документ
• Сложные формы для заполнения
• Узлы взаимосвязей не запроектированные как следует
• Еще получается сложно, когда толпа людей работает без общей идеи и направляющего документа. Вернее бардак получается. А бардак тяжело проверять, это я думаю и так понятно.
Статья получилась не очень длинной и не содержит исчерпывающего списка. Может, кому то еще накипело, буду благодарна за идеи.
Ну а тем, для кого предназначено сие письмо, могу сказать только одно: ДЕЛАЙ ТАК И ОТЧИЗНА БУДЕТ ТЕБЕ БЛАГОДАРНА.
Итак, ВСТУПЛЕНИЕ
Почему я ЭТО пишу? Да просто по роду деятельности приходится проверять чужую работу, окошки, кнопочки и отчеты. И хочется, чтоб меня уважали и работа моя была УМНАЯ. Не люблю я садится за тестирование в предвкушении, а тут бабах и не открывается ничего и проверить – не могу. Не люблю видеть в работе других откровенную глупость и растрындяйство. Потому этот список – не для умудренных сединами программистов разработчиков, а для тех, кто только начал, но все таки хочет работать с другими людьми. Хочет, чтобы его работа отвечала минимальным критериям качества. Хочет уважения от людей, которые немного в этом понимают и работают рядом.
Поскольку работаю в одном из 1 франчайзи, и опыт работы у меня связан прежде всего с конфигурациями славной фирмы 1С, потому эти много буков предназначены прежде всего стажеру одинеснику.
ОСНОВНАЯ ЧАСТЬ
Будет содержать в себе несколько списков.
ПЕРВЫЙ СПИСОК, без выполнения пунктов которого просто не подходи и не говори, что работа сделана.
Если ты подумал, что ты завершил писать код, сохранил все что наделал, и хочешь показать это кому-то (тестировщице, тете Маше с бухгалтерии), то перед этим будь добр – ПРОВЕРЬ. Что я понимаю под словом ПРОВЕРЬ? Посмотри на свой труд глазами тети Маши.
1. Если сделал документ – проверь, чтоб он ОТКРЫВАЛСЯ.
2. И ЗАКРЫВАЛСЯ (его можно было записать и/или провести).
3. Не поленись и заполни ОДИН документ. Простые действия по заполнению полей не должны попадать в категорию необрабатываемых событий (простыми словами - не должны ошибки появляться).
4. Если в документе есть табличная часть, то попытайся создать хотя бы одну строку. И заполнить её. И записать. И провести.
5. Посмотри в документации (или спроси у тети Маши), сколько ролей пользователей будет использовать этот документ. Узнай, что они будут с ним делать (создавать, редактировать или смотреть). Для всех тех ролей, которые будут создавать документ и повтори для каждой роли все пункты от 1 до 4 этого списка. С остальными ролями попробуй сделать все, что они должны иметь право делать (например, просмотреть).
6. Если создал отчет, то проверь, открывается ли он.
7. В справочнике нужно что? Правильно, создать элемент, заполнив все поля.
8. Если у тебя все получилось, то честь тебе и хвала. И тестировщику останется проверить логику работы, а не искать бракодела.
Читающий умник скажет, что это и так понятно всем. И будет не прав. Да есть толпа, кому не понятно. НАДОЕЛО. Толпа, исправляйтесь!
ВТОРОЙ СПИСОК, в котором есть перечень того, что пользователь ждет от системы, если он надеется что система будет дружелюбна к нему. Наивный пользователь конечно не догадывается про то, что система что то ДОЛЖНА, но мы то хотим, чтобы программа соответствовала каким то стандартам, была комфортна и т.д. и т.п. В принципе, всего этого можно не делать, объявив «что в ТЗ такого нету», но всем известно, чем отличается работа мастера от работы дилетанта. И куда стремиться надо. Так давайте прочтем и будем стремиться.
1. Первый и главный пункт. В системе должны быть использованы одни и те же методы и приемы при обработке одних и тех же событий в разных местах (формах различных метаданных). Если мы создаем новый документ, то нам (пользователям) привычно нажать определенную кнопочку. Не надо нам новый способ. Мы хотим, так как мы привыкли. Конечно, для того чтобы знать, как система обрабатывает разные события, нужно знать дорабатываемую конфигурацию. Надеюсь это не станет препятствием на пути к совершенству. В конце концов – можно спросить как делать. Остальные пункты списка будут только частными случаями этого пункта, а именно вопиющими случаями, которых лучше бы не было, но они были, есть и будут, а мне как вы помните, НАДОЕЛО.
2. Нельзя чтобы документы и элементы справочника удалялись непосредственно. Если только Ваш только что созданный документ можно удалить непосредственно, а все остальные документы конфигурации нельзя, то наверно в этом есть какой то скрытый смысл. Наверно такой что если тетя Маша с бухгалтерии случайно удалит локтем документ, а в этом документе учтено денег 100 тысяч и 50 строк в табличной части, то это будет не приятно. Так сделаем пользователю приятно и безопасно. Запретим непосредственное удаление, даже если права полные (права то полные, но люди с полными правами тоже люди, с локтями). В экономическом ПО, где учитывают ДЕНЬГИ, делать так, чтоб можно тихонько удалить что-то и никто не заметит – НЕЛЬЗЯ.
3. Если есть функция для табличной части, которая чистит эту самую табличную часть или перезаполняет, или массово заполняет какие то реквизиты, то перед тем как ЭТО сделать, надо бы спросить у пользователя, а надо ли ему чистить и не случайно ли он нажал куда ни будь, и что может очистить 50 строк его накладной.
4. Если есть функция, которая заполняет табличную часть (например, импорт откуда то), то надо бы подумать, может стоит предварительно очистить эту самую табличную часть.
5. Если для табличной части нужно считать итоги, то это не должно быть поле, куда нужно посчитать итог и ручками вбить. И такое было тоже. Вообще – не делайте мне забавно:)
6. Если создаете документ с различными статусами, стадиями обработки, то проверь, с каким статусом документ оказывается, если его скопировали.
7. Список будет расширяться и продолжаться. Обещаю.
ТРЕТИЙ СПИСОК, для продвинутых, для тех, кто можно сказать архитектор, кому поручили что-то сделать, но не разжевали как.
1. Если твой документ делает + или – в какой то регистр, узнай что это за регистр и какая логика у него. Постарайся не нарушить внутреннюю логику системы. Если ты со своим документом делаешь + то кто и почему делает – ? И может когда то должен быть ноль? В этом может быть скрыт важный смысл. ЗРИ В КОРЕНЬ, и попробуй понять, для чего работала толпа людей до тебя или прямо сейчас возле тебя.
2. Если ты проектируешь интерфейс, то постарайся не ставить отборы в табличных частях и не делать скрытыми реквизиты, из которых потом формируешь движения и проводки. Даже если ты уверен, что совершенно точно туда записываешь то, что надо. Все ошибаются, даже ты. А проверить тебя будет тяжело – спрятал все. А пользователь, он существо сомневающееся. Будет смотреть в документ, видеть, что там все как ему надо и счастливо проводить неизвестно что. Другой более ответственный пользователь увидит, что там в движении неизвестно что, но в документе то - нормально. Опять посмотрит в документ, и снова посмотрит движения. Скоро ему покажется, что он слишком много работает на этой безрадостной работе и что у него не все в порядке со зрением/головой. Но у него то все в порядке… Так что представь беднягу пользователя и будь осторожен со скрытыми реквизитами.
3. Попытайся использовать простые решения. Конечно, не всякая система проста. Бывают и действительно сложные решения, но если делаешь сложно, то это должно быть оправдано. Что я подразумеваю под СЛОЖНО?
• Большая гибкость в настройках (большая гибкость практически всегда обозначает большой бардак или большую работу по ограничению прав к доступу к настройкам и по работе над автоматизацией контроля над всеми кто гибко пользуется)
• Тысяча настроек, чтобы заполнить один документ
• Сложные формы для заполнения
• Узлы взаимосвязей не запроектированные как следует
• Еще получается сложно, когда толпа людей работает без общей идеи и направляющего документа. Вернее бардак получается. А бардак тяжело проверять, это я думаю и так понятно.
Статья получилась не очень длинной и не содержит исчерпывающего списка. Может, кому то еще накипело, буду благодарна за идеи.
Ну а тем, для кого предназначено сие письмо, могу сказать только одно: ДЕЛАЙ ТАК И ОТЧИЗНА БУДЕТ ТЕБЕ БЛАГОДАРНА.
