Ответ:
суббота, 31 декабря 2011 г.
пятница, 30 декабря 2011 г.
Подарка пост
Получен первый презент.
Вот такой- раз:
И два, чтоб понятен габарит был:
Собственно, первому догадавшемуся усб-фонарик или усб-хаб, самовывозом. Ну и респект, хех.
Вот такой- раз:
И два, чтоб понятен габарит был:
Собственно, первому догадавшемуся усб-фонарик или усб-хаб, самовывозом. Ну и респект, хех.
Lesson 58
Друзья, эту уютненькую читают ПМы, тестировщики и программисты?
Как вы считаете, кто должен определять приоритет баг, приоритет работ по исправлению багов?
Проект еще не выдан клиентам. Но вроде уже скоро. Я - не знаю. По ощущениям - что-то не так. Что именно - не могу понять.
Ответ очень важен для меня, особо реквестирую в тред айронбага, картмендуума, астеникса, кодера 117, крузайдера, дибра, думтеста, джекса альтерго, конекошам, редфокса, феликса, ваху, френьку и вол-овл.
Ну а кто аргументирует или расскажет, как у них - вообще молодцы.
Слово Канеру:
Ваш багрепорт представляет вас.
Обычно вы не присутствуете, когда читают ваш багрепорт. Когда ты пишешь репорт, ты просишь программиста (который не у тебя в подчинении) сделать еще кое-какую работу. Программисты редко имеют достаточно времени, чтоб починить все баги. Многие баги чинят спустя несколько часов - или через выходные. Вы же просите их потратить это время на багу, которую вы нашли.
В некоторых компаниях (особенно в тех, кде разработка подходит к концу), менеджеры решают, что исправлять. Лиц, принимающих решения, можно назвать группой контроля за изменениями. (В других компаниях эта группа называется командой проекта, командой сортировки, боевой командой, командой ревью багов). Эти люди определяют стоимость изменения, оценивают время и риски задачи.
Чтоб получить исправленную ошибку, ты должен убедить группу Контроля Изменений заапрувить работу по исправлению бага или убедить программиста исправить его по собственной инициативе (например поздно ночью, когда группа не работает. Убеждение людей за спиной группы может быть правильным решением в одних компаниях и неправильным в других, это зависит от вашей корпоративной культуры). Багрепорт - главное (часто единственное) средство убеждения людей. Вы можете иметь возможность защитить баг перед группой, но во многих компаниях только тестировщики (с тест-лидом и тест-менеджером обсуждают баги. От того, как хорошо вы защитите багу будет зависеть судьба вашего багрепорта.
Как вы считаете, кто должен определять приоритет баг, приоритет работ по исправлению багов?
Проект еще не выдан клиентам. Но вроде уже скоро. Я - не знаю. По ощущениям - что-то не так. Что именно - не могу понять.
Ответ очень важен для меня, особо реквестирую в тред айронбага, картмендуума, астеникса, кодера 117, крузайдера, дибра, думтеста, джекса альтерго, конекошам, редфокса, феликса, ваху, френьку и вол-овл.
Ну а кто аргументирует или расскажет, как у них - вообще молодцы.
Слово Канеру:
Ваш багрепорт представляет вас.
Обычно вы не присутствуете, когда читают ваш багрепорт. Когда ты пишешь репорт, ты просишь программиста (который не у тебя в подчинении) сделать еще кое-какую работу. Программисты редко имеют достаточно времени, чтоб починить все баги. Многие баги чинят спустя несколько часов - или через выходные. Вы же просите их потратить это время на багу, которую вы нашли.
В некоторых компаниях (особенно в тех, кде разработка подходит к концу), менеджеры решают, что исправлять. Лиц, принимающих решения, можно назвать группой контроля за изменениями. (В других компаниях эта группа называется командой проекта, командой сортировки, боевой командой, командой ревью багов). Эти люди определяют стоимость изменения, оценивают время и риски задачи.
Чтоб получить исправленную ошибку, ты должен убедить группу Контроля Изменений заапрувить работу по исправлению бага или убедить программиста исправить его по собственной инициативе (например поздно ночью, когда группа не работает. Убеждение людей за спиной группы может быть правильным решением в одних компаниях и неправильным в других, это зависит от вашей корпоративной культуры). Багрепорт - главное (часто единственное) средство убеждения людей. Вы можете иметь возможность защитить баг перед группой, но во многих компаниях только тестировщики (с тест-лидом и тест-менеджером обсуждают баги. От того, как хорошо вы защитите багу будет зависеть судьба вашего багрепорта.
среда, 28 декабря 2011 г.
Итогов года пост
В лето Господне 1420 конец света не наступил
Хоть многое говорило о том, что наступит
Хоть многое говорило о том, что наступит
А я чо? Рыжий что ли? Я не рыжий, я через несколько лет буду лысый, поэтому тоже хочу итоги года.
В этом году я ни разу не был в Твери.
В этом году я три раза переезжал из одной квартиры в другую.
Сменил пять интернет-провайдеров.
Так и не нашел места, где хочу остаться надолго.
По месяцам:
Январь
В десять раз больше, чем в прошлом году, катался на борде.
Февраль
Умер Френки.
Я захотел рассказать кому-нибудь о том, что я знаю в тестировании.
Март
Я не понимаю, зачем митинги и почая политика.
 |
| Альбом: home |
Апрель
Выступил на девелкампе с рассказом о том, как у нас было с тестированием. Захотелось рассказать - а как надо, и еще - как будет.
Съездил на SQA Days 9. Понравилось.
Май
Дали бойца в группу. Дел мы с ним натворим...
Июнь
Офис переехал на запад.
Июль
Весь месяц играл студентами-практикантами. Тестировали, таскали столы, читали лекции, делали CI и ревью кода.
Дали еще бойца в группу. С учетом временных студентов - в моей группе семеро автоматизаторов.
Август
Я перехал на запад.
Начал переводить Канера. Промежуточный итог - 57 за полгода, примерно 2 в неделю.
 |
| Альбом: home |
Сентябрь
Двух из четырех студентов наняли, одного из них - мне в группу.
Минус один в группе.
Октябрь
Переехал чуть на юг.
 |
| Альбом: home |
Ноябрь
Спорим, много спорим с группой. Пишем классные тесты.
Сходил на митинг. Больше не пойду.
Декабрь
Только в наше направление, только в нашу группу тестирования наняли третью Наташу. Сколько Наташ-тестировщиц ходит по компании - никто уж и не считает...
Ездил на SQA Days 10. Видел живого Астеникса.
Из группы забрали бойца.
вторник, 27 декабря 2011 г.
Есть вопросы
Стоит ли дарить людям книги?
Живые, со страницами и переплетом.
Художественные или того хуже - стихи.
Найденные в третьем по счету магазине, а не просто выбранные.
Вот ты - честно только - обрадуешься?
Я - нет.
Хоть и люблю читать.
Но потом - уже прочтя- пойму и оценю. А сразу как-то нет.
Живые, со страницами и переплетом.
Художественные или того хуже - стихи.
Найденные в третьем по счету магазине, а не просто выбранные.
Вот ты - честно только - обрадуешься?
Я - нет.
Хоть и люблю читать.
Но потом - уже прочтя- пойму и оценю. А сразу как-то нет.
Lesson 57
Слово Канеру:
Сделайте ваш багрепорт эффективным инструментом продаж.
Вне зависимости от того, как вы думаете, багрепорт это инструмент продаж. Он спроектирован для того, чтоб убедить людей расстаться с ресурсами ради получения выгоды. В случае дефектов ресурсы это время и деньги, а выгода - увеличение качества продукта возникающее вследствие фикса баги.
Стратегия продаж, как правило, преследует две цели.
Преподнесите выгоду так, чтоб ее захотели Ваш багрепорт должен ясно дать понять читателю, почему баг нужно исправить. Например, вы могли бы объяснить, как ошибка мешает нормальной работе продукта, какие данные повреждены, или как часто люди будут с ней сталкиваться. Вы могли бы указать на обзор в периодике или иную публикацию, в которой жалуются на подобную ошибку у конкурентов. Вы могли бы процитировать статистику техсаппорта, показывая, что такие баги как этот стоят продукту много денег. Вы могли бы показать, что программа проходила тест в предыдущем релизе (это ключевой показатель в некоторых компаниях). Или вы могли бы указать в репорте на кого-нибудь, чьей работе помешало наличие бага. Во многих случаях, вы могли бы найти еще несколько зависимых баг, с более серьезными последствиями.
Предвидеть возражения и бороться с ними Многие баги отклоняются, как совсем незначительные, невоспроизводимые, непонятные, неповторимые в реальном мире, становящиеся проблемой только в очень специфическом окружении; баги, которые опасно фиксить или не беспокоящие реальных пользователей продукта. Вы могли бы учесть эти возражения, следуя хорошим практикам отчетности: писать ясные и простые проверки, уточнять, что бага повторяется на разных конфигурациях. Другие возражения меняются от дефекта к дефекту, но вы могли бы предвосхитить их и включить в репорт дополнительные сведения. Мы де говорим, что вы должны биться за ошибку. Rarely or never say, "I know you're thinking of not fixing this, but if you think it's unimportant for this reason, then you should know about that." (Вот вообще не понял предложение) Вместо этого мы предлагаем заранее подумать о ключевых возражениях и включить в отчет такие сведения, как "Похожая ошибка была найдена во 2й версии продукта и менеджер техподдержки оценил ее стоимость в $100 000 накладных технических расходов."
Сделайте ваш багрепорт эффективным инструментом продаж.
Вне зависимости от того, как вы думаете, багрепорт это инструмент продаж. Он спроектирован для того, чтоб убедить людей расстаться с ресурсами ради получения выгоды. В случае дефектов ресурсы это время и деньги, а выгода - увеличение качества продукта возникающее вследствие фикса баги.
Стратегия продаж, как правило, преследует две цели.
Преподнесите выгоду так, чтоб ее захотели Ваш багрепорт должен ясно дать понять читателю, почему баг нужно исправить. Например, вы могли бы объяснить, как ошибка мешает нормальной работе продукта, какие данные повреждены, или как часто люди будут с ней сталкиваться. Вы могли бы указать на обзор в периодике или иную публикацию, в которой жалуются на подобную ошибку у конкурентов. Вы могли бы процитировать статистику техсаппорта, показывая, что такие баги как этот стоят продукту много денег. Вы могли бы показать, что программа проходила тест в предыдущем релизе (это ключевой показатель в некоторых компаниях). Или вы могли бы указать в репорте на кого-нибудь, чьей работе помешало наличие бага. Во многих случаях, вы могли бы найти еще несколько зависимых баг, с более серьезными последствиями.
Предвидеть возражения и бороться с ними Многие баги отклоняются, как совсем незначительные, невоспроизводимые, непонятные, неповторимые в реальном мире, становящиеся проблемой только в очень специфическом окружении; баги, которые опасно фиксить или не беспокоящие реальных пользователей продукта. Вы могли бы учесть эти возражения, следуя хорошим практикам отчетности: писать ясные и простые проверки, уточнять, что бага повторяется на разных конфигурациях. Другие возражения меняются от дефекта к дефекту, но вы могли бы предвосхитить их и включить в репорт дополнительные сведения. Мы де говорим, что вы должны биться за ошибку. Rarely or never say, "I know you're thinking of not fixing this, but if you think it's unimportant for this reason, then you should know about that." (Вот вообще не понял предложение) Вместо этого мы предлагаем заранее подумать о ключевых возражениях и включить в отчет такие сведения, как "Похожая ошибка была найдена во 2й версии продукта и менеджер техподдержки оценил ее стоимость в $100 000 накладных технических расходов."
Справедливости пост
МТС молодцы.
Поясню.
Намедни взалкал дешевых GPRS, EDGE и HSDPA интернетов. Местный опсос тарифами не радовал, обратил очи к МТС. Через интерфейс системы "павильон и продавец в ем" приобрел симку и кинул на счет денег.
Был отравлен метилкарбинолом Хворал, потому тупил и забыл взять чек. На счету соответственно оказалось ноль рублей.
О чем с утра депешей известил головную компанию, ни на что особо не претендуя (хуле, чека нет...), но с крайним прискорбием.
И что бы вы думали? Еще до обеда мне сказали, что мое мнение крайне важно. А вчерась так и вовсе - вернули деньги.
Без потрясаний саблями, угроз затаскивания по судам и выкручивания корпоративной символики.
Выводы:
1. Сотрудник техподдержки всегда поймет сотрудника техподдержки, ящитаю.
2. Проблемы не в Системе(тм), а впидорасах и лоботрясах людях на местах.
Поясню.
Намедни взалкал дешевых GPRS, EDGE и HSDPA интернетов. Местный опсос тарифами не радовал, обратил очи к МТС. Через интерфейс системы "павильон и продавец в ем" приобрел симку и кинул на счет денег.
О чем с утра депешей известил головную компанию, ни на что особо не претендуя (хуле, чека нет...), но с крайним прискорбием.
И что бы вы думали? Еще до обеда мне сказали, что мое мнение крайне важно. А вчерась так и вовсе - вернули деньги.
Без потрясаний саблями, угроз затаскивания по судам и выкручивания корпоративной символики.
Выводы:
1. Сотрудник техподдержки всегда поймет сотрудника техподдержки, ящитаю.
2. Проблемы не в Системе(тм), а в
пятница, 23 декабря 2011 г.
Lesson 56
В ноябре я много спорил с бойцами. КВНщики из 80-х емко охарактеризовали суть, в частности, мои доводы:
Зачем делать сложным то, что лучше не делать.
Слово Канеру:
Защита багов - драйвер их исправления.
Каждый багрепорт, который вы написали, является требованием исправления ошибки.
Некоторые баги никогда не будут исправлены. Вы отвечаете не за то, чтоб все баги были исправлены, вы отвечаете за то, чтоб все баги были зарепорчены аккуратно, так, чтоб читатель понял, в чем они заключаются и осознал всю важность проблемы.
Насколько хорошо вы исследуете и зарепортите баг, настолько выше будет вероятность того, что ошибка будет исправлена.
Зачем делать сложным то, что лучше не делать.
Слово Канеру:
Защита багов - драйвер их исправления.
Каждый багрепорт, который вы написали, является требованием исправления ошибки.
Некоторые баги никогда не будут исправлены. Вы отвечаете не за то, чтоб все баги были исправлены, вы отвечаете за то, чтоб все баги были зарепорчены аккуратно, так, чтоб читатель понял, в чем они заключаются и осознал всю важность проблемы.
Насколько хорошо вы исследуете и зарепортите баг, настолько выше будет вероятность того, что ошибка будет исправлена.
Lesson 55
С тех пор как wurstenator'а забрали в другой проект - нас в кабинете два человека.
Заказал диван, посмотрим, добудут ли.
Кстати, вот так незаметно - дошли до 4-го чаптера.
Слово Канеру:
Chapter 4 Защита багов.
Тестировцик, не умеющий сообщить об ошибке, похож на холодильник, в котором свет горит только когда дверца закрыта. Ситуацию можно осветить очень хорошо - но так, что все это не будет иметь смысла. Вы - информационная служба, но чтобы быть эффективными, ван нужно сделать большее, чем просто заполнить пробелы в отчетах и предположить, что вас понимают. Учитель писать и сообщать о результатах тестирования так, чтоб заказчики действительно получили эти результаты. Мы называем это "защитой багов".
Ты это то, что ты пишешь.
Багрепорты это основная работа большинства тестировщиков. Через эти документы читатели воспринимают вас. Чем лучше твои репорты, тем выше твоя репутация.
Программисты полагаются на ваши отчеты. Хороший репорт о хорошей баге - работает на вашу репутацию. Слабый отчет создает дополнительную (и, по их мнению, ненужную) работу для программистов. Если вы тратите много их времени, они будут избегать вас и работы с вами.
Программисты - не единственна ваша аудитория. Менеджмент и руководство иногда читают багрепорты, а они могут взять на заметку какой-нибудь баг и вымотать много нервов. Отчеты-обвинения, эмоциональные, слишком краткие, недостаточно аргументированные - могут создать о вас негативное впечатление в умах людей, принимающих решения.
И напротив, вы получаете все преимущества, если вы тратите время на то, чтоб написать отчет хорошо.
Заказал диван, посмотрим, добудут ли.
Кстати, вот так незаметно - дошли до 4-го чаптера.
Слово Канеру:
Chapter 4 Защита багов.
Тестировцик, не умеющий сообщить об ошибке, похож на холодильник, в котором свет горит только когда дверца закрыта. Ситуацию можно осветить очень хорошо - но так, что все это не будет иметь смысла. Вы - информационная служба, но чтобы быть эффективными, ван нужно сделать большее, чем просто заполнить пробелы в отчетах и предположить, что вас понимают. Учитель писать и сообщать о результатах тестирования так, чтоб заказчики действительно получили эти результаты. Мы называем это "защитой багов".
Ты это то, что ты пишешь.
Багрепорты это основная работа большинства тестировщиков. Через эти документы читатели воспринимают вас. Чем лучше твои репорты, тем выше твоя репутация.
Программисты полагаются на ваши отчеты. Хороший репорт о хорошей баге - работает на вашу репутацию. Слабый отчет создает дополнительную (и, по их мнению, ненужную) работу для программистов. Если вы тратите много их времени, они будут избегать вас и работы с вами.
Программисты - не единственна ваша аудитория. Менеджмент и руководство иногда читают багрепорты, а они могут взять на заметку какой-нибудь баг и вымотать много нервов. Отчеты-обвинения, эмоциональные, слишком краткие, недостаточно аргументированные - могут создать о вас негативное впечатление в умах людей, принимающих решения.
И напротив, вы получаете все преимущества, если вы тратите время на то, чтоб написать отчет хорошо.
вторник, 20 декабря 2011 г.
Рутина
Помнится, еще М. Дорофеев говорил, что не надо автоматизировать бардак. Потому как получится автоматизированный бардак.
Такой вопрос: если команда работает плохо - поможет ли ей KPI?
А если команда работает хорошо - зачем ей KPI?
Анекдот в тему:
Лежит Каа. Прибегает Маугли:
- Каа, Каа, рыжие собаки бросили нам вызов!
Каа:
- Нууу...
Маугли:
-Балу принял вызов!
Каа:
- Нууу...
Маугли:
- И Акела принял вызов!!
Каа):
- Нууу...
Маугли:
- И Маугли принял вызов!!
Каа:
- Нууу?
Маугли:
- Ну и ты, ты, Каа, тоже принял вызов!!!
Каа:
- Бля...
Такой вопрос: если команда работает плохо - поможет ли ей KPI?
А если команда работает хорошо - зачем ей KPI?
Анекдот в тему:
Лежит Каа. Прибегает Маугли:
- Каа, Каа, рыжие собаки бросили нам вызов!
Каа:
- Нууу...
Маугли:
-Балу принял вызов!
Каа:
- Нууу...
Маугли:
- И Акела принял вызов!!
Каа):
- Нууу...
Маугли:
- И Маугли принял вызов!!
Каа:
- Нууу?
Маугли:
- Ну и ты, ты, Каа, тоже принял вызов!!!
Каа:
- Бля...
Я просто оставлю это здесь
Bugs and Battleships
by Edward Z. Yang
http://blog.ezyang.com/2011/12/bugs-and-battleships/
by Edward Z. Yang
http://blog.ezyang.com/2011/12/bugs-and-battleships/
понедельник, 19 декабря 2011 г.
Ы!
М. Дорофеев, презентация Shewhart, 6-Sigma and snowflake-men
Избранные цитаты:
Нужно ли думать что он - человек снежинка с руками из жопы?
У запора и диареи KPI - время сидения в туалете - одинаковые. Но лечить мы их будем по разному.
Ну это смех, а вообще - посмотрите, там интересно.
Избранные цитаты:
Нужно ли думать что он - человек снежинка с руками из жопы?
 |
