(с) Коллективный автор.
План проверки двери
1. Функциональные проверки.
1.1. Проверить, что дверь открывается.
1.2. Проверить, что дверь закрывается.
1.3. Попытаться закрыть уже закрытую дверь.
1.4. Попытаться открыть уже открытую дверь.
2. GUI (интерфейс пользователя)
2.1. Проверить табличку на двери.
2.2. Проверить покраску двери.
2.3. Проверить наличие дверной ручки.
3. Permissions
3.1. Проверить, что правильным ключом дверь открывается.
3.2. Проверить, что неправильным ключом дверь не открывается.
3.3. Проверить, что закрытую на ключ дверь нельзя открыть.
3.4. Проверить, что не закрытую на ключ дверь можно открыть без ключа.
3.4. Позвонить в дверь. Если там никого нет, дверь не должна открыться сама.
3.5. Постучать в дверь. Если там кто-то есть и он спросит “кто?”, ответить “Полиция”. Дверь должна открыться.
4. Stress/Loading
4.1. Открывайте и закрывайте дверь со скоростью 120 циклов в минуту
4.2. Открывайте и закрывайте дверь со скоростью 6 раз в минуту на протяжении 48 часов.
4.3. Стучите в дверь с частотой 1200 стуков в минуту.
4.4. Стучите в дверь с частотой 10 раз в минуту на протяжении 24 часов.
4.5. Открывайте и закрывайте дверь ключом на протяжении 12 часов.
5. End to end
5.1. Постучать в дверь. Позвонить в звонок. Открыть ключом. Открыть дверь. Закрыть дверь. Закрыть ключом. Прочитать табличку на двери. Ничего не отвалилось, не звякает, не взрывается?
6. Usability
6.1. Проверить, что ручка двери помещается в ладонь.
6.2. Проверить, что ручка находится именно на двери, а не на соседней стене на высоте 20 см.
6.3. Проверить, что высота двери больше человеческого роста
6.4. Проверить, что усилие для поворота ключа в двери в пределах допустимого
……..
* Проверить функциональность двери при температуре 38, 45 и -15 градусов Цельсия.
* Проверить функциональность двери при различной относительной влажности, днем и ночью, в июле и с декабре.
* Проверить, что пол и социальное происхождение открывающего никак не влияют на результаты.
Добавка
1. Начать с использования двери одним человеков. Увеличивать количество пользователей с шагом 5 человек в 5 сек. Увеличивать нагрузку, пока дверь не сломается.
2. Проверка документации к двери – инструкции пользователя, технического паспорта..
3. Проверка сердцебиения и давления открывающего. Действия по открыванию-закрыванию не должны пожирать все ресурсы пользователя.
4. Проверить влияние функционирования двери на появление трещин в стене.
5. White box tests: проверить волокна древесного полотна на параллельность. Проверить отдельные элементы (классы) на предмет избыточности (а может там 6 замочных скважин). Проверка алгоритма запирания двери.
В релизе не проверено
- Отсутствуют проверки на стрессовость (удар ногой или головой)
- Отсутствуют проверки на крепеж двери к косяку
- Отсутствуют проверки соседнего модуля – косяка (зазоры между ним и дверью)
- Отсутствуют проверки между дверью и полом.
- Отсутствуют проверки на …







Давно хотел что-то такое выродить.
А то всё про ручку да про ручку … ну на собеседованиях то есть…
Никак не удосужусь, про Notepad наваять подобное, чтобы потрясать этим потенциальных работодателей, да и для души хорошо.
Про дверную ручку? Как банально…
Вот у меня анадысь собеседование было мощное. “Что будете делать, если вам кто-то из программистов скажет, что баг – не баг?” Вот какие вопросы надо задавать.
Alexei Lupan, нам сразу сказали – решение о том что “баг – не баг, а фича” принимает продукт менеджер. Наше дело – найти.
Правильно вам сказали, Андрей! Вы нам тут кто? Вы нам тут баги ищете? Ну так вы их нам и ищите… (на стенах мелькает тень профессора Выбегалло)
Вот когда вам скажут, что ваше дело – сделать так, чтобы эти баги не появлялись, тогда вы закажете себе визитки с кодовым словом “QA”…
Тут хочется сослаться на авторитета: Экономическая модель зрелости процессов тестирования ПО – посмотрите файл ‘ECMM4ST.pdf’. Судя по этому файлу, можно сказать, что у вас в компании – второй уровень зрелости процессов тестирования – “Найди мне баг!”
А можно и другое сказать. Можно сказать, что для программиста любое сообщение об ошибке – задача на “исправление”, и что он может не думать, что можно и не исправлять… It depends of… Некоторые дефекты требуют долгого исправления, и в некоторых обстоятельствах разумнее назначить на исправление кого-то очень опытного. А некоторые баги могут оставаться неисправленными в текущей версии – это вопросы в компетенции того, кто “принимает решение” о выпуске релиза на продакшн-сервер. Поэтому ревью всех багов на уровне продакт-менеджера – нормальное волевое решение менеджеров.
А еще программисты могу злоупотреблять “это же фича!”, и замыливать глаза тестировщикам
Вообще, тестировщик тоже может ошибаться
Если есть возможность, и цена ответственности за допущенную ошибку крайне высока, то все баги должны проходить review у нескольких людей – и у тим-лидера тестировщиков, и у менеджера отдела тестирования, и у продакт-менеджера, и у тим-лидера программистов. Если же компания небольшая, вполне разумно все подобные ревью отдать на совесть продакт-менеджера. Если он вообще есть в компании.
Авторами Плана Проверки Двери являются участники вот этого треда в ЖЖ: http://community.livejournal.com/rabota_il/3575492.html
Было бы приятно если бы они были указаны. Я не один из авторов, но все же ради так сказать справедливости. и чтоб автор был известен
С удовольствием!