Показаны сообщения с ярлыком QA. Показать все сообщения
Показаны сообщения с ярлыком QA. Показать все сообщения

понедельник, 11 октября 2010 г.

Полезные символы для тест дизайна


У каждого специалиста  со временем накапливаются свои трюки и стандартные решения. Я не исключение, а довольно хорошее подтверждение. Есть у меня страсть к сбору и сортировке всяких мыслей, созданию мини-стандартов и совершенствованию "снизу-вверх". В текущей заметке я бы хотел поделиться трюками в именовании тест сценариев.

четверг, 17 сентября 2009 г.

100 спартанцев из QA-QC....

ПОТОМУ ЧТО МЫ ТЕСТЕРЫ!!!!!

Ну как то так можно начать обзор моего первого опросника на тему "Кем вы были в прошлой жизни"




Собственно я решил остановиться на цифре в 100 проголосовавших и на дней до голосования в 105. Кругленькие цифирки меня радуют (где бы нормального психолога найти чтобы спросить: чего со мной такого в раннем детстве случилось, что меня на кругленькое тянет).

Удивляет пункт [Другое] = 30%. Т.е. 30 % заходивших ко мне в гости до тестирования были людьми не связанными с IT. Бездумно добавил в опросник [Не IT -шник].  Каюсь. И если суммировать, то среди тестировщиков и прочих специалистов по качеству окажется 39! Не знаю как к этому относиться если честно.

Еще кое что удивляет [Со студенческой скамьи]= 33%. Т.е. 33+39+6 (непостоянных не IT -ов) = 78% людей вышли на желтую дорогу качества программного обеспечения не имея глубоких познаний в IT! Можно же и так эти циферки повернуть?

И получается что  всего 40% (меньше половины) до тестирования были более или менее глубоко (а может и не очень) знакомы с процессами IT\softo-делания и пр.

PS. Выборка конечно не слишком репрезентативная - всего 100 спартанцев...ээээ тестировщиков, но все таки информация достаточно забавная. Понятно, что суммировать тоже так как я сделал нельзя. Но статистика вообще наука ложных выводов, так что если добавить туда еще немного, никто и не заметит.

Удачных выходных. А мне еще до выходных в поезде - ту ту!





вторник, 8 сентября 2009 г.

Вы хотите тестов? - их есть у меня...

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

Чтобы не раскрывать всякие коммерческие секреты именую всех просто: pападный хозяин (клиент), работник в русском офисе (русский значит), индийские аутсорсеры.

Было у русского работника 200 тест кейсов. Хороших, продуманных тест кейсов. Хозяин возьми и скажи ему: "А сделай в два раза больше тест кейсов и - за неделю".

Русский работник привык все делать хорошо и продумано. Поскольку времени на прогон тестов не увеличивали, то зачем создавать новые тесты, rогда времени на поддержание старых хватало впритык? Что именно расширять русский работник знал, но требовала эта работа месяц - не меньше.

В это время на западного хозяина обратили внимание индийские аутсорсеры. И, в качестве задания, хозяин выдал им: "Вот вам 200 тестов, нужно еще 200, и протестировать их надо за неделю".

Индийцы: "Да, не вопрос".

Через неделю 400 тестов протестированы силами двух индийцев.

Русского сотрудника ругают и переводят в другой проект. Индийцам перепадает проект и перспектива более близкого будущего отношения.

А что собственно сделали индийцы...

Во-первых они разделили 200 тестов на 400. Грубо каждый тест на два.

Во-вторых они протестировали не 400 тестов, а 100 - в случайном порядке.

И казалось бы. Правила индийцы не нарушали: вы хотели 400 тестов - вот они. Клиент остался доволен (хотя и в небольшом неведении). В принципе, оценку приложения, какую никакую, даже по 100 тестам можно провести. И теперь, на зарплату одного русского кормятся три индийца.

Намечается парадокс.

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

2. Русский проявил упорство и настойчивость (поскольку думал как нужно делать правильно), но получил нагоняй.

Есть конечно вопрос о профпригодности заказчика (ну или его представителей). Но задача была поставлена - кто с ней справился, то и герой.

понедельник, 7 сентября 2009 г.

Ни надежность, ни функциональность...

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

среда, 5 августа 2009 г.

Анкета допросник SQA

Поскольку я меняю место работы, начальство попросило подготовить документ "как подготовить тестера". Компания, в которой я сейчас работаю, до меня тестеров как таковых не имела. Я задумался... и сперва составил анкету допросник SQA. Которую и выкладываю. К некоторым вопросам я прилагаю комментарии.

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

Анкета опросник для собеседования на позицию QA

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

Вопросы о прошлой компании\месте работы и текущих ожиданиях:

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

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

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

Какой у вас самый любимый проект и почему полюбили?

Если у человека нет такого проекта, то такой человек скорее всего нам не нужен. Человек может любить проект из-за работы с людьми, из-за используемых технологий и пр. Если у него все проекты на одно лицо — то либо ему не повезло в жизни, либо он ничего не делал, либо у него пока нет еще опыта ( в последнем случае все еще можно исправить)

Какой у вас самый нелюбимый проект и почему не любили?

