Продолжая отдавать должное вопросам психологии в процессе тестирования, мы можем определить набор витальных (читай, чертовски жизненных) принципов тестирования. Многие из них покажутся очевидными, что, однако, не мешает зачастую ими пренебрегать. Вот они, а дальше – подробное их рассмотрение:
1. Обязательная часть тестирования – определение ожидаемого результата;
2. Программистам следует избегать тестирования их собственных программ (и участков кода);
3. Организациям, создающие программы, следует избегать тестирования их собственных программ;
4. Процесс тестирования должен включать в себя тщательную проверку результатов каждого теста;
5. Тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых;
6. Исследование Системы на предмет того, что она не делает того, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает;
7. Избегайте одноразовых тест-кейсов, только если сама программа не является одноразовой. Одноразовые тест-кейсы для одноразовых программ. В остальных случаях следует избегать таковых;
8. Не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок;
9. Вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок;
10. Тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие.
Принцип 1: обязательная часть тестирования – определение ожидаемого результата
Этот принцип, который типа очевидный, когда его упускают из вида, является причиной наиболее частых ошибок в процессе тестирования. Тут снова вмешивается психология. Если заранее не разобраться с тем, как должен выглядеть результат, то нечто похожее на правду, но таковым не являющееся, будет воспринято как корректный результат. Ведь «мы видим то, что хотим видеть». Другими словами, несмотря на разрушительную природу тестирования, где-то в глубине души мы все еще храним желание увидеть корректный результат. Но с этим нужно решительно бороться. Например, путем поощрения подробного заблаговременного исследования всех выходных данных и ожидаемых результатов. А это значит, что тест-кейс должен содержать два компонента:
— описание входных данных
— точное описание корректных выходных данных для указанных входных данных.
Проблемы могут возникнуть тогда, когда мы встречаем нечто, что не имеет приемлемого описания, что выглядит странным, что не согласуется с нашими ожиданиями или предубеждениями. При встрече с чем-то подобным нам нужно иметь хотя бы какие-то обобщенные представления, поскольку если не будет даже их, легко вообще пропустить потенциальные проблемы. Нет ожидания – нет сюрпризов.
Принцип 2: программистам следует избегать тестирования их собственных программ (и участков кода)
Каждый писатель знает – или должен знать – что редактировать свою собственную работу – это плохая идея. Они знают, что именно должна сказать, к примеру, определенная глава книги, и поэтому могут не увидеть то, что она говорит нечто другое. И они как-то не хотят искать ошибки в своей работе. То же можно сказать и об авторах программных продуктов.
Еще одна проблема связана со сменой фокуса. В то время, как при дизайне и написании кода программист настроен созидательно, перенастроиться на разрушительную волну может быть очень сложно.
Каждый домовладелец знает, что снимать обои очень трудно. Но если эти обои еще и ты сам вешал — это невыносимо удручает. Аналогично и с ПО, большинство программистов не могут протестировать свои программы эффективно, поскольку они не могут произвести ментальные перестройки, способствующие выявлению ошибок. Более того, подсознательный страх перед наказанием со стороны коллег, руководителей, клиентов или владельцев может приводить к избеганию ошибок.
И еще одна проблема: программа может содержать ошибки, которые вызваны непониманием поставленных задач или спецификации. И если это так, то сам процесс тестирования может включать в себя производные этого непонимания.
Это не значит, что путь тестирования собственных программ для программиста закрыт. Просто лучше (эффективнее), чтобы это делал кто-то другой. Разработчики могут быть полезными участниками команды тестирования, когда проводится оценка спецификации и самого программного кода.
И еще. Речь не шла о процессе дебаггинга. В этом случае автор кода является наиболее эффективным участником процесса.
Принцип 3: организациям, создающим программы, следует избегать тестирования их собственных программ
Аргументы такие же, что и для предыдущего принципа. Организация, создающая ПО, во многих смыслах как человек: имеет психологические проблемы. Более того, в нашем лучшем из миров работа организации или ее менеджеров часто оценивается способностью производить программы в установленные сроки и за определенную стоимость. Причиной этому то, что эти величины легко описать количественно, в противоположность надежности, которую оценить в цифрах может быть сложно. Отсюда — организациям-разработчикам сложно быть эффективными в тестировании собственных продуктов. Эта оценка может проводится на основе соблюдения графиков работ и расходов.
Следует сказать и тут, что участие организации в процессе тестирования собственных продуктов не обязательно является бессмысленным. Здесь мы говорим, что наиболее удачно с экономической точки зрения выполнять такую работу независимой стороной.
Принцип 4: процесс тестирования должен включать в себя тщательную проверку результатов каждого теста
Это очевидно, но это часто упускается. Мы знакомы с большим количеством случаев, когда ошибку не удавалось обнаружить даже тогда, когда ее симптомы были четко различимы в выходных списках (результатах). Если выразится по-другому, ошибки, которые находят в последующих тестах, часто не замечают в результатах предшествующих тестов.
Принцип 5: тест-кейсы должны быть составлены как для корректных и ожидаемых входных условий, так и для некорректных и неожидаемых
Это естественная и здравая тенденция – концентрироваться на допустимых и ожидаемых условия в процессе тестирования. Пренебрегать недопустимыми и неожиданными условиями также естественно, но не также здраво. Много ошибок может выявится, когда программный продукт используется неким новым или неожиданным путем. Невозможно определить все сценарии, какими пользователь будет работать с продуктом, однако что-то отличное от спокойного, привычного течения программы, кажется, имеет все шансы на успех (в деле поиска ошибок).
Принцип 6: исследование Системы на предмет того, что она не делает, что должна, — лишь пол дела. Вторая часть – разобраться в том, чего недолжного она делает
Это следствие предыдущего принципа. Программу нужно проверить еще и на предмет нежеланных сторонних эффектов. Например, ПО для расчета заработанной платы, которая выдает зарплатный чек корректно, все еще содержит ошибки, если она также выдает дополнительные чеки для несуществующих работников, или она переписывает первую запись в персональном деле.
Принцип 7: одноразовые тест-кейсы для одноразовых программ, в остальных случаях следует избегать таковых тестов
Эта проблема, кажется, часто проявляется в различных системах для тестирования программ. Типичная практика – сидеть у компьютера и разрабатывать тесты на лету, и далее проводить эти тест-кейсы в программе. Суть в том, что тест-кейсы представляют собой ценные инвестиции, которые в рамках конкретного окружения могут исчезнуть, как только процесс тестирования будет завершен. И всякий раз, когда возникнет необходимость в повторном тестировании ПО (в регрессионном тестировании или при улучшении системы), тест-кейсы могут потребовать новой разработки. Это дополнительная, сложная работа, встречаясь с которой тест-инженер может волить избегать ее. Так получается, что последующие усилия на работу редко столь же объемны и качественны сколь объемны и качественны первоначальные. И если, к примеру, изменение функциональности влечет за собой ошибки, вновь разработанные тесты могут их не обнаружить.
Принцип 8: не занимайтесь процессом тестирования с предустановкой, что вы не найдете ошибок
Частая ошибка менеджеров проекта и маленький звоночек к тому, что кто-то определяет процесс тестирования некорректно. Например, как процесс демонстрации, что программа работает правильно. Мы принимаем другое определение (хотя догадываемся, что есть ребята, которые так не делают) – это процесс выполнения программы со стойким намерением найти ошибки. Мы утверждаем: это очевидно, что разработать программный продукт, совершенно не содержащий ошибок, невозможно. Даже после качественно выполненного процесса тестирования и исправления ошибок, уместно предполагать, что ошибки все еще существуют; просто их пока не нашли.
Принцип 9: вероятность наличия ошибок в определенной части Системы пропорционально количеству уже найденных здесь ошибок
Может показаться, что эта штука сомнительна, но такой феномен наблюдается во многих программах. На пальцах это вот как: предположим, что программа состоит из модулей А и Б. В модуле А было найдено 5 ошибок, а в модуле Б – всего лишь одна. И если модуль А еще не подвергся тщательному тестированию, тогда принцип говорит: вероятность найти еще больше ошибок в модуле А выше, нежели вероятность найти еще больше ошибок в модуле Б.
Другой способ проиллюстрировать указанный принцип такой: ошибки имеют волю к объединению в группы, и в типичном случае, определенные программные блоки больше подвержены ошибочности, нежели другие. Хотя это похоже на магию… ничем не подкрепленную магию. Она может быть полезна, поскольку дает некое понимание и обратную связь в процессе тестирования. Если какой-то участок программы кажется больше подверженным ошибкам, нежели другие участки, этот феномен намекает нам, что лучше бы нам потестировать здесь чуточку дольше. И это вопрос об инвестициях.
Картинка даже есть:
Принцип 10: тестирование – это вызов вашим творческим и интеллектуальным способностям. Тестирование – это невероятно творческое и интеллектуальное занятие
Бесспорно, это так. Творческие способности, необходимые для тестирования программного продукта, превышают (да там так и написано) творческие способности, необходимые для создания этого программного продукта. Существует множество методик и техник для дизайна проникновенных тестов, но все это останется не высоко, если не будут приложены творческие усилия с Вашей стороны.
Автор: RockMachine
