Перейти к содержимому

Фотография

Тестирование проекта


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 15

#1 alexdfry

alexdfry

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Алекс Джонатан Фрай

Отправлено 27 октября 2010 - 18:18

Добрый день уважаемые господа тестировщики :)
Некоторое время назад я решил вступить в ваши ряды имея за плечами небольшой
опыт программирования...
После получения теста на вакансию я немного удивился....ведь получил описание того как работает
проект...я привык работать с чем-то что можно "поклацать"....а тут надо создать несколько тестовых кейсов и ожидаемый результат имея только System Requirements Specification О_О

Как надо поступать в таких случаях? о_о
  • 0

#2 frei_by

frei_by

    Постоянный участник

  • Members
  • PipPipPip
  • 177 сообщений
  • ФИО:Дмитрий

Отправлено 27 октября 2010 - 20:18

Да тебе ещё повезло крупно. Я в 60% сначала получаю программу, потом сам на неё SRS пишу, потом с этогол SRS план, потом тесты, а потом сам эти тесты выполняю.
Плюс ещё приходится рекомендации по исправлению ошибок вёрстки писать со ссылками на источники доп информации.
+ если баг забористый и требует доработки - приходится для програмистов писать требования к реализации доработки.
  • 0

#3 alexdfry

alexdfry

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Алекс Джонатан Фрай

Отправлено 27 октября 2010 - 20:20

Да тебе ещё повезло крупно. Я в 60% сначала получаю программу, потом сам на неё SRS пишу, потом с этогол SRS план, потом тесты, а потом сам эти тесты выполняю.
Плюс ещё приходится рекомендации по исправлению ошибок вёрстки писать со ссылками на источники доп информации.
+ если баг забористый и требует доработки - приходится для програмистов писать требования к реализации доработки.


но ведь ты получаешь программу....а у меня только srs....и не понятно как там все реализовано О_О
  • 0

#4 frei_by

frei_by

    Постоянный участник

  • Members
  • PipPipPip
  • 177 сообщений
  • ФИО:Дмитрий

Отправлено 27 октября 2010 - 20:58

Если по SRS не понятно как будет реализовано - то это не очень хорошее SRS мне таккажется...
  • 0

#5 alexdfry

alexdfry

    Новый участник

  • Members
  • Pip
  • 3 сообщений
  • ФИО:Алекс Джонатан Фрай

Отправлено 27 октября 2010 - 21:43

а есть какие-нибудь примеры создание тестовых случаев (test cases) на основании одного лишь srs?
  • 0

#6 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 27 октября 2010 - 23:16

Мне кажется, вы по-разному толкуете фразу "непонятно как будет реализовано": alexdfry говорит о технической составляющей, а frei_by - с точки зрения пользователя.

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

Советую подучить матчасть. Если с английским нормально, то начать можно с общей методологии (Ron Patton - "Software Testing") и продолжить подходами к созданию тестов (Lee Copeland - "Guide to Software Test Design").

А вообще, мне кажется, что навык абстрагироваться от UI и конкретики реализации - это очень важный навык, особенно для создания тестового набора.
  • 0

#7 frei_by

frei_by

    Постоянный участник

  • Members
  • PipPipPip
  • 177 сообщений
  • ФИО:Дмитрий

Отправлено 28 октября 2010 - 06:46

Как-бы я считаю что есть стандарт на SRS - IEEE 830-1998,
вот хотя-бы в таком виде:
русский перевод IEEE 830-1998
Конечно ушлые разработчики могут под видом SRS подсунуть всё что угодно. Они, как правило такие доки, не читают.

Там в SRS как правило есть раздел функции изделия, либо в виде use cases либо в виде списка, либо в виде рисунка интрефейса, либо ещё в каком нибудь вдие.
Написать для чего нужна программа и что она должна делать - ну даже если такого не написано то это вообще не SRS.