Таких проектов может и не быть. Но лично у меня есть. И если они есть — значит человек не боится признаться в своих ошибках. Это многого стоит.

Как бы вы могли оценить ваш вклад в работу вашей компании?

Есть легенда. Спросили у трех камнетесов что они делают. Один ответил что он зарабатывает на жизнь. Второй ответил что точит камни. Третий ответил что он строит храм. Нужно искать третьих.

Почему решили сменить работу?

Это пустой вопрос, но в очередной раз показывает кто перед нами: Камнетес, Зарабатывающий либоСстроящий Храм.

Почему выбрали нашу компанию?

Всегда полезно узнать откуда растут ноги. Здоровому пиару для компании всегда есть место.

Что вы планируете получить от компании кроме материального вознаграждения?

Пустой вопрос, но может показать многое.

Что вы можете предложить компании - чем бы вы могли ей помочь или навредить. Чем быть полезны и тому подобное?

Пустой вопрос, но может показать многое.


Вопросы по технологиям

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

5- знаю долго и пользуюсь технологией постоянно или знаю хорошо и достаточно глубоко в определенных местах (все знать невозможно!).

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

3 — либо работал достаточно давно, либо знаком поверхностно, документация требуется постоянно.

2 — знаю что такая технология есть, несколько раз сталкивался, знания поверхностны.

1 — слышал что такая технология есть, знаю где достать документацию, могу изучить в течение 1 месяца.

0 — никогда не слышал и не сталкивался.

Вполне очевидно что SQC должен уметь профессионально работать с компьютером - не как неопытный пользователь, а как достойнеший IT спец (умеет переустанавливать Win\Lin - значит мозги уже есть).

Bug Tracking System

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

Знакомы ли вы с другими продуктами по управлению процессами QA.

Очень полезно узнать с чем еще работал собеседник и сможет ли он их назвать:

- система управления требованиями,

- система управления тестами (типа TestLnik) и т.п.

Знание Windows

- Что такое файловая система, какие файловые системы для MS Windows вы знаете?

- Какие версии ОС MS Windows вы знаете (желательно что бы человек слышаел не только Vista\Xp но и понимал что есть Home\Basic Professional и пр.)?

- Что такое реестр Windows?

- Какие программные средства работы в среде Windows вы можете еще назвать (те которыми пользуетесь)?

- Каким почтовым клиентом вы пользуетесь? Почему?

- Что используете для time Management

и пр. и пр. и пр.

Вполне очевидно что QA данные вопросы не нужны, но они показывают общий уровень специалиста.

Возможно создать такой же список вопросов по Linux

Прочие технологии

Определить дополительные технологии и программные средства с которыми должен уметь работать QA сложно. Если собеседуется специалист на автоматизированное тестирование, то очевидно должны подбираться языки программирования, DBMS etc.


Вопросы о саморазвитии

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

Какие книги вы прочитали в последние месяц, год?

IT, QA и близкие книги. Впрочем человек должен читать не только профессиональные книги, но это только мое мнение.

Какие сайты/блоги по тестированию знаете?

Если человек может назвать www.software-testing.ru, http://www.rbcs-us.com это очень хорошо.

Ведет ли свой профессиональный блог.

Если человеку есть что сказать и он говорит — это хорошо. Я тому пример ;)

Проходил ли обучение или курсы по тестированию

Если не проходил - то и фиг с ним. Я вот тоже только один вебсеминар прошел, остальное в книгах, блогах и материалах конференций искал.


Вопросы по предметной области

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

Что такое жизненый цикл ПО и цикл разработки ПО.

Комментарии излишни.

Какие модели разработки ПО знаете, в чем они отличаются

Водопад, циклический водопад, Agile: scrum, xp.

Что такое требование к ПО и какие у требования есть аттрибуты


Какие документы при разработке ПО используются

ТЗ\FDD, Sodftware Specifications, Test Plan (test case)

Какие стандарты по разработке ПО вы знаете

Знает что есть 34 и 19 — не плохо, знает IEEE 829 – значительно лучше, знает в добавок ISO 12207 – человек в теме!


Вопросы по QA

Данный список вопросов достаточно важен. Он показывает насколько человек продвинулся в понимании того что такое QA.

Какие документы по организации процесса тестирования вы знаете.

Ответы в вопросах ниже

Что такое Test Case и его структура?


Что такое Test Plan и его структура?


Что такое Bug Report и его структура?


Какие виды тестирования вы знаете?

Ответы в вопросе ниже

Что такое и объясните принципы
- Installation / Uninstallation testing
- Perform boundary testing
- Functionality testing
- Virus Check
- Scenario testing
- Perform database testing
- Field Entry testing
- Interface testing
- Regression testing
- Perform application interoperability testing
- Perform OS interoperability testing
- Perform Hardware, Network compatibility testing
- Architecture reviews
- Code reviews
- Functional and Test Spec Review
- Requirements, Design docs Review
- Usability testing
- Specification based testing
- Test Progress and Summary Review
- User Documentation Review
- International/Localization
- Perform error handling testing/Recovery testing
- Performance testing
- Submit testing summary report
- Automated Testing
- Stress testing

Выбрать несколько вопросов (не более 5) для проверки знаний собеседуемого

