среда, 30 мая 2012 г.

Lesson 123

Слово Канеру

Проектируйте автоматизированные тесты так, чтоб их удобно было просматривать.

Ты тестируешь ПО так как в коде ошибки случаются. И в коде тестов встречаются ошибки. Что вы с этим сделаете?

Ты должен тестировать код тестов. Хорошая идея. Хочешь автоматизировать и это тестирование? Хочешь протестировать код, который автоматизирует тестирование тестов? Об этом просто больно думать.

Другой подход заключается в том, чтоб сфокусироваться на ревью кода тестов. Проектируйте фреймворк, чтоб сделать ревью проще для людей. Это усилит их веру в тесты, что пишет ваша команда. Сохраняйте код простым. Оптимизируйте формат тестовых входных данных для нужд тестировщиков. Используйте стандартные языки программирования.

Автоматизация тестирования может пойти не так множеством способов. Делая ревью проще, вы уменьшаете вероятность совершения основных ошибок. Также вы помогаете вашей команде учиться друг у друга. Как только они научатся просматривать код тестов, они смогут просматривать код продукта.

Культура, которая поощряет ревью кода, приводит к автоматизации, на которую можно рассчитывать.

У нас есть небольшой опыт парного программирования автоматизированных тестов. Это другая форма ревью, и мы ждем (но пока не можем основываться на опыте), что эта практика будет хорошо работать.

вторник, 29 мая 2012 г.

Lesson 122

Слово Канеру

Have testers and programmers charter automation projects
туплю сегодня, не осилил перевод заголовка


Проекты автоматизации приносят пользу, когда ими совместно занимаются программисты и тестировщики продукта.

Тестировщики продукта Заставьте тестировщиков определить требования к автоматизации. Кроме того, заставьте их проверить, что автоматизация будет полезна, понятна и будет заслуживать доверие. Не достаточно того, чтоб тесты просто прошли. Они должны заработать доверие тестировщиков. Если тестам не будут доверять, их не будут использовать. Автоматизация должна служить интересам тестировщиков.

Программисты продукта Программисты продукта, как эксперты в разработке ПО должны просматривать архитектуру автоматизации. Их вовлечение обеспечит широкие возможности тестируемости приложения.
Установите четкие цели и определите требования в ключевых областях, часто упускаемых из виду (Pettichord 1999):

Удобство просмотра Кто нужен, чтоб просматривать тесты? Насколько это сложно?
Ремонтопригодность Кто будет чинить тесты? Что он должен знать?
Целостность Откуда вы узнаете, что тестам можно доверять?

суббота, 26 мая 2012 г.

Непонимания псто

Кастую коллег в тред.

Просматривая разнообразные вебинары, семинары и прочие обучающие материалы заметил, что любой менеджер, дорвавшийся до настройки JIRA, тестлинка и других подобных инструментов - норовит прикрутить к ним дашборд с круговой диаграммой, отображающей количество пройденных и не пройденных кейсов.

Тестировать может автоматика, могут люди, но дашбордик будет висеть полюбому, в первом случае вероятней, так как есть готовые плагины.

Расскажите мне, какую полезную информацию несет любое значение, отличное от 100% прохождения?

Чем будет отличаться ваше поведение в случае, если прошло 87% тестов, от вашего поведения, когда вы узнаете, что прошло 63%?

В случае, если тесты гоняет автоматика можно продолжить вопросы: что вам даст список упавших тестов? Что хуже для продукта - один упавший тест или тридцать?

пятница, 25 мая 2012 г.

Lesson 121

Слово Канеру

Используйте пилотные проекты, чтоб доказать возможность

Используйте пилотные проекты автоматизации тестирования, чтоб проверить ваш подход, подтвердить, что ваш инструмент может работать с продуктом, и определить, какие виды преимуществ вы сможете ждать из автоматизации. Планируйте так, чтоб продемонстрировать результаты через месяц или около того. Заем масштабируйте проект для серьезных усилий.

Пилотный проект поможет продемонстрировать ваши способности. Он защитит ресурсы и упростить сотрудничество с людьми, помощь которых нужна для успеха.


Автоматизированные тесты изменят ваш процесс разработки и тестирования. Чем раньше у вас что-нибудь появится, тем раньше вы сможете вносить изменения. Чем больше ваша команда использует процессы ручного тестирования, тем сложнее получить максимальную пользу от автоматизированных тестовых наборов.

Lesson 120

Слово Канеру

Проекты по автоматизации тестирования требуют навыков программирования, тестирования и управления проектами.

Сложно найти людей, которые одновременно разбираются в проектировании тестов и их автоматизации. Обычно назначают разных людей на выполнение этих задач. Каждый — на полный рабочий день. Использование специалистов дает хорошие результаты.

Тестирование Изложите цели тестирования для автоматизации. Какие цели будет преследовать автоматизаация? Как она поможет найти баги? Какие баги? Are the tests informed by an understanding of the product user domain? Благонамеренные программисты, мало смыслящие в тестировании могут создавать наборы тестов, сами по себе являющиеся интересными, но приносящими мало пользы. Обеспечьте консультации от людей, понимающих тестирование и знающие, как будет использоваться продукт.

