Тестирование Часть 1.2.

ЦИКЛ РАЗРАБОТКИ ПО

Цикл (процесс) разработки ПО (software development life cycle) - это путь от идеи до поддержки готового продукта.

Мы рассмотрим цикл "Waterfall"(Водопад).

Цель: понять логику взаимосвязи между стадиями цикла и основные моменты каждой стадии.

Цикл разработки ПО состоит из:

1. Идея.

2. Разработка дизайна продукта и создание документации.

3. Кодирование ( в смысле создание кода).

4. Исполнение тестирования и ремонт багов.

5. Релиз.

1. В действующей интернет-компании идеи генерирует как правило отдел маркетинга, нередко идеи инициируются службой поддержки пользователей или новым контркатом. Как правило идеи компонуются в MRD (marketing requirement document - документ о требовании маркетинга, суть которого "хотелось бы это иметь"). Затем менеджер проворачивает mrdшки через жернова анализа, утверждения и приоритезации, а выжившие идеи передаются продюсерам, которые их обрабатывают, чтобы получилась спецификация.

2. На основании идеи, утвержденной менеджментом, разрабатывается и документируется ее воплощение, которое называется дизайном продукта (product design). Разница между идеей и дизайном продукта заключается в том, что идея- это описание цели, а дизайн это описание пути к достижению этой цели. Профессионально это осуществляется менеждерами продукта (product managers), которые могут называться продюсерами или дизайнерами продукта. Результатом продюсерских усилий являются спеки , называемые также PRD(product requirements document) или просто requirements (требования). Спеки должны иметь уникальное название и уникальный ID. Каждый спек имеет также обозначение своей важности (приоритета). Практическая ценность придания спеку приоритетности состоит в следующем:

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

-программист и тестировщик всегда должны начинать со спека с большим приоритетом.

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

Как правило, приоритет присваивается спекам менеджером продюсеров.

Хороший спек отличают следующие вещи:

1. Акцент на деталях и их четкое определение.

2. Забота о недопущении неверного толкования.

3. Непротиворечивость внутри спека и с другими спеками.

4. Логическая взаимосвязь компонентов.

5. Полнота охвата предмета.

6. Соответствие нормативным актам.

7. Соответствие деловой практике.

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

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

5. не забывать добавлять СVV2 код.

6. Некоторые лекарства в онлайн аптеке не могут продаваться.

7. Если денежный перевод обычно знаимает 3-6 дней, то нужно так и говорить пользователю.

Спеки имеют следующую очередность статусов:

1. Во время написания они имеют статус Черновик (Draft), продюсер пишет спек.

2. После написания и до утверждения - ожидание утверждения (Approval pending). Спек написан и назначается совещание (meeting) с программистами и тестировщикамипо его обсуждению или же просто им посылается е-мейл с приложением.

3. После утверждения - утверждено (approved или final). Если спек получит положительные отзывы от всех реципиентов, утвержденный спек выкладывается на один из серверов, чтобы быть доступным любому лицу внутри компании, если же нет, то все начинается с пункта 1.

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

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

Тестировщики должны настаивать на том, чтобы спеки по максимуму иллюстрировались:

-макетами(mock-up)

-блок-схемами(flow-chart)

-примерами(example)

Интерфейс- это то, что видит пользователь, а алгаритм- это то, почему пользователь видит то, что он видит.

3. Кодирование. Работа программиста заключается в том, чтобы перевести вещи, отраженные в спецификации, на язык программирования. Перевод осуществляется:

-напрямую, т.е. программист берет спек и напрямую кодирует его предписания (плохая, недальновидная и опасная идея),

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

К документам о внутреннем дизайне кода относятся, например

-документ о дизайне/архитектуре системы;

-документ о дизайне кода.

В идеальном случае каждый программист имеет личную версию сайта (или playground), в которую входят:

-веб-сервера;

-сервер с приложением (application server);

-база данных (database).

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

а. Некачественные и/или изменяющиеся спецификации

б. Личностные качества программиста( невнимательность, лень, халатность)

в. Отсутствие опыта-программист может не знать как сделать правильно.

г. Пренебрежение стандартами кодирования

д. Сложность системы

е. Баги в ПО третьих лиц.

ж. Отстутствие юнит-тестирования-программист не тестирует свою программу.

з. нереально короткие сроки для разработки.

Возможности оздоровления кода и превентирования багов до передачи кода тестировщикам включают:

1. Наличие требований к содержанию спеков и следование правилам их изменения.

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

