Теоретика и рабочие моменты

Во-первых, нашла наконец приличные учебные материалы, а не просто "как я тестировал то-то" и спешу поделиться. Это - материалы подготовки к сертификации ISTQB. Вот тут материалы подготовки по всем уровням, для базового - есть на русском языке, в т.ч. есть глоссарий - там выписаны все определения, каноничноЪ. Это, повторюсь, первый встреченный мною нормальный учебный (именно учебный, практически учебник) материал. Как преподаватель говорю :) Это не значит, что публикации корифеев читать не нужно и бесполезно - вовсе нет - чужой опыт ценен, а если вы сможете адаптировать его к собственным нуждам - бесценен. Но экзамен (или сертификацию) вы по нему не сдадите. Что касается сертификации тестировщиков как таковой, то мое отношение к ней такое же, как и к любой другой бумажке с курсов - это иногда помогает пустить пыль в глаза недалеким людям, но сам по себе сертификат особо ничего не значит. Он значит лишь то, что вы знаете теорию, а об умении применять ее на практике там практически ни слова, так, пара тестов. Где-то я вычитала фразу, что сертфикация в общем нужна лишь тебе самому - проверить свои сил, знания. И с этим я более чем согласна, но бывает человеку это и не надо. Я пока еще думаю буду ли я сдавать на нее, но скорее да - потому что у нас компания заинтересована в сертифицированных тестировщиках. На черта, правда, не знаю, но если начальство говорит: "Лягушка" - то надо прыгать :) Опять же - не нужно понимать эту фразу буквально - разумеется, требования начальства необходимо выполнять в разумных пределах, до тех пор, пока это не ущемляет какие-то личные права/свободы. Расползаюсь что-то, но в любом случае, я полагаю небесполезной будет информация о том, как это проходит. Даже если вы не собираетесь сдавать - рекомендуется к ознакомлению.
А теперь о рабочих моментах, в частности - о баг-репортах. И нет, не о их составлении. А, любите Родину, мать вашу! - об их чтении! Я понимаю, что данная ситуация не показатель вообще, конец пятницы, мы все устали - но бывает вот такое. Составленный четче некуда баг-репорт (не мной даже, начальник клепал давно, решили повысить приоритет после жалобы в FAQ'е) и вопросы от программиста: а что, а как, а так где мне это делать? Где?! В гнезде!!! Мы все знаем, что у нас игра (программа), так ГДЕ ты должен это воспроизводить? В баг-репорте важно _каждое_ слово, это документ (конечно, бывает я делаю спецом забавные опечатки - чтоб чуток развеять официоз), тут ничего не пишется просто так. Но нет, Коля молодец, он взял последний абзац (не вникая в описание), который как раз относился непосредственно к описанной ситуации - и говорит - не, у меня все работает! Это слава яйцам, мы сидим в одной комнате, я могу подойти, ткнуть пальцем и показать что именно он пропустил. А если бы это было "программист тут, тестер - там"? Мы бы запинали этот тикет до посинения и взаимной ненависти. В общем, я что хочу сказать - иногда если программист не понимает баг-репорта, это не обязательно значит, что тестировщик его плохо написал. Просто программисты тоже люди и могут что-то в описании - одно слово! - прошляпить. А это одно слово может быть определяющим. Так что учитесь сами писать верно и учите верно читать.

Савин+Тамре. Генерация тестовых случаев

Савин.
Методы генерации тестов:
1. Черновик-чистовик. Локальный мозговой штурм. Цикличен.
2. Матричная раскладка.
Этапы: набросок элементов и комбинация элементов.
В примере рассматривалось тестирование полей ввода индекса:

3. Блок-схемы.
Методы отбора тестов.
1. Оценка рисков. Какие из тестов будут исполнятся в первую очередь исходя из ситуации, оценку должны производить профессионалы, т.к. "на первый взгляд логично..." очень часто приводит к противоположенным результатам без знания нюансов.
2. Эквивалентные классы.
3. Граничные значения (возможно, как частный случай эквивалентных классов).
Тамре.
Я уже писала подробно, выпишу ещё раз вкратце.
Категории тестов.
• нет данных
• повторный ввод данных
• верные данные (значения внутри диапазона)
• неверные данные (граничное значение +/- 1)
• сброс/отмена/дисконект ~ стрессовое тестирование
• создание напряжений в системе ~ нагрузочное
• тестирование характеристик ~ функциональное
Знать как отченаш.

Савин-3

Цикл разработки ПО, модель "Водопад" (Waterfall)
1. Идея - маркетинг, описание цели.
2. Разработка дизайна и создание спецификации - путь к цели.
Must be спецификации:
• акцент на деталях и их чёткое определение
• недопущение неверного толкования (предельная чёткость формулировок)
• непротиворечивость
• логическая взаимосвязь компонентов
• полнота охвата предмета
• соответствие нормативным актам
• соответствие деловой практике/этике
Стадии: Черновик --> Ожидает подтверждения --> Утверждён
макеты с иллюстрациями спецификаций
3. Кодирование.
Внутренний дизайн кода
Причины возникновения багов:
• некачественная или изменяющаяся спецификация
• личные качества программиста
• отсутствие опыта
• пренебрежение стандартами кодирования
• сложность системы
• баги в ПО сторонних лиц
• отсутствие юнит-тестирования
• сжатые сроки разработки
Причины ликвидации соответствующие.
Требования к юнит-тестированию: юнит-тесты планируются ДО написания кода; требования к ним должны быть сформулированы в стандартах.
4. Исполнение тестирвоания и ремонт багов.
Приоритет:
-тестирование новых компонентов
-регрессионное
5. Релиз.
Виды: релиз, дополнительные релиз, пач-релиз
Бранчи.
А вот почему "водопад":

Савин-2. Виды тестирования.

Я не со всем согласна, но у Савина это выглядит так:
Т.к. классификация бываю разные, то в случае тестирования они выглядят примерно так:
• по доступу к коду
чёрный ящик;
белый ящик;
серый ящик.
• по объекту тестирования
альфа-тестировщик;
бета-тестировщик.
• по времени проведения тестирования
альфа-тестирование (до передачи пользователю);
○ тест приёмки (дымовое);
○ тестирование новых функциональностей;
○ регрессионное;
○ тест сдачи;
бета-тестирование (после передачи пользователю)
• по позитивности сценариев
позитивное тестирование;
негативное тестирование.
• по уровням
компонентное;
интеграционное;
модульное.
• ручное или автоматизированное
• по объекту тестирования (тут я лучше дам схемку, составленную с помощью protesting.ru)

Конспект Савина

Вряд ли, к сожалению, мне поможет Selenium - по крайней мере IDE не записывает действия во флеше.
И как бы я не не любила Савина, читать придётся. Ибо эбо.
Итак, тест кейсы по Савину. Я уж не буду снисходить до уровня детсада как это делает Савин и пудрить мозги тупыми конкретными примерами, воспользуюсь определением с простестниг'а: Тест-кейс (тестовый случай) - это прописанная совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части. В виде таблицы представляется полями Действие (Action), Ожидаемый Результат (Expected Result) и Фактический Результат (Result). На практике (моей) используется поле с фактическим результатом, а отметку о том пройден тест кейс или провален ставят в чек-листе (check list). Так же необходимыми атрибутами тест кейса являются поля с предусловием (состояние системы на начало выполнения тест кейса, по Савину "SETUP and ADDITIONAL INFO"), кратким описанием (summary или IDEA по Савину) и уникальным номером - ID. Так же в тест кейсе может быть указан его приоритет (по Савину), однако чаще всего приоритет фигурирует в баг репорте (Bag Report) - отчёте о найденом баге (проваленном тест кейсе). О нём я ещё буду писать. Так же Савин предлагает вести историю изменений тест кейсов (я бы уточнила - тест сьюитов (test suite) как комплекта тест кейсов), это кажется разумным. В целом, я бы оформляла тест кейсы примерно так. На первой - краткие описания с ID, на отдельных страницах - сами кейсы со всеми атрибутами. Бывает, если кейсы оформлены в док документе, приходится часто листать туда-сюда для того, чтобы найти нужный, для этого лучше реализовать список с кратким описанием и удобной навигацией по сьюиту.
Тест кейс считается пройденным (passed), если ожидаемый результат совпадает с фактическим. Соответственно, проваленным (failed), если фактический результат оказался отличным от ожидаемого. Так же у тест кейса может быть состояние заблокирован (blocked), оно возникает если невозможно выполнить какое-либо условие из Действия (Action).
У Савина так же описан такой функционал, как поддерживаемость тест кейсов. Поскольку мы тест кейсы пишем не для одного раза и планируем ими пользоваться регулярно, а в программе может что-то меняться, нужно максимально продумать их дальнейшее сопровождение. Для этого тест кейсы должны быть: a) максимально независимы друг от друга и b) минимально конкретизированы - т.е. мы должны избегать отсылки к конкретным полям/товарам/атрибутам, поскольку они могут меняться с течением времени. Пример: в "добавьте товар "мишка плюшевый" в корзину" следует опустить имя товара, т.к. мишки на складе могут закончится и воспроизвести тестовый случай будет невозможно. Я считаю это разумно, но слишком общее описание будет занимать больше времени на разбор содержания, поэтому тут нужно найти золоту середину - и чтобы избежать излишней детализации, и чтобы не удариться в пространные описания.
Так же Савин уточняет, что ОР (ожидаемых результатов) в одном тест кейсе может быть и два. К примеру, если мы проверяем функционал добавления товара в корзину и смотрим, чтобы он корректно отобразился в корзине и одновременно в базе данных (т.н. "проверка внутри" (front end) - проверка интерфейса пользователя и "проверка изнутри" (back end) - проверка в базе). Ещё раз подчеркну, что нужно избегать зависимости тест кейсов, т.к. при "выпадении" одного может получится блокировка другого вследствии нарушения целостности ссылок сцелочная ссылочность. Так же важным параметром "хорошести" тест кейсов служит то, что их сможет выполнить другой человек - т.е. кто-то, кроме составителя.
Удалять выпавшие тест кейсы не рекомендуется несмотря на их независимость друг от друга, во-первых потому что ВНЕЗАПНО может оказаться, что удалять не нужно было, а во-вторых, он может понадобиться в качестве базы для создания нового. Савин рекомендует переносить удалённые тест кейсы в специальный раздел.