Программирование Автоматизация тестирования это программирование. Стратегии использования инструментов, обещающих позволить тестировщикам создавать тестовые наборы не программируя проваливаются. Don't solely depend on junior programmers or programmer rejects either. Управление, установка, конфигурирование и поддержка инструмента требует навыков программирования. Каждый автоматизированный тест это программма или фича в большом тестовом приложении. Автоматизация тестирования сложна и не удастся без следования принципам разработки ПО.

Управление проектами Без достаточного внимания со стороны руководства, проекты по автоматизации могут не помочь в решении изначально поставленных целей. Не делайте автоматизацию сторонним проектом. Не комплектуйте ее людьми на неполный рабочий день.

Хороший баланс навыков особенно важен для проектов, в которых будут создаваться тесты, которые должны использоваться длительное время. Вам будут нужны люди, обученные языкам и инструментам, которые вы будете использовать. Подход, который вы используете для автоматизации поможет вам определить точное сочетание навыков.

среда, 23 мая 2012 г.

Рутина

Наша система с подачи падавана Эттариона создает объекты с таким вот описанием:

Альбом: bug


Напомнило это:
Податель сего документа действует по моему распоряжению и на благо Франции. Ришелье.

Альбом: bug

Lesson 119

В качестве эксперимента притащили в кабинет колонки и включили тихо так музыку. Решили ограничиться спокойной и без слов.
Сегодня плейлист выбираю я, поэтому слушали радио классической музыки The Mostly Classical (Sky.fm). Да, это пеар.

Результат - имхо отлично. Бойцы тоже ок, одному, правда, классика не очень, но как минимум - не раздражает.

Поэтому - рекомендую, диалогам не мешает вообще.

Слово Канеру

Автоматизация тестирования это серьезная инвестиция

Автоматизация тестирования потребует много времени и денег. Будьте готовы к тому, что хорошо спроектированный тест на графический интерфейс в десять раз дольше автоматизировать, чем провести вручную. Это показатель зависит от множества факторов, но многие опытные автоматизаторы используют его как разумную первую оценку (Kaner 1998a). Мы рассмотрели несколько предположений, в которых говорилось, что тесты могут быть автоматизированы ценой двух- или трехкратных усилий. Мы считаем, что эти заявления являются результатом разработки одноразовых тестов, failing to account for the full efforts involved in automation, or good luck[не понимаю, как это перевести]. Если вы разумны, вы не будете использовать более низкий показатель, пока у вас не появятся специфические данные для ваших обстоятельств.

Эффективное использование инструментов тестирования включает навыки программирования и проектирования. Как и автоматизация чего-либо еще, автоматизация тестирования это проблема программной инженерии.

Автоматизация тестирования может помочь тебе уменьшить затраты, если у тебя есть хорошая причина использовать какой-либо тест много раз. С ее помощью можно создавать и выполнять тесты, которые дорого или невозможно провести вручную. С ее помощью можно измерить такие характеристики работы программы (временные, связанные с памятью), которые вы не смогли бы измерить вручную. С ее помощью можно массово запускать серии тестов, чтоб найти дефекты, которые появятся только после месяцев нормальной эксплуатации, ручной поиск которых занял бы слишком много времени. Любое из этих преимуществ могло бы оправдать инвестиции в автоматизацию, но если ваш персонал и бюджет проекта автоматизации предполагают, что все это можно будет сделать за неполный рабочий день, то вы будете разочарованы.

На день публикации многие инструменты тестирования через интерфейс стоили около 5 000$. Инструменты нагрузочного тестирования могли стоить от 50 000$. Какими бы ни были большими эти расходы, мы считаем, что они карликовые по сравнению с расходами на обучение персонала (как формального, так и на рабочем месте). Не совершайте ошибки, тратя весь бюджет автоматизации на инструмент тестирования. Это только вершина айсберга.

вторник, 22 мая 2012 г.

Рутина

В последнее время локальной идиомой становится фраза:

Вчера поздно вечером %programmerName% одним яростным коммитом [сломал/починил/запилил фичу]

суббота, 19 мая 2012 г.

О управлении проектами

Нашел здесь.
Лошадь сдохла.