3. Инспекции кода;

4. Стандарты программирования;

5. Реальные сроки;

6. Доступность документации;

7. Требования к проведению юнит-тестирования;

8. Реальные финансовые рычаги стимуляции написания эффективного и чистого кода;

9. Наличие понятий качество и счастье пользователя как основных состовляющих корпоративной философии.

2. а. Психологический аспект: -если к тебе обратились - помоги

-не нужно стесняться уточнять то, что не понятно

-менеджер должен регулярно устраивать team building activities (мероприятия по сплочению коллектива)

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

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

4. -правила о комментариях

-правила об именах таблиц в базе данных, классов, функций и различных видов переменных

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

-прочее

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

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

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

- перераспределить нагрузку и

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

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

7. Юнит-тестирование (unit testing) - это тестирование, производимое самим программистом.

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

2.) Требования к юнит-тестам должны быть формализованы в стандартах о юнит-тестировании. Например, каждая функция должна иметь по крайней мере один тест-кейс с одним конкретным вводом и одним конкретным выводом.

Три основных занятия программистов:

1. Написание кода для данного релиза происходит во время стадии кодирование.

2. Интеграция кода для данного релиза происходит по завершении стадии кодирование.

3. Ремонт багов для данного релиза происходит во время стадии кодирования следующего витка цикла разработки ПО.

2. Интеграция кода- соединение нескольких кусков кода в один, без ошибок компиляции.

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

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

Синтаксический баг - баг который находит компилятор языка программирования.

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

4. Исполнение тестирования и ремонт багов.

После того как проинтегрирован код, тестировщики проводят тест приемки( smoke test, sanity test или confidence test), в процессе которого проверяются основные функциональности. Если тест приемки пройден, то код замораживается и тестировщкик начинают тестирование новых компонентов (new feature testing), т.е. исполнение своих тест-кейсов, написанных по спекам данного релиза. После того как новые функциональности протестированы, наступает очередь исполнения "старых" тест-кейсов. Этот процесс называется регрессивным тестированием (regression testing), которое проводится для того, чтобы удостовериться, что компоненты ПО, которые работали раньше, все еще работают. Баги заносятся в систему трэкинга багов (Bug tracking system, далее -СТБ), программисты их ремонтируют, и затем тестировщики проверяют, насколько качественным был ремонт.

5. Релиз. Release (англ.) -выпуск, освобождение.

Виды релизов:

1. Релиз (major release) - стадия в цикле разработки ПО, идущая за стадией тестирование и ремонт багов, т.е. передача пользователям кода новой версии нашего ПО. Как правило обозначается целыми числами, например 7.0.

2. Дополнительный релиз (minor release) - ситуация, когда после основного релиза планово выпускается новая функциональность или изменяется/удаляется старая. Он не связан с багам, обозначается например 7.1.

3. Заплаточный релиз (patch release) - когда после обнаружения и ремонта бага выпускается исправленный код. Как правило обозночается сотыми, например 7.11.

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

- для данного релиза.

Каждое отоброжение кода веб-сайта называется билдом. Блил- это версия ПО.

Цель создания билдов, чтобы измененный код (сохраненный в CVS) стал доступный для тестировщиков:

а. после того как программист починил баг, найденный при тестировании, он проверяет отремонтированный код в CVS.

б. Отремонтированный код становится частью нового билда.

в. Новый билд замещает (replace) на тест-машине код предыдущего билда.

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

Первый релиз происходит так:

1. Подготовка машины у хостинг-провайдера. Используя IP адрес мы подсоединяеся к арендованной машине-серверу и настраиваем

а) провайдерский Линукс ( например, создаем дериктории, редактируем разрешения и т.д.)

б) провайдерский Apache (например, вносим изменения в файл конфигурации и т.д.)

в) провайдерскую MySQL (например, определяем максимальное число соединений и т.д.)

2. Подготовка релиз-скрипта (release script) программы, которая автоматизирует процесс релиза на машину для пользователя.

3. Исполнение релиз-скрипта:

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

б) релиз-скрипт берет файлы этого нового билда и по протоколу FTP пересылает их в машину для пользователей.

в)релиз скрипт:

-копирует из CVS на машину для пользователя скрипты для базы данных (DB-scripts) и

-запускает эти скрипты.

Каждый удачный релиз нужно сохранять в CVS и потом создавать новую ветвь (branch) для нового релиза.

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

Альфа-тестирование - любое тестирование кода до передачи его пользователям (включая бета-пользователей).

#тестирование