Форсаж

Ссылки для Selenium'а:
оглавление статей: http://automated-testing.info/knowledgebase/avtomatizaciya-funkcionalnogo-testirovaniya/selenium
список с общими компонентами и их описанием: http://automated-testing.info/knowledgebase/article/chto-takoe-selenium-i-s-chem-ego-edyat
Selenium Core: http://automated-testing.info/knowledgebase/article/selenium-core-obshchie-ponyatiya
расширение под IDE и комманды: http://automated-testing.info/knowledgebase/article/selenium-ide-flowcontrol-primery-ispolzovaniya

Тест план, тест дизайн, тест кейсы.

Поскольку возникла пищащая необходимость разложить в голове по полочкам эти понятия, постольку буду делать это здесь, да и в качестве вводной теорчасти это будет небесполезно, ящитаю. Итак, пункт первый.
Тест план. Как новичок обычно представляет себе процесс тестирования? Ну там посмотреть текстовые ошибки, отловить баги, понажимать кнопочки так и сяк. Баг репорт склепать и отправить разработчикам. Вот что я вам скажу - херня всё это, процесс собственно отлова багов занимает процентов 10-20 всего процесса (зато регрессионное тестирование это по стопиццот раз одно и тоже). Ибо нажимая так и сяк каждый раз одно и тоже, приходишь к выводу, что делаешь одну работу и нужно её как-то систематизировать, а потом просто адаптировать к каждому случаю. То есть нам нужен план отличный план!. Тест план Джеймс План. Итак, тест план - это документ, описывающий весь объём работ по тестированию (более полно тут, с обязательными пунктами) с учётом используемых подходов, системных ресурсов, человеческих в конце концов ресурсов (кто и что будет разрабатывать и тестировать). Я полагаю, тест план в идеале должен составлять руководитель отдела тестировщиков (Team Lead?), ибо плохо пока представляю иерархию в этой области. Но кто-то главный, кто видел процесс и изнутри, и снаружи - это точно.
Тест дизайн. Итак, тест план уже есть, задачи разделены, серьги розданы, можно кидаться к вожделенному отлову зловредных багов? Не-ет, родные, мы же не хотим из раза в раз на разных продуктах делать одно и тоже без системы, с ужасном накануне релиза вспоминая что забыли проверить ещё "вот это, это и то"? Мы-то хотим спать с чистой совестью, зная, что прошлись по всем возможным местам обитания любимых насекомых. Значит, каждому из команды нужен ещё и тест дизайн, на основе которого будут составлены тест кейсы, на основе которых будут писаться баг репорты в доме, который построил Джек, и на основе которых будет идти регрессионное тестирование (прогонка после отладки) и не один раз. Собственно, тест дизайн - это всего лишь набор техник для составления тест кейсов. В некотором роде у Тамре вот тут тоже техники тест дизайна. По protesting.ru это:
Эквивалентное Разделение (Equivalence Partitioning - EP)
Анализ Граничных Значений (Boundary Value Analysis - BVA)
Причина / Следствие (Cause/Effect - CE)
Предугадывание ошибки (Error Guessing - EG)
Исчерпывающее тестирование (Exhaustive Testing - ET)
То есть это приёмы, на основе которых мы будем писать тест кейсы. К примеру, Анализ граничных значений - это те самые граничные значение, +1 и -1, эта техника будет использована для валидации полей ввода данных. Если есть поля вводы данных - без этого не обойтись и мы уже не забудем включить этот метод в тест кейсы при проверке всех возможных полей ввода. Кстати, я не совсем понимаю почему бы, имея прямой контакт с разработчиками, заранее не оговорить, чтобы такие поля прописывались с некими стандартами - скажем, тип поля text с ограничением на ввод по ASCII (Юникод) и количеству символов? Ну, к примеру, в поле логин нельзя ввести больше 256 символов только из английской раскладки. На любое другое значение либо превышение размера поля возвращать сообщение об ошибке. Ну, это я так. В рамках тест дизайна. Что касается того, кто разрабатывает тест-дизайн, так это тест-аналитик (определяющий что тестировать) и тест-дизайнер (определяющий как тестировать).
Итак, техники тест дизайна мы изучили, можно приступать к разработке тест кейсов. Это, пожалуй, самая объемная часть работы, потому как, помимо составления, требует и документирования (первые две части тоже требуют документирования, просто эта - наиболее объемная). Тест кейс (тестовый случай) - это, если говорить по существу, условия, в которых система выдаёт ту или иную ошибку (или реагирует правильно). Как правило, условия создаются специально, но вот для текстовых ошибок не нужно что-либо создавать. Но вот указывая последовательность действий, которая приведет к окну с тестовой ошибкой, мы описываем Steps to reproduse - шаги воспроизведения ошибки- один из артефактов баг репорта. В тест кейсе это просто Action - действие, приведшее к фиксации бага. Два других артефакта тест кейса - это Result (результат фактический) и Expected Result (ожидаемый в идеале результат. Как обычно, тут более детально. Тест кейсы составляются непосредственно тестировщиком, хотя вот в России, по слухам с Дальнего Востока, они составляются старшим и даются для прохождения манки-тестеру.
Я хотела ещё зацепить такое понятие, как тестовое покрытие, но, видимо, уже в следующий раз, т.к. слишком много информации в одном посте и папа с малым уже нагулялись и требуют внимания :)
P.S. Ещё на эту же тему: та-дам очень хорророшая аналогия со строительством, настоятельно рекомендую.

