Test It! Про приёмо-сдаточные испытания

Всем привет-привет!
Сегодня очередная пятница, а значит пришло время для очередного выпуска Test It. И сегодня мы поговорим о том, как сдавать программу заказчику.

Вот ded пишет:

"Здравствуйте.
Мы занимаемся разработкой программного обеспечения для телевизионных приставок. Компания - интернет/ктв провайдер. 
Сейчас идет продвижение IPTV, приставки ставим нашим абонентам. Перед выпуском новой версии проверку осуществляет служба тех. поддержки. Однако план проверки отсутствует и не ясно можно ли доверять их результатам. Мы взялись за то чтобы создать план проверки новой версии.
Чего хотим этим добиться:
    Находить ошибки раньше конечных пользователей, до выхода новой версии
    Включить в процесс разработки еще и внутренне тестирование(внутри группы разработки, но занимаются не программисты)

Вопросы:

    Как описать и сгруппировать тестовые сценарии в наборы?
    Как организовать процесс тестирования и разработки?
    Как организовать приемо-сдаточное тестирование"

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

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

1. Ввести поле "логин" admin
2. Ввести в поле "пароль" 12345
 Ожидание - пользователь перейдет в личный кабинет.

А можно написать чек-листом:
Проверка логина:
1. Корректные данные
2. Некорректные данные
3. Пустые значения.

Конечно, это всё утрированно сейчас. Но принцип, надеюсь понятен?

По поводу процесса тестирования и разработки. За разработку не скажу, конечно, но процесс тестирования должен быть организован до того, как будет готова программа :) Пока программисты пишут, мы, тестировщики, должны подготовить тестовые сценарии, помучить программистов и аналитиков, почитать т.з., чтобы при передаче нам программы, начинать тестирование сразу же, а не тратя время на разбор. Времени и так не хватает.

По поводу приёмо-сдаточных испытаний. На самом деле, не так всё страшно, как кажется. В первую очередь, это надо иметь такое же "железо", что у заказчика. Иначе смысла не будет. У меня был случай, когда программа прекрасно работала на 7ке, но у конечного заказчика была Виста. И там стало всё-всё-всё плохо. Для того, чтобы избежать таких ситуаций, изначально надо уточнять, на чём будет работать программа. И постараться это приобрести. Хотя бы виртуалки. На самом деле, эти все моменты обговариваются в ТЗ. Поэтому с выяснением проблем не должно быть.
Ну и соответственно, какие тесты должны выполняться при приёмо-сдаточных испытаниях? Понятно, что вроде должно работать абсолютно всё. И никакие апострофы не должны ломать программу. Но тут уже из того набора, что был раньше (на котором программа тестировалась и в хвост, и в гриву) выбираются те, которые наиболее типичны для пользователя. Например, вряд ли нормальный пользователь (если это не тестировщик, конечно же) будет вводить в поле  все символы в имени или 150%. Эти моменты должны быть протестированы раньше. В приёмо-сдаточное остаётся только ввод 45%, например. Или имя обыкновенной средней длины.
Обычно, кстати, вот эти тесты согласовываются с заказчиком. Иначе может быть большая проблема. И приёмо-сдаточные, опять же, в основном, проводятся на стороне заказчика. Но чтобы быть уверенным, что всё будет хорошо, надо иметь такой же набор тестов. И прогонять по нему перед тем, как отгружать программу.

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

Все вопросы и предложения можно оставлять в комментариях. Кстати, а как у кого приёмочные тесты проходят?
Ну и нам можно писать по следующему адресу

Приём-приём :)

Я тут потерялась немного. Всё потому, что очень затягивает моя нынешняя жизнь и работа фрилансером :) Особенно, когда находишься не там, где холодно и снег в апреле лежит, а там, где температура +30 и солнце светит постоянно :)

Все, кстати, помнят, что с понедельника стартует ConfetQA? И первая в этот раз будет FunConfetQA под руководством Тани Зинченко? )

Кстати, там я расскажу, как я дошла до жизни такой. В смысле, как я ушла на фриланс и чем теперь занимаюсь.

А ещё вчера у Тани был очередной выпускной в Курсе практического тестирования. В наших рядах тестировщиков прибыло. И даже некоторые уже нашли работу (вот так вот)

Вчера тоже выступала, кстати. Вообще, забавно. Ещё осенью я писала пост о том, что я не знаю, правильно ли я работаю с ТЗ. Потом в комментариях я убедилась, что, в принципе, в некоторых вопросах я палку перегибаю, но работаю так, как надо всё же. Меня до сих пор удивляет, как я до некоторых вещей дошла сама. Вот где была Таня с её курсами 5ть лет назад?)

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

Ну вот как-то и закончились новости пока что. До понедельника :)
Санук!