Всем привет-привет!Сегодня очередная пятница, а значит пришло время для очередного выпуска Test It. И сегодня мы поговорим о том, как сдавать программу заказчику.
Вот ded пишет:
"Здравствуйте.
Мы занимаемся разработкой программного обеспечения для телевизионных приставок. Компания - интернет/ктв провайдер.
Сейчас идет продвижение IPTV, приставки ставим нашим абонентам. Перед выпуском новой версии проверку осуществляет служба тех. поддержки. Однако план проверки отсутствует и не ясно можно ли доверять их результатам. Мы взялись за то чтобы создать план проверки новой версии.
Чего хотим этим добиться:
Находить ошибки раньше конечных пользователей, до выхода новой версии
Включить в процесс разработки еще и внутренне тестирование(внутри группы разработки, но занимаются не программисты)
Вопросы:
Как описать и сгруппировать тестовые сценарии в наборы?
Как организовать процесс тестирования и разработки?
Как организовать приемо-сдаточное тестирование"
Наверное, это самый животрепещущий вопрос: а как сделать, чтобы пользователи не нашли ошибки.
Если человек будет сегодня читать, то у меня тоже есть сразу вопрос: группы тестирования до этого не было, если идёт вопрос о том, как описать и сгруппировать тестовые сценарии в наборы?
Как по мне, самый удобный тестовый набор это тот, который полностью описывает действие пользователя. Банальнейший пример: зашел на сайт - выбрал товар - перешел в корзину - решил, что надо больше - решил, что вообще одной штукой обойдется - решил оплачивать - передумал. И так далее.
Естественно, на каждом этом шаге проверяется ещё куча всего вспомогательного. Например, на шаге "решил, что надо больше", можно проверить и целые, и отрицательные, и дробные числа, а также буквы и спец. символы. А описывать можно как хочешь. Кто-то каждый шаг пишет:
1. Ввести поле "логин" admin
2. Ввести в поле "пароль" 12345
Ожидание - пользователь перейдет в личный кабинет.
А можно написать чек-листом:
Проверка логина:
1. Корректные данные
2. Некорректные данные
3. Пустые значения.
Конечно, это всё утрированно сейчас. Но принцип, надеюсь понятен?
По поводу процесса тестирования и разработки. За разработку не скажу, конечно, но процесс тестирования должен быть организован до того, как будет готова программа :) Пока программисты пишут, мы, тестировщики, должны подготовить тестовые сценарии, помучить программистов и аналитиков, почитать т.з., чтобы при передаче нам программы, начинать тестирование сразу же, а не тратя время на разбор. Времени и так не хватает.
По поводу приёмо-сдаточных испытаний. На самом деле, не так всё страшно, как кажется. В первую очередь, это надо иметь такое же "железо", что у заказчика. Иначе смысла не будет. У меня был случай, когда программа прекрасно работала на 7ке, но у конечного заказчика была Виста. И там стало всё-всё-всё плохо. Для того, чтобы избежать таких ситуаций, изначально надо уточнять, на чём будет работать программа. И постараться это приобрести. Хотя бы виртуалки. На самом деле, эти все моменты обговариваются в ТЗ. Поэтому с выяснением проблем не должно быть.
Ну и соответственно, какие тесты должны выполняться при приёмо-сдаточных испытаниях? Понятно, что вроде должно работать абсолютно всё. И никакие апострофы не должны ломать программу. Но тут уже из того набора, что был раньше (на котором программа тестировалась и в хвост, и в гриву) выбираются те, которые наиболее типичны для пользователя. Например, вряд ли нормальный пользователь (если это не тестировщик, конечно же) будет вводить в поле все символы в имени или 150%. Эти моменты должны быть протестированы раньше. В приёмо-сдаточное остаётся только ввод 45%, например. Или имя обыкновенной средней длины.
Обычно, кстати, вот эти тесты согласовываются с заказчиком. Иначе может быть большая проблема. И приёмо-сдаточные, опять же, в основном, проводятся на стороне заказчика. Но чтобы быть уверенным, что всё будет хорошо, надо иметь такой же набор тестов. И прогонять по нему перед тем, как отгружать программу.
Я уверена, что в Вашей тех. поддержке есть хоть что-то, издали напоминающее тестовые наборы. Попробуйте у них попросить? На их основе будет проще составлять те тесты, которые должны проходить в отделе при разработке.
Все вопросы и предложения можно оставлять в комментариях. Кстати, а как у кого приёмочные тесты проходят?
Ну и нам можно писать по следующему адресу
Бывает по-разному. Редко ( к сожалению ), когда согласованный набор тестов идет сразу с ТЗ, чаще - план ПСИ составляется непосредственно перед внедрением и зачастую без участия заказчика. Они, как часто показывает практика, стараются устраниться от подобных согласований, тем самым делая хуже прежде всего самим себе )... Исходным материалом для составителя ПСИ являются требования, методики тестирования (выходной результат группы тестирования), замечания и пожелания заказчика.
ОтветитьУдалить