Чем отличается Severity от Priority

Классика жанра )

Тестирование белого ящика, черного ящика, серого ящика


Что такое бетта тестирование


Что такое Regresion Testing


Что такое Acceptance Testing


Что такое Smoke tests


Что такое модульное, интеграционное и системное тестирование.


Что такое Requirement traceability matrix


Что такое Bug life cycle


Что такое процесс управления конфигурацией в разработке ПО и в тестировании


Что такое процесс управления изменениями в разработке ПО и в тестировании


Что такое баг. Приведите пример. Какие типы багов вы знаете

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

Какой по вашему идеальный программный продукт для автоматизации работы QA

Данный вопрос показывает насколько человек понимает что такое QA и чем он отличается от QC. Также можно определить насколько человек понимает принципы автоматизации работы QA.

Какие процессы тестирования могли бы быть автоматизированы.

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

Что такое QA и что такое QC

Данный вопрос для общего развития. Хорошо если собеседуемый понимает что QC включен в QA, и что QA это не тестирование, а обеспечение качества на всем цикле разработки ПО.

Для чего проводится тестирование ПО

Вопрос для понимания общего развития собеседуемого.

Нужно ли тестировать документацию?

Ответ — да. Это называется «Тестирование требований к ПО”. Собеседуемый должен понимать, что требования в ТЗ могут быть: неправильно сформулированы, противоречащими и просто нереализуемыми.

Какие цели тестирования вы бы выделили?

Лично я бы выделил три цели:

- поиск багов,

- оценка качества продукта (ни в коем случае не обеспечение качества, от того сколько багов найдено качество ПО не улучшается),

- оценка рисков (поскольку выпуск продукта с малым качеством не есть гуд, всегда найдуться риски — например, что кто то умрет или на вас подадут в суд)




Практические задачи

Практические задачи позволяют отделить теоретиков от практиков. Человек может прочитать туеву кучу книг по тестированию но так ни разу не написать тест кейс или тест план.

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

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

Провести собеседование на английском на одну из тем по QA

Очень легко показывает уровень английского у человека.

По заданной интервьиром теме:
- создать формализованные требования,
- создать формализованные test-cases,
- создать тест план,
- создать предпологаемые баг репорты,

Примеры систем для данного тестирования
- Система авторизации на любом сайте электронной коммерции
- Дана консольная программа. Программа позволяет вводить последовательно три числа. Каждое число подтверждается клавишей Enter. После того как введено первое число, можно вводить второе. После того как введено второе число, может быть введено третье. После того как введено третье число программа сообщает - является ли треугольник с данными сторонами равнобедренным.
- Банка с кофе.
- Стерка
- Авторучка
- Солонка
- Любая другая вещь. Чем неожиданнее будет вешь тем лучше. Еще лучше если с самого начала собеседуемый начнет сам задавать вопросы. Какая именно банка, какая форма, какой материал. Т.е. еще лучше если он изначально сам создать список требований по объекту и начнет эти требования тестировать.

Сколько комнат в нашем офисе

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



Задачи на сообразительность


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

Почему крышка от люка круглая?

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

Ну конечно она имеет круглую форму и очевидно для того чтобы не упасть (любая иная фигура с углами или формы может провалиться в люк).

Есть 10 кроликов

Есть 1000 бутылок с вином

Одна из бутылок содержит яд. Как определить в которой?

Задача на двоичное мышление. Кролик пьет (1) или не пьет (0), соответсвенно мы можем закодировать 2 в 10 позиций

0000000000 — первая бутылка

0000000001 — вторая бутылка и т.п.

Есть дом. В доме четыре стены. У каждой стены по окну. Все окна выходят на север. Сколько таких мест на земле?

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

И тому подобное....

Для получения дополнительных примеров достаточно прочитать книгу Как сдвинуть гору Фудзи (См. Список литературы)


Список литературы:

Книги (все можно найти в электронном варианте):
- Тестирование ПО. Кем Канер и др.;
- Искусство тестирование. Майерс;
- Tестирование dot com. Роман Савин;
- Как сдвинуть гору Фудзи. Уильям Паундстоун;

Сайты:
1) http://www.rbcs-us.com/software-testing-resources/library/basic-library.html (в том числе и особенно Freightliner Test Level Matrix);
2) www.software-testing.ru;
3) Глоссарий терминов используемых в тестировании ПО
http://www.rstqb.org/index.php?id=25,0&sitelang=ru;
4) Более простой глоссарий http://testirovschiki.ru/glossary.php;
5) FAQ по тестированию http://www.ruleworks.co.uk/testguide/;

