Это не проверить в данном контексте, это — подтвердить.
Конечно, всем все понятно, но блин. Ваш чекинг и верифаинг это что-то.
Был СССР, была своя русская терминология.
Отладка.
Забой (backspace кто не в курсе).
Математический адрес.
И так далее. Что-то нам осталось с тех пор — переменная, массив, отладка и т.д. А то, что появилось позже, особенно связанное с процессом разработки ПО — калька. Ныне основным языком является английский, терминология английская. Это печально, но вот так есть.
Здравый смысл у каждого свой — и это прекрасно. Именно из того, что люди неодинаковы и получаются команды, а не набор взаимозаменяемых элементов.
Здесь обычная ошибка — вы путаете интеллектуальный творческий процесс и рутину. Какими бы интеллектуальными и самостоятельными мы ни были, мы все равно все моем руки перед едой и вытираем ноги перед входом. Обязательно. И отмазка «я не буду вытирать ноги, потому что я личность» не к месту. Команда получается из разносторонних людей, т.к. они могут работать с разными проблемами, по-разному смотреть на них. А не потому, что часть команды — обязательные люди, а часть — как бог на душу положит.
Тут все просто — либо есть правила, и они соблюдаются, либо мы наслаждаемся тем, как тестеры и разрабы играют тасками в пинг-понг. Ну, кому что нравится.
Инструкции могут работать, пока их немного, пока они просты, как инструкция по заполнению багрепорта, которая по сути своей — чеклист, позволяющий не забыть, какие данные надо указать
Я говорил именно об этой инструкции.
Слово «всегда» вообще выглядит неуместным, когда речь идет о сколько-то интеллектуальной человеческой деятельности… и далее по тексту
См. выше тезис номер 1 про «я — личность». Заполнение тасков — интеллектуальная, но не творческая деятельность.
Кстати, точное следование инструкциям, даже в высшей степени разумным, называется «итальянская забастовка».
Не совсем так. Итальянская забастовка — это когда делается только то, что есть в инструкции, и на грамм больше. Обязанность следовать инструкции, описывающий минимум, не итальянская забастовка.
Извините, как случайно-то? Я правильно понял (сам не в теме, извините; просто заинтересовало), что нам нужно вычислить хеш, на выходе которого мы и получаем, условно, нужную строку? И вдруг, совершенно случайно, на очередном раунде, имеем на выходе нужную красивую строчку?
Более чем. «Здравый смысл» у каждого свой. Вон у того парня проехать на красный свет — здравый смысл. А чо, никого ж нет.
Такие ситуации, когда что-то делается опционально, должны вносится в инструкцию. Да, любой «здравый смысл» должен быть описан. В данном конкретном случае — если репликация бага простая, не нужно, например, вставлять ролик с записью. Это все оговаривается инструкцией. Что не оговаривается — делается обязательно.
Обновить мало. Надо еще чтоб все причастные перечитали, поняли что изменилось, зачем изменилось и так далее
В чем проблема прочитать? Доводим то тимлидов, они делают в тот же день пятиминутную летучку и объясняют остальным, что поменялось.
Ну и момент, когда уже пора обновлять, надо не упустить. И поди еще обновлять может только строго ограниченный круг лиц?
Это забота начальника отдела тестирования, начальника разработки, ну и может, крупнейших тимлидов.
Впрочем, если вы видите свою задачу как просто точное исполнение записанной инструкции (отступление от которой бьет по карману и прочим нежным местам), то менять ее вряд ли когда понадобится: никто просто не скажет, что что-то в ней не важно, не нужно или устарело — этак и недисциплинированным можно прослыть.
О, какой знакомый разговор. Прям как в жизни, право слово. Вон тот закон нам кажется дурацким — исполнять не будем.
Не, почему ж прослыть недисциплинированным? Наоборот — нашел косяк, хоть в коде, хоть в инструкции, проявил инициативу — молодец.
Принцип простой:
1)Инструкция выполняется. Точно.
2)ВСЕГДА
3)Да, даже если она дурацкая
4)Если она дурацкая — добиваемся внесения изменений, а не сидим на попе ровно, обсуждая в курилке «начальник — дурак».
А вообще, формализм и дисциплина — это немножко разные вещи. Мне так кажется.
Дисциплина — следование правилам. Формализм — следование дурацким правилам без попыток их отменить/изменить, кмк.
— инструкция будет нарушаться ежедневно, просто из соображений здравого смысла
Ну, значит, нарушитель будет лишаться квартальной премии. Проблема-то?
— в какой-то момент (и зачастую довольно скоро) инструкция начнет устаревать и не соответствовать жизни, а обновлять ее никто не будет
Я вас умоляю. Пол-страницы текста обновить несложно.
В общем, фиксация правил и договоренностей — это полезно, но без налаженного взаимодействия, общения и взаимопонимания она ничем не поможет.
Извините, но то, что вы описываете, называется «разгильдяйство». Т.е. в коллективе нет дисциплины. Это проблема совсем иного плана.
У нас, например, решение об упомянутой инструкции принималось коллективно начальником отдела тестирования и самыми крупными тимлидами, которые довели инструкцию до нас, разработчиков попроще. Естественно, ВСЕ поля заполняются только если процесс тестирования сложен. Есть обязательные поля, есть «для сложных случаев». Такая разбивка как раз и сделана исходя «из здравого смысла». Но раз и навсегда, а не так, что каждый сам делает, как хочет. Никому в голову не придет нарушать, просто потому что это не культурно — все равно, извините, что накидать окурков посреди чистого опен-спейса.
А, ну это просто разные инструменты используются.
У нас своя среда со своими заданиями, которые могут быть на фикс, на тестирование и соединяются в цепочки.
Т.е. создан task на проблему, ты работаешь над ней, потом отдаешь тестировщикам, они создают дочерний task на тестирование, и ты не можешь свой закрыть, пока дочерний не закрыт. Они тестируют, находят проблемы — прикрепляют их как дочерние task'и к task'у на тестирование и т.д.
читаем символ, если он А и стейт «начало», идем в стейт «ждем С». Читаем символ, если он С — идем в стейт «ждем D», иначе откатываемся в начало
Ну так, блин, это и есть конечный автомат. Автор описал универсальное, короткое решение.
Таблица легко строится по графу, методы минимизации автомата известны. Соответственно, решение топикстартера лекго поменять. А вот править стену кода…
В этом случае полезным может быть комментарий типа «Дайте информацию, как верифаить, или поверифайте, пожалуйста, сами». Такая фраза, в сочетании с назначением бага на разработчика, работает лучше, чем просто «Дайте информацию, как верифаить».
Почему не разработать обязательную к исполнению внутреннюю инструкцию, которая требует при передаче «дела» разработчиком тестировщику описывать конкретные пункты (как у нас сделали)
1) в чем была проблема
2) как пофикшено
3) изменения с внутренней точки зрения
4) изменения с пользовательской т.з.
5) возможные риски
6) видеозапись-демка, которая показывает, что фикс есть, и все работает, как надо
7) описание в деталях, как проверять (дополнительное тестирование по необычным usecase'ам тестировщики разработают сами).
Можете мне пожалуйста рассказать, как живут студенты на 50€? Без сарказма, мне очень интересно.
В 2006 году у меня была стипендия в 650 рублей (СПБ). Это в те годы примерно 20 евро. У круглых отличников была повышенная — 900р.
Хватало на:
1) Проездной — 300 р для студента
2) Общагу — 300р для бюджетника
3) Ручку и карандаш с линейкой — 50р.
Жил я тогда на 3800-4000р (117 евро), присылаемых родителями. Хватало на нормальную еду и книги.
Было бы интересно узнать, чем он ограничен (шаблоны не в счет — во-первых, они и в дельфи уже давно есть, а во-вторых, у него большая встроенная библиотека — «контейнеры» и прочее присутствует).
В штатах одна из крупных страховых компаний до 2005 года примерно использоваля при обработке мэйнфрйм с 7 битной кодировкой родом из 70-80х.
Незачем менять работающую вещь, если она делает то, что нужно (и если при этом производительности и надежности хватает).
http://habrahabr.ru/post/241955/#comment_8100713
Был СССР, была своя русская терминология.
Отладка.
Забой (backspace кто не в курсе).
Математический адрес.
И так далее. Что-то нам осталось с тех пор — переменная, массив, отладка и т.д. А то, что появилось позже, особенно связанное с процессом разработки ПО — калька. Ныне основным языком является английский, терминология английская. Это печально, но вот так есть.
Здесь обычная ошибка — вы путаете интеллектуальный творческий процесс и рутину. Какими бы интеллектуальными и самостоятельными мы ни были, мы все равно все моем руки перед едой и вытираем ноги перед входом. Обязательно. И отмазка «я не буду вытирать ноги, потому что я личность» не к месту. Команда получается из разносторонних людей, т.к. они могут работать с разными проблемами, по-разному смотреть на них. А не потому, что часть команды — обязательные люди, а часть — как бог на душу положит.
Тут все просто — либо есть правила, и они соблюдаются, либо мы наслаждаемся тем, как тестеры и разрабы играют тасками в пинг-понг. Ну, кому что нравится.
Я говорил именно об этой инструкции.
См. выше тезис номер 1 про «я — личность». Заполнение тасков — интеллектуальная, но не творческая деятельность.
Не совсем так. Итальянская забастовка — это когда делается только то, что есть в инструкции, и на грамм больше. Обязанность следовать инструкции, описывающий минимум, не итальянская забастовка.
Более чем. «Здравый смысл» у каждого свой. Вон у того парня проехать на красный свет — здравый смысл. А чо, никого ж нет.
Такие ситуации, когда что-то делается опционально, должны вносится в инструкцию. Да, любой «здравый смысл» должен быть описан. В данном конкретном случае — если репликация бага простая, не нужно, например, вставлять ролик с записью. Это все оговаривается инструкцией. Что не оговаривается — делается обязательно.
В чем проблема прочитать? Доводим то тимлидов, они делают в тот же день пятиминутную летучку и объясняют остальным, что поменялось.
Это забота начальника отдела тестирования, начальника разработки, ну и может, крупнейших тимлидов.
О, какой знакомый разговор. Прям как в жизни, право слово. Вон тот закон нам кажется дурацким — исполнять не будем.
Не, почему ж прослыть недисциплинированным? Наоборот — нашел косяк, хоть в коде, хоть в инструкции, проявил инициативу — молодец.
Принцип простой:
1)Инструкция выполняется. Точно.
2)ВСЕГДА
3)Да, даже если она дурацкая
4)Если она дурацкая — добиваемся внесения изменений, а не сидим на попе ровно, обсуждая в курилке «начальник — дурак».
Дисциплина — следование правилам. Формализм — следование дурацким правилам без попыток их отменить/изменить, кмк.
{$APPTYPE CONSOLE} и все дела.
Ну, как. Если версия от 5 (1999 г) и новее — New -> Application -> Console application.
По сравнению с чем?
Ну, значит, нарушитель будет лишаться квартальной премии. Проблема-то?
Я вас умоляю. Пол-страницы текста обновить несложно.
Извините, но то, что вы описываете, называется «разгильдяйство». Т.е. в коллективе нет дисциплины. Это проблема совсем иного плана.
У нас, например, решение об упомянутой инструкции принималось коллективно начальником отдела тестирования и самыми крупными тимлидами, которые довели инструкцию до нас, разработчиков попроще. Естественно, ВСЕ поля заполняются только если процесс тестирования сложен. Есть обязательные поля, есть «для сложных случаев». Такая разбивка как раз и сделана исходя «из здравого смысла». Но раз и навсегда, а не так, что каждый сам делает, как хочет. Никому в голову не придет нарушать, просто потому что это не культурно — все равно, извините, что накидать окурков посреди чистого опен-спейса.
У нас своя среда со своими заданиями, которые могут быть на фикс, на тестирование и соединяются в цепочки.
Т.е. создан task на проблему, ты работаешь над ней, потом отдаешь тестировщикам, они создают дочерний task на тестирование, и ты не можешь свой закрыть, пока дочерний не закрыт. Они тестируют, находят проблемы — прикрепляют их как дочерние task'и к task'у на тестирование и т.д.
Насколько ж по-разному головы работают… Мне бы в голову ничего, кроме двухмерного массива не пришло бы.
Извините, без подкола, — а как еще можно представить-то?
Ну так, блин, это и есть конечный автомат. Автор описал универсальное, короткое решение.
Таблица легко строится по графу, методы минимизации автомата известны. Соответственно, решение топикстартера лекго поменять. А вот править стену кода…
Почему не разработать обязательную к исполнению внутреннюю инструкцию, которая требует при передаче «дела» разработчиком тестировщику описывать конкретные пункты (как у нас сделали)
1) в чем была проблема
2) как пофикшено
3) изменения с внутренней точки зрения
4) изменения с пользовательской т.з.
5) возможные риски
6) видеозапись-демка, которая показывает, что фикс есть, и все работает, как надо
7) описание в деталях, как проверять (дополнительное тестирование по необычным usecase'ам тестировщики разработают сами).
«На машине нет колес» — «пофикшено, поставили 2 колеса». Какой же тут фикс? Колес (комплекта) как не было, так и нет.
Тем более, закрываться же баг должен тестером?
В 2006 году у меня была стипендия в 650 рублей (СПБ). Это в те годы примерно 20 евро. У круглых отличников была повышенная — 900р.
Хватало на:
1) Проездной — 300 р для студента
2) Общагу — 300р для бюджетника
3) Ручку и карандаш с линейкой — 50р.
Жил я тогда на 3800-4000р (117 евро), присылаемых родителями. Хватало на нормальную еду и книги.
Незачем менять работающую вещь, если она делает то, что нужно (и если при этом производительности и надежности хватает).