1. Мы уговариваем себя, что есть еще надежда.
2. Мы бьем лошадь сильнее.
3. Мы говорим «Мы всегда так скакали».
4. Мы организовываем мероприятие по оживлению дохлых лошадей.
5. Мы объясняем, что наша дохлая лошадь гораздо «лучше, быстрее и дешевле».
6. Мы организовываем сравнение различных дохлых лошадей.
7. Мы сидим возле лошади и уговариваем ее не быть дохлой.
8. Мы покупаем средства, которые помогают скакать быстрее на дохлых лошадях.
9. Мы изменяем критерии опознавания дохлых лошадей.
10. Мы посещаем другие места, чтобы посмотреть, как там скачут на дохлых лошадях.
11. Мы собираем коллег, чтобы дохлую лошадь проанализировать.
12. Мы стаскиваем дохлых лошадей, в надежде, что вместе они будут скакать быстрее.
13. Мы нанимаем специалистов по дохлым лошадям.
14. Мы достаём более хлёсткий и мощный кнут для мёртвой лошади (а нередко и на конюхов розг хватает).
15. Мы ждём, ничего не делаем, ведь мы всегда точно так, ездили на мёртвых лошадях. И раньше проблем не было!
16. Мы меняем наездника. Когда мёртвая лошадь не скачет, – виноват обычно он.
17. Мы облагораживаем стойло, достаём конюхам пряников.
18. Мы едем за бугор, там с незапамятных времён водились наездники на мёртвых лошадях, перенимаем их опыт.
19. Мы в добровольно-принудительном порядке предлагаем курсы верховой езды сотрудникам отдела.
20. Мы создаём группу и анализируем мёртвую лошадь, время смерти и меру окоченения.
21. Мы признаём мёртвую лошадь неверно аттестованной, она живее всех живых.
22. Мы оптимизируем коммуникацию между наездником и мёртвой лошадью.
23. Мы резко повышаем стандарты контроля качества мёртвой лошади.
24. Мы увеличиваем зону ответственности наездников, вводим меры по мотивации конюхов, вводим поощрения.
25. Мы необоснованно увеличиваем ЦА мёртвой лошади, исследуем, таким образом, открывшиеся рынки.
26. Мы оптимизируем все процессы специально для поездок на мёртвой лошади.
27. Мы приглашаем экспертов, которые имеют опыт езды на мёртвых лошадях.
28. Мы создаём команду по воскрешению мёртвой лошади.
29. Мы выносим мёртвую лошадь в отдельную бухгалтерию.
30. Мы проводим сравнительный анализ разных мёртвых лошадей на рынке, сравниваем их с нашей, делаем вывод, что наша лошадь ещё не вполне мертва.
31. Мы изменяем критерии определения факта смерти лошади.
32. Мы аутсорсим езду на мёртвой лошади подрядчикам.
33. Мы создаём упряжку из мёртвых лошадей для увеличения скорости и надёжности поездки.
34. Мы проводим исследование на предмет наличия на рынке более живых и при этом более дешевых лошадей.
35. Мы выделяем дополнительные средства на увеличение производительности мёртвой лошади.
36. Мы покупаем стероиды для ободрения мёртвых лошадей.
37. Мы пересматриваем критерии производительности лошадей в целом.
38. Мы продвигаем на рынке идею, что мёртвые лошади всегда были экономичнее, стабильнее и по многим параметрам лучше живых.
39. Мы формируем исследовательскую группу для поиска применения мёртвой лошади.
40. Мы рисуем много-много Powerpoint презентаций, которые доказывают, что лошадь могла бы всё-всё-всё, если бы только была жива.
41. Мы официально меняем стратегию, вместо максимизации прибыли минимизируем потери.
42. Мы проталкиваем на рынке идею, что мёртвые лошади быстрее и дешевле умирают, чем живые, их похороны по всем показателям дешевле.
43. Мы заявляем, что ни одна лошадь не может быть так мертва, чтобы мы её не смогли заставить снова бежать.
44. Мы через месяц заявляем, что даже мёртвая лошадь имеет ценность, монетизация мёртвых лошадей лишь незначительно отличается от оперативного бизнеса.
45. Мы объясняем, что лошадь при жизни была приобретена по завышенной цене, по совету прежнего наездника, слабо масштабируется, плохо управляется, ест много, спит мало, итд итп.
46. Мы реструктурируем компанию таким образом, чтобы мёртвая лошадь попала в другой отдел или к другому наезднику.
47. Мы создаём специальную конюшню отдел, в чьё виденье передаём всех мёртвых лошадей, используем синергические связи.
48. Мы находим денежного партнёра и объединив наших мёртвых лошадей с их организуем Joint Venture.

На правах рекламы

Это ПЕАР

Альбом: office

Lesson 118

Слово Канеру

Автоматизация тестирования это разработка программного обеспечения


Проекты по автоматизацию тестирования часто проваливаются из за отсутствия дисциплины и управления. Многие тестировщики не осознают, что когда они автоматизируют тесты — а самом деле они разрабатывают ПО.

Weinberg (1992) представил шкалу для оценки организационного развития. Как и в других подобных шкалах — первый уровень — хаотическая организация; до пятого уровня все повторяется. Тем не менее, он ввел дополнительный уровень — нулевой. На этом уровне вообще забывают о организации. На этом уровне вообще не осознают, что они занимаются разработкой программного обеспечения. Многие группы тестировщиков, не знающие, что автоматизация это тоже разработки ПО, попадают в эту категорию.

Любой успешный проект по разработке ПО должен следовать некоторым базовым правилам. Тестировщики — первые, кто жалуется, что программисты не следуют правилам. И тестировщикам не следует удивляться,Ю когда в проектах по автоматизации возникают проблемы от срезания углов.