По технической составляющей - если это web то подразумевается что http + html, если приложение - то всё равно подразумевается какая-то библиотека окошек.

И соотв. чем более детальное описание, тем более проще созавать тесты.
Например:
вчера букавально пришло SRS в духе -
Введение - (одна строка) -
"Для управление компаниями по продвижению ... необходимо создать модуль "
А дальше одна старница типичного use case как нужно добавить компанию по продвижению,
и ещё две страницы описания интерфейса.
Модуль ещё не разработан.

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

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

#8 frei_by

frei_by

    Постоянный участник

  • Members
  • PipPipPip
  • 177 сообщений
  • ФИО:Дмитрий

Отправлено 28 октября 2010 - 07:19

а есть какие-нибудь примеры создание тестовых случаев (test cases) на основании одного лишь srs?

Запостите SRS мы вам составим тесткейсов.
  • 0

#9 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 28 октября 2010 - 07:23

Как-бы я считаю что есть стандарт на SRS - IEEE 830-1998,
вот хотя-бы в таком виде:
русский перевод IEEE 830-1998

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


Спасибо за стандарт (слабость моя, да..затащила в свою папочку Стандарты)!
Если есть спецификация - так это ж счастье Ваше!
Что делать? Я бы так поступила.
1. Проработала спецификацию. Тщательнейшим образом. С тем чтоб найти мутные места:
- места, где есть явные противоречия,
- места, где невнятица/неодназначность - что должен делать проект.
Все такие места - взяла на заметку - отметила/пометила, по возможности постаралась бы прояснить ситуацию. При тестировании - на эти места обратила бы особое внимание.
2. Параллельно с поиском таких мест - прикидывала - как проверять все написанное в спецификации.
По возможности записывала бы - пусть сокращенно.

Пример. У меня в проекте сейчас есть некий параметр (назовем его кренделем ), изменять который можно с помощью кнопки (железной), ручки-крутилки (железной) и может еще что появится. Управлять кренделем в одних случаях пользователь может, в других - нет.
Проверять правильность отработки ПО этого кренделя надо? Да!
Поэтому
1. Правильность отработки кренделя
1.1. Управление кренделем с помощью.... (ежели - знаем.., нет - ну и пусть многоточие ПОКА!)
1.2. Управление кренделем с помощью....
и т.д.
2. Возможность управления кренделем в ситуации 1 .... (и сколько там вариантов?)

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

Вот как-то так.
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#10 Arel

Arel

    Новый участник

  • Members
  • Pip
  • 18 сообщений
  • ФИО:Джина Шев
  • Город:Kyiv


Отправлено 28 октября 2010 - 14:05

Я вот не пойму вообще, в чем проблема. Кто-то жалуется, что ему дают программу и не дают требования. Кто то что дают требования и не дают программу. Так вот второй вариант по-моему намного лучше. Потому что программу уж точно кто то напишет. =)) Нам тоже часто дают требования со словами ребята почитайте, может, что не так и подумайте на тест кейсами. Ну и отлично читаем и параллельно представляем что и как будем тестировать. (конечно если сказали написать тест кейсы, тогда свои представления оформляем, заодно оформляя ошибки в этих самых требованиях =)). Обычно одно требование – это 1-2 тест кейса. Если новая функция сохраняет нужный объект в двух форматах, какой тест кейс? Сохранить в одном формате, проверить что сохранилось. Второй тест кейс сохранить во втором формате, проверяем.. Можно объединить в один кейс. Ну а дальше все зависит от твоей фантазии. (граничные значения, классы эквивалентности, функциональное тестирование, тестирование безопасности, тестирование интерфейса и т.д.) Какие из требований имеют больший приоритет и т.д. Работа тестировщика не только клацать по кнопкам, как думают некоторые.. =))))
  • 0
"Это можно сделать ещё лучше"

#11 Undi

Undi

    Активный участник

  • Members
  • PipPip
  • 134 сообщений
  • Город:Kiev