Конфереции:
SQADays (например http://it-conf.ru/ru/content/190.htm);

Обучение тестировщиков:
http://www.luxoft-training.ru/training/school/72;
http://www.avalon.ru/PPS/QA/Courses/About/?CourseID=905.

понедельник, 3 августа 2009 г.

Профессионализм тестировщиков дело рук самих утопающих


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

Во истину так.

среда, 29 июля 2009 г.

Хорошие новости нужно часто повторять!
















Не могу пройти мимо хорошей новости. Хорошие новости нужно повторять.

Selenium обзавелся очередным дополнением Selenium Inspector.

Библиотечка позволяет содержит всякие вкусности для облегчения работы с табличками, assert-ами, легким парсингом DOM модели. Короче немножко улучшений и со вкусом.

В купе с тем что Selenium RC обновился до 1.0.1 и в скором времени обещают объединение с Web Driver - это вообще становиться мечта практикующего QA автоматизатора.

среда, 15 июля 2009 г.

Паттерны тестирования. Timestamped Name

Я уже упоминал про желание складировать полезные мысли о проектировании автоматизированных тестов - паттернах и стратегиях тестирования. Данная запись одна из, надеюсь, многих и связана с использованием времени - как одного из вспомогательных факторов при создании объектов в процессе тестирования.

Timestamped Names

Имя паттерна: Timestamped Names
Назначение паттерна: Создание уникального имени для объекта

Во время прогона тестов, часто возникает ситуация когда необходимо создать новый объект. У любого объекта есть, как минимум, две характеристики: уникальный идентификатор и имя. Уточним, что имя должно быть более или менее понятным после прочтения (Good, Project etc), т.е. изначально все таки задается текстовая константа, по которой объект и будет именоваться.

У нас есть несколько путей задания задания константы:
- hardcoded константа,
- константа в конфигурационном файле.

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

Случается, что имя объекта также должно быть еще и уникальным. И тут указание имен в конфигурационные файлы выносить проблематично. Создаваться может несколько объектов одного типа, но требуются разные имена. Создавать для каждого объекта отдельную константу - слишком сложно (например имена для 1000 объектов). Нужен smart dynamic name. В данном случае - добавление временного префикса или постфикса к имени объекта. Само имя может как задаваться hardcoded, так и храниться во временном файле.

Например мы создаем товар Goods и и после выполнения timestamped операции получаем имя Goods_<...>, где <...> - это timestamped индекс. В будущем если мы захотим найти товар, с вероятностью 99,99999 мы найдем по данному имени только один товар. Оставшийся 0,00...1% я оставляю на проблемы с потоками, из за которых могут возникнуть два товара с одинаковым именем. Эта проблема известна и решаема, в каждом языке программирования - по своему.

В качестве альтернативы Timestamped Names можно использовать Indexed Name. Данный паттерн к имени создаваемого объекта добавляет числовой префиск или постфикс, который после именования очередного объекта увеличивается на единицу или на определенный шаг.

понедельник, 29 июня 2009 г.

Цитата недели для QA от Developer

Цитата недели для QA от Developer

Новая цитата недели пришла не от QA и не для QA, но данная фраза может быть перефразирована для специалиста любой специальности и любого направления. В том числе и QA:

Программист каждый день должен узнавать что-то новое. Если он этого не делает, значит он живет во вред себе
Джеймс Гослинг (автор языка программирования Java)

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

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

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

понедельник, 22 июня 2009 г.

Паттерны тестирования. Велосипед первый: GUI-Domain-Test-Report


Паттерны тестирования.
Велосипед первый: GUI-Domain-
Test-Report




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

И поскольку я человек умный, я должен как и всякий умный человек размышлять об умных вещах (подозреваю, что за такие предложения нужно сжигать прилюдно). Я уже упоминал про желание складировать паттерны тестирования в своем блоге . В данной заметке я бы хотел обсудить паттерн построения архитектуры тестовых фреймворков приложений, которому я дал название "GUI-Domain-Test-Report".

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

Проблематика построения тестовых фрейморков приложений

WebDriver: Design Patterns and Development Strategies

Первая ссылка это Design Patterns and Development Strategies . Проект WebDriver должен быть знаком тем, кто занимается автоматизированным тестированим веб-приложений. В документации к данному проекту присутствует описание стратегий-паттернов тестирования.

Остановим внимание на двух:
- DomainDrivenDesign - стратегия, которая предлагает, что работать с веб-приложением ннеобходимо на уровне предметной области (обсудим позже, что такое предметная область приложения).
- PageObjects - стратегия, которая предполагает, что должны быть выделены объекты ответственные за работу со страницами, с которыми вам необходимо работать (обсудим так же позже и подробнее).

GUI-level

В статье компании ATSG упоминаются оконные объекты:
Оконные объекты - этот тип компонентов специфичен для автоматизированного тестирования, в частности GUI-level тестирования и один из наиболее критичных к изменениям тестируемого приложения. Поэтому, для тестирования подобных компонент следует выработать некоторый workflow-сценарий, который затронет все ( или хотя бы просто большинство ) оконных объектов

В статье используется термин GUI-level, которым очень и очень важен для нашего исследовния. Level означает, что существует распределенная архитектура с ярко (или темно) выраженными уровнями-слоями. Вспоминая DomainDrivenDesign (упомянутый ранее), можно выделить также и Domain уровень - уровень предметной области.

Test-Buisiness-GUI

Недавно прошла конференция SQADAYS 2009, на которой мне не удалось побывать. Среди прочих презентаций нам будет очень очень полезна презентация господина Ревко Практические Рекомендации По Организации и Проведению Автоматизированного Тестирования. На странице 11 данной презентации появляется картинка с иерархией различных уровней.






"Для создания тестов, тестируемое приложение нужно разбить на 3 основных уровня:
- Тестовый Уровень
- Бизнес Уровень
- GUI Уровень
2 дополнительных:
- Уровень данных

- Уровень Функций"


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

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

Фреймворк-тест-драйвер-приложение

В веб-семинаре Алексея Баранцева Автоматизация функционального тестирования приводился пример стека автотестов:

И один из примеров стека автотестов:

В том числе на семинаре были озвучены паттерны тест-дизайна:
- адаптер для всего приложения,
- адаптеры страниц,
- адаптеры частей страниц\блоков,
- репозитарий элементов UI.

Замечание: Алексей просил не выкладывать материалы семинара на общее обозрение, - чего я и не делаю, но делаю небольшую рекламу его презентации и пиарю его курсы - надеюсь мы в расчете ;).