Что это за правила? Распланируйте проект, выделите этапы и цели. Определите требования. Используйте инструменты контроля исходного кода для инструментов, кода автоматизации, тестов. Проектируйте тесты перед кодированием. Просматривайте код и тестируйте его. Ведите учет дефектов в автоматизации и в тестах. Документируйте способы использования автоматизации и планируйте, что их могут использовать не те люди, что создавали.

Отказы от понимания автоматизации как разработки привели к дорогим провалам, так как команды тестировщиков оказались далеко позади со своими неиспользуемыми автоматическими тестами.
Мы не будем рассказывать, какому именно процессу нужно следовать, но мы говорим, что нужно следовать процессу.

пятница, 18 мая 2012 г.

Классный пост, хорошие ребята

Я просто оставлю это здесь.
http://habrahabr.ru/post/144051/#habracut

Несовершенство мира

Не, реально жаль, что прогулка состоится не 19, а 20 мая.

А то как прекрасно было бы в одном месте увидеть много людей - и ни одного оппозиционно настроеного гражданина, встрадавшего от тирании и произвола.

Lesson 117

Бгг

Альбом: randompics4lj





Автоматизированные регрессионные тесты умирают


Самая большая проблема автоматизированных регрессионных тестов в их распаде и преждевременной смерти. Вы разрабатываете регрессионные тесты для обнаружения проблем в фичах, которые вы уже проверили - проблем, связанных с ошибками программистов, которые они допускают, исправляя ошибка или добавляя новые фичи.

Регрессионные тесты разваливаются по целому ряду причин, таких как:

Изменение пользовательского интерфейса или формата вывода Эти изменения — главная причина. Из-за них большое количество тестов упадет, хотя очевидно, что не было ни каких изменений, влияющих на тестируемые функции. Изменения могли быть столь незначительны, что ручные тестировщики не замечают их Автоматизированные же тесты чувствительны, хрупки и неспособны различать изменения и баги.

Предположения в тестовой среде Тестовые наборы могут сломаться, будучи перемещены на другую машину или в случае, когда необходимые ресурсы были перемещены.

Ошибки в обслуживании Автоматизаторы, чинящие тесты, сами допускают ошибки. Таким образом, наборы регрессионных тестов сами имеют регрессионные баги.

Изменение операторов Тестовые наборы могут требовать специальных умений и знаний для эксплуатации и обслуживания. Или автоматизатор сменился, ценные знания могут быть потеряны. Например, Шейла временно отключает тесты на ввод/вывод в связи с ошибкой в продукте, затем покидает проект. Замена Шейлы предполагает, что тесты полностью устарели и перемещает их в архив, чтоб больше никогда не увидеть.


Тестировщики инвестируют в автоматизацию регрессионного тестирования, ожидая, что она окупится через длительное время. К сожалению, они часто обнаруживают, что тесты перестают работать раньше, чем ожидалось. Тесты не синхронизированы с продуктом. Они требуют починки. Они больше не помогают искать баги. Тестировщики реагируют, обновляя тесты, но это может быть труднее, чем ожидалось. Как оказалось, многие автоматизаторы тратят слишком много времени на диагностику и починку сломанных тестов.


Осторожно выбирайте тесты для автоматизации. Автоматизировать можно все , но он чего-то вам придется отказаться, а что-то сохранить. Неконтролируемые затраты на техническое обслуживание более серьезная проблема, чем сложность написания тестов.

Расходы на техническое обслуживание должны убедить вас не верить сказке, что автоматизация превратит вашу работу в отпуск.

среда, 16 мая 2012 г.

Прогулка

Вчера я писал: Попробуйте такую игру. Опишите улицу, по которой ходите каждый день: магазины, рекламные щиты, местных жителей, деревья, светофоры, припаркованные машины соседей. Потом выйдите из дому и пройдитесь по той же улице, записывая в блокнот, наговаривая на диктофон, фотографируя на мобильник. Вернитесь домой. Сравните обе версии.

Нашел эту идею тут

Как я реализовал: прочел статью - написал текст и нарисовал по памяти, что помню. Точки - раз в сто метров. Вот кстати, карта, шел - навстречу:
Альбом: office


На следующий день - сегодня - с утра шел и фотографировал на мобилку.


Каждый день для меня - это из дома на работу, проклятые рудники.

На первом этаже темно, но есть датчики шума, поэтому успевает включиться свет.

У подъезда припаркованы акцент и старая бэха. Через 20 метров следующий дом, у него в цоколе ломбард, вечером на него ссут маргиналы-аборигены. [См. картинку 1]
Поворачиваю налево у торца дома - и тут же закрываю глаза - очень яркий свет с востока - девять утра, солнце уже взошло.
Тридцать шагов до перекрестка, слева в цоколе хрущобы продают разливное пиво, справа - киоск с фруктами, не знаю открыт или нет, все еще иду с полузакрытыми глазами.