| Альбом: bug |
У запора и диареи KPI - время сидения в туалете - одинаковые. Но лечить мы их будем по разному.
Ну это смех, а вообще - посмотрите, там интересно.
суббота, 17 декабря 2011 г.
Lesson 54
Таки лекции вернулись и никуда не денутся, просто занят был.
Пару дней работе почти ничего не мешало, сегодня вечером споткнулся на верстке. И кстати, начинаю ощущать нехватку теоретических знаний.
Где-то читал, что самая большая необходимость в обучении для профессиональной реализации у врачей - вроде как быстрее и кардинальней меняются методы диагностики и лечения.
Если отбросить аспект критичности их работы, то у них хотя бы объект работы - организм - остается более менее один.
Хорошая песня, про выборы.
Выбери любого, главное выбери, не зря же тебе право выбирать, блядь, выбили!
Слово Канеру:
Классификация техник тестирования зависит от того, что вы о них думаете.
You might be puzzled about why we placed particular techniques where we did (ну не получилось у меня это перевести). Если так, то у меня для вас хорошая новость - ваш мозг включен. Вспомните, любое тестирование включает в себя все пять аспектов Five-Fold System. Мы перечислили техники по категориям, чтобы просто дать вам почувствовать разницу и выделить случаи, когда одни виды мышления превалируют над другими. Ваше мнение может быть иным. Например, один читатель спорил с нами о том, что нагрузочное тестирование может быть классифицировано как проблемно-ориентированное тестирование, а не как тестирование, основанное на активности(виде деятельности). Наш ответ - вы можете думать об этом в любом ключе.
Давайте посмотрим на это в проблемно-ориентированном ключе:
- Вы можете думать о нагрузочном тестировании в терминах эффекта от атак на отказ в обслуживании. Атакующий может попытаться добиться отказа сервиса путем создания большого количества соединений или используя большое количество памяти (одновременно выполняя каждым пользователем действия, интенсивно использующие память) или вызывая задачи, активно использующие процессор. Вы должны выполнить разные тесты для каждого из этих рисков.
Теперь рассмотрим эту деятельность в перспективе активности:
- Используете инструмент для отслеживания моделей поведения ваших клиентов. Какие команды они выполняют чаще всего? Какие задачи чаще всего пытаются решить? Какой процент клиентов проявляет ту или иную активность? Когда у вас появится модель поведения пользователей, используйте инструмент для нагрузочного тестирования и выполните тест по сценариям, которые согласованы с видами деятельности пользователя. Этот инструмент может случайным образом выбирать сценарий - по сути, создавать различные сессии. которые соответствуют различным типам поведения пользователей. Продолжайте добавлять сессии и наблюдайте как производительность и надежность системы уменьшаются с увеличением нагрузки. По необходимости - вносите в ваш продукт изменения.
Если вы думаете в терминах рисков, вы думаете о слабых местах программы и спрашиваете, как спроектировать тесты, которые эти слабости выявят. Когда вы знаете, какой тип теста вы хотите запустить, думайте о пути. которым вы его хотите провести. Если вы тестируете телефонию, вам может понадобиться инструмент или десять друзей, которые создадут серию звонков. Критерий проектирования теста - он должен иметь возможность обнаружить проблему, которую вы ищете.
В противоположность этому, если вы мыслите в терминах активностей, вы спрашиваете себя, как провести нагрузочное тестирование. Каким инструментом? Что делает этот инструмент? И так далее. Ожидается, что если вы используете инструмент грамотно, модель поведения клиентов составлена верно, а также поведены остальные мероприятия, связанные с качественным нагрузочным тестированием, то вы, вероятно, найдете те типы ошибок, которые способно выявить нагрузочное тестирование.
Классификация может не быть точной, но сам факт ее проведения может много вам дать. Однако, как бы вы ни классифицировали технику, например, нагрузочное тестирование, когда придет время, перед вами будут стоять все те же пять вопросов:
1. Кто будет тестировать?
2. Какие аспекты программы будут тестироваться?
3. Какие типы проблем мы будем искать?
4. Какие задачи будут выполнены при тестировании?
5. Как вы будете оценивать результаты?
Пару дней работе почти ничего не мешало, сегодня вечером споткнулся на верстке. И кстати, начинаю ощущать нехватку теоретических знаний.
Где-то читал, что самая большая необходимость в обучении для профессиональной реализации у врачей - вроде как быстрее и кардинальней меняются методы диагностики и лечения.
Если отбросить аспект критичности их работы, то у них хотя бы объект работы - организм - остается более менее один.
Хорошая песня, про выборы.
Выбери любого, главное выбери, не зря же тебе право выбирать, блядь, выбили!
Слово Канеру:
Классификация техник тестирования зависит от того, что вы о них думаете.
You might be puzzled about why we placed particular techniques where we did (ну не получилось у меня это перевести). Если так, то у меня для вас хорошая новость - ваш мозг включен. Вспомните, любое тестирование включает в себя все пять аспектов Five-Fold System. Мы перечислили техники по категориям, чтобы просто дать вам почувствовать разницу и выделить случаи, когда одни виды мышления превалируют над другими. Ваше мнение может быть иным. Например, один читатель спорил с нами о том, что нагрузочное тестирование может быть классифицировано как проблемно-ориентированное тестирование, а не как тестирование, основанное на активности(виде деятельности). Наш ответ - вы можете думать об этом в любом ключе.
Давайте посмотрим на это в проблемно-ориентированном ключе:
- Вы можете думать о нагрузочном тестировании в терминах эффекта от атак на отказ в обслуживании. Атакующий может попытаться добиться отказа сервиса путем создания большого количества соединений или используя большое количество памяти (одновременно выполняя каждым пользователем действия, интенсивно использующие память) или вызывая задачи, активно использующие процессор. Вы должны выполнить разные тесты для каждого из этих рисков.
Теперь рассмотрим эту деятельность в перспективе активности:
- Используете инструмент для отслеживания моделей поведения ваших клиентов. Какие команды они выполняют чаще всего? Какие задачи чаще всего пытаются решить? Какой процент клиентов проявляет ту или иную активность? Когда у вас появится модель поведения пользователей, используйте инструмент для нагрузочного тестирования и выполните тест по сценариям, которые согласованы с видами деятельности пользователя. Этот инструмент может случайным образом выбирать сценарий - по сути, создавать различные сессии. которые соответствуют различным типам поведения пользователей. Продолжайте добавлять сессии и наблюдайте как производительность и надежность системы уменьшаются с увеличением нагрузки. По необходимости - вносите в ваш продукт изменения.
Если вы думаете в терминах рисков, вы думаете о слабых местах программы и спрашиваете, как спроектировать тесты, которые эти слабости выявят. Когда вы знаете, какой тип теста вы хотите запустить, думайте о пути. которым вы его хотите провести. Если вы тестируете телефонию, вам может понадобиться инструмент или десять друзей, которые создадут серию звонков. Критерий проектирования теста - он должен иметь возможность обнаружить проблему, которую вы ищете.
В противоположность этому, если вы мыслите в терминах активностей, вы спрашиваете себя, как провести нагрузочное тестирование. Каким инструментом? Что делает этот инструмент? И так далее. Ожидается, что если вы используете инструмент грамотно, модель поведения клиентов составлена верно, а также поведены остальные мероприятия, связанные с качественным нагрузочным тестированием, то вы, вероятно, найдете те типы ошибок, которые способно выявить нагрузочное тестирование.
Классификация может не быть точной, но сам факт ее проведения может много вам дать. Однако, как бы вы ни классифицировали технику, например, нагрузочное тестирование, когда придет время, перед вами будут стоять все те же пять вопросов:
1. Кто будет тестировать?
2. Какие аспекты программы будут тестироваться?
3. Какие типы проблем мы будем искать?
4. Какие задачи будут выполнены при тестировании?
5. Как вы будете оценивать результаты?
Lesson 53
Слово Канеру:
Техники тестирования основанные на том, как вы оцениваете результаты теста.
Техники, основанные на оценках описывают способы, с помощью которых можно определить, прошла ли программа тест. Они не говорят о том, как будет проходить тест или какую информацию мы будем собирать. Они говорят о том, как мы будем оценивать собранные данные.
Самопроверяющиеся данные Собранные данные несут в себе информацию, позволяющую определить, были ли выходные значения программы корректными.
Сравнение с ранее сохраненными результатами Регрессионное тестирование (обычно, но не всегда автоматизируемое) определяет прошел тест или нет путем сравнения результатов, которые мы получили сегодня с результатами, полученными на прошлой неделе. И если результаты были верны на прошлой неделе и изменились сегодня, то разница дает нам повод подозревать наличие нового дефекта.
Сравнение со спецификацией или надежным документом Несоответствие спецификации, вероятно, означает ошибку.
Эвристическая согласованность Согласованность - важный критерий оценки программы. Несогласованность может быть причиной регистрации дефекта или отражать изменения в архитектуре программы. Мы выделяем семь основных согласованностей:
1. Согласованность с историей. Нынешнее поведение функции соответствует ее прошлому поведению.
2. Согласованность с вашим представлением. Функция ведет себя согласно тому, как вы себе представляете организацию продукта.
3. Согласованность с аналогичными продуктами. Функция ведет себя подобно тому, как ведут себя такие функции в аналогах продукта.
4. Согласованность претензий. Функция ведет себя так, как люди говорят, что она должна себя вести.
5. Согласованность с ожиданиями пользователя. Поведение функция соответствует тому, что мы думаем, что хотят пользователи.
6. Согласованность с продуктом. Поведение функции соответствует поведению сопоставимых функций продукта или функциональных моделей продукта.
7. Согласованность с целями. Функция ведет себя согласно ее прямому назначению.
тестирование по оракулу Оракул - это инструмент оценки, который может сообщить, прошла ли программа тест или нет. В высоконагруженных автоматизированных системах оракулом часто является другая программа, которая генерирует результаты или проверки. Оракулу обычно больше доверяют, чем тестируемой программе, поэтому проблемы, выявленные им, как правило, стоят времени и сил для проверки.
Техники тестирования основанные на том, как вы оцениваете результаты теста.
Техники, основанные на оценках описывают способы, с помощью которых можно определить, прошла ли программа тест. Они не говорят о том, как будет проходить тест или какую информацию мы будем собирать. Они говорят о том, как мы будем оценивать собранные данные.
Самопроверяющиеся данные Собранные данные несут в себе информацию, позволяющую определить, были ли выходные значения программы корректными.
Сравнение с ранее сохраненными результатами Регрессионное тестирование (обычно, но не всегда автоматизируемое) определяет прошел тест или нет путем сравнения результатов, которые мы получили сегодня с результатами, полученными на прошлой неделе. И если результаты были верны на прошлой неделе и изменились сегодня, то разница дает нам повод подозревать наличие нового дефекта.
Сравнение со спецификацией или надежным документом Несоответствие спецификации, вероятно, означает ошибку.
Эвристическая согласованность Согласованность - важный критерий оценки программы. Несогласованность может быть причиной регистрации дефекта или отражать изменения в архитектуре программы. Мы выделяем семь основных согласованностей:
1. Согласованность с историей. Нынешнее поведение функции соответствует ее прошлому поведению.
2. Согласованность с вашим представлением. Функция ведет себя согласно тому, как вы себе представляете организацию продукта.
3. Согласованность с аналогичными продуктами. Функция ведет себя подобно тому, как ведут себя такие функции в аналогах продукта.
4. Согласованность претензий. Функция ведет себя так, как люди говорят, что она должна себя вести.
5. Согласованность с ожиданиями пользователя. Поведение функция соответствует тому, что мы думаем, что хотят пользователи.
6. Согласованность с продуктом. Поведение функции соответствует поведению сопоставимых функций продукта или функциональных моделей продукта.
7. Согласованность с целями. Функция ведет себя согласно ее прямому назначению.
тестирование по оракулу Оракул - это инструмент оценки, который может сообщить, прошла ли программа тест или нет. В высоконагруженных автоматизированных системах оракулом часто является другая программа, которая генерирует результаты или проверки. Оракулу обычно больше доверяют, чем тестируемой программе, поэтому проблемы, выявленные им, как правило, стоят времени и сил для проверки.
пятница, 16 декабря 2011 г.
Второе пришествие
Второе пришествие меня на sqa days состоялось. После девятой я доложился, мол, привез Наташу.
В этот раз приехал с примкнувшей Олей из соседнего отдела. Наташа тоже была, но не та, что прошлый, новая.
Вот ее портрет, кстати:
И в следующий раз будет новая Наташка. У нас этого добра полно.
Пока шли от метро, смотрели на гостиницу "Орехово", жалели, что наша бронь в "Царицыно". Это я уж потом понял, что жалели зря.
Ролик сняли какой-то нудноватый. Неясно, чего там колдовали руки. У казанцев в прошлый раз поживее получилось.
По докладам, ведь мое мнение крайне важно для вас.
Алексей Лянгузов Грамотная работа с дефект-трекером -- путь к успеху! Хороший, годный доклад про то, что и у программистов на собеседовании надо спрашивать умение работать с дефект трекером.
Заметки на полях: Статус - надо ли что-то делать, подстатус - что именно. Ответственный - тот, кто должен изменить код. Не настраивать воркфлоу жестко, разрешать любые переходы, но с аргументированием.
Александр Барановский Собеседование тестировщиков: что спросить и как ответить К собеседованию нужно готовиться, и, стало быть, понимать, что и зачем ты спрашиваешь. Спасибо, кэп.
Мои мысли: да, как же это классно, когда на собеседование приходят опытные тестировщики, им можно задавать умные и сложные вопросы. Только у нас не получается весело поболтать, потому как все опытные тестировщики города работают либо у нас либо у 1-2 конкурирующих компаний, которые ими упорно не хотят делиться.
Виктор Малый TPI Next®: оптимизируем процессы тестирования по-взрослому Очередная модель чвототам. Докладчик бойко рассказывал, отвечал и не отвечал на вопросы. Но уже есть TMMi. И их уже слишком много.
Роман Юферев О чем мы забываем в QA или “Знакомьтесь – Manageability!” Жог напалмом. Радовал и приводил примеры.
Заметки: Думайте заранее, блядь! Заранее, блядь, думайте. Проблемы не только и не столько от баг, сколько от сбоев. И их надо тестировать. Ибо кто, если не мы? Мне, как бывшему бойцу техподдержки сие близко, да.
Юлия Нечаева Команда, где каждый лидер
- Лидерство!
- Дааааааааа!
- Ответственность!
- Ото ж!
- Команда!
- Еще бы!
- Высокое качество!
- Конечно!
- Мы команда профессионалов!
- Дааааа! Ураааа!
Глеб Рыбалко Оценки имеют значение. Практические советы по оценке задач тестирования на каждый день Оценки в скрам и Agile своими словами, не?
Татьяна Зинченко Вредные советы для тестирования юзабилити Весело. Зажигательно. Интересно. Читайте Якоба Нильсена и Рольфа Молича. Лозунг: Интернет не для юзеров!
Только при чем тут тестирование? Доклад о проектировании интерфейсов.
Илья Фомин Вирусное тестирование. Что-то новое в конфигурационном тестировании Прикольно, забавно, но не мой домен, у нас серверная ява, вся конфигурация - тюнинг jvm.
Заметки: На этот доклад пошел методом исключения, а также потомушто Илья быстро говорит и мало капитанит. Исключил Наташу Руколь - ну не нравятся мне ее доклады, что поделаешь. Исключил "Качество софта ДО и ПОСЛЕ защиты" - у нас FOSS, нас невалнуэт.
Владимир Лысенко Увеличиваем мощь фреймворка: KDT & генератор тестов в TestComplete Междумордие DSL или как автоматизаторам сбагрить написание сценариев. Практическое руководство. Но - прозреваю значительное увеличение трудозатрат на техподдержку.
Николай Алименков DSL, Page Object и WebDriver – путь к надежным функциональным тестам Однозначный зачет. Были исходники.
Заметки: комментирование кода - для слабаков. Или для небольших проектов. Или для автоматизатора, который пишет тесты один.
Я то думал - мы с wurstenator и entarrion лабаем тесты, а Николай объяснил, что мы пишем на DSL согласно ODT и частично BDT.
Интересно было посмотреть, как другие специалисты решают проблему удаления тестовых данных. Решают они ее просто - они их, блин, не удаляют.
Первый час рассказывал, что рефакторинг, это, блядь, хорошо! А вот потом пошел цымес, да.
Подтвердил некоторые мои догадки, добавил пару идей. Думаю, что самый полезный для меня доклад.
В финале выступил А. Баранцев, сорвал покровы с webdrivera, показал пальцем на аудиторию и сказал: "А ты - выложил свой фреймворк на гитхаб?". Каюсь, мы не выложили.
Круглый стол "Сообщества тестировщиков. Старт дан. И что дальше?" Основной вопрос - откуда в Костроме столько тестировщиков? 0_о А в остальном - славно поговорили.
В кулуарах спросил Астеникса, что б такое натворить, чтоб взлабать у себя в городе сообщество. Он выразил мысль, что вряд-ли получится заставить сообщество быть. Жизнеспособней вариант, когда оформляется в сообщество уже существующая группа. Я буду эту мысль думать, чо.
Я знаком с одной жизнеспособной группой по it-интересам в ебурге, он она состоит из тестировщика, сисадмина и серверной техподдержки. Не получится даже сообщество любителей пива, 2 из трех почти не пьют. Как официально самоназваться-то?
Александр Александров Оценка трудозатрат на тестирование в проектах сопровождения Статистику нужно не только собирать, но и обрабатывать. И делать правильные выводы, да.
Павел Павлов Автоматизированное тестирование клиентской производительности Крайне полезный и актуальный для меня доклад... был бы, если бы, да кабы. В части теории и так все ясно, нужна была конкретика, тонкости, нюансы и исходники. Их не было, была ссылка на платный продукт, oh shi...
Евгения Фирсова Очередь на тестирование Зачетно проклассифицировала очереди. Причины. Последствия. Серебрянных пуль не давала. Статистику не вела. Мы статистику ведем, видим тенденции и тренды. Но с пулями тоже беда, декреты и насморки не запланируешь.
Андрей Терехин Автоматизация тестирования модели разграничения прав доступа к функционалу Хороший доклад для меня ибо домен близкий.
- Как тестировать права?
- Леххко! Берем эксель и разворачиваем 10 трехмерных матриц в плоскость.
- Что делать с получившимися 8 000 - 16 000 сценариями?
- Леххко! Кладем болт на атомарность, тестируем по 3-10 условий зараз.
- Что делать с получившейся 1000 длиннотестов?
- Леххко. Фигачить их.
- Что делать, когда на поддержку всей этой ереси будет уходить 40 часов за 5 рабочих дней?
- Хз, но уже страшно.
Алексей Лупан Качество отсутствует, коль баги присутствуют Этот доклад Алексей сперва рассказал участникам конференции по отдельности, а уже потом всем вместе. Хороший, индивидуальный подход, мне нравится.
Заметки: Качество не бывает второй свежести, оно или есть или его нет. Тестировщики работают по правилу мертвеца - они могут сделать не плохо. Хорошо они сделать не могут. Но - кто если не мы? Надо влиять: угрозами, подкупом и грубой лестью.
Теперь - фотки.
наташки и Оля:
Я:
Резюме:
Хорошо съездил. Больше не поеду.
В этот раз приехал с примкнувшей Олей из соседнего отдела. Наташа тоже была, но не та, что прошлый, новая.
Вот ее портрет, кстати:
 |
