Тестирование программного обеспечения в настоящее время находится на уровне принятия, который не всегда был там. В первые дни разработки программного обеспечения отладка была основной формой тестирования программного обеспечения. Первоначально он был выполнен программистом, который написал код, и целью было заставить приложение работать без сбоев системы.
В эти дни конечные пользователи играли очень небольшую роль в принятии заявок. Пользователь должен был научиться манипулировать программой для достижения ожидаемых результатов. Если программа не дала желаемых результатов, пользователь должен был найти способы корректировки данных или методов ввода для достижения ожидаемой конечной цели.
Краткая история
Когда я присоединился к корпорации DataPoint в 1974 году, меня наняли непосредственно в отдел тестирования. Наша работа заключалась в разработке и производстве испытательного оборудования и процедур для тестирования печатных плат производственной линии. Акцент был сделан на тестирование оборудования. Было хорошо понятно, что доска должна быть правильно заполнена и функционировать правильно, чтобы успешно выполнять свою задачу.
DataPoint, как мне нравится верить, был создателем первого настольного персонального компьютера — DataPoint 2200. 2200 был удивительной машиной для своего времени: он полностью автономен, имел небольшой размер рабочего стола и выполнял некоторые очень полезные задачи. с полной независимостью. У него была собственная операционная система, и все приложения были разработаны собственными силами. Аппаратное обеспечение было тщательно протестировано, но в отделе тестирования не было отдела тестирования программного обеспечения. Все тестирование программного обеспечения было выполнено техническим отделом, который отвечал за его разработку. Когда я покинул DataPoint в 1980 году, в этом отношении мало что изменилось. Тестирование программного обеспечения было немного больше, чем запоздалая мысль.
Прогресс создает проблемы
С появлением графического интерфейса пользователя (GUI) и дружественного к пользователю программного обеспечения стала очевидной необходимость более комплексного тестирования программного обеспечения. Дружественный пользователь возлагает большую ответственность на плечи разработчика, создавая программы, которые можно запускать «из коробки». К сожалению, разработчики не думают как конечные пользователи. Производители посчитали необходимым нанять команды сторонних «экспертов» для моделирования деятельности конечного пользователя. Предполагалось, что эти «эксперты» обнаружат любые проблемы, с которыми может столкнуться конечный пользователь, но сделайте это до выпуска продукта.
Примерно в то же время бета-тестирование стало популярным. Бета-тестирование — это практика, позволяющая осведомленным конечным пользователям получить доступ к программам и использовать их в соответствии с тем, как фактический конечный пользователь будет использовать продукт в полевых условиях. Однако проблема с бета-тестированием заключается в том, что оно начинается в конце производственного цикла. Если бета-тестеры обнаружили какие-либо существенные дефекты, которые означали, что проект должен быть возвращен в разработку, определите причину проблемы, устраните ее и верните бета-тестерам. Это стоило производителю времени и денег и могло привести к перерасходу средств, а также задержкам при отгрузке. Очевидно, что это был не лучший подход к производству прибыльного, приносящего доход продукта.
Решение, ожидающее обнаружения
К счастью, разум и здравый смысл возобладали, и была разработана более тщательная и продуманная схема тестирования программного обеспечения. Сегодня тестирование программного продукта начинается с планирования продукта. Цикл тестирования программного обеспечения сосуществует с производственным циклом. Специализированные команды создаются для совместной работы с разработчиками и планировщиками. Планы тестирования программного обеспечения стали неотъемлемой частью поставляемого пакета для клиента. Эти планы охватывают процедуры, которые будут внедрены, пока продукт находится в стадии разработки и доработан до того, как продукт будет доставлен конечному пользователю.
Будущее исследование
Используя ресурсы этого форума, я хотел бы представить вам различные этапы, уровни и процессы, которые стали настолько важными в жизненном цикле производства. Я расскажу о различных уровнях тестирования: модульное, интеграционное, системное, принятие пользователя, регрессия и др. Я углублюсь в тестирование белого и черного ящиков (и, возможно, даже серого ящика). Я буду обсуждать нового члена группы тестирования: Тестирование производительности и его конечные цели и заблуждения. И я углублюсь в то, что многие называют «отрицательным тестированием». Это практика попыток заставить программу сделать то, чего она не должна делать.
Я надеюсь представить эти концепции и практики в увлекательной и познавательной форме, которую вам будет трудно отрицать. Попутно я раскрою некоторые мифы и открою вам очень сложную и полезную область карьеры. Надеюсь увидеть вас на следующей неделе и услышать от вас во время процесса.