Нам важны данные материалы поскольку на конкретном примере TestNG-Tests-Selenium-Application мы можем понять, как приложение разбивается на слои с использованием существующих продуктов.

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

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

GUI-Domain-Test-Report (GDTR)

Как это принято в умных книгах, я приведу краткое описание паттерна:

Наименование: GUI-Domain-Test-Report (GDTR)
Также известен: стратегия построения тестового фреймворка
Тип: системный
Уровень: архитектурный
Назначение: обеспечить создание тестового фреймворка разрабатываемого приложения

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

Паттерн GUI-Domain-Test-Report или в дальнейшем GDTR я бы определил как архитектурный, по той причине, что он связан с построением архитектуры тестового фреймворка приложения.

Еще раз о том, что я вкладываю в термин тестовый фреймворк приложения - это приложение, разработанное для тестирования какого-либо бизнес приложения (или просто приложения).

Паттерн ADTR подразумевает выделение логически разделенных слоев в тестовом фреймворке приложения для обеспечения более гибкой архитектуры. Паттерн включает выделение тех же самых уровней что и в презентации Ревко , но
+ еще один, самый верхний, следующий после тестового - слой формирования отчетности ADTR:REPORT
- один, уровень Функций, который я не понимаю для чего выделять.
- еще один уровень Данных - о котором позже.

GDTR: GUI-ADAPTER
Данный слой предоставляет набор объектов (GUI-ADAPTERS) , озвученных ранее как ObjectAdapter или оконные объекты.

В основе создания данных объектов как я понимаю, лежит использование паттерна проектирования Adapter (он же Wrapper) (http://en.wikipedia.org/wiki/Wrapper_pattern). Любой графический объект (элемент оконной формы) может иметь свой т.н. адаптер для манипуляции с его содержимым в самом тестовом фреймворке.

Я бы выделил следующие графические объекты:
- Элемент (может быть объединен с другими элементами в контейнере формы или более высокого уровня).
В качестве примера графического объекта можно привести: выпадающий список, поле ввода, чекбокс или радиокнопка.

- Форма (может быть объединена с другими формами в общий компонент или страницу).
В качестве примера: вкладка с зависимыми элементами, тег FORM в HTML.

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

- Страница (является контейнером обычных полей, форм, общих компонент) .

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

Что же входит в обязанности адаптера графических объектов:
- получение данных,
- установка данных,
- клики,
- проверки данных и пр.

В данном слое есть некоторые неприятные моменты. Например для веб-приложений существуют т.н. локаторы, их можно назвать также уникальными идентификаторами графических элементов. Они разные: если используется сложный JavaScript и структура HTML-документа, то всегда возникают проблема - локаторы могут быть разными для:
- кликов,
- получения значения,
- установки значения.

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

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

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

GDTR: DOMAIN-ADAPTER
Данный слой предназначен для того, что бы "беседовать" с приложением на его языке - на языке проблемной области. В этом слое также создаются адаптеры, но уже над графическими адаптерами и для бизнес логики.

В качестве примера можно привести оформление товара в интернет магазине. Для выполнения заказа мы должны:
1. Авторизоваться (адаптер авторизации);
2. Перейти в каталог (адаптер главного меню, адаптер страницы каталога);
3. Перейти выбрать товар (скорее всего адаптер формы товара с ссылкой на товар);
4. Перейти на страницу корзины (адаптер страницы корзины);
5. Оформить заказ (адаптер страницы оформления заказа).

В скобках я указал приблизительные gui-adapter-ы для выполнения операции заказа товара. Данную операцию из 5 шагов может выполнять даже один domain adapter.

Здесь возникает вопрос - могут ли одни адаптеры проблемной области включать другие адаптеры проблемной области? Я считаю, что могут. В противном случае возникает дублирование кода. При усложнении поведения сайта, я бы рассмотрел возможность выделения в отдельный адаптер проблемной области шаги 2 и 3 и еще в один отдельный адаптер шаги 4 и 5. Но тут нужно думать ;)

GDTR: TEST

От тестового уровня требуется одно - провести проверку выполнения бизнес логики приложения. Используя адаптеры уровня проблемной области выполняются определенные тестовые шаги с последующей проверкой (сравнение с существующим эталоном, например).

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

В качестве примера можно привести оформление заказа товара, с последующей проверкой - отразилась ли информация о товаре (количество и сумма) на странице "Корзина".