Метод Recordset

В программе я использовала метод Recordset для доступа к данным. Освоение этого метода и его применение оказалось самым сложным в написании программы, ведь ничего необычного в том, чтобы вырезать ненужную часть в тексте нет. Я думаю, по книгам я бы вряд ли смогла его освоить - у меня был модуль от бывшей сотрудницы. От этого я отталкивалась. Возможно, я невнимательна, но нигде в литературе я не нашла (а может просто теорию не удалось конкретизировать) как его применять. Типы курсоров, объекты, коллекции - всё это не давало мне представления как же мне показать программе какую таблицу подключить, а, главное, как. Тут я хочу сделать очередные "заметки на полях". И да, нигде не нашла упоминания о библиотеках. Выложат кусок модуля - закинешь его в Access, запустишь - и о боже! - убей их всех. Не хватает библиотеки. Какой? Из тысячи как её выбрать? Наугад? Опять же - слава предшественнице, надоумила. Обычно пользуются DAO или ADO, смотря каким методом вы организуете доступ к данным (проще говоря - какую ткнете). Иногда не хватает Jet and Replication, хотя я читала, что с некоторых пор она входит в DAO. Итак, как указать модулю нужную таблицу и какие дополнительные параметры нам понадобятся, если мы хотим редактировать записи. Что есть вообще Recordset? Как я понимаю, это некая промежуточная таблица, копия той, с которой вы работаете, записанная в оперативную память и потом замещающая (если не забудете указать) рабочую. То есть - взяли слепок ("набор записей на основе таблицы", как ещё пишут) с таблицы, с ним сделали все действия и заменили им таблицу. А если это новая таблица, значит её нужно описать в переменных. Итак:
Dim [имя "слепка"] As Recordset
Превосходно. Мы сказали модулю, что у него будет табличка-слепок (полученная методом Recordset) с именем... Пусть будет банальное rst
Dim rst as Recordset
Пока она девственно пуста, но нам нужно наполнить её нашей рабочей. А наша рабочая таблица находится в базе данных (в конкретном случае - в той же, что и модуль, в противном случае нужны другие параметры). Из этого следует, что нам нужно ещё и базу данных описать. Главное, не описаться :)
Dim [имя базы] as Database
Пусть её тоже зовут стандартно, dbs
Dim dbs as Database (кстаит сказать, иногда на эту строку у меня отладчик ругается и я её просто убираю - видимо, подхватывается на автомате)
Теперь "скажем" модулю, что наша dbs - текущая база данных:
Set dbs = CurrentDb
И вот теперь мы можем наконец заполнить нашу промежуточную табличку рабочей:
Set rst = dbs.OpenRecordset("имя рабочей таблицы", dbOpenDynaset)
OpenRecordset открывает табличку. А константа dbOpenDynaset позволяет производить изменения (есть константы, к примеру, только для чтения) и допускает соединение нескольких таблиц. Вообще говоря, мне кажется что и более узкая dbOpenDynamic будет работать как нужно, но я взяла пошире, как с типом переменной - чтоб не промахнуться.
После этого наша промежуточная таблица готова к редактированию, а доступ к полям осуществляется оператором ! с указанием имени поля. К примеру:
!proizv = Trim (!proizv)
Итак, мы хотим произвести в таблице некоторые изменения. По умолчанию курсор стоит в начале записей. Если честно, с другими вариантами, когда его нужно поставить на определённую запись, не сталкивалась. Курсор будет двигаться строго по порядку - от начальной позиции к следующей и так, пока не будет достигнут конец записей. Логично, что для внесения изменений, придется иметь дело с циклом, и не одним. Будут два вложенных. Первый - как раз на это движение от первой позиции к последней и проверки каждой записи на условия и второй - на редактирование (изменение) и обновление данных в таблице.
While not rst.EOF
...
Wend
Или цикл Do Until ... Loop
Do Until rst.EOF
...
Loop
.EOF - End of file.
Второй же цикл - на внесение изменений при выполнении условий.
With rst
.Edit
...
.Update
.MoveNext
End With
.Update - метод, который позволяет вносить изменения в нашу исходную таблицу, а .MoveNext осуществляет переход к следующей записи. Ну а внутри второго цикла, собственно, идёт банальная проверка условий и преобразования с текстом. Фух, вроде ничего не упустила.