| Альбом: office |
И в следующий раз будет новая Наташка. У нас этого добра полно.
Пока шли от метро, смотрели на гостиницу "Орехово", жалели, что наша бронь в "Царицыно". Это я уж потом понял, что жалели зря.
Ролик сняли какой-то нудноватый. Неясно, чего там колдовали руки. У казанцев в прошлый раз поживее получилось.
По докладам, ведь мое мнение крайне важно для вас.
Алексей Лянгузов Грамотная работа с дефект-трекером -- путь к успеху! Хороший, годный доклад про то, что и у программистов на собеседовании надо спрашивать умение работать с дефект трекером.
Заметки на полях: Статус - надо ли что-то делать, подстатус - что именно. Ответственный - тот, кто должен изменить код. Не настраивать воркфлоу жестко, разрешать любые переходы, но с аргументированием.
Александр Барановский Собеседование тестировщиков: что спросить и как ответить К собеседованию нужно готовиться, и, стало быть, понимать, что и зачем ты спрашиваешь. Спасибо, кэп.
Мои мысли: да, как же это классно, когда на собеседование приходят опытные тестировщики, им можно задавать умные и сложные вопросы. Только у нас не получается весело поболтать, потому как все опытные тестировщики города работают либо у нас либо у 1-2 конкурирующих компаний, которые ими упорно не хотят делиться.
Виктор Малый TPI Next®: оптимизируем процессы тестирования по-взрослому Очередная модель чвототам. Докладчик бойко рассказывал, отвечал и не отвечал на вопросы. Но уже есть TMMi. И их уже слишком много.
Роман Юферев О чем мы забываем в QA или “Знакомьтесь – Manageability!” Жог напалмом. Радовал и приводил примеры.
Заметки: Думайте заранее, блядь! Заранее, блядь, думайте. Проблемы не только и не столько от баг, сколько от сбоев. И их надо тестировать. Ибо кто, если не мы? Мне, как бывшему бойцу техподдержки сие близко, да.
Юлия Нечаева Команда, где каждый лидер
- Лидерство!
- Дааааааааа!
- Ответственность!
- Ото ж!
- Команда!
- Еще бы!
- Высокое качество!
- Конечно!
- Мы команда профессионалов!
- Дааааа! Ураааа!
Глеб Рыбалко Оценки имеют значение. Практические советы по оценке задач тестирования на каждый день Оценки в скрам и Agile своими словами, не?
Татьяна Зинченко Вредные советы для тестирования юзабилити Весело. Зажигательно. Интересно. Читайте Якоба Нильсена и Рольфа Молича. Лозунг: Интернет не для юзеров!
Только при чем тут тестирование? Доклад о проектировании интерфейсов.
Илья Фомин Вирусное тестирование. Что-то новое в конфигурационном тестировании Прикольно, забавно, но не мой домен, у нас серверная ява, вся конфигурация - тюнинг jvm.
Заметки: На этот доклад пошел методом исключения, а также потомушто Илья быстро говорит и мало капитанит. Исключил Наташу Руколь - ну не нравятся мне ее доклады, что поделаешь. Исключил "Качество софта ДО и ПОСЛЕ защиты" - у нас FOSS, нас невалнуэт.
Владимир Лысенко Увеличиваем мощь фреймворка: KDT & генератор тестов в TestComplete Междумордие DSL или как автоматизаторам сбагрить написание сценариев. Практическое руководство. Но - прозреваю значительное увеличение трудозатрат на техподдержку.
Николай Алименков DSL, Page Object и WebDriver – путь к надежным функциональным тестам Однозначный зачет. Были исходники.
Заметки: комментирование кода - для слабаков. Или для небольших проектов. Или для автоматизатора, который пишет тесты один.
Я то думал - мы с wurstenator и entarrion лабаем тесты, а Николай объяснил, что мы пишем на DSL согласно ODT и частично BDT.
Интересно было посмотреть, как другие специалисты решают проблему удаления тестовых данных. Решают они ее просто - они их, блин, не удаляют.
Первый час рассказывал, что рефакторинг, это, блядь, хорошо! А вот потом пошел цымес, да.
Подтвердил некоторые мои догадки, добавил пару идей. Думаю, что самый полезный для меня доклад.
В финале выступил А. Баранцев, сорвал покровы с webdrivera, показал пальцем на аудиторию и сказал: "А ты - выложил свой фреймворк на гитхаб?". Каюсь, мы не выложили.
Круглый стол "Сообщества тестировщиков. Старт дан. И что дальше?" Основной вопрос - откуда в Костроме столько тестировщиков? 0_о А в остальном - славно поговорили.
В кулуарах спросил Астеникса, что б такое натворить, чтоб взлабать у себя в городе сообщество. Он выразил мысль, что вряд-ли получится заставить сообщество быть. Жизнеспособней вариант, когда оформляется в сообщество уже существующая группа. Я буду эту мысль думать, чо.
Я знаком с одной жизнеспособной группой по it-интересам в ебурге, он она состоит из тестировщика, сисадмина и серверной техподдержки. Не получится даже сообщество любителей пива, 2 из трех почти не пьют. Как официально самоназваться-то?
Александр Александров Оценка трудозатрат на тестирование в проектах сопровождения Статистику нужно не только собирать, но и обрабатывать. И делать правильные выводы, да.
Павел Павлов Автоматизированное тестирование клиентской производительности Крайне полезный и актуальный для меня доклад... был бы, если бы, да кабы. В части теории и так все ясно, нужна была конкретика, тонкости, нюансы и исходники. Их не было, была ссылка на платный продукт, oh shi...
Евгения Фирсова Очередь на тестирование Зачетно проклассифицировала очереди. Причины. Последствия. Серебрянных пуль не давала. Статистику не вела. Мы статистику ведем, видим тенденции и тренды. Но с пулями тоже беда, декреты и насморки не запланируешь.
Андрей Терехин Автоматизация тестирования модели разграничения прав доступа к функционалу Хороший доклад для меня ибо домен близкий.
- Как тестировать права?
- Леххко! Берем эксель и разворачиваем 10 трехмерных матриц в плоскость.
- Что делать с получившимися 8 000 - 16 000 сценариями?
- Леххко! Кладем болт на атомарность, тестируем по 3-10 условий зараз.
- Что делать с получившейся 1000 длиннотестов?
- Леххко. Фигачить их.
- Что делать, когда на поддержку всей этой ереси будет уходить 40 часов за 5 рабочих дней?
- Хз, но уже страшно.
Алексей Лупан Качество отсутствует, коль баги присутствуют Этот доклад Алексей сперва рассказал участникам конференции по отдельности, а уже потом всем вместе. Хороший, индивидуальный подход, мне нравится.
Заметки: Качество не бывает второй свежести, оно или есть или его нет. Тестировщики работают по правилу мертвеца - они могут сделать не плохо. Хорошо они сделать не могут. Но - кто если не мы? Надо влиять: угрозами, подкупом и грубой лестью.
Теперь - фотки.
наташки и Оля:
 |
| Альбом: office |
Я:
 |