GDTR: REPORT
Я выделил данный уровень в отдельный, поскольку получение отчетов о тестах, как мне кажется, должно быть выделено из уровня тестов. Сделать это необходимо хотя бы потому, что отчеты могут быть представлены в разных форматах, с разной детализацией содержать разные данные - т.е. быть вообще разными.

На практике тестовый уровень и уровень формирования отчетов о проведенных тестах могут встречаться в одном фреймворке (например TestNG формирует отчетность в HTML формате, зеленым цветом выделяются прошедшие тесты, красным - не прошедшие.)


Заключение
Надеюсь, что в моей заметке есть и новое и занятное, (да бог чтобы не было такой ситуации когда новое не занятное, занятное не новое) и даже неправильное. К сожалению я не присутствовал на SQADays 2009 и не знаю как обсуждалась презентация господина Ревко. Очень бы хотелось, но не получилось. Думаю результаты обсуждения могли бы серьезно повлиять на содержание данной заметки.

Конечно же многое еще не раскрыто. Есть еще вопросы, которые следует обдумать:
- Вопросы именования объектов слоев. Весьма спорный вопрос. Например, именовать все тестовые объекты начиная с префикса Test. Я лично против такой обязательности. Но в JUnit так принято (а вот в TestNG - нет).

- Проблема разделения данных между слоями. В презентации господина Ревко есть слой, Данных, растянутый между центральными. Я пока не готов рассуждать, как его разделить между упомянутыми мной слоями паттерна GDTR.

- Проблема отделения локаторов графических элементов от их поведения - в литературе используется термин GUI mapping. Я упомянул проблему в заметке. Дай бог разумения понять, как это делается.

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

Замечания принимаются и обсуждаются.

воскресенье, 21 июня 2009 г.

Цитата недели: Хороший тестировшик, не тот, кто выявит больше всего ошибок, и не тот, кто заставит смутиться даже самого первоклассного программиста. Лучшим является тот, кто добьется исправления наибольшего количества ошибок. Сэм Канер

Умная мысль для цитирования на этой неделе:

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

четверг, 11 июня 2009 г.

Новые велосипеды и Паттерны Тестирования


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

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

Во вторых, я вижу мало информации о "велосипедах" в тестировании. Читаю я много, но вот встречаются подобные патерны редко. Разве что - можно назвать паттерны документирования - процесса, в котором можно найти достаточное количество паттернов только потому, что бюрократия порождает патерны постоянно (например баг репортинг у Джоела - хорошенький такой патерн). Или Unit-тестирование (модульное тестирование), которое, все таки ближе к программированию и поэтому многое оттуда позаимствовало.

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

На одном из веб-семинаров Алексея Баранцева я задал вопрос - почему озвучено так мало паттернов (практически - только адаптер страниц\объектов). Ответ прозвучал приблизительно так: "наверное потому, что среди тестеров мало хороших программистов". Согласиться с этим не могу, и буду с спорить (люблю спорить если честно): скорее всего просто нет еще достаточного уровня унифицированности и стандартизации (хотя есть istqb), нет еще своего Кента Бека и Марти Фаулера в этой области (хотя есть Канер и Роман Савин), нет еще своих легенд (хотя есть Luxsoft: ).

