Тестовые случаи (категории тестов, прмиеняемые к схеме) желательно фиксировать. Вряд ли, не обладая феноменальной памятью, мы сможем воспроизвести все те издевательства над системой, после которых ее отправили на доработку. А повторная прогонка после доработки необходима - проверить всё ли исправлено и корректно ли работают те функции, которые и раньше отрабатывали правильно. Итак, нам нужны краткие описания тестов. В общем случае она выглядит так:
1. ID тестового прмиера (идентификатор, уникальный номер);
2. Элемент схемы тестов (номер в той схеме с требованиями);
3. Предыдущее состоние (состояние системы до теста);
4. Входные данные (что мы, собственно, делаем);
5. Ожидаемые результаты (что должна делать система);
6. Реальные результаты (что в итоге она делает).
Отмечу, что при тестировании сайта (собственный опыт) предыдущее состояние не важно, зато важна последовательностей действий перед входными данными (впрочем, вся последовательность может включатся в "входые данные").
Упрощенный формат документации имеет место быть, однако только при условии, что никому, кроме вас не придется ею пользоваться в полной мере (не привлекаются новые сотрудниик и аудиторы). Упрощать схему можно как удобно тестеру, некоторые примеры рассмотрены в книге, мне же приводить их лень - все равно если мы захотим упростить тесты "под себя" мы их упростим так, как удобно нам самим.
Для фиксации очень удобны электронные таблицы.
понедельник, 8 августа 2011 г.
Конспект-3
Глава next. С одной стороны условия тестирования упрощаются (времени уже не в обрез), но документация все еще в плохом виде; с другой - усложняется - теперь подход должен быть шире. Используется схематический подход к фиксации требований. Потом даются категории тестов:
1. Нет данных (что случится, если не ввести данные; есть ли значение по умолчанию);
2. Повторный ввод данных (быстрая отправка одних и тех же данных - как поведет себя система - игнорирует повторный ввод, возьмет только последние данные, обработает как независимые данные, вернет сообщение об ошибке);
3. Верные данные (диапазон, граничные значения);
4. Неверные данные (выход за границы диапазона, неверный формат данных);
5. Сброс (кнопка "отмена" или выдернуть кабель: как отреагирует система);
6. Потери мощности (актуально для ПО техники);
7. Создание напряжений в системе;
8. Тестирование характеристик.
Далее все типы применяются к схеме с требованиями.
1. Нет данных (что случится, если не ввести данные; есть ли значение по умолчанию);
2. Повторный ввод данных (быстрая отправка одних и тех же данных - как поведет себя система - игнорирует повторный ввод, возьмет только последние данные, обработает как независимые данные, вернет сообщение об ошибке);
3. Верные данные (диапазон, граничные значения);
4. Неверные данные (выход за границы диапазона, неверный формат данных);
5. Сброс (кнопка "отмена" или выдернуть кабель: как отреагирует система);
6. Потери мощности (актуально для ПО техники);
7. Создание напряжений в системе;
8. Тестирование характеристик.
Далее все типы применяются к схеме с требованиями.
пятница, 5 августа 2011 г.
Конспект-2
Все еще касаясь тестирования в экстримальных условиях. Наброски этапов:
1. Базовый тест. Контакт с авторитетным лицом проекта (только этао самаяое морда лицо может прояснить технические моменты; короче юзать вместо документации)
2. Оценка правдивости результирующих данных (вариации со входными - при условии, что нет схемы расчета). Иметь ввиду, что резкие скачки результирующих данных могут быть следствием пороговых значений.
3. Инвентаризация (правильность типов данных), анализ пунктов меню (доступных для выбора). Удерживая одно из начальных значений постоянным, варьируем другое по всем возможным значениям.
4. После исправлений необходимо прогнать программу по тем же базовым тестам (преварительно зафиксированным). Наращиваемый подход в создании тестовых ситуаций (сначала - изолированный, потом - наращиваемый)
5. Граничные оценки. при тестрировании границ - три тестовых примера (само граничное значение, гр. знач-е +1, гран-е значение -1)
6. Ошибочные данные (ожидается, что програма отловит эти данные и вернет сообщение об ошибке)
7. Создание напряжений (поставить систему в невыносимые условия - урезать память, параллельно запустить несколько приложений, разъединение кабелей и т.п.) в системных ресурсах.
1. Базовый тест. Контакт с авторитетным лицом проекта (только эт
2. Оценка правдивости результирующих данных (вариации со входными - при условии, что нет схемы расчета). Иметь ввиду, что резкие скачки результирующих данных могут быть следствием пороговых значений.
3. Инвентаризация (правильность типов данных), анализ пунктов меню (доступных для выбора). Удерживая одно из начальных значений постоянным, варьируем другое по всем возможным значениям.
4. После исправлений необходимо прогнать программу по тем же базовым тестам (преварительно зафиксированным). Наращиваемый подход в создании тестовых ситуаций (сначала - изолированный, потом - наращиваемый)
5. Граничные оценки. при тестрировании границ - три тестовых примера (само граничное значение, гр. знач-е +1, гран-е значение -1)
6. Ошибочные данные (ожидается, что програма отловит эти данные и вернет сообщение об ошибке)
7. Создание напряжений (поставить систему в невыносимые условия - урезать память, параллельно запустить несколько приложений, разъединение кабелей и т.п.) в системных ресурсах.
четверг, 4 августа 2011 г.
Конспект
Итак, у Тамре все же понятнее. По крайней мере, мне. Вполне допускаю, что кому-то больше подойдет Савин и вообще я еще не сбрасываю его со счетов, однако после прочтения 20 страниц Тамре в мозгу уже появилась схема простейшего тестрирования.
Вкратце - если у вас есть программка, нет документации, и очень сжатыеочко сроки - первое, что вам нужно сделать - прогнать ее (после визуального ознакомления, разумеется) на простейшие функции. В примере разобран налоговый калькулятор - вот его и проверяем, вводя начальные (для простоты их минимум) данные. Результат на самом деле - отрицательный (программа считает неверно) или положительный - это уже первая веха. Если результат отрицательный (ну вообще неправильно считает) - не спешите бежать к программистам с криком: "Ваше детище никуда не годно!". Во-первых, проверьте еще раз - правильно ли вы ввели исходные данные, не было ли нигде опечатки (было бы несправедливо обвинять программистов в собственной невнимательности), не связано ли это с аппаратными конфигурациями (в ситуации, когда ошибка не воспроизводится на другой машине). Во-вторых, у вас есть уникальная возможность поковрять программку на дополнительные стрессовые ситуации (неправильные начальные данные, юзабилити и пр) и отнести на доработку сразу пакетик с багами. Согласитесь, куда неудобнее носится из-за каждого отдельно. Если же базовый тест пройден успешно - он (не даром базовый) станет для вас платформой для написания последующих (с расширенным набором начальных данных, к примеру). Так что, повторюсь, базовый тест - это первый и важный шаг, который нельзя недооценить.
Вкратце - если у вас есть программка, нет документации, и очень сжатые
Продолжение ознакомления с литературкой
Я не могу читать Савина дальше. Это какой-то писец - возможно, за примерами я полезу, но читать общие положения невозможно. Плохой перевод - и больше у меня слов нет. Есть удачные мыли и аналогии, но в целом это кошмарно. Взялась за Тамре ("Введение в тестирование программного обеспечения") - намного лучше. Смотрите, какая прелесть: "Автору часто приходилось сдерживаться, чтобы не высказать менеджерам проекта свое негодование: "Требования [техническое задание, необходимое тестировщику как отправная точка] совсем никуда не годятся и мы не можем продуктивно проводить тестирование до тех пор, пока вы не проясните ситуацию". В действительности эта фараза обычно содержит непечатные идиоматические выражения и произносится под чьи-то вздохи...". Переводчик тоже не без чувства юмора. В общем, пока мне больше нравится эта книга. И не только наличием юмора на первых же страницах - она логична и целостна, чего не скажешь о Савине. Посмотрим, что дальше.
вторник, 2 августа 2011 г.
Еще полезные ссылки
http://www.quizful.net/interview/qa - вопросы по собеседованию
http://www.quizful.net/test - тесты проверки знаний
http://www.quizful.net/test - тесты проверки знаний
Ознакомление с литературой по сабжу
Начала читать Савина "Тестирование дот.ком...". Впечатления пока двоякие - вроде автор пытается писать неакадемическим языком, но получается слишком топорно. Такое впечатление, что читаешь плохой перевод. Даже академические тексты, правильно и грамотно написаные, читаются легче. Ну, к примеру:
Рассмотрим, что объединяет следующие ситуации.
1. Девушка рекламирует себя как хорошую, на все руки хозяйку, а утром выясняется, что она даже яичницу пожарить не в состоянии.
2. Вы купили книгу по интернет-тестированию, а в ней рассказывается о приготовлении яичницы.
3. Девушка из пункта 1 прочитала книгу из пункта 2, но яичница пересолена.
Если возвыситься над яичницей, фигурирующей в каждом из трех пунктов, и абстрагироваться от женщин, карт и вина, то мы увидим, что общее — это отклонение фактического от ожидаемого.
Разбор ситуаций.
1. Ожидаемый результат -— девушка умеет готовить.
Фактический результат — утро без завтрака.
2. Ожидаемый результат — знания по тестированию.
Фактический результат — знания по кулинарии.
3. Ожидаемый результат — яичница будет приготовлена.
Фактический результат — еще одно утро без завтрака.
Вообще, это о чем?! Что есть баг, и что им не является, автор уже дал вполне понятное описание, так нет же, он решил еще пожевать резины и приплел сюда ситуации с параллелями, но неясно как относящиеся к т.н. багам. Такое впечатление, что автор хотел что-то сказать о возможной скопенсированности багов, но как-то все скомкал и просто свел сложную конструкцию к отдельным случаям. И таких фраз "их есть у меня". Право - плохой перевод, да и только. Или взять термин "спецификация". Цитирую:
Спецификация (или spec — читается "спек". Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Конец цитаты.
А я всегда думала, что тестировщики обычно отталкиваются от технического задания, по которому, собственно, пишется программа, и начинают ее тестить чем раньше, тем лучше.
Ладно, добавлю и пару ополовников мёда - автор честно пытается говорить просто о сложном. Почитаем дальше - увидим что там не только с терминологией, но и с частными случаями (проблемы и их решения).
Рассмотрим, что объединяет следующие ситуации.
1. Девушка рекламирует себя как хорошую, на все руки хозяйку, а утром выясняется, что она даже яичницу пожарить не в состоянии.
2. Вы купили книгу по интернет-тестированию, а в ней рассказывается о приготовлении яичницы.
3. Девушка из пункта 1 прочитала книгу из пункта 2, но яичница пересолена.
Если возвыситься над яичницей, фигурирующей в каждом из трех пунктов, и абстрагироваться от женщин, карт и вина, то мы увидим, что общее — это отклонение фактического от ожидаемого.
Разбор ситуаций.
1. Ожидаемый результат -— девушка умеет готовить.
Фактический результат — утро без завтрака.
2. Ожидаемый результат — знания по тестированию.
Фактический результат — знания по кулинарии.
3. Ожидаемый результат — яичница будет приготовлена.
Фактический результат — еще одно утро без завтрака.
Вообще, это о чем?! Что есть баг, и что им не является, автор уже дал вполне понятное описание, так нет же, он решил еще пожевать резины и приплел сюда ситуации с параллелями, но неясно как относящиеся к т.н. багам. Такое впечатление, что автор хотел что-то сказать о возможной скопенсированности багов, но как-то все скомкал и просто свел сложную конструкцию к отдельным случаям. И таких фраз "их есть у меня". Право - плохой перевод, да и только. Или взять термин "спецификация". Цитирую:
Спецификация (или spec — читается "спек". Далее употребляется в мужском роде) — это детальное описание того, как должно работать ПО. Конец цитаты.
А я всегда думала, что тестировщики обычно отталкиваются от технического задания, по которому, собственно, пишется программа, и начинают ее тестить чем раньше, тем лучше.
Ладно, добавлю и пару ополовников мёда - автор честно пытается говорить просто о сложном. Почитаем дальше - увидим что там не только с терминологией, но и с частными случаями (проблемы и их решения).
Подписаться на:
Сообщения (Atom)