| Альбом: office |
Резюме:
Хорошо съездил. Больше не поеду.
четверг, 15 декабря 2011 г.
Holy shit
Заявление
"У нас большая и сильная команда/отдел тестирования"
для коммерческих продуктов можно перевести как
"мы настолько тупы, что исправляем ошибки, а не предотвращаем".
Дискасс.
"У нас большая и сильная команда/отдел тестирования"
для коммерческих продуктов можно перевести как
"мы настолько тупы, что исправляем ошибки, а не предотвращаем".
Дискасс.
Хех
Тридцать из тридцати.
http://nazva.net/logic_test1/
Удивительно, задачки за шестой-восьмой класс, но более двух третей людей с двумя высшими образованиями не могут правильно ответить на эти вопросы.
Кстати, какие свойства логических операций вы помните навскидку? Я транзитивность, ассоциативность, симметричность. Или симметричность это свойство отношения, а не операции?
http://nazva.net/logic_test1/
Удивительно, задачки за шестой-восьмой класс, но более двух третей людей с двумя высшими образованиями не могут правильно ответить на эти вопросы.
Кстати, какие свойства логических операций вы помните навскидку? Я транзитивность, ассоциативность, симметричность. Или симметричность это свойство отношения, а не операции?
Так
Как то так:
http://kirguduev.livejournal.com/502184.html
- Ты многое забыл, - проворчал Странник. - Ты забыл про передвижные излучатели, ты забыл про Островную Империю, ты забыл про экономику... Тебе известно, что в стране инфляция?.. Тебе вообще известно, что такое инфляция? Тебе известно, что надвигается голод, что земля не родит?.. Тебе известно, что мы не успели создать здесь ни запасов хлеба, ни запасов медикаментов? Ты знаешь, что это твое лучевое голодание в двадцати процентах случаев приводит к шизофрении? А? - Он вытер ладонью могучий залысый лоб. - Нам нужны врачи... двенадцать тысяч врачей. Нам нужны белковые синтезаторы. Нам необходимо дезактивировать сто миллионов гектаров зараженной почвы - для начала. Нам нужно остановить вырождение биосферы...
"
(c)
http://kirguduev.livejournal.com/502184.html
- Ты многое забыл, - проворчал Странник. - Ты забыл про передвижные излучатели, ты забыл про Островную Империю, ты забыл про экономику... Тебе известно, что в стране инфляция?.. Тебе вообще известно, что такое инфляция? Тебе известно, что надвигается голод, что земля не родит?.. Тебе известно, что мы не успели создать здесь ни запасов хлеба, ни запасов медикаментов? Ты знаешь, что это твое лучевое голодание в двадцати процентах случаев приводит к шизофрении? А? - Он вытер ладонью могучий залысый лоб. - Нам нужны врачи... двенадцать тысяч врачей. Нам нужны белковые синтезаторы. Нам необходимо дезактивировать сто миллионов гектаров зараженной почвы - для начала. Нам нужно остановить вырождение биосферы...
"
(c)
суббота, 10 декабря 2011 г.
Политики пост
Из Брига. О политике, подпишусь под каждым словом:
Я иногда думаю, что мир, в котором мы живем - тускнеет. Смотришь телевизор - чернуха, слушаешь радио - чернуха, шляешься по улице - та же херня и куча дебилов в придачу. Но то - я думаю. А ты так не думай. Потому что ты - это будущее. Где-то еще есть такой же малолетний опездол. И еще и еще. Вас много, Студент. Вы не строите баррикады и не размахиваете флагами. Вы не лезете в политику и не рвете на себе футболки. Вы делаете то, что должно делать любое существо на этой планете - вы развиваете разум. Свой. А значит - все одно, как говорил профессор Иван Васильевич Вернадский, работаете на ноосферу. Когда таких, как вы будет большинство - планета станет умнее и чище.
Так что не спрашивайте меня, за кого я буду голосовать. Я вообще не голосую. У меня мурло мещанина. Я - обыватель. Политически безграмотный и идейно отсталый. Когда белые начнут хуячить красных, то - не поверите -красные начнут пиздошить белых. Среди всех этих трупов будут очень приличные люди с обеих сторон. В этой же куче буду лежать и я. И не потому что не успел убежать. А потому что я не смог выстрелить. А они - смогли. В легких у меня, например, застрянет красная пуля. А в сердце, например, - белая. Или наоборот. По большому счету мне до пизды, кто меня завалит. Потому что поколение вымрет полностью, как это всегда и было. Но - спаси и сохрани - где-то будут ходить наши женщины, уже выебанные, но еще неродившие. И жизнь продолжится.
Я иногда думаю, что мир, в котором мы живем - тускнеет. Смотришь телевизор - чернуха, слушаешь радио - чернуха, шляешься по улице - та же херня и куча дебилов в придачу. Но то - я думаю. А ты так не думай. Потому что ты - это будущее. Где-то еще есть такой же малолетний опездол. И еще и еще. Вас много, Студент. Вы не строите баррикады и не размахиваете флагами. Вы не лезете в политику и не рвете на себе футболки. Вы делаете то, что должно делать любое существо на этой планете - вы развиваете разум. Свой. А значит - все одно, как говорил профессор Иван Васильевич Вернадский, работаете на ноосферу. Когда таких, как вы будет большинство - планета станет умнее и чище.
Так что не спрашивайте меня, за кого я буду голосовать. Я вообще не голосую. У меня мурло мещанина. Я - обыватель. Политически безграмотный и идейно отсталый. Когда белые начнут хуячить красных, то - не поверите -красные начнут пиздошить белых. Среди всех этих трупов будут очень приличные люди с обеих сторон. В этой же куче буду лежать и я. И не потому что не успел убежать. А потому что я не смог выстрелить. А они - смогли. В легких у меня, например, застрянет красная пуля. А в сердце, например, - белая. Или наоборот. По большому счету мне до пизды, кто меня завалит. Потому что поколение вымрет полностью, как это всегда и было. Но - спаси и сохрани - где-то будут ходить наши женщины, уже выебанные, но еще неродившие. И жизнь продолжится.
четверг, 8 декабря 2011 г.
Горки
Сегодня Одепт и Джонни вытащили меня покататься на борде. И не зря, хорошие ребята.
Первый спуск только и делал, что кувыркался, падал и вспоминал, в какую сторону нужно ехать.
Зато потом - ехал прям таки с ветерком. Медленней Джонни, но тем не менее.
Обратную дорогу обсуждали политику и то как правильно переносить вес на заднюю ногу. Потом Одепт посмотрел на меня и сказал, чтоб я не слушал, мне еще на передней ездить надо учиться.
В целом хорошо, одобряю.
Пикрелейтед.
Не забываем, что наличие на фото ковра автоматически делает штаны и борд инсталляцией, а фото - предметом искусства.
Первый спуск только и делал, что кувыркался, падал и вспоминал, в какую сторону нужно ехать.
Зато потом - ехал прям таки с ветерком. Медленней Джонни, но тем не менее.
Обратную дорогу обсуждали политику и то как правильно переносить вес на заднюю ногу. Потом Одепт посмотрел на меня и сказал, чтоб я не слушал, мне еще на передней ездить надо учиться.
В целом хорошо, одобряю.
Пикрелейтед.
Не забываем, что наличие на фото ковра автоматически делает штаны и борд инсталляцией, а фото - предметом искусства.
вторник, 6 декабря 2011 г.
Скоро
Скоро будет отчета о sqadays пост.
А пока - не успел я вернуться, как приехало начальство и интересуется, зачем наш проект. Я один из тех, кто будет объяснять - зачем. И еще много всякого.
По эскуа. Доклад Катукату Каменевой стоил того, чтоб его слышали. Но она маленькая хрупкая девочка. Алексей Лупан, судя по ттх, голосом должен уметь останавливать параходы. Но говорил не громче маленькой хрупкой девочки. Жаль.
От каждого из них я ждал настоящего боевого рыка тестировщика. Доклады того стоили. Подробности позже.
А пока - не успел я вернуться, как приехало начальство и интересуется, зачем наш проект. Я один из тех, кто будет объяснять - зачем. И еще много всякого.
По эскуа. Доклад Катукату Каменевой стоил того, чтоб его слышали. Но она маленькая хрупкая девочка. Алексей Лупан, судя по ттх, голосом должен уметь останавливать параходы. Но говорил не громче маленькой хрупкой девочки. Жаль.
От каждого из них я ждал настоящего боевого рыка тестировщика. Доклады того стоили. Подробности позже.
среда, 30 ноября 2011 г.
Есть вопросы
Как часто вы хвалите своих коллег, своих бойцов?
Признаете победы, идеи, итпх.
Я посчитал. Четыре раза в день - я.
И еще посчитал. Меня - раз в полтора месяца.Непризнанны гений, епт.
Буду что-то менять.
Как-то так. Всем спасибо.
Признаете победы, идеи, итпх.
Я посчитал. Четыре раза в день - я.
И еще посчитал. Меня - раз в полтора месяца.Непризнанны гений, епт.
Буду что-то менять.
Как-то так. Всем спасибо.
понедельник, 28 ноября 2011 г.
По результатам поста - я на sqa days буду в форме сотрудника NAUMEN, белая такая, с оранжевым текстом. Да-да, это пеар.
Сегодня очень хочу перевести еще немного этого замечательного Канера. Но, скорее всего, не успею.
Как вы заметили, тестирование у нас развивается семимильными шагами, не то что 10 лет назад. Каждые полгода - слет тестеров всея СНГ. Раз в неделю - тренинги разных гуру. Докладов - усмотреться.
Знаете, как создают все эти тренинги и доклады люди, зарабатывающие на них деньги и популярность? У меня появилось ощущение, что так:
1. Берется любой пост Виттакера, любая глава Майерса, любой урок Канера или любой абзац Бейзера. Любой давности.
2. Дополняется примерами из практики.
3. ...
4. ДОКЛАД ГОТОВ!!!
Неленивые и хитрые переводят по две статьи сразу и это тянет уже на семинар, тыщ за пять. Соответственно, три - тренинг, осилившие четыре называют свое творение курсом.
Я пока не знаю хорошо это или плохо. Наверное, хорошо.
Но по концентрации и по содержанию идей и мыслей - совпадает сильно
Сегодня очень хочу перевести еще немного этого замечательного Канера. Но, скорее всего, не успею.
Как вы заметили, тестирование у нас развивается семимильными шагами, не то что 10 лет назад. Каждые полгода - слет тестеров всея СНГ. Раз в неделю - тренинги разных гуру. Докладов - усмотреться.
Знаете, как создают все эти тренинги и доклады люди, зарабатывающие на них деньги и популярность? У меня появилось ощущение, что так:
1. Берется любой пост Виттакера, любая глава Майерса, любой урок Канера или любой абзац Бейзера. Любой давности.
2. Дополняется примерами из практики.
3. ...
4. ДОКЛАД ГОТОВ!!!
Неленивые и хитрые переводят по две статьи сразу и это тянет уже на семинар, тыщ за пять. Соответственно, три - тренинг, осилившие четыре называют свое творение курсом.
Я пока не знаю хорошо это или плохо. Наверное, хорошо.
Но по концентрации и по содержанию идей и мыслей - совпадает сильно
суббота, 26 ноября 2011 г.
Lesson 52
Ах, да.
Благодаря конторе и начальству еду на sqa days 10. Еще едут 2 тестировщицы.
Хорошо.
Екб, кто-нибудь еще будет там?
Не екб: Феликс? Редфокс? Думтест? Кто там еще-то... Вас увижу?
4-го буду в мск. Там есть что-нибудь интересное?
Слово Канеру:
Техники тестирования основанные на том, как вы тестируете.
Регрессионное тестирование Регрессионное тестирование включает в себя переиспользование однажды уже созданных и проведенных тестов после изменений в продукте. Вы поводите регрессионное тестирование фикса после того, как узнали о том, что баг был исправлен. Цель регрессионного тестирования в том, чтобы убедиться, что баги исправлены и изменения не внесли новых ошибок в старый функционал. Побочный эффект регрессии называется стабилизация, включающая перетестирование важных частей продукта. Цель в том, чтоб доказать, что предыдущие изменения не сломали важных компонент продукта.
Тестирование по плану Ручное тестирование, обычно выполняемое новичками, которые шаг за шагом следуют плану тестирования, написанному старшим тестировщиком.
Смок-тест Это тип регрессионного тестирования выполняется с целью проверить, готов ли новый билд к тестированию. Смок-тест часто автоматизируется и стандартизируется. Он проверяет вещи, которые должны работать, и если они не функционируют, то мы подозреваем, что программа была создана полностью некорректно.
Исследовательское тестирование Мы ждем, что тестировщик знает весь проект, продукт, целевую аудиторию, риски, сценарии, которые привели к предыдущим сбоям, Новые тесты постоянно создаются и используются. Они гораздо эффективней, чем старые, так как основываются на том, что тестировщик постоянно увеличивает объем знаний о проекте.
Партизанское тестирование Быстрая и грязная атака продукта. Форма исследовательского тестирования, ограниченная во времени, выполняемая опытным тестировщиком-исследователем. Например старший тестировщик может потратить один день на область, которая в противном случае игнорировалась бы. Он пробует на продукте самые мощные свои атаки. И если находит серьезную проблему, то область будет перетестирована и может быть изменен весь план тестирования. Если он не находит проблем, то и в дальнейшем область будет игнорироваться или походить лишь небольшие испытания.
Тестирование по сценарию Обычно обладает четырьмя атрибутами. 1) Тесты должны быть реалистичны. Они должны повторять то, что обычно делают с продуктом заказчики. 2) Тесты должны быть сложными, включать в себя использование нескольких функций. 3) По ним должно быть просто определить, прошла программа тест или нет. 4) Заинтересованные лица должны согласиться, что программа должна быть исправлена если не выдержит этой проверки. Тест, обладающий всеми четырьмя атрибутами будет убедительным, и давать на выходе реальные баги. Однако вам придется долго создавать и поддерживать качественные сценарии.
Тестирование по сценарию (прим. w_bf: это не я ошибся, это у Канера повтор) Тесты, основанные на кейсах использования продукта обычно называют тестами по сценарию (Jacobson 1992, Collard 1999) или юзкейс-тестами. (Многие люди классифицировали бы их как тесты основанные на покрытии важных сценариев использования)
Тестирование установки Установка ПО различными путями на различных системах. Проверка того, какие файлы добавлены и изменены на диске. Работает ли установленная программа? Что случится при удалении программы?
Стресс тестирование Тестирование системы, находящейся под атакой\нагрузкой и требующей для работы большого количества ресурсов. Под высокой нарузкой система имеет высокую вероятность падения, но картина событий, предшествующих падению может указывать на уязвимость в ПО, которая может быть использована. Asbock (2000) - отличная инструкция по нагрузочному тестированию.
Тестирование длинных последовательностей Выполняется всю ночь или весь день или всю неделю. Цель - обнаружить ошибки, которые не смогли найти короткие последовательности тестов. Пример ошибок, которые находят таким образом - дикие указатели, утечки памяти, переполнения стека, плохое взаимодействие нескольких функций. Часто такой вид тестирования называют продолжительным тестированием, тестированием выносливости или испытанием на надежность.
Тестирование производительности Такие тесты проводят для определения того, как быстро работает программа, чтоб решить, нуждается ли ПО в оптимизации. Но такие тесты могут найти и многие другие баги. Значительные изменения в производительности по сравнению с предыдущим релизом могут идентифицировать эффект от ошибки в программе. Например, если проверите, как долго работает некая функция сегодня, а затем проверите то же самое завтра, вы вероятно, сможете проверить это вместе с программистом и написать отчет об ошибке, в случае если тест прошел значительно быстрее или медленнее. Либо считать эти изменения подозрительными, так как произошли фундаментальные изменения в программе.
Sam Guckenheimer заметил: "Разница в производительности также может означать изменения в сторонних компонентах ПО или изменения в конфигурации. Например изменения в JVM с различными релизами JDK. Так тестирование производительности может даль удивительные результаты, даже если ваш код не менялся вообще."
Благодаря конторе и начальству еду на sqa days 10. Еще едут 2 тестировщицы.
Хорошо.
Екб, кто-нибудь еще будет там?
Не екб: Феликс? Редфокс? Думтест? Кто там еще-то... Вас увижу?
4-го буду в мск. Там есть что-нибудь интересное?
Слово Канеру:
Техники тестирования основанные на том, как вы тестируете.
Регрессионное тестирование Регрессионное тестирование включает в себя переиспользование однажды уже созданных и проведенных тестов после изменений в продукте. Вы поводите регрессионное тестирование фикса после того, как узнали о том, что баг был исправлен. Цель регрессионного тестирования в том, чтобы убедиться, что баги исправлены и изменения не внесли новых ошибок в старый функционал. Побочный эффект регрессии называется стабилизация, включающая перетестирование важных частей продукта. Цель в том, чтоб доказать, что предыдущие изменения не сломали важных компонент продукта.
Тестирование по плану Ручное тестирование, обычно выполняемое новичками, которые шаг за шагом следуют плану тестирования, написанному старшим тестировщиком.
Смок-тест Это тип регрессионного тестирования выполняется с целью проверить, готов ли новый билд к тестированию. Смок-тест часто автоматизируется и стандартизируется. Он проверяет вещи, которые должны работать, и если они не функционируют, то мы подозреваем, что программа была создана полностью некорректно.
Исследовательское тестирование Мы ждем, что тестировщик знает весь проект, продукт, целевую аудиторию, риски, сценарии, которые привели к предыдущим сбоям, Новые тесты постоянно создаются и используются. Они гораздо эффективней, чем старые, так как основываются на том, что тестировщик постоянно увеличивает объем знаний о проекте.
Партизанское тестирование Быстрая и грязная атака продукта. Форма исследовательского тестирования, ограниченная во времени, выполняемая опытным тестировщиком-исследователем. Например старший тестировщик может потратить один день на область, которая в противном случае игнорировалась бы. Он пробует на продукте самые мощные свои атаки. И если находит серьезную проблему, то область будет перетестирована и может быть изменен весь план тестирования. Если он не находит проблем, то и в дальнейшем область будет игнорироваться или походить лишь небольшие испытания.
Тестирование по сценарию Обычно обладает четырьмя атрибутами. 1) Тесты должны быть реалистичны. Они должны повторять то, что обычно делают с продуктом заказчики. 2) Тесты должны быть сложными, включать в себя использование нескольких функций. 3) По ним должно быть просто определить, прошла программа тест или нет. 4) Заинтересованные лица должны согласиться, что программа должна быть исправлена если не выдержит этой проверки. Тест, обладающий всеми четырьмя атрибутами будет убедительным, и давать на выходе реальные баги. Однако вам придется долго создавать и поддерживать качественные сценарии.
Тестирование по сценарию (прим. w_bf: это не я ошибся, это у Канера повтор) Тесты, основанные на кейсах использования продукта обычно называют тестами по сценарию (Jacobson 1992, Collard 1999) или юзкейс-тестами. (Многие люди классифицировали бы их как тесты основанные на покрытии важных сценариев использования)
Тестирование установки Установка ПО различными путями на различных системах. Проверка того, какие файлы добавлены и изменены на диске. Работает ли установленная программа? Что случится при удалении программы?
Стресс тестирование Тестирование системы, находящейся под атакой\нагрузкой и требующей для работы большого количества ресурсов. Под высокой нарузкой система имеет высокую вероятность падения, но картина событий, предшествующих падению может указывать на уязвимость в ПО, которая может быть использована. Asbock (2000) - отличная инструкция по нагрузочному тестированию.
Тестирование длинных последовательностей Выполняется всю ночь или весь день или всю неделю. Цель - обнаружить ошибки, которые не смогли найти короткие последовательности тестов. Пример ошибок, которые находят таким образом - дикие указатели, утечки памяти, переполнения стека, плохое взаимодействие нескольких функций. Часто такой вид тестирования называют продолжительным тестированием, тестированием выносливости или испытанием на надежность.
Тестирование производительности Такие тесты проводят для определения того, как быстро работает программа, чтоб решить, нуждается ли ПО в оптимизации. Но такие тесты могут найти и многие другие баги. Значительные изменения в производительности по сравнению с предыдущим релизом могут идентифицировать эффект от ошибки в программе. Например, если проверите, как долго работает некая функция сегодня, а затем проверите то же самое завтра, вы вероятно, сможете проверить это вместе с программистом и написать отчет об ошибке, в случае если тест прошел значительно быстрее или медленнее. Либо считать эти изменения подозрительными, так как произошли фундаментальные изменения в программе.
Sam Guckenheimer заметил: "Разница в производительности также может означать изменения в сторонних компонентах ПО или изменения в конфигурации. Например изменения в JVM с различными релизами JDK. Так тестирование производительности может даль удивительные результаты, даже если ваш код не менялся вообще."
среда, 23 ноября 2011 г.
Lesson 51
Что-то уроки у Сэма пошли немаленькие, быстренько перевести уже не получается, эх.
Слово Канеру:
Техники тестирования, основанные на проблемах сфокусированы на причинах тестирования (каких рисков мы хотим избежать)
Тестирование основанное на рисках имеет по крайней мере два основных значения.
Amland (1999) предоставил замечательное описание менеджмента тестирования основанного на рисках. Согласно его точке зрения, анализ рисков необходим для определения следующих шагов тестирования. Тесты приоритезируются с точки зрения вероятности того, что фича сломается и с точки зрения вероятной цены поломки фичи. И чем больше вероятность поломки, тем важнее тест и тем раньше его нужно проводить.
По другомум мнению, анализ рисков можно делать собственно для поиска ошибок. Когда мы изучаем особенности продукта, мы спрашиваем себя, как он может ломаться. Этот вопрос распадается на на множество дополнительных вопросов, таких как: Как будет выглядеть бага? Почему эта фича сломалась? (Мы опишем наш подход к тестированию основанному на рисках в дополнении к книге)
Оба этих подхода обсуждались в James Bach on Risk-Based Testing (1999c).
Whittaker и Jorgensen (1999 and 2000) предоставили отличное обсуждение и примеры широких классов ошибок, включающих нарушения ограничений:
Ограничения ввода Ограничение на ввод данных, с которыми программа может работать. Если программа работает с 32-разрядными числами, программист должен обеспечить защитные процедуры, которые смогут обнаружить и отклонить ввод более, чем 32-разрядных чисел. Если такого ограничения не будет, то программа упадет при попытке обработать такие числа.
Ограничения вывода Ввод был корректным, но он привел к выходным значениям, которые не могли быть обработаны. Программа может упасть при попытке отобразить, распечатать или сохранить эти данные.
Ограничения компиляции Ввод и вывод корректен, но в ходе расчета выходной величины программа падает. Например, умножение двух больших чисел может дать число, которое программа не может обработать.
Ограничения хранения Входные, выходные и внутренние значения корректны, но запуск программы приводит к переполнению данных или созданию слишком больших файлов.
Whittaker (2002) дал детальные рекомендации по тестированию этих ограничений.
Вот несколько полезных советов для проектирования тестов с учетом риска:
- Вы должны также сделать сопоставимые тесты, не основанные на рисках, для проверки тех рисков, которые вы не изучили достаточно хорошо.
- Тестируйте проблемы связанные со временем. Удивительно, но многие американские образованные тестировщики не учитывают временные проблемы. Классические проблемы сроков включают в себя вопрос гонок, и неожиданный порядок событий.
- Когда вы создаете тест, всегда создавайте процедуру испытаний, заставляющую программу использовать тестовые данные, которые вы ввели и позволяющую вам проверить, корректно ли вы используете данные.
Настроение дня:
Готовая тема попутчика Декстера.
Слово Канеру:
Техники тестирования, основанные на проблемах сфокусированы на причинах тестирования (каких рисков мы хотим избежать)
Тестирование основанное на рисках имеет по крайней мере два основных значения.
Amland (1999) предоставил замечательное описание менеджмента тестирования основанного на рисках. Согласно его точке зрения, анализ рисков необходим для определения следующих шагов тестирования. Тесты приоритезируются с точки зрения вероятности того, что фича сломается и с точки зрения вероятной цены поломки фичи. И чем больше вероятность поломки, тем важнее тест и тем раньше его нужно проводить.
По другомум мнению, анализ рисков можно делать собственно для поиска ошибок. Когда мы изучаем особенности продукта, мы спрашиваем себя, как он может ломаться. Этот вопрос распадается на на множество дополнительных вопросов, таких как: Как будет выглядеть бага? Почему эта фича сломалась? (Мы опишем наш подход к тестированию основанному на рисках в дополнении к книге)
Оба этих подхода обсуждались в James Bach on Risk-Based Testing (1999c).
Whittaker и Jorgensen (1999 and 2000) предоставили отличное обсуждение и примеры широких классов ошибок, включающих нарушения ограничений:
Ограничения ввода Ограничение на ввод данных, с которыми программа может работать. Если программа работает с 32-разрядными числами, программист должен обеспечить защитные процедуры, которые смогут обнаружить и отклонить ввод более, чем 32-разрядных чисел. Если такого ограничения не будет, то программа упадет при попытке обработать такие числа.
Ограничения вывода Ввод был корректным, но он привел к выходным значениям, которые не могли быть обработаны. Программа может упасть при попытке отобразить, распечатать или сохранить эти данные.
Ограничения компиляции Ввод и вывод корректен, но в ходе расчета выходной величины программа падает. Например, умножение двух больших чисел может дать число, которое программа не может обработать.
Ограничения хранения Входные, выходные и внутренние значения корректны, но запуск программы приводит к переполнению данных или созданию слишком больших файлов.
Whittaker (2002) дал детальные рекомендации по тестированию этих ограничений.
Вот несколько полезных советов для проектирования тестов с учетом риска:
- Вы должны также сделать сопоставимые тесты, не основанные на рисках, для проверки тех рисков, которые вы не изучили достаточно хорошо.
- Тестируйте проблемы связанные со временем. Удивительно, но многие американские образованные тестировщики не учитывают временные проблемы. Классические проблемы сроков включают в себя вопрос гонок, и неожиданный порядок событий.
- Когда вы создаете тест, всегда создавайте процедуру испытаний, заставляющую программу использовать тестовые данные, которые вы ввели и позволяющую вам проверить, корректно ли вы используете данные.
Настроение дня:
Готовая тема попутчика Декстера.
вторник, 22 ноября 2011 г.
Lesson 50 (часть 2)
Часть первая
Слово Канеру:
Техники тестирования основанные на том, что тестируется.
Тестирование репрезентативных значений Репрезентативные значения класса эквивалентности те, которые чаще приводили к ошибкам. В тестировании граничных значений - граничные значения всегда наиболее репрезентативны. Но предположим, что вы не можете отобразить класс эквивалентности на числовую ось. Например принтеры Hewlett-Packard PCL-5 являются классом эквивалентности, потому как должны работать одним и тем же образом. Теперь предположим, что для конкретной задачи один из принтеров имеет немного больше шансов заполучить проблему, чем другие. Это принтер и будет репрезентативным значением класса, и если он нас не подведет - не подведут и остальные.
Тестовая матрица для полей ввода Для каждого типа поля ввода ты можешь разработать достаточно стандартный набор кейсов и использовать их в этом и других продуктах. Пример мы приведем далее в этой главе.
Карта и проверка всех способов редактирования полей Часто есть возможность изменить значение переменной несколькими путями. Например, есть способ импортировать данные в поле, ввести значение напрямую, скопировать результат в поле, поле может программно вычисляться и перевычисляться автоматически и так далее. Поле имеет ограничения. Некоторые ограничения могут быть постоянными, друггие могут меняться в зависимости от значений в соседних полях. Например, если J и K - целые положительные числа, они ограничены значениями от 0 до MaxInt. Это постоянное ограничение, зависящее от языка программирования. Предположим, что N тоже положительное целое, N = J + K, и если N=5, то J = 5 − K, и J не может быть больше 5(значение N). Это меняющееся ограничение, чей диапазон допустимых значений зависит от N. Чтоб проверить, что J находится в диапазоне допустимых значений (5-K) мы должны попытаться изменить его значение в каждом возможном направлении.
Логическое тестирование Переменные имеют зависимости в программе. Например, в программе может быть правило, которое говорит, что если PERSON-AGE больше 50 и если SMOKER = YES, то OFFER-INSURANCE должно быть равно NO. Правило выражает логическую зависимость. Логическое тестирование пытается проверить все логические зависимости в программе. График причинно-следственных связей - техника проектирования широкого набора тестов основанных на логике системы.
Тестирование состояний Программа двигается от состояния к состоянию. В данном состоянии некоторые входные данные корректны, другие будут проигнорированы или отклонены. В ответ на валидные входные данные тестируемая программа делает то, что может и не пытается делать то, что не должна. В тестировании состояний мы ходим по программе согласно большому набору переходов между состояниями и тщательно проверяем результаты на каждом шаге.
Тестирование путей Путь включает все шаги, что ты совершил и все состояния через которые прошел, чтоб дойти до текущего состояния. Тестирование путей включает в себя тестирование множества путей в пhограмме. Нельзя проверить все пути в нетривиальной программе. Некоторые тестировщики проводят тестирование "подпутей" - тестирование частей пути. Тестирование базовых путей включает в себя все подпути одного типа, предполагая, что вы тестируете эти длинные пути, чтоб найти ошибки, которые пропустили более мелкие тесты.
Покрытие линий и ветвей кода Вы достигли 100% покрытия, если ваши тесты исполняют каждую линию или ветвь кода программы. Проектирование тестов для достижения покрытия называют "Тестирование основанное на покрытии" (После того, как вы достигли этого вы можете прекратить тестирование или прекратить создание новых тестов). Мы называем это покрытием строк и ветвей кода, чтоб отличить от других типов тестирования, основанных на покрытии. Покрытие конфигураций - отличный пример техники, которая проверяет один и тот же код несколько раз, но при этом все равно может потенциально привести к отличным результатам. Есть много других примеров. Для тестирования основанного на достижении высокого покрытия строк и ветвей кода характерно упущение многих видов ошибок, таких как(но не только) баги с участием пропущенного кода, баги некорректного обращения с граничными значениями, проблемы со временем, проблемы с совместимостью с железом и ПО, баги delayed-fuse, такие как дикие указатели, утечки памяти или stack corruption, которые в конечном счете ведут к переполнению стека, проблемы юзабилити и другие неисправности с точки зрения заказчика. Эта техника является более ценной в плане выявления неполноты тестирования (какой код сейчас не тестируется), как стандарт минимального необходимого объема тестирования. И в действительности опасно, если тестировщики останавливаются только потому, что они достигли определенного процента покрытия (Marick 1999).
Покрытие конфигураций Вам нужно протестировать совместимость 100 принтеров, а вы проверили 10, вы достигли 10% покрытия конфигураций. В общем виде, покрытие конфигураций означает процент конфигураций, на которых запускались и успешно прошли ваши тесты в сравнении с общим числом конфигураций, на котором вы запланировали запустить тесты. Почему мы назвали это техникой тестирования? Обычно мы считаем, что это просто мера - сколько определенных типов тестов мы повели. Однако сами тестировщики создают специальные серии тестов, которые работают с большим объемом конфигураций быстро и просто. В их руках оптимизация тестов для достижения большого покрытия становится техникой.
Тестирование спецификаций Тестирование, сфокусированное на каждом минимальном фактическом требовании к продукту, которое можно получить из спецификаций (Фактическое требование - это то, что для определенного состояния продукта может быть представлено в виде "да" или "нет"). Оно часто включает в себя проверку всех утверждений, сделанных в руководстве пользователя, рекламе, технической литературе или письме заказчику.
Тестирование требований Тестирование сфокусированное на том, насколько программа удовлетворяет требованиям (как вариант доказательство того, что требования выполнить нельзя).
Комбинированное тестирование Тестирование двух или более переменных в комбинации. Мы поговорим об этом позднее в этой главе. Это важный вид тестирования, но многие тестировщики пренебрегают им. Профит от программ обычно заключается как раз во взаимодействии множества переменных и если вы не не учитываете это в тестах, то имеете шанс пропустить множество ошибок, вызванных сочетанием значений нескольких переменных, а не значением одной.
Слово Канеру:
Техники тестирования основанные на том, что тестируется.
Тестирование репрезентативных значений Репрезентативные значения класса эквивалентности те, которые чаще приводили к ошибкам. В тестировании граничных значений - граничные значения всегда наиболее репрезентативны. Но предположим, что вы не можете отобразить класс эквивалентности на числовую ось. Например принтеры Hewlett-Packard PCL-5 являются классом эквивалентности, потому как должны работать одним и тем же образом. Теперь предположим, что для конкретной задачи один из принтеров имеет немного больше шансов заполучить проблему, чем другие. Это принтер и будет репрезентативным значением класса, и если он нас не подведет - не подведут и остальные.
Тестовая матрица для полей ввода Для каждого типа поля ввода ты можешь разработать достаточно стандартный набор кейсов и использовать их в этом и других продуктах. Пример мы приведем далее в этой главе.
Карта и проверка всех способов редактирования полей Часто есть возможность изменить значение переменной несколькими путями. Например, есть способ импортировать данные в поле, ввести значение напрямую, скопировать результат в поле, поле может программно вычисляться и перевычисляться автоматически и так далее. Поле имеет ограничения. Некоторые ограничения могут быть постоянными, друггие могут меняться в зависимости от значений в соседних полях. Например, если J и K - целые положительные числа, они ограничены значениями от 0 до MaxInt. Это постоянное ограничение, зависящее от языка программирования. Предположим, что N тоже положительное целое, N = J + K, и если N=5, то J = 5 − K, и J не может быть больше 5(значение N). Это меняющееся ограничение, чей диапазон допустимых значений зависит от N. Чтоб проверить, что J находится в диапазоне допустимых значений (5-K) мы должны попытаться изменить его значение в каждом возможном направлении.
Логическое тестирование Переменные имеют зависимости в программе. Например, в программе может быть правило, которое говорит, что если PERSON-AGE больше 50 и если SMOKER = YES, то OFFER-INSURANCE должно быть равно NO. Правило выражает логическую зависимость. Логическое тестирование пытается проверить все логические зависимости в программе. График причинно-следственных связей - техника проектирования широкого набора тестов основанных на логике системы.
Тестирование состояний Программа двигается от состояния к состоянию. В данном состоянии некоторые входные данные корректны, другие будут проигнорированы или отклонены. В ответ на валидные входные данные тестируемая программа делает то, что может и не пытается делать то, что не должна. В тестировании состояний мы ходим по программе согласно большому набору переходов между состояниями и тщательно проверяем результаты на каждом шаге.
Тестирование путей Путь включает все шаги, что ты совершил и все состояния через которые прошел, чтоб дойти до текущего состояния. Тестирование путей включает в себя тестирование множества путей в пhограмме. Нельзя проверить все пути в нетривиальной программе. Некоторые тестировщики проводят тестирование "подпутей" - тестирование частей пути. Тестирование базовых путей включает в себя все подпути одного типа, предполагая, что вы тестируете эти длинные пути, чтоб найти ошибки, которые пропустили более мелкие тесты.
Покрытие линий и ветвей кода Вы достигли 100% покрытия, если ваши тесты исполняют каждую линию или ветвь кода программы. Проектирование тестов для достижения покрытия называют "Тестирование основанное на покрытии" (После того, как вы достигли этого вы можете прекратить тестирование или прекратить создание новых тестов). Мы называем это покрытием строк и ветвей кода, чтоб отличить от других типов тестирования, основанных на покрытии. Покрытие конфигураций - отличный пример техники, которая проверяет один и тот же код несколько раз, но при этом все равно может потенциально привести к отличным результатам. Есть много других примеров. Для тестирования основанного на достижении высокого покрытия строк и ветвей кода характерно упущение многих видов ошибок, таких как(но не только) баги с участием пропущенного кода, баги некорректного обращения с граничными значениями, проблемы со временем, проблемы с совместимостью с железом и ПО, баги delayed-fuse, такие как дикие указатели, утечки памяти или stack corruption, которые в конечном счете ведут к переполнению стека, проблемы юзабилити и другие неисправности с точки зрения заказчика. Эта техника является более ценной в плане выявления неполноты тестирования (какой код сейчас не тестируется), как стандарт минимального необходимого объема тестирования. И в действительности опасно, если тестировщики останавливаются только потому, что они достигли определенного процента покрытия (Marick 1999).
Покрытие конфигураций Вам нужно протестировать совместимость 100 принтеров, а вы проверили 10, вы достигли 10% покрытия конфигураций. В общем виде, покрытие конфигураций означает процент конфигураций, на которых запускались и успешно прошли ваши тесты в сравнении с общим числом конфигураций, на котором вы запланировали запустить тесты. Почему мы назвали это техникой тестирования? Обычно мы считаем, что это просто мера - сколько определенных типов тестов мы повели. Однако сами тестировщики создают специальные серии тестов, которые работают с большим объемом конфигураций быстро и просто. В их руках оптимизация тестов для достижения большого покрытия становится техникой.
Тестирование спецификаций Тестирование, сфокусированное на каждом минимальном фактическом требовании к продукту, которое можно получить из спецификаций (Фактическое требование - это то, что для определенного состояния продукта может быть представлено в виде "да" или "нет"). Оно часто включает в себя проверку всех утверждений, сделанных в руководстве пользователя, рекламе, технической литературе или письме заказчику.
Тестирование требований Тестирование сфокусированное на том, насколько программа удовлетворяет требованиям (как вариант доказательство того, что требования выполнить нельзя).
Комбинированное тестирование Тестирование двух или более переменных в комбинации. Мы поговорим об этом позднее в этой главе. Это важный вид тестирования, но многие тестировщики пренебрегают им. Профит от программ обычно заключается как раз во взаимодействии множества переменных и если вы не не учитываете это в тестах, то имеете шанс пропустить множество ошибок, вызванных сочетанием значений нескольких переменных, а не значением одной.
понедельник, 21 ноября 2011 г.
Рутина
Сегодня почти треть дня - спорим.
О том, что лучше - сравнивать две модели данных или пользоваться жестким списком assert'ов
Жесткой ли должна быть модель данных или динамически формирующейся.
О том, нужно ли помещать знания о манипуляциях в тестируемой системе в модель тестирующей системе или нет.
И грустно мне, потому как я - на темной стороне - убеждаю и учу бойцов копипастить, разворачивать классы в последовательности действий и прочим непотребствам.
Потому как цель - не создание тестирующей системы, а тестирование продукта. И я уже начинаю ощущать разницу.
P.S. Или котоверсия, да:
О том, что лучше - сравнивать две модели данных или пользоваться жестким списком assert'ов
Жесткой ли должна быть модель данных или динамически формирующейся.
О том, нужно ли помещать знания о манипуляциях в тестируемой системе в модель тестирующей системе или нет.
И грустно мне, потому как я - на темной стороне - убеждаю и учу бойцов копипастить, разворачивать классы в последовательности действий и прочим непотребствам.
Потому как цель - не создание тестирующей системы, а тестирование продукта. И я уже начинаю ощущать разницу.
 |
