Для тестирования какая разница, кто с этим работает? Разница есть

У нас есть бесплатное приложение folks, на котором мои студенты могут пощупать автоматизацию. Оно же нынче выступает в роли выпускного экзамена, так как позволяет объединить весь пройденный материал:

• Как писать тест-кейсы и чек-листы (ибо там мы пишем нечто среднее)
• Тест-дизайн
• Тест-анализ
• ...

И еще в самой первой лекции мы учим исследовать продукт, пытаться понять его логику. Зачем он нужен, для чего? Поэтому студенты часто интересовались, зачем нужно два вида поиска: простой и расширенный. Так что я добавила в описание расширенного поиска пояснялку для студентов.

Прошла пара курсов. Теперь другой студент пришел с новым вопросом:

— Мне, как тестировщику, чем поможет это пояснение: "(Ремарка для студентов: этот поиск используют только сильно прошаренные дата-стюарды и API, остальные люди используют простой)", я не понимаю.

— Ну как же, вы же должны знать, что делает ваша программа и для чего она нужна. Это влияет на выбор тестов

— Как? Не помню такого в лекции

В лекции такое есть, причем в самой первой. Это первое, чему мы учим — сначала узнай, ЧТО за приложение, ЗАЧЕМ оно нужно, это и будет влиять на тесты. Но раз это забывается, решила вынести отдельно.

См также:

Зачем вообще нужны программы

Как накидать тестов на что-нибудь — и снова о том, что сначала узнаем, что это и зачем оно нужно

Как знание «кто с этим работает и как?» влияет на тесты

Testbase

Рассмотрим пример с порталом Testbase из статьи «Зачем вообще нужны программы». В нем есть внешняя часть и админка. Админка — стандартный функционал Wordpress с небольшими наворотами.

Нужно ли тестировать админку? На граничные значения и всякие такие баги? Нет! Потому что «а зачем?». Пользователь у админки один — я. Ну либо коварный взломщик, но если сайт взломают, это будет другая беда.

Так вот, если мы не знаем, кто пользователь и зачем ему система, мы можем потратить кучу времени и сил на никому ненужные тесты. Будем с интересом проверять все-все-все возможности админки, репортить баги о том, что что-то неработает... А мне пофиг на тот функционал, все, что я использую — работает!

И наоборот, зная о пользователе, мы выкидываем из тестов все ненужное. И в итоге тратим на проверку функционала 5 минут вместо дня работы. Профит же.

GUI или CMD?

Другой пример абстрактный, но показывает суть разницы. Что важнее проверить — кнопочки в графическом интерфейсе или все то же самое через командную строку / горячие клавиши / API?

Это сильно зависит от того, кто будет пользоваться системой:

• Неопытные пользователи — в первую очередь стоит проверить графический интерфейс. Если что-то из горячих клавиш не работает, не важно. Если через командную строку / API что-то не работает, тоже пока не важно.
• Опытные пользователи, использующие горячие клавиши — они будут меньше тыкать кнопки в интерфейсе, но очень расстроятся, если привычные горячие клавиши вдруг не сработают. На API им плевать
• Бородатые админы — вообще не полезут в графический интерфейс, все будут пробовать через командную сроку делать
• Интеграция — полезет через API, в основном оринтир будет туда

Может, система делается для «простых» людей и админов, но вначале будут только админы. Поэтому первый приоритет будет явно не у графического интерфейса. И наоборот, если админ один, он может и пострадать, главное — чтобы большинство пользователей были довольны.

Folks

Так а что же с примером в folks? Чем поможет знание, для чего два разных режима работы?

Это не поможет, если цель — проверить вообще все. В том плане, что все равно придется писать чек-листы и на простой поиск, и на расширенный.

Но это поможет в расстановке приоритетов. Как расположить проверки внутри каждого чек-листа? Что вообще следует проверить? Разница в действиях людей и API есть. API как настроят, так он и будет делать. Могут неправильно настроить, не должно ничего сломаться. Но после настройки это в любом случае робот. И ему даже не суть важно, что поисковый запрос получился «большой и страшный». А человеку нужно, чтобы удобно и без лишних символов все было.

Выводы

Если в ТЗ не описаны сценарии использования — их нужно уточнять, чтобы потом не делать дополнительной работы. И чтобы правильно расставить приоритеты.

Если вы читаете ТЗ и горите желанием сразу пойти клепать тесты — остановитесь и подумайте. Вернитесь к основам. Сначала стоит все же узнать, для чего нужна программа.

Если вы студент школы и не понимаете, зачем знать о том, для чего нужна программа — то вернитесь к самому первому уроку и вспомните ДЗ со стулом 

См также:

Зачем вообще нужны программы

Как накидать тестов на что-нибудь — и снова о том, что сначала узнаем, что это и зачем оно нужно

Учитесь задавать вопросы! — ведь без этого никуда!
Когда можно обойтись без тестирования — да, и такое бывает =)