Вопросы на которые отвечает ревью:
- Правильно ли выставлено плановое время?
- под плановым временем понимается время выставленное тест-дизайнером для прохождения конкретного тест-кейса одним манки-тестером
- Есть ли завязка на другие кейсы?
- ...
- Наличие и понятность начальных условий.
- это особенно важный момент, т.к. система находящаяся в разных состояниях на момент начала прохождения тест-кейса может выдавать разные результаты, хотя это зависит от конкретной системы
- Понятность не подготовленному сотруднику…
- тут всё зависит от того, кто проходит тест-кейсы и каков уровень этих сотрудников по отношению к уровню тест-дизайнеров, т.е. если манки вовсе не манки, а хорошо знающие функционал системы сотрудники, то для них разжёвывания в тест-кейсах только в минус, соответственно если манки именно манки, то...
- Есть зацикливание? – обороты вида "…проверяем шаги 1-3…
- украдено: Это миф. Тест кейс зацикливать нельзя. То есть писать «Repeat steps 1-3» не стоит. А собственно почему? Только потому, что это прерывает последовательность шагов? Вот фигня то. Тест кейс – это обычный сценарий действий, и если действительно нужно повторить шаг с первого по третий, то почему бы не повторить? Но вот если шаг 1-3 говорит о том, что действие надо сделать с объектом «А», а нужно повторить эти шаги для объекта «Б», тогда придется писать эти шаги снова, но уже для объекта «Б». Так же придется делать, если количество шагов больше семи (магическая цифра, найденная психологами или психиатрами).
- Полнота проверки (возможно пропущенные тестовые ситуации).
- действуем по принципу "одна голова хорошо, а две лучше"
- И напоследок, руководитель проведя ревью сможет оценить эффективно ли потрачено время
Как и прежде, буду рад комментариям и критике...
Про пункт 6 всё понятно, про пункт 3 тоже. А про все остальные не понял -- зачем? Если мы получим ответы на эти вопросы, что дальше делать с этой информацией?
ОтветитьУдалитьПункт 4 вверг в ступор. Какая разница кто проходит кейс? Кейс в любом случае должен быть понятным и разжеванным. К примеру, сейчас его проходит мега гуру тестер, завтра он ушел в запой и этот кейс передали манки-кликеру. Ну или ситуация в точности да наоборот...
ОтветитьУдалитьА вообще, мне кажется все можно свести к 2-3 ем пунктам:
1. Наличие и понятность начальных условий
2. Полнота и понятность шагов и проверок
Ну и более общий пункт:
- полнота покрытия тестируемого функционала, предоставленным набором тест кейсов.
Вот.
по пункту 5. Зацикливание может сыграть злую шутку в долговременной перспективе. Если однажды продукт изменится, и соответсвенно изменятся шаги тескейса, фраза "Repeat steps 1-3" может получить совершенно новое звучание.
ОтветитьУдалитьВообще, имеет смысл сразу подумать, как массив тесткейсов будет поддерживаться в будущем - изменения, взаимосвязи и т.д. Если этот вопрос уже решен или неактуален - тем лучше :)
По поводу правильности планового времени - время затраченное на тесткейс зависит от многих факторов и в разных ситаациях может отличаться в разы. Не уверен, что этот пункт даст полезную информацию о самих тесткейсах. Тут важен размер выборки.
По пункту 4 - немного возражу Алексею Булату. Можно писать "high-level" тесткейсы для человека знакомого с продуктом, не указывая точные пути в интерфейсе и т.п. Новичок с такими тесткейсами скорее всего с наскоку не справится. То есть конечно понятность - ключевой момент, но тут важно понять: понятность кому, на какой уровень мы рассчитываем?
Ну и по пункту 7 - непонятно, эффективность использования чего планируется оценивать: времени, потраченного на ревью? на тестирование? Если первое, то неясно, как делать вывод на основе предыдущих пунктов. Если второе - то оценивать эффективность на основе только ревью тесткейсов странная идея :)
2Алексей Булат
ОтветитьУдалитьНу смотрите, до недавнего времени, в отделе не было неопытных сотрудников и расписывать тест-кейсы смысла не было - это пустая трата времени, сейчас есть необходимость разжёвывать и поэтому необходимо этот пункт контролировать... В принципе ситуация похожа на Вами описанную, с тем лишь моментом, что тест-кейсы мы не поддерживаем в актуальном состоянии и поэтому если в конкретный момент времени они готовились для опытных, то их и писали без разжёвывания, а если надо писать для "манки", то и пишем мы их соответственно.
2Alexei Barantsev
1. Плановое время - это время которое должен потратить на тест-кейс тестировщик, в том числе по нему мы планируем работу, поэтому и контралируем.
2. Стараемся по возможности избавиться от вариантов "чтобы пройти этот кейс Вам необходимо пройти ТС1 и ТС5"
4. Об этом написал выше
5. Прохожу я кейс, прошёл один набор шагов с объектом "А", и тут шаг в котором написано пройдите для объекта "Б" шаги 1-5, я прохожу и фэйлю тест-кейс... дальше, если этот тест-кейс будет проходить другой человек, ему может быть не совсем понятно на каком именно шаге обвалилась программа, или стоит ли все шаги проходить или можно обойтись одним из связки 1-5...
7. На написание заложено конкретное время, если дизайнер в него не укладывается и результаты ревью слабые - это дополнительный момент подтверждающий необходимость принять меры...
Примерно так...
2Анонимный
ОтветитьУдалитьНе узнаю Вас в гриме... :)
По пункту 5. Изначально именно из поддержания и постоянных изменений было принято решение использовать меньше связей и зацикливаний.
Плановое время. Ну почему же, исходя из опыта и "похожести" функционала системы можно достаточно точно указать время на прохождение.
Ну и по пункту 7. Простите... не дописал :) эффективность потраченного на написание времени.
Анонимный, пример свой я привел из жизни, и поверьте никто мне спасибо не сказал за High Level тест кейсы (мораль такова: "все нужно делать по науке, чтобы потом не было стыдно за зря прожитые годы"). А вот если у вас тестер - это эксперт в предметной области, да еще и с продуктом на "ТЫ", то я бы вообще усомнился бы с надобности тест кейсов :) переходите на Exploratory Testing и не тратьте время попусту.
ОтветитьУдалить2 Сергуня McKenzie:
"тест-кейсы мы не поддерживаем в актуальном состоянии"... Хм... А зачем их тогда писать, если их потом не поддерживать??? Ну да ладно, "Бах" вам судья... :)
Так вот получилось, что тест-кейсы не актуализируются... хотя после прохождения руками они автоматизируются и авто-тесты уже поддерживаются, поэтому по сути тест-кейсы нет смысла держать в порядке.
ОтветитьУдалитьПо поводу Exploratory, ну а если объёмы функционала большие и постоянно растут, ручным тестировщикам некогда изучать ТЗ и "исследовать"...