Мысль о паттернах тестирования витает в воздухе - об этом упоминали в SQADays 2009, в книге Кента Бека Разработка через тестирование (http://www.ozon.ru/context/detail/id/1501671/) есть небольшая глава "Паттерны тестирования" (опять же связанные с модульным тестированием). Паттерны тестирования протягивают свои метастазы и в веб-семинары. Но мало кто складирует паттерны тестирования в одном месте. Пора навести порядок. Если не я - то кто (вроде бы это слова Жанны Д'Арк?).

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

вторник, 9 июня 2009 г.

Почему я не верю в жизнь после смерти или баги выше третьего приоритета

С некоторых пор я занялся профессиональным тестированием.

По окончании 3 месячного срока знакомства с этой работой, я понял что тестирование мне нравиться. Три месяца это тот срок за который, я считаю, можно понять: человек может заниматься этой деятельностью к которой его приставили, или - пора перестать мучить и себя и человека и дать что то другое. Например сокращение :(

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

Почему я не верю в жизнь после смерти? - потому что я никого не видел из тех, Кто От Туда Вернулся.

Почему я не верю в баги третьего приоритета (4,5 а то и 7!)? - такая приоритезация за собой не несет никакой пользы.

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

С тех пор я подрос и понял что кроме сейчас и потом есть еще когда будет время или когда нибудь или когда вспомним или, в самом экстремальном случае, наверное уже никогда, но для отчиски совести.... Сейчас нужно написать баг репорт, потом можно протестировать фичу после ребилда, если будет время - просмотреть API новой версии Selenium RC - 1.0. Сейчас нужно покормить ребенка, потом - посадить на горшок, если будет время до прогулки - повторить с ребенком два цвета: синий и зеленый.

Приоритеты 4, 5 ... n не несут в себе никакой информации. Они просто добавляют уровень к вашей некомпетентности. Вы либо знаете что в вашем продукте имеет приоритеты:
- сейчас
- сразу-после-того-как-закончаться-баги-сейчас
- просмотреть-и-повысить-приоритеты-для-тех-которые-сразу-после-сразу-после-того-как-закончаться-баги-сейчас.
Либо вы не знаете этого.

Сложно?

Cуть в том чтобы баги приоритета 1 и 2 были бы постоянными (стараться этого достичь), а баги приоритета 3 - либо повышались либо оставались такими же. Пересмотр багов должен проводиться периодически и постоянно. Это один из процессов которые нужно внедрять. Простая мысль - управлять багами тоже нужно - но я не встречал практического применения данной мысли на практике - наверное мне "везло".

Пересмотр, повышение приоритетов, и даже (что мне не нравиться) - понижение приоритета, объединение багов в один и присваивание им приоритета на один выше - вот я думаю начальные шаги управления багами.

Есть еще такая вещь как удаление бага по прохождении некоторого заданного времени. Например год прошел и бага самоликвидировалась (как и демоны из к\ф "Иван Васильевич Меняет Профессию") - их как бы и нет. Не встречал такого подхода, но слышал - интересно посмотреть компанию, где годами не исправляют баги :).


Но что делать когда багов сотни? Тысячи? И ими (багами) управлять и пересматривать сложно! - здесь я пожалуй спрошу - а вы уверены что у вас все в порядке с процессом разработки, программистами и лично вами?

понедельник, 8 июня 2009 г.

Exploratory Testing, Мартышкино тестирование, Тестирование по аналогии, Фейман и сейфы

С некоторых пор я читаю ... много. И много чего. За последние полгода в среднем я читаю по три книги в месяц, сотне другой статей, и прослушиваю c пяток аудиокниг.
Эти книги связаны не только с тестированием (нужно же знать больше чем знают другие которые могут предложить новую работу), но также:
- с подготовкой к сертификации по SCJP (нужно же расти профессионально и в цене),
- современная фантастика (нужно же знать что стоит за тем что называют современной фантастикой,
- фентези Пратчета (нужно же иногда и отдыхать),
- преподавание в высших учебных заведениях (нужно же знать о своем хобби),
- блоги своих студентов (нужно же знать тех кому ты преподаешь),
- материалы конференций (нужно же знать умных людей и места где они появляются) и прочее и прочее и прочее И в этом месяце я начал читать книгу "Вы конечно шутите мистер Фейнман". Я уже упоминал о ней и о ее герое. Я думаю данную книгу нужно внести в список книг для обязательного прочтения всеми ... не только тестерами но и людьми IT. Книга далека от IT но мышление господина Фейнмана пригодилось бы любому специалисту этой области. Одна из последних глав прочитанных мной - глава "Ты шнифер, и я - шнифер". Вкратце перескажу одну историю:

Фейнман - любознательный человек. Он решил научиться взламывать сейфы. Он научился. Он также прочел несколько книг как взломать сейф зная человека (очевидно одни первых книг по социальной инженерии ).
И вот несколько больших сейфов со всей документацией по тому как создать атомную бомбу. Хозяин сейфов - человек очень близкий к математике.
И вот приходит Фейнман. Он пытается понять какие числа нужно вбить.
Фейнман находит записку с константой π = 3,14159. Но она не подходит.
И тогда Фейнман использует код основания натурального логарифма e = 2,71828 (вторая по важности после пи математическая константа)
И сейфы с секретами создания атомной бомбы открываются.


Действуя по аналогии господин Фейнман раскрыл секрет создания атомной бомбы - но он то знал его и раньше, поэтому удовольствие было в другом. Я вообще считаю что Фейнман врожденное чувство специалиста по тестированию - любить проверять изделия людей на прочность. Именно по этому я и внес в заголовок "Фейнман и тесты"

Теперь об остальных частях заголовка. Что же я хотел сказать.

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

Я применяю небольшое ответвление данного ET - и называю его Мартышкины Тесты. Если опять перейти к аналогии, то это прогулка по городу, но с попыткой пройти сквозь стены стоящих домов, попыткой вломиться в милицейский участок с требованием "Свободу Анжеле Девис оборотни в погонах!", поесть в ресторане и не расплатиться, предложить студентам платить зарплату своим преподавателям. Т.е. полный негативный тест по неправильно выбранным направлениям.

Теперь про тестирование по аналогии. Очень редко я читаю про данный вид тестирования. Редко его вспоминают. Тем более ни разу не читал про использование мартышкиных тестов в связке с тестированием по аналогии, а это дает очень и очень хороший результат. Правда, - в количестве багов. К сожалению, данные баги (все 99,99%) будут 3 приоритета. Про баги с приоритетом выше третьего я не верю, равно как про жизнь после смерти, а 1 и 2 приоритеты им дать сложно, поскольку воспроизвести пользователю все то, что я проделал очень сложно.

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

И будем вам счастье.

пятница, 5 июня 2009 г.

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

C некоторых пор я начал читать книгу "Вы, конечно, шутите, Мистер Фейнман. " о Ричарде Филлипсе Феймане - нобелевском лауреате, одном из создателей атомной бомбы. Это набор историй об этом крайне любознательном и веселом человеке. Среди прочих его рассказов есть глава "Смешивание красок".
Эта глава - прекрасный пример работы тестировщика по жизни. Надеюсь что никто не оторвет мне голову за то что я процитирую кусочек этой интересной книги:

...Я частенько бывал в симпатичном маленьком ресторанчике, который назывался “Папино место”. Однажды, когда я там обедал, недалеко от меня сел маляр в рабочем комбинезоне. Он спустился со второго этажа, где красил комнату. Каким то образом между нами завязалась беседа, и он начал говорить о том, как много нужно знать для того, чтобы заниматься малярным делом. “Например, – сказал он, – если бы вам пришлось красить стены в этом ресторане, какой цвет Вы бы выбрали?”

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

Видимо, парень действительно разбирался в том, о чем говорил, так что я сидел, развесив уши, когда он сказал: “Кроме того, нужно разбираться в цветах: знать, как при смешивании красок можно получить различные цвета. Например, какие цвета Вы смешали бы, чтобы получить желтый?”

Я понятия не имел, как можно получить желтый цвет, смешивая краски. Если речь идет о свете, то нужно смешать зеленый и красный, но я знал, что он говорит о красках. Поэтому я сказал:

“Я не знаю, как получить желтый цвет без желтой краски”.

– Ну что же, – сказал он, – если смешать красную и белую краски, то получится желтая.

– Вы уверены, что получится не розовая?

– Конечно, – сказал он, – получится желтая.

Я поверил, что он получит желтый цвет, потому что он был профессиональным маляром, а я всегда восхищался людьми подобных профессий. Но мне все равно было интересно, как он это делает.

Тут меня осенило. “Должно быть, происходит какое то изменение в химическом составе. Может быть. Вы используете какой то особый вид пигментов, которые изменяют химический состав краски?”

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

В этот момент я подумал: “Что то здесь не так. Я достаточно знаю о красках, чтобы знать, что в таком случае желтый цвет получить невозможно, но он, должно быть, знает, что желтый цвет получается, а значит, происходит что то интересное. Я должен это увидеть!”

Поэтому я сказал: “Хорошо, я принесу краску”.

Маляр поднялся наверх, чтобы закончить работу, а ко мне подошел хозяин ресторана и сказал: “В чем смысл вашего спора? Он маляр и всю свою жизнь был маляром, и он утверждает, что желтый получается именно так. Так зачем же с ним спорить?”

Я смутился. Я не знал, что сказать. Наконец, я ответил: “Всю свою жизнь я изучаю свет. И я считаю, что, смешивая красный и белый цвет, желтый получить невозможно – можно получить лишь розовый”.

Итак, я отправился в хозяйственный магазин, купил краску и принес ее обратно в ресторан. Маляр спустился со второго этажа, и хозяин ресторана тоже пришел посмотреть. Я поставил банки с краской на старый стул, и маляр начал смешивать краски. Он взял красную краску, добавил белой – мне по прежнему казалось, что получается розовый цвет, – он смешал еще немного краски. После этого он пробормотал что то вроде: “Я обычно использовал небольшой тюбик желтой краски, чтобы усилить эффект – вот тогда получится желтый цвет”.

– А! – сказал я. – Конечно! Если добавить желтый, то получится желтый, но без него ничего не выйдет.

Маляр ушел обратно красить комнату.

Хозяин ресторана сказал: “У этого парня хватило наглости спорить с человеком, который всю свою жизнь изучает свет!”

...

В конце главы есть предложение которое нужно распечатать крупными черными буквами и повесить на видное место:

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



четверг, 4 июня 2009 г.

Буквально вчера провел в своей конторе занятие. Лекцию, может быть семинар: автоматизированное тестирование веб приложений. Взял за основу прослушанный веб-семинар и материалы к этому же Алексея Баранцева (Функциональное тестирование веб-приложений), презентации последней конференции SQADays 5 2009, материалы конференции SEC(R)-2008 и свое понимание и опыт.

Целей было несколько:
1) донести до разработчиков именно моего проекта (в конторе несколько проектов) что автоматизированное тестирование не есть зло в своем ярком обличии - а всего лишь дополнительный инструмент, который нужно использовать в нужное время в нужных местах с нужными людьми;
2) систематизировать для себя ЧТО нужно делать дальше с построенным фреймворком для тестирования приложения и КАК это сделать наиболее безболезненно
3) показать пример того что занятия в конторе нужны - опытом делиться нужно ( я бы вот послушал особенности работы с СУБД MS SQL Server и Java в нашем проекте - но кого заставишь?)
4) попробовать выступать не перед студентами. Все таки преподавание студентам ( которые по любому будут тебя слушать ) и выступление перед более умными людям (которые могут встать и уйти) - имеют большую разницу

Все цели считаю достигнутыми.
1) разработчики поняли что я не лентяй :)
2) систематизацию провел - наметил план рефакторинга своего кода для автоматизированных тестов
3) пример повлиял - недели через две будет озвучен доклад о проектировании приложений на C++ с использованием UML и паттернов проектирования.
4) выступил не плохо, людям кажется понравилось. Но опять же думаю нужен опыт выступления не перед знакомыми людьми с которым кофе по утрам распиваешь а перед аудиторией побольше и менее знакомой. Думаю провести встречу OSUM в сентябре-октябре в родном Ульяновском политехе. Должно быть интересно. Надеюсь.