| Альбом: randompics4lj |
P.S. Или котоверсия, да:
 |
| Альбом: randompics4lj |
пятница, 18 ноября 2011 г.
Lesson 50 (часть 1)
День сегодня какой-то неспокойный.
Процитирую Славу П.:
- Кто ее блин создает эту обстановку нервную, которая в проекте? Леша? По Леше можно приборы калибровать!
И еще сэра Терри:
- Нельзя сказать, что Витинари был расистом. Он одинаково ненавидел все расы.
(вроде так)
Слово Канеру:
Техники тестирования основанные на том, что тестируется.
Ты мог бы классифицировать эти техники по иному, как сфокусированные на проблемах, это зависит от того, что ты имеешь в виду, используя эту технику. Например, интеграционное тестирование фич - техника ориентированная на то, что тестируется, если ты используешь ее для проверки каждой фичи - тестирует поведение фичи в связке с другими. И оно же будет техникой, ориентированной на проблемы, если у вас есть идея или предположение о взаимодействии функций и вы хотите проверить эту идею. (Например, это будет тестирование ориентированное на проблемы, если ваша цель в демонстрации ошибки, которая возникает при передаче данных от одной функции к другой.)
Мы отводим много места тестированию областей определений функций в этой главе, так как основанные на этом техники широко используются и очень важны в нашей сфере. Вы должны знать это.
Функциональное тестирование Тестировать функции, одну за другой. Тестируйте функции тщательно, до такой степени, пока вы не сможете с уверенностью сказать, что функция работает. Функциональное тестирование методом белого ящика обычно называется юнит-тестированием и концентрируется на функциях в том виде, в каком мы их видим в коде. Функциональное тестирование черного ящика концентрируется на командах и фичах, которые видит или может использовать пользователь. Желательно проводить функциональное тестирование до того, как будут проводиться более сложные тесты, вовлекающие несколько функций. В сложных тестах первая сломавшаяся функция может остановить весь тест и не позволить вам искать ошибки дальше. Если вы полагаетесь на комплексные испытания, не используя тестирование отдельных функций, вы можете до самого конца не узнать, что одна из функций сломана и тратить огромное количество времени на поиск неисправности в сложном тесте для поиска неисправности в одной маленькой функции.
Интеграционное функциональное тестирование Тестирование совместной работы нескольких функций.
Хождение по меню Проход по всем пунктам меню в графическом интерфейсе пользователя, выбирая каждый пункт меню.
Тестирование областей определений данных Область определения переменной - математическое понятие, включающее все возможные значения переменной какой-либо функции. В тестировании областей определения ты определяешь функции и их переменные. Переменные могут быть входящими и исходящими (с точки зрения математики между ними разницы нет, в тестировании анализ проводится в обоих случаях). Для каждой переменной набор ее значений делится на классы эквивалентности и выбирается небольшой набор примеров (обычно граничных значений) для каждого класса. Допущение метода в том, что вы тестируя несколько примеров для каждого класса, вы можете найти все баги, которые вы нашли бы, тестируя все значения класса. Обратите внимание, что в отличие от функционального тестирования, мы тестируем переменные, а не функции. Многие переменные используются более, чем одной функцией. Тестировщик анализирует переменную, и затем, основываясь на этом анализе, проводит тесты, в которых переменная используется каждой функцией - на входе или на выходе.
Анализ классов эквивалентности Класс эквивалентности это набор значений переменной, которые вы рассматриваете как эквивалентные. Сценарии эквивалентны, если вы верите, что а) они тестируют одно и то же б) если один из них нашел баг, который, скорее всего, найдут и другие в) один из них не нашел баг, которые не найдут и другие. Как только вы нашли класс эквивалентности - протестируйте один или два его члена.
Тестирование граничных значений Класс эквивалентности это набор переменных. Если вы можете отразить их на числовой оси, то граничными значениями будут наибольшие и наименьшие значения класса. В тестировании граничных значений вы тестируете их, а также те граничные значения близлежащих классов, которые лишь ненамного меньше, чем наименьшее значение вашего класса и ненамного больше, чем наибольшее значение вашего класса. Рассмотрим поле ввода, принимающее целые значения от 10 до 50. Значения, представляющие интерес, это: 10(меньшее значение), 9(наибольшее неподходящее значение), 50(наибольшее), 51(наименьшее неподходящее).
Часть вторая
Процитирую Славу П.:
- Кто ее блин создает эту обстановку нервную, которая в проекте? Леша? По Леше можно приборы калибровать!
И еще сэра Терри:
- Нельзя сказать, что Витинари был расистом. Он одинаково ненавидел все расы.
(вроде так)
Слово Канеру:
Техники тестирования основанные на том, что тестируется.
Ты мог бы классифицировать эти техники по иному, как сфокусированные на проблемах, это зависит от того, что ты имеешь в виду, используя эту технику. Например, интеграционное тестирование фич - техника ориентированная на то, что тестируется, если ты используешь ее для проверки каждой фичи - тестирует поведение фичи в связке с другими. И оно же будет техникой, ориентированной на проблемы, если у вас есть идея или предположение о взаимодействии функций и вы хотите проверить эту идею. (Например, это будет тестирование ориентированное на проблемы, если ваша цель в демонстрации ошибки, которая возникает при передаче данных от одной функции к другой.)
Мы отводим много места тестированию областей определений функций в этой главе, так как основанные на этом техники широко используются и очень важны в нашей сфере. Вы должны знать это.
Функциональное тестирование Тестировать функции, одну за другой. Тестируйте функции тщательно, до такой степени, пока вы не сможете с уверенностью сказать, что функция работает. Функциональное тестирование методом белого ящика обычно называется юнит-тестированием и концентрируется на функциях в том виде, в каком мы их видим в коде. Функциональное тестирование черного ящика концентрируется на командах и фичах, которые видит или может использовать пользователь. Желательно проводить функциональное тестирование до того, как будут проводиться более сложные тесты, вовлекающие несколько функций. В сложных тестах первая сломавшаяся функция может остановить весь тест и не позволить вам искать ошибки дальше. Если вы полагаетесь на комплексные испытания, не используя тестирование отдельных функций, вы можете до самого конца не узнать, что одна из функций сломана и тратить огромное количество времени на поиск неисправности в сложном тесте для поиска неисправности в одной маленькой функции.
Интеграционное функциональное тестирование Тестирование совместной работы нескольких функций.
Хождение по меню Проход по всем пунктам меню в графическом интерфейсе пользователя, выбирая каждый пункт меню.
Тестирование областей определений данных Область определения переменной - математическое понятие, включающее все возможные значения переменной какой-либо функции. В тестировании областей определения ты определяешь функции и их переменные. Переменные могут быть входящими и исходящими (с точки зрения математики между ними разницы нет, в тестировании анализ проводится в обоих случаях). Для каждой переменной набор ее значений делится на классы эквивалентности и выбирается небольшой набор примеров (обычно граничных значений) для каждого класса. Допущение метода в том, что вы тестируя несколько примеров для каждого класса, вы можете найти все баги, которые вы нашли бы, тестируя все значения класса. Обратите внимание, что в отличие от функционального тестирования, мы тестируем переменные, а не функции. Многие переменные используются более, чем одной функцией. Тестировщик анализирует переменную, и затем, основываясь на этом анализе, проводит тесты, в которых переменная используется каждой функцией - на входе или на выходе.
Анализ классов эквивалентности Класс эквивалентности это набор значений переменной, которые вы рассматриваете как эквивалентные. Сценарии эквивалентны, если вы верите, что а) они тестируют одно и то же б) если один из них нашел баг, который, скорее всего, найдут и другие в) один из них не нашел баг, которые не найдут и другие. Как только вы нашли класс эквивалентности - протестируйте один или два его члена.
Тестирование граничных значений Класс эквивалентности это набор переменных. Если вы можете отразить их на числовой оси, то граничными значениями будут наибольшие и наименьшие значения класса. В тестировании граничных значений вы тестируете их, а также те граничные значения близлежащих классов, которые лишь ненамного меньше, чем наименьшее значение вашего класса и ненамного больше, чем наибольшее значение вашего класса. Рассмотрим поле ввода, принимающее целые значения от 10 до 50. Значения, представляющие интерес, это: 10(меньшее значение), 9(наибольшее неподходящее значение), 50(наибольшее), 51(наименьшее неподходящее).
Часть вторая
четверг, 17 ноября 2011 г.
Ненависти пост
Внезапно, но моего отца охмуряли на поучаствоать в какой-то интернет пирамиде интер континенталь по впариванию всякой херни людям.
Очень надеюсь, что в телефонном разговоре я был более убедителен, чем та "ну вроде солидная знакомая тетка", и отговорил батю от участия.
P.S. Давненько не общался хотя бы со свидетелями Иеговы, подрастерял навыки тролинга сектантов.
Очень надеюсь, что в телефонном разговоре я был более убедителен, чем та "ну вроде солидная знакомая тетка", и отговорил батю от участия.
P.S. Давненько не общался хотя бы со свидетелями Иеговы, подрастерял навыки тролинга сектантов.
среда, 16 ноября 2011 г.
Lesson 49
Слово Канеру:
Техники тестирования основанные на людях
Вот некоторые примеры общих методов, зависящих от того, кто тестирует.
Пользовательское тестирование Тестирование с помощью тех типов людей, которые обычно пользуются вашим продуктом. Оно может быть проведено в любой момент разработки, на вашем или внешнем стенде, особое внимание уделяется мнению, опыту и особенностям пользователя. Некоторые типы пользовательского тестирования, такие как анализ задач, больше похожи на совместное исследование(с участием как минимум одного пользователя и как минимум одного тестировщика), чем на тестирование одним человеком.
Альфа-тест Внутреннее тестирование выполняется командой тестировщиков (и, возможно, других заинтересованных, дружественных инсайдеров).
Бета-тест Использует тестировщиков, которые не являются сотрудниками вашей организации, но являются целевой аудиторией вашего продукта. Продукт во время такого тестирования уже близок к готовности. Многие компании считают, что любой предварительный выпуск версии для клиентов это бета-тестирование. Они называют этап разработки "бета". Это ошибка. Действительно, есть много различных видов бета-тестирования. Бета тестирование дизайна, которое просит пользователей(особенно у экспертов) оценить дизайн продукта, должно пройти как можно раньше, для того, чтоб оставить время внести изменения по результатам тестирования. Маркетинговое бета-тестирование, которое необходимо для того, чтоб уверить крупных клиентов в том, что они должны купить продукт, когда он станет доступным и установить его в своей большой сети, должно выйти достаточно поздно, когда продукт будет уже стабилен. На бета-тесте совместимости заказчики запускают продукт в своем программном и аппаратном окружении - на том, которое вы бы не смогли протестировать самостоятельно. Этот вид тестирования важно провести до того как станет слишком поздно исправлять проблемы совместимости. Для любого вида бета-теста вы должны определить цели до того, как вы начнете планировать и выполнять что-либо.
Удар по багам Внутреннее тестирование с привлечением секретарей, программистов, маркетологов и всех, кого только можно. Обычно оно длится полдня и проводится когда продукт уже близок к релизу. (Замечание: мы описываем эту технику, но не одобряем ее, некоторые компании сочли эту технику полезной, другие нет).
Экспертное тестирование Дайте продукт экспертам в той или иной области ПО и получите от них фидбек (баги, критику и комплименты). Эксперт может быть, но может и не быть тем кто использует продукт - смысл в его знаниях, а не принадлежности к целевой аудитории.
Парное тестирование Два тестировщика ищут баги вместе. Как правило, они используют один компьютер и передают друг другу контроль во время тестирования.
Попробуйте корм вашей собаки Ваша компания может использовать в своей работе релизную или предрелизную версию своего продукта, обычно происходит ожидание того момента, когда продукт будет достаточно надежен, чтоб продать его.
Техники тестирования основанные на людях
Вот некоторые примеры общих методов, зависящих от того, кто тестирует.
Пользовательское тестирование Тестирование с помощью тех типов людей, которые обычно пользуются вашим продуктом. Оно может быть проведено в любой момент разработки, на вашем или внешнем стенде, особое внимание уделяется мнению, опыту и особенностям пользователя. Некоторые типы пользовательского тестирования, такие как анализ задач, больше похожи на совместное исследование(с участием как минимум одного пользователя и как минимум одного тестировщика), чем на тестирование одним человеком.
Альфа-тест Внутреннее тестирование выполняется командой тестировщиков (и, возможно, других заинтересованных, дружественных инсайдеров).
Бета-тест Использует тестировщиков, которые не являются сотрудниками вашей организации, но являются целевой аудиторией вашего продукта. Продукт во время такого тестирования уже близок к готовности. Многие компании считают, что любой предварительный выпуск версии для клиентов это бета-тестирование. Они называют этап разработки "бета". Это ошибка. Действительно, есть много различных видов бета-тестирования. Бета тестирование дизайна, которое просит пользователей(особенно у экспертов) оценить дизайн продукта, должно пройти как можно раньше, для того, чтоб оставить время внести изменения по результатам тестирования. Маркетинговое бета-тестирование, которое необходимо для того, чтоб уверить крупных клиентов в том, что они должны купить продукт, когда он станет доступным и установить его в своей большой сети, должно выйти достаточно поздно, когда продукт будет уже стабилен. На бета-тесте совместимости заказчики запускают продукт в своем программном и аппаратном окружении - на том, которое вы бы не смогли протестировать самостоятельно. Этот вид тестирования важно провести до того как станет слишком поздно исправлять проблемы совместимости. Для любого вида бета-теста вы должны определить цели до того, как вы начнете планировать и выполнять что-либо.
Удар по багам Внутреннее тестирование с привлечением секретарей, программистов, маркетологов и всех, кого только можно. Обычно оно длится полдня и проводится когда продукт уже близок к релизу. (Замечание: мы описываем эту технику, но не одобряем ее, некоторые компании сочли эту технику полезной, другие нет).
Экспертное тестирование Дайте продукт экспертам в той или иной области ПО и получите от них фидбек (баги, критику и комплименты). Эксперт может быть, но может и не быть тем кто использует продукт - смысл в его знаниях, а не принадлежности к целевой аудитории.
Парное тестирование Два тестировщика ищут баги вместе. Как правило, они используют один компьютер и передают друг другу контроль во время тестирования.
Попробуйте корм вашей собаки Ваша компания может использовать в своей работе релизную или предрелизную версию своего продукта, обычно происходит ожидание того момента, когда продукт будет достаточно надежен, чтоб продать его.
вторник, 15 ноября 2011 г.
Рутина
Намедни я научил наш фазер открывать несколько модальных окон. Он радостно заурчал и выплюнул в логи 400 багов этого типа. Я тоже радостно заурчал и заслал это специально обученной тестировщице для разбора и регистрации.
Она, почему-то, радости не показала, зато возразила, что воспроизвести удается пару-тройку. Из четырехсот.
Я почесал репу, нашел прогу и провел исследование - как быстро может кликать человек левой кнопкой мыши. Оказалось:
Ваш покорный слуга выжал 300 мс между кликами, мой падаван примерно так же.
Специально обученная тестировщица показала 500 мс и сказала что устала.
Руководитель отдела разработки три минуты разминался, показал 500 мс, обиделся, разозлился и выдал 150 мс
Заглянувший на ваш аттракцион еще не закрыт? программист показал результат 140 мс.
Но автотестеры не подвели. Боец wursternator, временно приданный группе для усиления, скромно улыбнулся, вспомнил геймерскую молодость и удивил нас 90 мс.
Selenium умеет кликать очень быстро. Примерно 70 мс между щелчками.
Я опять почесал репу и выставил тайм-аут быстрой части фазера в 150 мс. Если что - знаю кого позвать воспроизвести багу.
Она, почему-то, радости не показала, зато возразила, что воспроизвести удается пару-тройку. Из четырехсот.
Я почесал репу, нашел прогу и провел исследование - как быстро может кликать человек левой кнопкой мыши. Оказалось:
Ваш покорный слуга выжал 300 мс между кликами, мой падаван примерно так же.
Специально обученная тестировщица показала 500 мс и сказала что устала.
Руководитель отдела разработки три минуты разминался, показал 500 мс, обиделся, разозлился и выдал 150 мс
Заглянувший на ваш аттракцион еще не закрыт? программист показал результат 140 мс.
Но автотестеры не подвели. Боец wursternator, временно приданный группе для усиления, скромно улыбнулся, вспомнил геймерскую молодость и удивил нас 90 мс.
Selenium умеет кликать очень быстро. Примерно 70 мс между щелчками.
Я опять почесал репу и выставил тайм-аут быстрой части фазера в 150 мс. Если что - знаю кого позвать воспроизвести багу.
 |