Перехожу дорогу, светофор отрабатывает очень быстро. Справа через дорогу - становка трамвая и мини-рынок. В мини рынке продают по большей части рыбу, но ближе всего - киоск гриль, когда пойду вечером обратно - будет вонять курицей.
Передо мной - киоск, посреди кучи щебня, асфальт так и не положили, чуть левее - кабак с узбекским названием. Перед кабаком грязно - перекапывали и не зарыли.
[См картинку 2]

Картинки 1 и 2
Альбом: office


Фотка 1
Альбом: office


Фотка 2
Альбом: office


Сто метров прямо - вдоль магазина с бетонным парапетом и крышей - удобно прятаться от дождя. В магазине продают мебель.
Справа через дорогу - закончился рынок и начались деревенские такие домики. И пункт приема стеклотары около сломанной газельки, там тусуются местные колоритные бомжи. [См. картинку 3]

В том же доме где мебель - аптека и еще какой-то магазин, у аптеки крыльцо высокое, вроде даже второй этаж. Вывеска, как водится, бело-зеленая.
Затем дорогу пересекают рельсы - трамвай к дворцу молодежи и на сортировку.

За рельсами на небольшом возвышении - дом непонятного форм-фактора и в пристрое к нему отделение сбербанка, только что открылось после ремонта. Стало еще более зеленым, чем раньше, но крыльцо все такое же убитое. Стоят две урны, зеленые.

Переходим через небольшой переулок - и видим местный филиал дневного дозора - магазин с лампочками. У них большое крыльцо, на нем с утра курят маги третьей и четвертой ступени. Перед горсветом раздолбан асфальт и насыпана щебень. Вывеску горсвета ремонтируют постоянно, в ней лампочка не работает, козни Завулона, не иначе. [См. картинку 4]

Картинки 3 и 4
Альбом: office


Фотка 3
Альбом: office


Фотка 4
Альбом: office


Справа через дорогу щебень, грязь, техника, ямы, стоянка, два деревенских домика, масса деревьев, стоянка и длинная белая девятиэтажка на четвертом этаже которой я жил раньше. Очень зеленый и ухоженный дворик у того дома, кстати.

Заныриваем в переход, знаете деревянный такой, вдоль бетонной стены, около строек. [См. картинку 5] На стройке шум, мат таджики, не виден, но подразумевается кран. Около выхода из перехода ворота на стройку, двухэтажная собака и пожилой охранник в камуфляже.

Картинка 5
Альбом: office


Фотка 5
Альбом: office


Выныриваем уже почти на перекрестке татищева-токарей. Как обычно выныриваем неудачно - на красный, перекресток долгий - 90 секунд. Справа - рекламный щит, на нем валуев рекламирует МТС, с другой стороны щита тинькоф тоже чего-то хочет.

Здоровенное здание в котором наш офис - трехбашенное, с девятиэтажными переборками, скрам-доску в моем кабинете уже видно - в полукруглом торце на пятом этаже. На первом этаже ипонское кафе где продают отвертку трехлитровыми порциями и кормят маленькими и невкусными обедами. [См. картинку 6] Перед зданием стоянка на стопиццот автомобилей, но все равно ставят на дороге и на пешеходной зоне. Ладно хоть перед входом клумбы посадили. Да, под зданием парковка наверняка пуста.

Картинка 6
Альбом: office


Фотка 6
Альбом: office


Когда часов в девять подходишь к крыльцу - там уже тень. Перед крыльцом - автомобили в пять рядов, наши стоят в четвертом и пятом, ага, еще никто не приехал.

Все.

вторник, 15 мая 2012 г.

Lesson 116

Прочел вот эту штуку:

Цитата:
Попробуйте такую игру. Опишите улицу, по которой ходите каждый день: магазины, рекламные щиты, местных жителей, деревья, светофоры, припаркованные машины соседей. Потом выйдите из дому и пройдитесь по той же улице, записывая в блокнот, наговаривая на диктофон, фотографируя на мобильник. Вернитесь домой. Сравните обе версии. Узнаете ли вы что-то о городском хозяйстве, политике правительства, идеологических устремлениях общества, об архитектуре, машиностроении и коммерции? Нет. Зато вы много чего узнаете о том, сколь восхитительно логичен, умен, прекрасен тот образ окружающего мира, который существует в вашей голове – и который не имеет почти никакого отношения к тому, что можно увидеть за окном.

Я описал и карандашиком начеркал, чтоб понятней было. Завтра с утра пройду, пофоткаю. И сравню.

Слово Канеру:

Выбирай инструменты тестирования пользовательского интерфейса, основываясь на совместимости, знакомстве с ними и поддержке этих инструментов.

Нас часто просят порекомендовать инструменты тестирования. Лучший выбор зависит от конкретной ситуации. Некоторые инструменты тестирования GUI не поддерживают особенности сред разработки или поддерживают их плохо. Мелкие детали могут привести к беде. Сложно заранее сказать, что будет работать, а что нет. В действительности это вопрос проб и ошибок. Итак, с чего начать?

