Как мы находим баги - или "а не роботы ли мы часом?" )

Навеяно 'Звездным крейсером 'Галактика''

Существует два(по сути один, но!) пути, по которым идёт наше сознание, когда мы находим дефект в программном обеспечении.

Путь первый, самый простой - мы хотели что-то сделать, но не можем.

Например, нажимаем на кнопку и ожидаем появления новой формочки для заполнения, а её нет. Как же, конечно - баг.

Или после определённой последовательности действий ожидаем увидеть какую-то надпись, какую-нибудь анимацию, какую-то реакцию нашей системы.

И если реакция нашей системы не соответствует нашим ожиданиям, мы понимаем что "что-то не так" и начинаем анализ наблюдаемой ситуации.

Второй путь интереснее.

Мы что-то делаем (или даже не делаем, оно само) и тут появляется что-то подозрительное. Например, мы видим поплывшую верстку. Это, по-сути, вариация первого пути, но здесь есть принципиальное отличие. Мы попали на эту страницу с другой целью.

Мы просто шли проверять что можем обновить пароль пользователя, но тут на середине нашей проверки мы видим красную надпись на половину экрана с какой-нибудь SQL-ошибкой.

Пароль мы поменять сможем, и если бы мы просто шли первым путём - то мы бы проигнорировали эту ошибку. Второй путь включает в себя переключение внимания на окружающую нас обстановку. Мы постоянно анализируем всё, что вокруг нас.

Мы хотим настроить один параметр, попутно замечая, что что-то не так со вторым, который мы пока не собирались проверять.

В обоих случаях работает простой шаблон - "совпадает ли то, что мы видим с тем, что мы ожидаем", но в первом случае мы знаем чего ожидать, во втором - мы замечаем проблему раньше, чем формулируем желаемый результат.

Первый путь - это путь робота. Знайте и думайте об этом, когда в очередной раз находите такие ошибки. Почему автоматизированные тесты не делают эту работу за вас?

Да, знаю я - проблем у нас в этом очень много: и времени не хватает, и квалификации. Но стремиться есть к чему ;) Это действительно очень серьёзный вопрос.

И чем больше я занимаюсь автоматизацией, тем больше склоняюсь к мысли о том, что и второй путь может быть осилен роботами.

В этом и видится надвигающийся прогресс в тестировании и разработке программного обеспечения - возможно, это только недостижимая цель, к которой хочется стремиться.

Человек продумывает идеи того, что и как должно работать - ведь для этого необходимо воображение, а робот это проверяет и находит все баги.

При этом очень важно, чтобы основные проверки такой робот делал не на основе программного кода - ведь это как раз то, к чему у робота и человека не должно быть никакого доверия. Такие проверки могут быть сделаны на основе высокоуровневых описаний историй использования, записи "демо" работы с прототипами программы, анализа интерфейса (например, чтобы робот мог зайти на страницу и сообразить, какие кнопки тут можно нажать).

Представляете, через сотню лет специалисты по тестированию почти перестанут заводить сообщения об ошибках - если только так, понастальгировать по былым временам )

А пока что мы можем видеть? До безоблачного будущего ещё очень далеко.

Все самописные роботы слабоваты и явно не способны обрабатывать высокоуровневые "желания" инженеров по обеспечению качества о том, "как всё должно работать".

У нас есть BBD, системы генерации автоматизированных тестов на основе наборов состояний тестируемой системы (это интересная технология), краулеры и умные роботы, на подобии Роботестера Яндекса (хотел бы я взглянуть на его алгоритмы) - но всё это ещё довольно сложно, отнимает много времени и не даёт полностью удовлетворительного результата.

А до систем, которые бы оценивали систему но основе выдвинутых нами требований - ещё далеко. Мы и сами не знаем, как оно должно работать ;) - а когда видим "результат", то сразу же хочется чтобы было "иначе".

Вот попадаем мы на новую, только что написанную программистами формочку - и видим что, "нам не нравится", что можно сделать лучше. Но решение проблемы - как подобные дефекты должны тестироваться роботами - оставим тем, кто будет разрабатывать системы проектирования и разработки продуктов - в их силах сделать инструменты коллективного владения продуктом и совместного обсуждения всего функционала до его реализации.