Отправлено 28 октября 2010 - 21:17

Да тебе ещё повезло крупно. Я в 60% сначала получаю программу, потом сам на неё SRS пишу, потом с этогол SRS план, потом тесты, а потом сам эти тесты выполняю.Плюс ещё приходится рекомендации по исправлению ошибок вёрстки писать со ссылками на источники доп информации. + если баг забористый и требует доработки - приходится для програмистов писать требования к реализации доработки.

но ведь ты получаешь программу....а у меня только srs....и не понятно как там все реализовано О_О

Если по SRS не понятно как будет реализовано - то это не очень хорошее SRS мне таккажется...


Как будет реализована какая-то фича (кнопочками, меню, комбобоксом или еще чем-то) тестировщика на этом этапе не волнует. "Как" - это проблемы разработчиков и их документации. Задача SRS - описать ЧТО должно быть, а не как. Например: "сумма должна отображаться в окне". А в каком гриде она будет отображаться - это к девелоперам и дизайнерам.
Тесты пишутся по SRS в идеальном случае, до первой версии продукта. Это позволяет во-первых получить тесты и сразу по ним тестировать, во-вторых максимально покрыть функциональность тестами без привязки к реализации.


у меня только srs....и не понятно как там все реализовано

Слова программиста, а не тестировщика :) Вам нужно тесты писать или в коде разбираться? :)

alexdfry, а не дали ли Вам задачу про стороны треугольника? :) очень уж любят ее на собеседованиях.
Вот здесь в средине текста есть описание: http://window.edu.ru...2txt?p_id=22383
  • 0

#12 Natalya Rukol

Natalya Rukol

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 2 001 сообщений
  • Город:Moscow


Отправлено 29 октября 2010 - 04:56

Так вот второй вариант по-моему намного лучше. Потому что программу уж точно кто то напишет. =))

:good:
  • 0

#13 Pryanik

Pryanik

    Постоянный участник

  • Members
  • PipPipPip
  • 214 сообщений
  • Город:МОСКВА

Отправлено 29 октября 2010 - 06:05

Добрый день уважаемые господа тестировщики :)
Некоторое время назад я решил вступить в ваши ряды имея за плечами небольшой
опыт программирования...
После получения теста на вакансию я немного удивился....ведь получил описание того как работает
проект...я привык работать с чем-то что можно "поклацать"....а тут надо создать несколько тестовых кейсов и ожидаемый результат имея только System Requirements Specification О_О

Как надо поступать в таких случаях? о_о

Я думаю у вас все-таки не SRS, а BRS(Business Requirement Specification), потому как SRS это скорее требование к "железу" (но это впринципе неважно как назвать).
Примеры можно посмотреть тут и описание к подходу тут.
  • 0

#14 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 29 октября 2010 - 06:32

Пожалуй что появились еще темы для обсуждения.
1. Коммуникация тестировщик - авторы SRC.
2. Как фиксировать баги в SRC (спецификации, требованиях к ПО)
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....

#15 frei_by

frei_by

    Постоянный участник

  • Members
  • PipPipPip
  • 177 сообщений
  • ФИО:Дмитрий

Отправлено 29 октября 2010 - 08:03

Как фиксировать баги в SRC (спецификации, требованиях к ПО)


Да известно на самом деле, вопрос в том как сделать так чтобы эти баги ещё и фиксились...
  • 0

#16 Фрося

Фрося

    Специалист

  • Members
  • PipPipPipPipPip
  • 514 сообщений
  • ФИО:Радилова Елена Игоревна

Отправлено 29 октября 2010 - 08:23

Как надо поступать в таких случаях? о_о

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

При этом - исправления в тесты вносить конечно приходиться, но!
гораздо проще, чем писать с "чистого листа".
  • 0
Почему-то по пятницам особо остро хочется быть блондинкой....


Количество пользователей, читающих эту тему: 1

0 пользователей, 1 гостей, 0 анонимных