Выясните, с какими инструментами ваша команда уже знакома. Или какие языки, используемые в инструментах, они уже знают. Цена обучения и изучения инструмента (будь то курсы, самообучение или метод проб и ошибок) часто значительна. Знакомство с инструментом часто может быть решающим фактором успешного внедрения, если этот инструмент вообще работает.

Другой важный фактор — поддержка инструмента. Даже если инструмент работает с вашим продуктом сейчас, что произойдет, когда вы будете проверять его на новой платформе в следующем году? Когда вы покупаете продукт, вы инвестируете в возможность поставщика поддерживать инструмент в актуальном с новыми технологиями состоянии. Проверьте их онлайн-поддержку, пообщайтесь с другими пользователями о производителе.

Вам необходимо время для проверки совместимости инструмента с вашим продуктом и проверки сервиса поддержки. Возьмите триальную версию инструмента (30-90 дней) или хотя бы добейтесь 30-дневной гарантии возврата денег. За это время вы, вероятно, успеете столкнуться с проблемами. Проверьте, даст ли техподдержка своевременные и обоснованные ответы. Также вы должны спросить о возможности покупки обучения инструменту. Это может помочь вам получить лучшую цену. Мы обнаружили, что важные советы по использованию некоторых продуктов можно получить только на обучении, этих советов нет в документации.

Мы твердо знает, какие функции должны быть в инструменте, но для большинства команд вышеизложенные мысли сведут все варианты выбора к одному. Для дальнейшего изучения смотри Hendrickson (1999).

суббота, 12 мая 2012 г.

Lesson 115

Внезапно. В екб есть работа для тех, кто владеет автокадом, 20-25к. Обращайтесь.

Стартанули тесты на разных базах. Сперва приложение опало аки озимые на всех конфигурациях. После того как суровый челябинский программист(тм) объяснил системе, что сие моветон - проверили еще разок.
Неожиданно порадовал mssql, прошедший почти все испытания.
И огорчил oracle, с его нетипичным ограничением в 30 символов(ORA-00972), о котором забывают.

Пыщ-пыщ, тестируем дальше.

Слово Канеру:

Пользовательский интерфейс меняется.

Идите в ногу с изменениями пользовательского интерфейса, они являются основной проблемой автоматизации тестирования через интерфейс.

Просьба обращенная к программистам о том, что они они должны заморозить пользовательский интерфейс не сработает. Ранние версии интерфейса часто нуждаются в пересмотре. Не ставьте себя в положение «рекомендующего улучшение». Пользовательский интерфейс будет меняться постоянно.

Абстрагируйтесь от интерфейса в архитектуре тестов. Когда интерфейс изменится, вы обновите соответствующий уровень абстракции, работающий с изменившимся интерфейсом.

Вот несколько техник для обеспечения абстрагирования от GUI:

Window map Инструменты тестирования GUI поддерживают различные техники идентификации окон и управляющих элементов, такие как: внутренние имена, различные свойства, метки, порядковые номера. Вместо того, чтоб внедрять новую методику идентификации с каждым новым окном, используйте window map, чтоб связать название с идентификатором управляющего элемента или окна. Если пользовательский интерфейс заставит вас изменить технику идентификации, вам нужно будет обновить только window map. Некоторые инструменты тестирования включают в себя поддержку создания и использования window map, которые также называются GUI maps или window declarations. Если ваш инструмент не имеет встроенной поддержки подобных вещей, то ее, как правило, можно добавить без особых проблем. Window map поддерживают изменение незначительных изменений GUI, таких как переименование заголовков или перемещение управляющих элементов. Также они могут быть полезны для переиспользования тестов на пользовательский интерфейс, написанных на других языках.

Автоматизация, основанная на данных (Lesson 127: Автоматизация основанная на данных позволяет легко запускать множество вариантов теста). Эта техника обеспечивает абстракцию в том, что вы должны быть в состоянии изменить процедуру тестирования и по прежнему использовать созданные для нее данные.

Библиотеки задач (Lesson 126: Не создавайте библиотеки тестов просто для того, чтоб избежать повторения кода). Анализируйте кейсы на предмет подзадач. Все подзадачи должны быть принципиально разными. Обратите особое внимание на начальное и конечное состояние подзадачи. Создайте функцию для ее выполнения и используйте ее в кейсах. Если изменится пользовательский интерфейс, вы должны будете изменить только эту функцию, а не использующие ее тесты. Это позволит достичь высокой степени абстракции, но может увеличить объем работ на разработку и проектирование тестов.

Keyword-driven автоматизация (Lesson 128: Keyword-driven автоматизация позволяет непрограммистам легко создавать тесты).

Автоматизация основанная на API (Lesson 132: автоматизируйте тесты, используя программный интерфейс). В целом, избегайте GUI.

пятница, 11 мая 2012 г.

Lesson 114

Пыщ-пыщ!
Посоветуйте книг и годных коротких сериалов по типу "17 мгновений весны", "Homeland" или там "Свет вечный".

Слово Канеру:

Тестовые инструменты это детская коляска

