В условиях ограниченных ресурсов, почему бы не провести стресс-тест для выявления багов функционала? Если стресс-тест сильный (выявляет больше багов, чем другие) почему принято начинать с функциональных и уж никак не смешивать функциональное тестирование со стресс-тестированием?

Можете привести примеры из Вашего опыта, когда ошибки функционала выявлялись стресс-тестами?

Какой продукт должен выдать такой поисковик-сборщик?
Инструмент должен облегчить написание сильных кейсов.
Речь о том, что Алексей называет «инкубатором, где из мусора могли бы формироваться идеи, которые могли бы оказаться полезны для поиска багов», аналогичных описанным с изложением мыслей по поводу. Только не «могли бы оказаться полезны для поиска багов», а обязаны (измеряемо в сравнительном исследовании) доказать свою полезность в поиске багов.
Мусор == вся немерянная масса гуглимых багрепортов и мысли по поводу них.

Как вообще пишут тесткейсы функционала? Из чего их выводят? Из отдельных пунктов требований. Из связок пунктов требований. Из известных тестспек по аналогичным технологиям. Из конкретных особенностей поведения тестируемой реализации системы. Из типичных ошибок программистов и архитекторов. Из найденных в продукте багов. Из багрепортов по аналогичному функционалу.

Как генерировать эвристику на основе текста (в котором встречается рассмотрение и обсуждение багов, что «помогает «натаскать» взгляд на обнаружение багов, благодаря фиксации в мозгу определённых шаблонов, состоящих из наборов признаков наличия багов того или иного вида»)?

Например, такой текст описывает как был найден баг: techblog.traveltripper.com/search/label/Bugs
Иногда публичные багтрекеры хорошо описывают процесс нахождения бага. Как будем загонять их в инкубатор?

https://bugs.eclipse.org/bugs/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__closed__&product=&content=recursion
https://bugs.launchpad.net/bugs/+bugs?field.searchtext=recursive&orderby=-users_affected_count&search=Search&field.status%3Alist=FIXRELEASED&field.importance%3Alist=CRITICAL

Как надо поиск обнаруживаемых глазами при ручном тестировании неувязок автоматизировать?

Пример обнаруженной глазами при ручном тестировании неувязки (предложите любой другой пример):



Радиобаттон, обеспечивает выбор одного из вариантов. Визуально выглядит, будто выбрано несколько вариантов. Это баг. Он был найден случайно вручную. Вопрос: как автоматизировать поиск такого типа багов?

( Читать дальше )

Последнее время наблюдается предрождественский водопад ненормальных сообщений об ошибках.
Сегодня меня порадовала та же самая программа, об ошибке в которой я писал намедни, но тут она превзошла сама себя:



Что же все-таки произошло? Всё хорошо — зачем тогда об этом сообщать? Что-то не так — зачем говорить что всё хорошо?
( Читать дальше )

В продолжение темы, посвященной дурацким сообщениям об ошибках, начатой Алексеем.

Я уже писал, что видел странное сообщение при старте системы в коментариях к предыдущей заметке в данной теме. И вот оно отловлено. Недаром я тогда в коментах запутался, что же там написано. Судите сами:



Все-таки это не лингва :)
( Читать дальше )

Продолжим тему загадочных сообщений об ошибках.

Сижу я как-то раз, работаю, и вдруг из области уведомлений (которая system tray) выползает вот такое сообщение об ошибке:



Что случилось? Где? Если бы я не знал, что Fine Objects используются в Abbyy Lingvo — ни за что бы не догадался (я уже раньше встречался с похожими сообщениями об ошибках в этой программе в другом контексте, поэтому и запомнил эти Прекрасные Объекты).

Мораль для тестировщиков

Следите за тем, чтобы сообщения об ошибках содержали данные, по которым можно идентифицировать программу, в которой возникла ошибка. Особенно если программа работает в фоновом режиме!

Открою ещё одну серию описаний багов (в добавок к серии про счётчики) — неудачные попытки сообщить пользователю о том, что что-то пошло не так.

И первым экспонатом в этой серии будет баг в инсталляторе инструмента тестирования WET — если при установке не ввести название организации, вы увидите вот такое сообщение о возникшей проблеме:



Мораль для тестировщиков будет не совсем обычная — не про то, как такие баги искать, а про то, как можно отучить разработчиков выдавать такие сообщения об ошибках. Покажите им скриншот ТОЛЬКО сообщения о возникшей в программе ошибке, и спросите — мне программа вот такое сообщение выдала, что это значит? И пусть они попробуют догадаться!

Продолжим тему счётчиков.

На днях меня удивил Windows Update совершенно детской выходкой: спросил «Хотите установить обновления?», а когда я ответил, что хочу, он сообщил — «А нет никаких обновлений!»

Мораль для тестировщиков

Мне приходилось встречаться с похожей ошибкой в другом месте, тоже в механизме обновлений. Там баг проявлялся из-за того, что клиент получал с сервера XML-файл с описанием доступных обновлений, и этот файл был повреждён, так что при анализе возникала ошибка в парсере. Но часть файла к моменту сбоя уже была разобрана, так что клиент знал, что обновления есть, и даже знал, сколько их, но не знал, какие именно.

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

Если в социальной сети Мой Круг время идёт по циклу, то в социальной сети HeadHunter Live оно просто делает петли, так что временные отметки не соответствуют логической последовательности событий:



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