суббота, 11 января 2014 г.

Намедни постил картинку, где напротив книги Г. Майерса Искусство тестирования программ было написано, что читаю.
Собственно, дочитал.

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

Дальше - немного цитат и мыслей.

1. О критериях завершения тестирования
Альбом: bug

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

2. Главный принцип локализации ошибок
Альбом: bug


3. О отладке, экспериментах и поиске багов
Альбом: bug

Да, черт возьми! Как по мне - самый шик: найти багу, а потом запустить приложение и удостовериться в том, что она есть. Современные средства разработки стирают грань между не тратить время на рутину и не думать.

4. О бранных алертах
Альбом: bug

Просто понравилось.

4. О том, что полезней всего, но что никто не делает.
Альбом: bug

2 комментария:

  1. На тему пунктов 4 и 4 (да, в этом посте два пункта 4 =)).
    Я мало помню примеров конкретных багов, встречавшихся мне. Но помню, когда я только начинала работать в Наумене, ну и работать вообще, обнаружила, что какая-то форма вместо адекватного сообщения об ошибке говорит "WTF?".
    Иногда задумываюсь, а как предотвратить хотя бы однотипные ошибки, но идей нет. Составить их хит-парад и заставить программистов ознакомиться? Ну да, посмотрят, но забудут и всё равно повторят. Поэтому скорее я помню, что программист А часто бажит там-то, программист Б там-то, и что все поголовно забывают, что фреймворк не идеален, и ему надо помогать, чем эти самые программисты запоминают свои типичные ошибки и перестают их делать. В ситуации "полтора тестировщика на команду" это работает, но если бы мы не были привязаны к командам или больше людей участвовало в разработке, наверное, желание как-то исправить это было бы сильнее.

    ОтветитьУдалить
  2. Все тестирование должно происходить по нажатию ctrl+s в IDE.
    То есть в идеале - заставить написать тест, максимально универсальный, а еще лучше - статическую проверку кода, которая подсветит проблему в IDE.

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

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

    ОтветитьУдалить