Вы серьёзно предлагаете перебирать посимвольно кусок текста тестировщику, если с этим куском падает приложение? Даже бинарным поиском тестировщик на это потратит в разы больше времени, чем программист с дебаггером, мне кажется.
Да, я понимаю, что это просто пример, но нахожу его как минимум неоднозначным.
Есть у нас один проект, например. Грубо говоря, там есть три различных клиентских приложения — Admin Client, Cashier Client и User Client. При описании какой-нибудь хитрой длинной баги я вполне могу начать называть их AC, CC и UC соответственно. Вероятно, о подобных (но менее очевидных) случаях и идёт речь в статье.
Всё же зависит от проекта в первую очередь, мне думается.
> Как раз чем подробнее — тем лучше. Пусть хоть 10кб текста напишет, это лучше, чем мы что-нибудь упустим.
А у нас вот кодеры ругаются, когда в описании видят простыню текста — они её читают по диагонали и делают основные выводы о баге из его заголовка. Всё же краткость — сестра таланта. Но только когда она рука об руку с ясностью изложения, конечно.
> Чтобы пользователь сокращения использовал?
Вы именно про пользователей продуктом или про пользователей баг-трекером (тестировщиков)? Я довольно часто в некоторых проектах использую. Стараюсь делать это только в тех случаях, когда сокращения очевидны. Например, при тестировании админского клиента для приложения могу использовать AC (Admin Client).
Да, соглашусь, Screenpresso ввиду несколько иной направленности (и, соответственно, функциональности) не в пример более прожорлива. И до минимализма CloudShot не дотягивает. Но мне всё равно понравилось относительная простота аплоада на DropBox и на другие сервисы.
Хорошая статья, спасибо.
Если интересно, в июньском Upgrade Special 2011 года очень неплохо освещали тему 3D — от первых экспериментов, до современных решений (кинотеатры, телевизоры, девайсы для PC, игровые консоли вроде Nintendo 3DS) и прогнозов.
Ниже в комментариях предлагают гексагональное поле. Я вот тоже о нём подумал: соседних ячеек становится шесть, а не восемь — возможно, в таких условиях рождение клетки от двух родителей будет иметь право на жизнь.
Да, я понимаю, что это просто пример, но нахожу его как минимум неоднозначным.
Есть у нас один проект, например. Грубо говоря, там есть три различных клиентских приложения — Admin Client, Cashier Client и User Client. При описании какой-нибудь хитрой длинной баги я вполне могу начать называть их AC, CC и UC соответственно. Вероятно, о подобных (но менее очевидных) случаях и идёт речь в статье.
Всё же зависит от проекта в первую очередь, мне думается.
А у нас вот кодеры ругаются, когда в описании видят простыню текста — они её читают по диагонали и делают основные выводы о баге из его заголовка. Всё же краткость — сестра таланта. Но только когда она рука об руку с ясностью изложения, конечно.
> Чтобы пользователь сокращения использовал?
Вы именно про пользователей продуктом или про пользователей баг-трекером (тестировщиков)? Я довольно часто в некоторых проектах использую. Стараюсь делать это только в тех случаях, когда сокращения очевидны. Например, при тестировании админского клиента для приложения могу использовать AC (Admin Client).
Как мой сейчас, например.
Если интересно, в июньском Upgrade Special 2011 года очень неплохо освещали тему 3D — от первых экспериментов, до современных решений (кинотеатры, телевизоры, девайсы для PC, игровые консоли вроде Nintendo 3DS) и прогнозов.