Тестировщики возмущаются, когда тестовые инструменты, которые они приобрели за серьезные деньги, сами полны баг. Действительно, тестовые инструменты часто забагованней, чем аналогичные более дешевые средства разработки. Запланируйте проверку инструментов тестирования и потратьте время на поиск обходных путей их ошибок.

Некоторые инструменты спроектированы для поддержки тестирования конкретных компонент технологий. Невозможность проверки таких компонент ведет к еще одному источнику ошибок измерительного прибора.
- Программисты инструмента тестирования должны ждать, пока тестируемая технология станет доступна
- Затем они должны провести реинженеринг технологии, чтоб выяснить, как добавить в нее поддержку тестируемости.
- За это время программисты вашего продукета начинают пользоваться новыми технологиями. А вы разочарованы тем, что вендор инструмента тестирования еще не выпустил необходимое обновление инструмента. Вендор проходит серьезные испытания, чтоб поставить инструмент вам тогда, когда это нужно.
- Сюрприз! Результат авральной работы полон ошибок.

Этот цикл будет повторяться вечно, до тех пор, пока для тестируемости будет необходим реинженеринг технологии. Мы надеемся и слышим обещания улучшений, но трудно сказать, когда это начнет происходить. Это проблемы отрасли.

Тестовые инструменты часто страдают от ошибок в сторонних компонентах. Один из нас, Pettichord, работает с инструментом, работающим нестабильно. События мыши иногда не генерируются. В конце концов, мы отследили ошибку до бага в драйвере операционной системе. Эта нестабильность воспроизводилась и без инструмента. Почему ручной тестировщик не смог найти это? Потому что он бы и не заметил, что случайное движение мышью не произошло. А если бы заметили, то обвинили бы драйвер мыши или себя. Мы сообщили о вине операционной системы поставщикам, которые отнеслись равнодушно. Серьезное влияние на проверяемость не было критичным. Мы, в конечном счете, обошли проблемы, используя другой драйвер мыши. Bob Johnson сообщает о аналогичных проблемах с использованием различных технологий: «Драйвер мыши не играл никакой роли в тестировании нашего приложения, но мы должны были отслеживать эту проблему и в нашем случае это заняло несколько дней, тестировщиков и разработчиков». Вот несколько тысяч долларов скрытых расходов на автоматизацию.

Другие инструменты могут повлиять на тестируемый продукт настолько, что сделают его непригодным для использования. Инструменты подсчета покрытия и мониторинга памяти занимают место в памяти. Такие инструменты могут замедлить ваш продукт до такой степени, что вы не сможете проверить его.

Так как тестовые инструменты имеют настолько плохую репутацию, ваши программисты, скорее всего, требуют, чтоб вы воспроизводили каждый дефект найденный автоматизированными тестами вручную, до того, как принять его всерьез. Это добавляет сложности в анализ сбоев автоматизированных тестов.

понедельник, 7 мая 2012 г.

О разном

Хорошая идея http://kaisi.livejournal.com/804833.html

суббота, 5 мая 2012 г.

Lesson 113

Слово Канеру:

Захват воспроизведения не работает


Одни из самых популярных тестовых инструментов — рекордеры. Они предлагают простой путь создания автоматических тестов без программирования. Просто включите рекордер, пока вы выполняете тест. Рекордер захватывает каждое пользовательское действие — нажатия клавиш, движения и клики мыши — и сохраняет их в скрипт, для дальнейшего воспроизведения. Также вы должны указать проверки — шаги в тесте, где вы нажимаете горячую клавишу, и информация с экрана сохраняется в скрипте. Во время воспроизведения, скрипт сравнивает текущий экран (или любые другие запрограммированные атрибуты, связанные с этим экраном) с сохраненной информацией. Если они отличаются — тест падает.


Ключевая проблема таких скриптов в том, что они плотно связаны с множеством мелких неважных деталей пользовательского интерфейса и с настройками системы. На практике, тесты чаще падают из-за запланированных изменений дизайна продукта, чем из-за регрессионных баг. Тестировщики тратят больше времени на анализ ошибок тестирования и перезапись тестов, чем на то же тестирование, которое раньше проводилось вручную.

Предположим, у вас есть 100 тестовых скриптов, включающих в себя создание учетной записи. Предположим продукт изменился. Сейчас система проводит вас через дополнительный диалог в процессе создания учетной записи. Все эти тесты упадут. Вам придется перезаписать их. Или, предположим, название окна изменилось с "Login Name" на "User Name". Все тесты, у которых есть проверки на этом окне также упадут.

Если тесты не прошли, то их анализ может быть невыносимо труден. Это дефект настроек, дефект теста или дефект продукта? На эти вопросы сложно ответить, глядя в сценарий, сгенерированный машиной. Если вы не можете прочесть сценарий, как вы можете сказать, как он работает?

Более структурная стратегия автоматизации использует те же инструменты, но занимает больше времени и требует навыков программирования. Получившиеся тесты легче обновлять, если изменился интерфейс пользователя.

По нашему опыту и опыту большинства автоматизаторов, автоматически записываемые тесты через интерфейс подобны ледяному склону с кирпичной стеной внизу. Очень много команд тратят значительное количество времени на запись тестовых скриптов, видят, что они ломаются уже через пару билдов, а затем перезаписывают их снова и снова.

