"О чём?" или "Про что?"
(рубрика "Театр и Тестирование")
Два вопроса. Вроде бы одинаковые, но в большинстве случаев кардинально разные.
В период подготовки к конкурсу художественного слова или дню Пушкина они звучат очень часто при обращении к участникам. И, как правило, ответ от дилетантов идёт на вопрос "Про что?", то есть они пересказывают содержание произведения, а не говорят о своём отношении к главной мысли и тем урокам, которые можно подчерпнуть из текста.
Точно также реагируют зрители современного кино, особенно зарубежного. Фильмы превратились по-сути в бессмысленное шоу. Зачастую отзыв о кино-новинке насыщен описанием задействованной компьютерной графики, большой работе гримёра и костюмера, изредка оценивается операторская работа. Но совсем забыта работа сценариста, режиссёра и актёра, от чего в полной мере зависит ответ на вопрос "О чём?".
Возможно истоки проблемы кроются в современном обучении, основанном на тестировании, а не передаче знаний. В день Пушкина и Русского Языка выпускники составляли "как-бы сочинение", а не описывали свои мысли и эмоции от ранее прочтённого, потому что их приучили излагать "по-рыбе". Да, чтобы оценить сочинение в рамках ЕГЭ проще проставить галочки о наличии основных требований, вернее фраз о мнении автора, наличии и месте героя и тому подобного, нежели вчитываться в ход мыслей, возможно, будущего писателя. Полагаю, по этой же причине режиссёры отказываются ставить современные пьесы, потому что в них нет ответа на вопрос "О чём?", а ответы на вопрос "Про что?" слишком навороченные о нереальных событиях.
Эти же два вопроса вполне применимы при оформлении задач в баг-трекинговую систему. На вопрос "О чём?" всегда должно отвечать краткое описание "Summary", а комбинация значений из полей "Component/Module", "Priority/Severity", "Environment", "Issue Type","Affected Version", "Description" расскажет "Про что?" данная задача. Чаще всего однотипные задачи, с одинаковым алгоритмом правки лучше именовать в "Summary" единым текстом, чтобы программисту было сразу ясно куда направлять свои мысли. Такое именование считают неверным только ленивые составители спринта, для которых добавление в фильтр для отбора задач ещё несколько полей - "Component/Module", "Priority/Severity", "Environment", "Issue Type","Affected Version" - проблематично. Поэтому текст "Summary" раздувают более 5-7 слов и впихивают в якобы короткое наименование ответы на все вопросы "что-где-когда?". Вместе с ними за длинное "Summary" ратуют составители Release Notes, которым проще вставить текст наименования задачи вместо того, чтобы описать пользователю доступным языком суть задачи. В большинстве баг-трекинговых систем заполнение поля "Summary" обязательно, и недаром браузеры выводят список ранее введённых значений в это поле. Например, при оценке спринта достаточно выбрать задачи о соблюдении стандартов интерфейса, нежели перечитывать каждую из тысячи задач и осознавать единость правок. Если бы создатели баг-трекинговых систем подразумевали необходимость разнообразия Summary, то кроме обязательности на поле бы навесили ключ уникальности. Почему этого не делается? Да, именно для того, чтобы у вашей команды составился свой список единства задач. Имея универсальные названия, проще выполнять следующее:
- распределять работы между специалистами, например, интерфейсниками и системщиками;
- составлять тест-кейсы, чек-листы обычным копированием из имеющихся подобных, быстрее осуществлять тест-дизайн без необходимости особого обучения или привлечения специалиста;
- планировать время работы над задачей, как программистом, так и тестировщиком;
- унифицировать тексты для Release Notes;
- предоставлять более понятный отчёт руководству.
А когда вам задают вопрос "О чём сие произведение?" вы поясняете его суть и описываете своё мнение, впечатление, осознание или пересказываете сюжет?
(рубрика "Театр и Тестирование")
Два вопроса. Вроде бы одинаковые, но в большинстве случаев кардинально разные.
В период подготовки к конкурсу художественного слова или дню Пушкина они звучат очень часто при обращении к участникам. И, как правило, ответ от дилетантов идёт на вопрос "Про что?", то есть они пересказывают содержание произведения, а не говорят о своём отношении к главной мысли и тем урокам, которые можно подчерпнуть из текста.
Точно также реагируют зрители современного кино, особенно зарубежного. Фильмы превратились по-сути в бессмысленное шоу. Зачастую отзыв о кино-новинке насыщен описанием задействованной компьютерной графики, большой работе гримёра и костюмера, изредка оценивается операторская работа. Но совсем забыта работа сценариста, режиссёра и актёра, от чего в полной мере зависит ответ на вопрос "О чём?".
Возможно истоки проблемы кроются в современном обучении, основанном на тестировании, а не передаче знаний. В день Пушкина и Русского Языка выпускники составляли "как-бы сочинение", а не описывали свои мысли и эмоции от ранее прочтённого, потому что их приучили излагать "по-рыбе". Да, чтобы оценить сочинение в рамках ЕГЭ проще проставить галочки о наличии основных требований, вернее фраз о мнении автора, наличии и месте героя и тому подобного, нежели вчитываться в ход мыслей, возможно, будущего писателя. Полагаю, по этой же причине режиссёры отказываются ставить современные пьесы, потому что в них нет ответа на вопрос "О чём?", а ответы на вопрос "Про что?" слишком навороченные о нереальных событиях.
Эти же два вопроса вполне применимы при оформлении задач в баг-трекинговую систему. На вопрос "О чём?" всегда должно отвечать краткое описание "Summary", а комбинация значений из полей "Component/Module", "Priority/Severity", "Environment", "Issue Type","Affected Version", "Description" расскажет "Про что?" данная задача. Чаще всего однотипные задачи, с одинаковым алгоритмом правки лучше именовать в "Summary" единым текстом, чтобы программисту было сразу ясно куда направлять свои мысли. Такое именование считают неверным только ленивые составители спринта, для которых добавление в фильтр для отбора задач ещё несколько полей - "Component/Module", "Priority/Severity", "Environment", "Issue Type","Affected Version" - проблематично. Поэтому текст "Summary" раздувают более 5-7 слов и впихивают в якобы короткое наименование ответы на все вопросы "что-где-когда?". Вместе с ними за длинное "Summary" ратуют составители Release Notes, которым проще вставить текст наименования задачи вместо того, чтобы описать пользователю доступным языком суть задачи. В большинстве баг-трекинговых систем заполнение поля "Summary" обязательно, и недаром браузеры выводят список ранее введённых значений в это поле. Например, при оценке спринта достаточно выбрать задачи о соблюдении стандартов интерфейса, нежели перечитывать каждую из тысячи задач и осознавать единость правок. Если бы создатели баг-трекинговых систем подразумевали необходимость разнообразия Summary, то кроме обязательности на поле бы навесили ключ уникальности. Почему этого не делается? Да, именно для того, чтобы у вашей команды составился свой список единства задач. Имея универсальные названия, проще выполнять следующее:
- распределять работы между специалистами, например, интерфейсниками и системщиками;
- составлять тест-кейсы, чек-листы обычным копированием из имеющихся подобных, быстрее осуществлять тест-дизайн без необходимости особого обучения или привлечения специалиста;
- планировать время работы над задачей, как программистом, так и тестировщиком;
- унифицировать тексты для Release Notes;
- предоставлять более понятный отчёт руководству.
А когда вам задают вопрос "О чём сие произведение?" вы поясняете его суть и описываете своё мнение, впечатление, осознание или пересказываете сюжет?
Комментариев нет:
Отправить комментарий