| Альбом: randompics4lj |
Есть вопросы
Диалог о системе тестирования:
Я: - Так вот, мы передаем контейнер в тот метод
Коллега1: - Мне не нравится слово контейнер, в программировании оно значит совсем другое
Я: - В %предыдущий_проект% мы с Коллега2 пользовались этим словом и привыкли.
Коллега1: - Мне оно все равно не нравится, давайте использовать слово метаобъект
Коллега2: - У нас в системе(тестируемой) есть метаданные и метаклассы, мы запутаемся
Я: - Правильно, запутаемся. У нас демократия поэтому будем пользоваться словом контейнер
Я и Коллега2: - Слово контейнер реально неудобное :(((
Коллега1: - Я же говорил!
Я и Коллега2: - Твои версии на этот счет?
Коллега1: - Эээ...
Я: - Раз версий нет - будем пользоваться термином модель данных объекта тестируемой системы
Вот вы сейчас, наверное, скажете
- Мне бы ваши проблемы!
Тоогда я, наверное, отвечу:
- Уж какие есть.
А потом спрошу:
- Но у вас наверняка есть свои версии на все эти счета?
Нет, серьезно. В любой автоматизированной системе управления должно быть представление о управляемом объекте, некая ее модель.
А мы должны получать информацию о объекте сравнивать ее с информацией о модели объекта.
И всю эту хрень надо как-то называть.
Мало того, я сознательно допускаю некую неточность, так как мы храним значения параметров объекта, а понятие модель данных подразумевает еще и аспект манипуляции...
Итак, если вы понимаете, о чем я, то скажите:
- Какими определениями/терминами пользуетесь для обозначения модели тестируемого объекта в тестах?
P.S. Прям потянуло перечитать курс лекций по ТАУ
P.P.S. Наш selenium фреймворк ведь можно описать как замкнутую САУ дискретного воздействия, без обратной связи, неадаптивную, детерминированную, программную, многомерную, гы...
Я: - Так вот, мы передаем контейнер в тот метод
Коллега1: - Мне не нравится слово контейнер, в программировании оно значит совсем другое
Я: - В %предыдущий_проект% мы с Коллега2 пользовались этим словом и привыкли.
Коллега1: - Мне оно все равно не нравится, давайте использовать слово метаобъект
Коллега2: - У нас в системе(тестируемой) есть метаданные и метаклассы, мы запутаемся
Я: - Правильно, запутаемся. У нас демократия поэтому будем пользоваться словом контейнер
Я и Коллега2: - Слово контейнер реально неудобное :(((
Коллега1: - Я же говорил!
Я и Коллега2: - Твои версии на этот счет?
Коллега1: - Эээ...
Я: - Раз версий нет - будем пользоваться термином модель данных объекта тестируемой системы
Вот вы сейчас, наверное, скажете
- Мне бы ваши проблемы!
Тоогда я, наверное, отвечу:
- Уж какие есть.
А потом спрошу:
- Но у вас наверняка есть свои версии на все эти счета?
Нет, серьезно. В любой автоматизированной системе управления должно быть представление о управляемом объекте, некая ее модель.
А мы должны получать информацию о объекте сравнивать ее с информацией о модели объекта.
И всю эту хрень надо как-то называть.
Мало того, я сознательно допускаю некую неточность, так как мы храним значения параметров объекта, а понятие модель данных подразумевает еще и аспект манипуляции...
Итак, если вы понимаете, о чем я, то скажите:
- Какими определениями/терминами пользуетесь для обозначения модели тестируемого объекта в тестах?
P.S. Прям потянуло перечитать курс лекций по ТАУ
P.P.S. Наш selenium фреймворк ведь можно описать как замкнутую САУ дискретного воздействия, без обратной связи, неадаптивную, детерминированную, программную, многомерную, гы...
 |
| Альбом: randompics4lj |
суббота, 12 ноября 2011 г.
Lesson 48
Уже часть третья.
Слово Канеру:
Тестирование сочетает в себе людей, объекты, способы, потенциальные проблемы и оценку.
Главная цель этой части - показать систему классификации техник тестирования. Мы называем это пятью измерениями тестирования. Любой вид тестирования описывается в терминах пяти измерений:
- Тестировщики. Те, кто занимается теcтированием. Например, пользовательское тестирование фокусируется на тестировании силами целевой аудитории, теми, кто обычно использует продукт.
- Покрытие. То, что тестируется. Например, в функциональном тестировании мы тестируем каждую функцию.
- Потенциальные проблемы. Почему мы тестируем (какие риски мы проверяем). Например, тестирование на ошибку с максимальными значениями.
- Активности. Как вы тестируете. Например, исследовательское тестирование.
- Оценка. Как определить, что тест прошел или сработал. Например, сравнение с известным правильным результатом.
Также мы детально описали несколько техник в этой части и понимание того, как использовать еще несколько других, но наша главная цель - объяснить систему классификации.
Во всех тестах есть все пять измерений. Техника тестирования фокусирует ваше внимание на одном из пяти измерений, обходя другие. Вы могли бы комбинировать технику, которая сфокусирована на одном измерении с техникой, которая сфокусирована на другом для достижения требуемого результата. Вы могли бы назвать результат этого действия новой техникой тестирования (некоторые так и делают), но мы думаем, что процесс мышления более полезен, чем добавление новых имен в постоянно расширяющийся перечень непоследовательно определенных техник, используемый в нашей области. Наша схема классификации поможет комбинировать сознательно и вдумчиво.
Задачи тестирования часто концентрируются на одном измерении, но мы работаем во всех пяти. Например:
- Кто-то может попросить вас сделать функциональное тестирование (тщательно поверить все функции). Это говорит вам, что тестировать. Вы все еще должны решить, кто будет тестировать, какие типы багов вы будете искать, как тестировать каждую функцию, и как вы будете определять, что в программе есть ошибка.
- Кто-то может попросить вас повести тестирование "предельных значений" (тест, на ошибки, появляющиеся, когда мы вводим экстремальное значение переменной). Это говорит нам, какой тип проблем мы будем искать. Но нам до сих пор нужно решить, кто тестирует, какие переменные мы будем поверять, и как мы оценим результаты.
- Кто-то может попросить нас заняться бета-тестированием (если есть внешние потребители вашего продукта). Это говорит вам, кто будет тестировать, на какие проблемы вы будете обращать внимание (и какие игнорировать). В некоторых случаях, вы могли бы сообщить бета-тестерам, как распознавать определенные типы проблем, а также попросить их выполнить определенные тесты и пойти определенным путем. В других бета-тестах, вы могли бы оставить на усмотрение бета-тестеров и оценку результатов.
Техники не обязательно соответствуют какому-то одному измерению. Они и не должны: любое тестирование включает все пять измерений, и мы должны ждать от техник тестирования более глубокого охвата измерений.
Вот пример того, как техника может быть многомерной: если кто-то вас просит провести тестирование основанное на требованиях, он говорит тебе о комбинации трех идей:
- Покрытие: мы тестируем все, что описано в требованиях.
- Потенциальные проблемы: тестировать в направлениях, на которых эти требования могут быть не выполнены.
- Оценка: тесты будут спроектированы так, что спецификация будет определять ожидаемое поведение программы.
Разные тестировщики подразумевают разные комбинации этих идей, когда говорят: "тестирование по требованиям". Нет "правильного" понимания этой фразы.
Несмотря на двусмысленность (и, в некоторой степени, благодаря ей), мы находим нашу классификацию хорошим генератором идей.
Сохраняя во время тестирования в голове все пять измерений, вы можете подобрать лучший выбор комбинаций. Например, в бета-тестировании вы могли бы жестко не оговаривать одно или несколько измерений. Вы могли бы не определять способ оценки результатов или последовательности действий. Однако мы предлагаем, чтоб вы сознательно сделали этот выбор, приняв саму технику, а не сосредотачиваясь на каком-либо из аспектов.
Ремарка: неоднозначное понимание тестирования по требованиям дает нам пример главной проблемы в разработке ПО.
Слово Канеру:
Тестирование сочетает в себе людей, объекты, способы, потенциальные проблемы и оценку.
Главная цель этой части - показать систему классификации техник тестирования. Мы называем это пятью измерениями тестирования. Любой вид тестирования описывается в терминах пяти измерений:
- Тестировщики. Те, кто занимается теcтированием. Например, пользовательское тестирование фокусируется на тестировании силами целевой аудитории, теми, кто обычно использует продукт.
- Покрытие. То, что тестируется. Например, в функциональном тестировании мы тестируем каждую функцию.
- Потенциальные проблемы. Почему мы тестируем (какие риски мы проверяем). Например, тестирование на ошибку с максимальными значениями.
- Активности. Как вы тестируете. Например, исследовательское тестирование.
- Оценка. Как определить, что тест прошел или сработал. Например, сравнение с известным правильным результатом.
Также мы детально описали несколько техник в этой части и понимание того, как использовать еще несколько других, но наша главная цель - объяснить систему классификации.
Во всех тестах есть все пять измерений. Техника тестирования фокусирует ваше внимание на одном из пяти измерений, обходя другие. Вы могли бы комбинировать технику, которая сфокусирована на одном измерении с техникой, которая сфокусирована на другом для достижения требуемого результата. Вы могли бы назвать результат этого действия новой техникой тестирования (некоторые так и делают), но мы думаем, что процесс мышления более полезен, чем добавление новых имен в постоянно расширяющийся перечень непоследовательно определенных техник, используемый в нашей области. Наша схема классификации поможет комбинировать сознательно и вдумчиво.
Задачи тестирования часто концентрируются на одном измерении, но мы работаем во всех пяти. Например:
- Кто-то может попросить вас сделать функциональное тестирование (тщательно поверить все функции). Это говорит вам, что тестировать. Вы все еще должны решить, кто будет тестировать, какие типы багов вы будете искать, как тестировать каждую функцию, и как вы будете определять, что в программе есть ошибка.
- Кто-то может попросить вас повести тестирование "предельных значений" (тест, на ошибки, появляющиеся, когда мы вводим экстремальное значение переменной). Это говорит нам, какой тип проблем мы будем искать. Но нам до сих пор нужно решить, кто тестирует, какие переменные мы будем поверять, и как мы оценим результаты.
- Кто-то может попросить нас заняться бета-тестированием (если есть внешние потребители вашего продукта). Это говорит вам, кто будет тестировать, на какие проблемы вы будете обращать внимание (и какие игнорировать). В некоторых случаях, вы могли бы сообщить бета-тестерам, как распознавать определенные типы проблем, а также попросить их выполнить определенные тесты и пойти определенным путем. В других бета-тестах, вы могли бы оставить на усмотрение бета-тестеров и оценку результатов.
Техники не обязательно соответствуют какому-то одному измерению. Они и не должны: любое тестирование включает все пять измерений, и мы должны ждать от техник тестирования более глубокого охвата измерений.
Вот пример того, как техника может быть многомерной: если кто-то вас просит провести тестирование основанное на требованиях, он говорит тебе о комбинации трех идей:
- Покрытие: мы тестируем все, что описано в требованиях.
- Потенциальные проблемы: тестировать в направлениях, на которых эти требования могут быть не выполнены.
- Оценка: тесты будут спроектированы так, что спецификация будет определять ожидаемое поведение программы.
Разные тестировщики подразумевают разные комбинации этих идей, когда говорят: "тестирование по требованиям". Нет "правильного" понимания этой фразы.
Несмотря на двусмысленность (и, в некоторой степени, благодаря ей), мы находим нашу классификацию хорошим генератором идей.
Сохраняя во время тестирования в голове все пять измерений, вы можете подобрать лучший выбор комбинаций. Например, в бета-тестировании вы могли бы жестко не оговаривать одно или несколько измерений. Вы могли бы не определять способ оценки результатов или последовательности действий. Однако мы предлагаем, чтоб вы сознательно сделали этот выбор, приняв саму технику, а не сосредотачиваясь на каком-либо из аспектов.
Ремарка: неоднозначное понимание тестирования по требованиям дает нам пример главной проблемы в разработке ПО.
Рутина.
Пишу фазер "гатлинга". Тот же самый батон-давитель, но делающий все на скорости максимума человеческих возможностей. Самое сложное - идентифицировать багу.
Кстати, на уровне "нутром чую", но начинаю понимать разницу между профессионалом-тестировщиком и джедаем.
Примерно так: профессионал проведет дизайн или нагрузочное быстро, качественно а, может, в срок. Годный профессионал напоследок подскажет, что делать. Отличный - научит вас.
Сделает не так джедай. Джедай тестирования напишет фреймворк и аналитиков научит фреймворку написал который джедай. Или тест бета проведет. А может кликать вручную начнет просветленный. Или бадминтоном с алкоголем команду займет. Да он может не делать ничего. Иначе или так, неизбежно это к решению проблем с качеством приведет. Силу использует джедай.
Не знаю, как это точнее сформулировать, просто читаю третью часть уроков о тестировании и отчетливо понимаю, что Канер - джедай.
Кстати, на уровне "нутром чую", но начинаю понимать разницу между профессионалом-тестировщиком и джедаем.
Примерно так: профессионал проведет дизайн или нагрузочное быстро, качественно а, может, в срок. Годный профессионал напоследок подскажет, что делать. Отличный - научит вас.
Сделает не так джедай. Джедай тестирования напишет фреймворк и аналитиков научит фреймворку написал который джедай. Или тест бета проведет. А может кликать вручную начнет просветленный. Или бадминтоном с алкоголем команду займет. Да он может не делать ничего. Иначе или так, неизбежно это к решению проблем с качеством приведет. Силу использует джедай.
 |
| Альбом: randompics4lj |
Не знаю, как это точнее сформулировать, просто читаю третью часть уроков о тестировании и отчетливо понимаю, что Канер - джедай.
пятница, 11 ноября 2011 г.
ЫЫЫЫ
История отсюда:
http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php
О тестировании, кстати, многобукаф, с подачи SALar
Для начала небольшая ремарка: у каждого сотрудника нашего банка есть 2 почтовых ящика: один - для переписки внутри банка и еще один - внешний.
На тот ящик, который предназначен для общения с окружающим миром, ясен пень, ежедневно валится разнообразный спам.
Понятно, что он тут же отправляется прямиком в корзину.
Но до сегодняшнего дня внутренняя почта была свободна от этой заразы...
Так вот, в связи с некоторыми изменениями, происходящими у нас на работе, первую половину дня я провожу в одном из наших доп. офисов, а вторую - в центральном офисе на своем рабочем месте.
Сегодняшний день не стал исключением.
Приехав, наконец, к себе в контору, я обнаружил, что работа нашего подразделения парализована.
Чтобы вы вполне могли себе представить картину, открывшуюся мне, когда я зашел в комнату - обрисую ситуацию.
В нашем отделе сидят кроме меня еще 4 человека: начальник нашего Управления, его секретарша, девушка-маркетолог и мой напарник.
Необходимо добавить, что площадь помещения, где мы впятером сидим, превышает, причем сильно, 300 кв. метров (эдакий спортзал).
Так вот, открыв дверь я слышу дикий гогот, что, скажем прямо, не очень характерно для моих коллег (особенно для мужской части коллектива), но при этом никого не вижу...
Выйдя на середину нашей комнаты, я, наконец, вижу, что начальник -солидный мужик лет сорока в своем недешевом костюмчике катается по полу и ржет...
Остальные, впрочем, заняты примерно тем же...
Немая сцена...
Минуты через три к ним возвращается дар речи, и я начинаю хотя бы в первом приближении понимать, что случилось...
Оказывается, сегодня по ВНУТРЕННЕЙ почте ВСЕ сотрудники банка получили письмо следующего содержания:
*************************************************************
Суперцена! Такого еще не было!
Профессиональные минеты от 5 у. е.!
Телефон: 775-**-** (круглосуточно).
*************************************************************
Ну, в принципе, таким текстом сегодня, в век высоких технологий и окончательно победившей сексуальной революции никого не удивишь...
Хотя, конечно, обороты вроде "профессиональный минет" - это сильно!...
Особенно интересно, чем профессиональный отличается от любительского и каковы критерии оценки...
Цена, опять же, весьма привлекательная...
Ну, как бы то ни было, факт остается фактом - письмо получено по внутренней почте (правда адрес отправителя не указан).
Самое забавное - телефон...
Дело в том, что все телефоны в центральном офисе выглядят следующим образом: 775-**-**.
Вы уже догадываетесь, что будет дальше?
Реакция всех очевидцев была синхронной: все схватили телефонные справочники и начали выяснять, кто это хочет нажиться на сослуживцах...
Однако, не все так просто: такой телефон в справочнике не указан...
Но разве можно на этом успокоиться?
Сделав вид, что тема закрыта, все (включая меня) разбрелись по своим местам...
Минуты 2 все усиленно лупили по клавиатуре, создавая видимость работы...
Во внезапно наступившей тишине было отчетливо слышно как все (и я тоже)схватились за телефоны и начали куда-то названивать с таким видом, словно у каждо гогорит контракт на несколько миллионов долларов...
Неудивительно, что спустя секунд 15 все с разочарованным видом положили трубки...
Ничего странного, у всех было занято, потому как ВСЕ звонили по номеру из объявления...
Не знаю что уж так заинтересовало девушек в этой объяве... наверное хотели узнать, как стать профессионалом и грести пятидолларовые бумажки лопатой...
Когда минут через 20 кому-то все-таки удалось прозвониться - выяснилось, что "аппарат абонента временно заблокирован"...
Все разочарованно покурили и разбрелись по своим углам.
Но на этом история не закончилась...
Спустя еще минут 20 к нам зашел один из компьютерщиков и по секрету рассказал, что вчера у нас установили новую офисную мега-супер-пупер-АТС.
Нужно было протестировать ее на предмет того, справится ли она с пиковыми нагрузками (короче, если все разом начнут куда-то звонить или принимать звонки, нае*нется АТС или нет)...
Кто-то из наших компьютерных гениев додумался позвонить в отдел по работе с персоналом и сформулировать задачу.
Весь вчерашний день и начало сегодняшнего в стенах кадрового отдела бушевал мозговой шторм (потому что мозговой штУрм не даст столь выдающихся результатов).
В итоге было сочинено то самое письмо, которое и было разослано всем нам...
Напоследок компьютерщик стрельнул у меня сигаретку про запас и совсем уж по секрету сказал, что АТС все-таки нае*нулся - за первые 10 минут поступило больше трех тысяч звонков (всего в банке работает человек 500)... так что когда технику починят, нас ждет продолжение тестирования.
Кот смотрит в будущее с надеждой.
http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php
О тестировании, кстати, многобукаф, с подачи SALar
Для начала небольшая ремарка: у каждого сотрудника нашего банка есть 2 почтовых ящика: один - для переписки внутри банка и еще один - внешний.
На тот ящик, который предназначен для общения с окружающим миром, ясен пень, ежедневно валится разнообразный спам.
Понятно, что он тут же отправляется прямиком в корзину.
Но до сегодняшнего дня внутренняя почта была свободна от этой заразы...
Так вот, в связи с некоторыми изменениями, происходящими у нас на работе, первую половину дня я провожу в одном из наших доп. офисов, а вторую - в центральном офисе на своем рабочем месте.
Сегодняшний день не стал исключением.
Приехав, наконец, к себе в контору, я обнаружил, что работа нашего подразделения парализована.
Чтобы вы вполне могли себе представить картину, открывшуюся мне, когда я зашел в комнату - обрисую ситуацию.
В нашем отделе сидят кроме меня еще 4 человека: начальник нашего Управления, его секретарша, девушка-маркетолог и мой напарник.
Необходимо добавить, что площадь помещения, где мы впятером сидим, превышает, причем сильно, 300 кв. метров (эдакий спортзал).
Так вот, открыв дверь я слышу дикий гогот, что, скажем прямо, не очень характерно для моих коллег (особенно для мужской части коллектива), но при этом никого не вижу...
Выйдя на середину нашей комнаты, я, наконец, вижу, что начальник -солидный мужик лет сорока в своем недешевом костюмчике катается по полу и ржет...
Остальные, впрочем, заняты примерно тем же...
Немая сцена...
Минуты через три к ним возвращается дар речи, и я начинаю хотя бы в первом приближении понимать, что случилось...
Оказывается, сегодня по ВНУТРЕННЕЙ почте ВСЕ сотрудники банка получили письмо следующего содержания:
*************************************************************
Суперцена! Такого еще не было!
Профессиональные минеты от 5 у. е.!
Телефон: 775-**-** (круглосуточно).
*************************************************************
Ну, в принципе, таким текстом сегодня, в век высоких технологий и окончательно победившей сексуальной революции никого не удивишь...
Хотя, конечно, обороты вроде "профессиональный минет" - это сильно!...
Особенно интересно, чем профессиональный отличается от любительского и каковы критерии оценки...
Цена, опять же, весьма привлекательная...
Ну, как бы то ни было, факт остается фактом - письмо получено по внутренней почте (правда адрес отправителя не указан).
Самое забавное - телефон...
Дело в том, что все телефоны в центральном офисе выглядят следующим образом: 775-**-**.
Вы уже догадываетесь, что будет дальше?
Реакция всех очевидцев была синхронной: все схватили телефонные справочники и начали выяснять, кто это хочет нажиться на сослуживцах...
Однако, не все так просто: такой телефон в справочнике не указан...
Но разве можно на этом успокоиться?
Сделав вид, что тема закрыта, все (включая меня) разбрелись по своим местам...
Минуты 2 все усиленно лупили по клавиатуре, создавая видимость работы...
Во внезапно наступившей тишине было отчетливо слышно как все (и я тоже)схватились за телефоны и начали куда-то названивать с таким видом, словно у каждо гогорит контракт на несколько миллионов долларов...
Неудивительно, что спустя секунд 15 все с разочарованным видом положили трубки...
Ничего странного, у всех было занято, потому как ВСЕ звонили по номеру из объявления...
Не знаю что уж так заинтересовало девушек в этой объяве... наверное хотели узнать, как стать профессионалом и грести пятидолларовые бумажки лопатой...
Когда минут через 20 кому-то все-таки удалось прозвониться - выяснилось, что "аппарат абонента временно заблокирован"...
Все разочарованно покурили и разбрелись по своим углам.
Но на этом история не закончилась...
Спустя еще минут 20 к нам зашел один из компьютерщиков и по секрету рассказал, что вчера у нас установили новую офисную мега-супер-пупер-АТС.
Нужно было протестировать ее на предмет того, справится ли она с пиковыми нагрузками (короче, если все разом начнут куда-то звонить или принимать звонки, нае*нется АТС или нет)...
Кто-то из наших компьютерных гениев додумался позвонить в отдел по работе с персоналом и сформулировать задачу.
Весь вчерашний день и начало сегодняшнего в стенах кадрового отдела бушевал мозговой шторм (потому что мозговой штУрм не даст столь выдающихся результатов).
В итоге было сочинено то самое письмо, которое и было разослано всем нам...
Напоследок компьютерщик стрельнул у меня сигаретку про запас и совсем уж по секрету сказал, что АТС все-таки нае*нулся - за первые 10 минут поступило больше трех тысяч звонков (всего в банке работает человек 500)... так что когда технику починят, нас ждет продолжение тестирования.
Кот смотрит в будущее с надеждой.
 |
| Альбом: randompics4lj |
четверг, 10 ноября 2011 г.
Ы!
Я уже перевел 2 чаптера из лессонсов Канера, если кто не заметил, но тут мне сказали, мол мой уютненький зануден. Я исправлюсь. Наверное.
Фор экзампл, давеча мы с коллегами проводили рисерч и обнаружили страшное: Ничего не найдено!. Что ж, будем жить в таком мире.
Ну и вернем кота.
Фор экзампл, давеча мы с коллегами проводили рисерч и обнаружили страшное: Ничего не найдено!. Что ж, будем жить в таком мире.
Ну и вернем кота.
 |
| Альбом: randompics4lj |
среда, 9 ноября 2011 г.
Рутина.
Наш глав-jenkins до сих пор пишет мне письма о том, что та или иная сборка с main view нестабильна или упала.
Единственное объяснение - он по старой памяти жалуется, хотя я уже давно не занимаюсь поддержкой внутренней инфраструктуры.
Вы не думайте, я не идиот. Команда
cat /home/hudson/.hudson/jobs/*/*.xml |grep
не дает ничего.
Еще я столько не коммичу. И мой мейл давно уже не записан в администраторы системы. Давно - это почти год, с тех пор система неоднократно перезагружалась. Единственное объяснение я написал выше - наша система CI жалуется мне.
Помнит, зараза...
Единственное объяснение - он по старой памяти жалуется, хотя я уже давно не занимаюсь поддержкой внутренней инфраструктуры.
Вы не думайте, я не идиот. Команда
cat /home/hudson/.hudson/jobs/*/*.xml |grep
не дает ничего.
Еще я столько не коммичу. И мой мейл давно уже не записан в администраторы системы. Давно - это почти год, с тех пор система неоднократно перезагружалась. Единственное объяснение я написал выше - наша система CI жалуется мне.
Помнит, зараза...
 |
| Альбом: randompics4lj |
Lesson 47
Днем услышал фразу, что то типа: "Инициализирует инстанс экземпляра класса объекта". Не дословно, но примерно так. Сперва долго пытался понять смысл фразы. Раз пять переспрашивал: Так все-таки что оно делает-то? Делает-то оно что?
Потом мне, вроде бы, объяснили, чего оно делает. Оставшийся час я выяснял, почему оно ТАК называется. Есть же хорошие простые добрые слова...
Слово Канеру:
Ты не освоишь тестирование пока, ты не изобретешь его.
Не изобретай колеса. Подождите-ка. Разве не изобретение колеса снова и снова чаще всего просходит в истории? Разве это плохо? В конце концов, мы ездим на пневматических шинах, а не на гранитных дисках. Есть тысячи, если не миллионы вариаций на тему колеса. Может быть это урок? Кажется, существует как минимум две причины изобрести что-то снова: адаптировать это к новой ситуации, и изучить как это работает. Мастерство требует и того и другого.
У нас есть коллеги, советующие студентам избегать повторного изобретения тестов или придумывания уже существующих идей по тестированию. Это все равно что наука без экспериментов. Учиться у других – это нормально. Мы считаем, что именно так и важно учиться – если не верите, проверьте название этой книги.
Но если это единственный способ изучения – вы никогда не станете мастером в ремесле тестировщика. Вы будете подмастерьем, не более. Следование инструкциям заведет вас не дальше, чем следование по трассе в направлении Марса. Мы призываем вас изучать тестирование в духе великих механиков и великих программистов: разбирайте все до винтиков, задумывайтесь как они работают, и собирайте обратно подругому. Не ограничивайтесь чужой мудростью, будьте автором своей.
Сначала, ваши тесты, идеи, методы, или документы будут так себе. Это нормально. Просто держите свой мозг включенным, наблюдайте за другими тестировщиками, изучайте, и постоянно оценивайте выхлоп от ваших идей. Если вы хотите преуспеть, практикуйтесь.
Мы годами занимаемся тестированием и мы все еще изобретаем, все еще модифицируем старые идеи. Все коллеги, которых мы уважаем, идут тем же путем.
Потом мне, вроде бы, объяснили, чего оно делает. Оставшийся час я выяснял, почему оно ТАК называется. Есть же хорошие простые добрые слова...
Слово Канеру:
Ты не освоишь тестирование пока, ты не изобретешь его.
Не изобретай колеса. Подождите-ка. Разве не изобретение колеса снова и снова чаще всего просходит в истории? Разве это плохо? В конце концов, мы ездим на пневматических шинах, а не на гранитных дисках. Есть тысячи, если не миллионы вариаций на тему колеса. Может быть это урок? Кажется, существует как минимум две причины изобрести что-то снова: адаптировать это к новой ситуации, и изучить как это работает. Мастерство требует и того и другого.
У нас есть коллеги, советующие студентам избегать повторного изобретения тестов или придумывания уже существующих идей по тестированию. Это все равно что наука без экспериментов. Учиться у других – это нормально. Мы считаем, что именно так и важно учиться – если не верите, проверьте название этой книги.
Но если это единственный способ изучения – вы никогда не станете мастером в ремесле тестировщика. Вы будете подмастерьем, не более. Следование инструкциям заведет вас не дальше, чем следование по трассе в направлении Марса. Мы призываем вас изучать тестирование в духе великих механиков и великих программистов: разбирайте все до винтиков, задумывайтесь как они работают, и собирайте обратно подругому. Не ограничивайтесь чужой мудростью, будьте автором своей.
Сначала, ваши тесты, идеи, методы, или документы будут так себе. Это нормально. Просто держите свой мозг включенным, наблюдайте за другими тестировщиками, изучайте, и постоянно оценивайте выхлоп от ваших идей. Если вы хотите преуспеть, практикуйтесь.
Мы годами занимаемся тестированием и мы все еще изобретаем, все еще модифицируем старые идеи. Все коллеги, которых мы уважаем, идут тем же путем.
вторник, 8 ноября 2011 г.
Lesson 46
Интересный способ оценки проекта. Один из.
Слово Канеру:
Одним из важных результатов процесса тестирования является хороший, умный тестировщик.
Мы часто слышим аргументы против любых форм тестирования, результаты которых имеют минимальное или не имеют никакого документирования, как будто единственная ценность тестирования состоит в описании тестов. Это игнорирует важный продукт тестирования — собственно тестировщик.
Хорошие тестировщики всегда учатся. С развитием проекта они все глубже понимают продукт и постепенно увеличивают рефлексы и чувствительность к важным частям проекта. Опытный тестировщик, который прошел один или два цикла релиза, способен тестировать с гораздо большей эффективностью — часто без каких-либо инструкций — по сравнению с неопытным, которому нужны письменные инструкции о том, как и что он проверяет в продукте.
Некоторые консультанты и писатели в нашей области кажется верят в то, что неэффективный тестировщик может стать эффективным только путем следования выданным ему инструкциям. По нашему мнению это плохая практика. Она отражает основополагающее заблуждение о тестировании и о людях, которые тестировать умеют.
Когда оцениваете процесс тестирования — смотрите в первую очередь на тестировщиков проекта. Смотрите на то, как они думают и как это влияет на то, что он делают. Только тогда вы сможете оценить работу продукта, который они производят.
Слово Канеру:
Одним из важных результатов процесса тестирования является хороший, умный тестировщик.
Мы часто слышим аргументы против любых форм тестирования, результаты которых имеют минимальное или не имеют никакого документирования, как будто единственная ценность тестирования состоит в описании тестов. Это игнорирует важный продукт тестирования — собственно тестировщик.
Хорошие тестировщики всегда учатся. С развитием проекта они все глубже понимают продукт и постепенно увеличивают рефлексы и чувствительность к важным частям проекта. Опытный тестировщик, который прошел один или два цикла релиза, способен тестировать с гораздо большей эффективностью — часто без каких-либо инструкций — по сравнению с неопытным, которому нужны письменные инструкции о том, как и что он проверяет в продукте.
Некоторые консультанты и писатели в нашей области кажется верят в то, что неэффективный тестировщик может стать эффективным только путем следования выданным ему инструкциям. По нашему мнению это плохая практика. Она отражает основополагающее заблуждение о тестировании и о людях, которые тестировать умеют.
Когда оцениваете процесс тестирования — смотрите в первую очередь на тестировщиков проекта. Смотрите на то, как они думают и как это влияет на то, что он делают. Только тогда вы сможете оценить работу продукта, который они производят.
пятница, 4 ноября 2011 г.
Lesson 45
Слово Канеру:
Если вы создаете процедуры тестирования, опасайтесь «1287.»
Один из нас, Бах, однажды был свидетелем того, как тестировщик писал процедуру тестирования, которая включала в себя строку «Введите 1287 символов в поле». Откуда взялись 1287? Тестировщик объяснил это тем, что по его идее нужно ввести в маленькое поле ввода очень большой набор символов. И, поскольку он слышал, что тестовые процедуры должны быть конкретными, он вернулся и тщательно пересчитал, сколько он ввел символов, их было 1287. И он вставил это в процедуру — и теперь произвольное число закреплено в тесте, как кошка в цементе.
Сверхточность не помогает. Когда вы пишете тест, избегайте любой специфики, которая не релевантна идее тестирования. Включайте любые моменты и тонкости, необходимые для того, чтоб сформулировать и объяснить тест, но позвольте будущему тестировщику поупражняться в творчестве и оценке. Позвольте будущему тестировщику внести изменения, которые сохранят процедуру тестирования свежей и эффективной.
Если вы создаете процедуры тестирования, опасайтесь «1287.»
Один из нас, Бах, однажды был свидетелем того, как тестировщик писал процедуру тестирования, которая включала в себя строку «Введите 1287 символов в поле». Откуда взялись 1287? Тестировщик объяснил это тем, что по его идее нужно ввести в маленькое поле ввода очень большой набор символов. И, поскольку он слышал, что тестовые процедуры должны быть конкретными, он вернулся и тщательно пересчитал, сколько он ввел символов, их было 1287. И он вставил это в процедуру — и теперь произвольное число закреплено в тесте, как кошка в цементе.
Сверхточность не помогает. Когда вы пишете тест, избегайте любой специфики, которая не релевантна идее тестирования. Включайте любые моменты и тонкости, необходимые для того, чтоб сформулировать и объяснить тест, но позвольте будущему тестировщику поупражняться в творчестве и оценке. Позвольте будущему тестировщику внести изменения, которые сохранят процедуру тестирования свежей и эффективной.
четверг, 3 ноября 2011 г.
Lesson 44
Сегодня ничего не понимаю.
Слово Канеру:
Избегай следования процедурам если они не следуют за тобой.
Остерегайся процедур других людей. Они обычно заключаются в сценариях тестирования и процедурах, сформулированных таким образом, что они ничего не говорят о целях, лежащих в основе стратегии тестирования. Это создает большую вероятность того, что ты будешь следовать тестам без полного понимания того, что они делают и на что нужно обращать внимание. Другими словами, вы на самом деле не будете следовать им. В целом, тестовые процедуры плохо описаны и плохо спроектированы так как несколько хороших тестировщиков попытались запрограммировать людей как компьютеры. Если вы хотите следовать процедурам тестирования, то предпочитайте те, что вы спроектировали сами, те что вам принадлежат или те, которые вы тщательно изучили.
Для достижения наилучших результатов вы должны контролировать ваше тестирование, а не вашу документацию. Заставьте ее следовать за вами.
Если вы убеждены, что процедуры тестирования хорошая вещь, по крайней мере изучите, как они работают. Посмотри Things that Make Us Smart: Defending Human Attributes in the Age of the Machine (Norman 1993) и The Social Life of Information (Brown and Duguid 2000).
 |
| Альбом: randompics4lj |
Слово Канеру:
Избегай следования процедурам если они не следуют за тобой.
Остерегайся процедур других людей. Они обычно заключаются в сценариях тестирования и процедурах, сформулированных таким образом, что они ничего не говорят о целях, лежащих в основе стратегии тестирования. Это создает большую вероятность того, что ты будешь следовать тестам без полного понимания того, что они делают и на что нужно обращать внимание. Другими словами, вы на самом деле не будете следовать им. В целом, тестовые процедуры плохо описаны и плохо спроектированы так как несколько хороших тестировщиков попытались запрограммировать людей как компьютеры. Если вы хотите следовать процедурам тестирования, то предпочитайте те, что вы спроектировали сами, те что вам принадлежат или те, которые вы тщательно изучили.
Для достижения наилучших результатов вы должны контролировать ваше тестирование, а не вашу документацию. Заставьте ее следовать за вами.
Если вы убеждены, что процедуры тестирования хорошая вещь, по крайней мере изучите, как они работают. Посмотри Things that Make Us Smart: Defending Human Attributes in the Age of the Machine (Norman 1993) и The Social Life of Information (Brown and Duguid 2000).
среда, 2 ноября 2011 г.
Lesson 43
Примерно с 2.9 релиза selenium начал нормально отрабатывать MoveTargetOutOfBoundsException — это когда нельзя пецкнуть элемент, находящийся вне рабочей области браузера. Cегодня обновил pom.xml и на тебе: наш «боевой фазер» находит четверть сотни такой хрени — и это на чистой базе.
Стоит похвалить и ручных тестировщиков — они об этом уже знали и повесили тикет в виде темно-розового сердечка(светло розовые сердечки менее приоритетны).
Ну а я что? Я прям обрадовался и решил, что мое существование в проекте становится близким к смыслу.
Сказал мол — даешь новые типы тестов в массы. Даешь автоматические тесты на права как в фейсбуке. А мне, как водится, тут же объяснили, что все это уже продумано без меня, запланировано до нас и вообще вчера обсуждалось с Наташей Р..
Велосипед изобрели до меня. Это печально.
Слово Канеру:
Свежий взгляд найдет багу.
Понять смысл чего-либо это сложный интеллектуальный процесс преобразования новой информации в то, что вы уже знаете, изменяя при этом то, что вы уже знаете, для размещения новой информации. После того, как вы поняли смысл продукта или фичи вы имеете их ментальную карту и вашему мозгу становится легче с этим работать. Это может быть проблемой для тестировщиков. Если вы хорошо знаете продукт, то вы делаете много допущений о нем и вы не так часто проверяете эти допущения.
Эта ситуация имеет по крайней мере три последствия для тестирования:
- Когда вы получаете продукт или фичу, уделите особое внимание тому, что смущает или раздражает вас. Это может говорить о том, какой окажется реакция пользователей на продукт.
- Если у вас в команде новички — работайте вместе с ними. Наблюдайте за их реакцией на продукт и на то, как они изучают его.
- Остерегайтесь попадания тестирования в колею. Даже если вы не следуете жестким сценариям тестирования, вы можете быть так хорошо знакомы с особенностями продукта, что вы будете тестировать все более сужающиеся части продукта. Внесите изменения там где вы можете или обменяйтесь обязанностями с другим тестировщиком.
Стоит похвалить и ручных тестировщиков — они об этом уже знали и повесили тикет в виде темно-розового сердечка(светло розовые сердечки менее приоритетны).
Ну а я что? Я прям обрадовался и решил, что мое существование в проекте становится близким к смыслу.
Сказал мол — даешь новые типы тестов в массы. Даешь автоматические тесты на права как в фейсбуке. А мне, как водится, тут же объяснили, что все это уже продумано без меня, запланировано до нас и вообще вчера обсуждалось с Наташей Р..
Велосипед изобрели до меня. Это печально.
 |
| Альбом: randompics4lj |
Слово Канеру:
Свежий взгляд найдет багу.
Понять смысл чего-либо это сложный интеллектуальный процесс преобразования новой информации в то, что вы уже знаете, изменяя при этом то, что вы уже знаете, для размещения новой информации. После того, как вы поняли смысл продукта или фичи вы имеете их ментальную карту и вашему мозгу становится легче с этим работать. Это может быть проблемой для тестировщиков. Если вы хорошо знаете продукт, то вы делаете много допущений о нем и вы не так часто проверяете эти допущения.
Эта ситуация имеет по крайней мере три последствия для тестирования:
- Когда вы получаете продукт или фичу, уделите особое внимание тому, что смущает или раздражает вас. Это может говорить о том, какой окажется реакция пользователей на продукт.
- Если у вас в команде новички — работайте вместе с ними. Наблюдайте за их реакцией на продукт и на то, как они изучают его.
- Остерегайтесь попадания тестирования в колею. Даже если вы не следуете жестким сценариям тестирования, вы можете быть так хорошо знакомы с особенностями продукта, что вы будете тестировать все более сужающиеся части продукта. Внесите изменения там где вы можете или обменяйтесь обязанностями с другим тестировщиком.
понедельник, 31 октября 2011 г.
Хорошо.
Помните, как-то весной я рассказывал, что у нас в городе побывала Наталья Руколь?
У меня еще появился прикольный календарик с автографом.
На днях она еще раз приезжала к нам рассказать о планированиии и проектировании тестов.
Меня, как водится, там не было, но начальство, которое там, как водится, было, еще раз передало мне приятный ништячок от Натальи.
Раз:
А унутре у неенеонка автограф, ага.
P.S. Ну и еще руководство всяко хвалило сей тренинг, да.
У меня еще появился прикольный календарик с автографом.
На днях она еще раз приезжала к нам рассказать о планированиии и проектировании тестов.
Меня, как водится, там не было, но начальство, которое там, как водится, было, еще раз передало мне приятный ништячок от Натальи.
Раз:
 |
| Альбом: office |
А унутре у нее
 |
| Альбом: office |
P.S. Ну и еще руководство всяко хвалило сей тренинг, да.
суббота, 29 октября 2011 г.
Lesson 42
Рисовали мы тут диаграммы - кто как работает, что на входе, какой продукт на выходе и так далее. Для всех. Чтоб выяснить, на каких печеньках сэкономить и вообще понять, что происходит.
Примерно так выглядит небольшая часть диаграммы работ у программистов:
Оно же ИРЛ:
А вот так - у автотестеров:
Оно же ИРЛ:
Как то так.
Слово Канеру:
Путаница это инструмент тестировщика.
Если вы чувствуете, что запутались, знайте, это может говорить вам о чем-то важном.
Это путаница в спецификациях? Неясности в спецификациях часто появляются чтоб скрыть важные разногласия среди влиятельных заинтересованных сторон.
Это путаница в продукте? Он может быть сломан.
Это путаница в пользовательской документации?Эта часть продукта может быть очень сложной. Слишком много разных сценариев использования и несоответствий между ними, чтоб описать их.
Лежащая в основе проблема трудна для понимания? Некоторые системы, которые мы пытаемся автоматизировать, по своей сути сложны или включают в себя различные технические вопросы. Программисты тоже находят их сложными и это приводит к ошибкам, упущениям, непониманию, переупрощению.
Чем больше ты знаешь о продукте, технологиях и тестировании вообще, тем лучший компас у тебя появится, который покажет тебе, где лежат важные проблемы.
В тестировании, если ты ничего не знаешь о продукте, то ты хотя бы понимаешь, что запутался. В этой ситуации путаница, в форме вопросов о проблеме, которые никто не имел смелости поднять, может быть лучшим результатом
Примерно так выглядит небольшая часть диаграммы работ у программистов:
 |
| Альбом: office |
Оно же ИРЛ:
 |
| Альбом: office |
А вот так - у автотестеров:
 |
| Альбом: office |
Оно же ИРЛ:
 |
| Альбом: office |
Как то так.
Слово Канеру:
Путаница это инструмент тестировщика.
Если вы чувствуете, что запутались, знайте, это может говорить вам о чем-то важном.
Это путаница в спецификациях? Неясности в спецификациях часто появляются чтоб скрыть важные разногласия среди влиятельных заинтересованных сторон.
Это путаница в продукте? Он может быть сломан.
Это путаница в пользовательской документации?Эта часть продукта может быть очень сложной. Слишком много разных сценариев использования и несоответствий между ними, чтоб описать их.
Лежащая в основе проблема трудна для понимания? Некоторые системы, которые мы пытаемся автоматизировать, по своей сути сложны или включают в себя различные технические вопросы. Программисты тоже находят их сложными и это приводит к ошибкам, упущениям, непониманию, переупрощению.
Чем больше ты знаешь о продукте, технологиях и тестировании вообще, тем лучший компас у тебя появится, который покажет тебе, где лежат важные проблемы.
В тестировании, если ты ничего не знаешь о продукте, то ты хотя бы понимаешь, что запутался. В этой ситуации путаница, в форме вопросов о проблеме, которые никто не имел смелости поднять, может быть лучшим результатом
пятница, 28 октября 2011 г.
Так
Переводить текст с английского не могу под музыку со словами.
Писать сценарии для тестирования не могу под музыку с русскими словами.
Писать код тестов можно не только под русскоязычную музыку, но и - сняв наушники - под диалоги коллег.
Как-то так.
Писать сценарии для тестирования не могу под музыку с русскими словами.
Писать код тестов можно не только под русскоязычную музыку, но и - сняв наушники - под диалоги коллег.
Как-то так.
четверг, 27 октября 2011 г.
ЗВ
Смотрю возвращение джедая.
Не понимаю: Вейдер хотел увидеть Люка, чтоб убедить перейти на темную сторону силы - то есть донести свои убеждения, попытаться договориться.
Люк в разговоре с Кеноби понимает "встретиться" только как "убить".
И кто на темной стороне?
Не понимаю: Вейдер хотел увидеть Люка, чтоб убедить перейти на темную сторону силы - то есть донести свои убеждения, попытаться договориться.
Люк в разговоре с Кеноби понимает "встретиться" только как "убить".
И кто на темной стороне?
среда, 26 октября 2011 г.
Lesson 41
Слово Канеру:
Если вы пропустили ошибку — проверьте, была ли это случайность или естественный результат вашей стратегии тестирования.
Если вы подбрасываете монету и загадываете решку, но продолжает появляться орел, не значит ли это, что вы приняли неверное решение? Независимо от какого-либо рационального стандарта. Если это не фокус, то у нас есть 50% шанс на выпадение решки и выпадение орла будет просто невезением, а не чем-либо удивительным.
Этот же вопрос стоит задать, когда вы не находите баги в процессе тестирования и это создает проблемы вашим клиентам. Не бейте себя по голове, пока не проверите, что случилось со стратегией тестирования. Случилось бы это, если бы вы следовали верной стратегии тестирования? Если это случайность — следуйте прежним курсом. Но, если вы пропустили баг из-за того, что ваша стратегия тестирования сфокусирована на других типах проблем, используйте эту возможность, чтоб изменить ее.
Если вы пропустили ошибку — проверьте, была ли это случайность или естественный результат вашей стратегии тестирования.
Если вы подбрасываете монету и загадываете решку, но продолжает появляться орел, не значит ли это, что вы приняли неверное решение? Независимо от какого-либо рационального стандарта. Если это не фокус, то у нас есть 50% шанс на выпадение решки и выпадение орла будет просто невезением, а не чем-либо удивительным.
Этот же вопрос стоит задать, когда вы не находите баги в процессе тестирования и это создает проблемы вашим клиентам. Не бейте себя по голове, пока не проверите, что случилось со стратегией тестирования. Случилось бы это, если бы вы следовали верной стратегии тестирования? Если это случайность — следуйте прежним курсом. Но, если вы пропустили баг из-за того, что ваша стратегия тестирования сфокусирована на других типах проблем, используйте эту возможность, чтоб изменить ее.
вторник, 25 октября 2011 г.
Lesson 40
Слово Канеру:
Вас труднее обмануть, если вы знаете, что вы дурак.
Мошенники говорят, что легче всего обмануть тех, кто убежден, что его невозможно обмануть. Вы можете применить этот принцип в своей работе тестировщика. Убедите себя в том, что вы дурак. Это несложно, просто осторожно наблюдайте за своими ошибками во время тестирования. Записывайте каждый раз, когда другой тестировщик обнаружил проблему там, где вы могли бы ее обнаружить, но не сделали этого.
Если вы знаете, что вас легко обмануть, то вы становитесь немного более внимательным. Вы и ваш ум сильнее и подробнее работают с деталями стратегии тестирования. Это один из самых быстрых путей совершенствования начинающего тестировщика, так как сознание того, что вы дурак — это отношение, а не навык или знание. Проблема начинающих тестировщиков в том, что для них этот принцип — просто вера («Мне сказали, что я должен думать, что меня можно обмануть...»); в то время как чувства и рефлексы опытных тестировщиков были разбужены и обострены болью от постоянного накручивания («Я помню большой возврат 94-го. Мы не могли представить себе, что вирус может заразить наш золотой мастер-диск. Я потерял свою невинность в тот день.»)
Вас труднее обмануть, если вы знаете, что вы дурак.
Мошенники говорят, что легче всего обмануть тех, кто убежден, что его невозможно обмануть. Вы можете применить этот принцип в своей работе тестировщика. Убедите себя в том, что вы дурак. Это несложно, просто осторожно наблюдайте за своими ошибками во время тестирования. Записывайте каждый раз, когда другой тестировщик обнаружил проблему там, где вы могли бы ее обнаружить, но не сделали этого.
Если вы знаете, что вас легко обмануть, то вы становитесь немного более внимательным. Вы и ваш ум сильнее и подробнее работают с деталями стратегии тестирования. Это один из самых быстрых путей совершенствования начинающего тестировщика, так как сознание того, что вы дурак — это отношение, а не навык или знание. Проблема начинающих тестировщиков в том, что для них этот принцип — просто вера («Мне сказали, что я должен думать, что меня можно обмануть...»); в то время как чувства и рефлексы опытных тестировщиков были разбужены и обострены болью от постоянного накручивания («Я помню большой возврат 94-го. Мы не могли представить себе, что вирус может заразить наш золотой мастер-диск. Я потерял свою невинность в тот день.»)
понедельник, 24 октября 2011 г.
Процент багов найденных различными техниками.
Проценты багов найденных различными техниками.
Обнаружено у А. Селяева, ориджинал контент тут.
Тут не написано, сколько это стоит трудозатрат, это бы серьезно поменяло картину.
Опытные товарищи говорят, что львиная доля приходится на - Personal desk checking of code, да и reviewsстоят недешево.
UPD: Там и дальше интересно:
non-critical bugs are twice as expensive to fix after release, on average. However, the multiplier becomes much, much larger for severe bugs: according to several estimates severe bugs are 100 times more expensive to fix after shipping than they are to fix before shipping.
 |
| Альбом: bug |
Обнаружено у А. Селяева, ориджинал контент тут.
Тут не написано, сколько это стоит трудозатрат, это бы серьезно поменяло картину.
Опытные товарищи говорят, что львиная доля приходится на - Personal desk checking of code, да и reviewsстоят недешево.
UPD: Там и дальше интересно:
non-critical bugs are twice as expensive to fix after release, on average. However, the multiplier becomes much, much larger for severe bugs: according to several estimates severe bugs are 100 times more expensive to fix after shipping than they are to fix before shipping.
Подписаться на:
Сообщения (Atom)