Инвестируйте в навыки и планирование, необходимые для создания автоматизированных тестов, которые будут работать долго. Или тестируйте вручную. Любой из этих подходов более эффективен, чем рекордеры.

(Мы понимаем, что подобные рекордеры полезны для изучения инструментов тестирования и как средство для разработки тестов. Мы против того, чтоб их рассматривали в качестве решения.)

пятница, 4 мая 2012 г.

Lesson 112

Лейтмотив недели: люди бьются за promoted build.

Слово Канеру:

Проблема плохой автоматизации в том, что ее сложно заметить

Продукты которые существуют некоторое время, часто имеют наборы автоматизированных тестов. Созданные давно, они продолжают по прежнему использоваться для тестирования.

Тестировщикам нравится иметь такие тестовые наборы. Мы хотели бы высказать несколько предупреждений.

Тесты могут делать не то, что вы думаете Откуда вы знаете, что тесты делают то, что вы предполагаете? Автоматизаторы иногда пишут не те тестовые процедуры, что им было указано. Много лет назад, возможно, для этого были веские причины. Что вы о них знаете? Насколько легко прочитать тесты и просмотреть их код?

Тесты могут стать неинтересны обозреватель Douglas Hoffman сообщает, «Недавно я обнаружил автоматизированный тест памяти, используемый производителем компьютера, который они называли ‘lonely bit test’». Это был тест, используемый для того, чтоб найти ошибки записи в памяти до 1970х годов. Самое большой размер памяти тогда был 16кб и тест занимал несколько минут. Теперь он может занять несколько часов, на новых объемах памяти, а ошибка невозможна в современных системах. Другой автоматизированный тест, который я просматривал, был разработан для проверки состояния встроенного процессора. Я увидел, что документация написана в 1986 году, семь поколений продукта назад. И никто не думал обновить тесты для каждого нового поколения».

Покрытие может быть небольшим Люди часто сосредоточены на количестве тестов в наборе. Легко раздуть количество тестов, запуская множество вариаций одного и того же теста. Проверьте текущее покрытие тестового набора. Вы можете быть удивлены тем, что не проверяется.

Ложные срабатывания могут стать массовыми Со временем, небрежное программирование и обслуживание автоматизации может привести к большому количеству тестов, срабатывающих из за бага в автоматизации. Конечно, вы не будете точно знать, что послужило причиной срабатывания, ошибка в продукте или в тесте, так что вам придется изучить все тесты. Многие из них являются сломанными тестами — тестами, которые когда-то работали, но затем у вас не хватило времени, чтоб починить их. Удалите сломавшиеся тесты из набора. Какая от них польза? Они мертвы. Примите это и похороните их, или почините — прямо сейчас. Но не оставляйте их вонючие трупы в активном наборе тестов.

Результаты тестов могут лгать Некоторые тесты не проверяют результаты. Они проходят пока продукт не упадет. Другие тесты имеют ошибку, такую, что они могут пропустить ошибку или препятствовать ее выявлению. Третьи содержат некорректные «золотые» файлы: когда тест срабатывает, золотой файл обновляется, но не происходит сообщения об ошибке. Мы так не делаем. Такие проблемы, по нашему опыту, можно ожидать от сравнительно сложных наборов тестов. Чтоб их избежать, автоматизаторы должны сохранять простоту системы или использовать методы защищенного программирования. Проблемы такого рода — плохой признак, но мы видели, когда тесты были жестко запрограммированы на то, чтоб пройти. Они просто говорили «Результат — тест прошел».

У автоматизаторов не было и мысли о том, что продукт может не работать. Мы размышляли о том, почему это происходит, но так и не нашли убедительных причин. Все что мы можем сказать — это случается в разное время в разных местах. Мы постоянно слышим новые истории от людей, видевших подобное. Что вы думаете о тестах, которые проходят, даже если продукт, который они тестируют, не существует?

Mary Sweeney считают, что это происходит из-за того, что автоматизаторы начинают создание тестов с создания шаблона, который выполняется успешно, затем забывают про него.

Хороший тестовый набор — живое существо. Новые тесты добавляются. Старые тесты чинятся или удаляются. Если этого не происходит, тестовый набор начинает костенеть. Создатели тестов будут двигаться дальше и тестовый набор достигнет состояния великого старого мифического дуба, к которому персонажи сказок ходят за советом. Репутация дерева растет по мере того, как оно становится старше, но идея о том, что дуб работает правильней с течением времени хороша для мультфильмов, к тестам стоит относиться более скептически. Мы называем это «синдромом веры в мудрость предков-тестировщиков», которые создали большой тестовый набор.

четверг, 3 мая 2012 г.

Fuck yeah

http://www.forbes.com/pictures/efkk45gmhl/the-20-happiest-jobs/#gallerycontent
а точнее
http://www.forbes.com/pictures/efkk45gmhl/1-software-quality-assurance-engineer/#gallerycontent