Feeds:
Записи
Комментарии

Archive for the ‘Exploratory testing’ Category

А давайте вот что сделаем.

Давайте мы не пойдем на очередной тренинг по тестированию методом замученного поиска в аджайл.

Никуда это от нас не денется просто потому, что это не для всех и не для каждого.

Все равно ведь «Было очень интересно; вопросы появятся после практического освоения полученого материала; но поскольку в нашей компании это будет будет невозможно внедрить, то практического освоения полученого материала не будет; поэтому вопросов нет и не будет…» Фубля!

Давайте мы возьмем, купим, скачаем, нагуглим, разъяндексуем хотя бы книжицу ‘A Practitioner’s Guide to Software Test Design‘ за авторством Lee Copeland (он еще жив).

Там есть целый раздел «Black Box Testing Techniques», и содержимое его такое:

  • Equivalence Class Testing
  • Boundary Value Testing
  • Decision Table Testing
  • Pairwise Testing
  • State-Transition Testing
  • Domain Analysis Testing
  • Use Case Testing

Это, на минуточку, основные подходы к тестированию программного обеспечения.

Это наша мамкина титька, если угодно.

Давайте эти главки прочитаем хотя бы по-диагонали.

И давайте сделаем это ПЕРЕД тем, как пойти на очередной тренинг по тестированию.

А на очередном тренинге мы будем не слушать, а выяснять и прояснять.

А если соображалки на «прочитать ДО того, как» традиционно не хватает, тогда мы не будем брюзжать, что «тренер просто пересказывает Коупленда«.

Пусть он нам хотя бы Коупленда пересказывает.

Давайте мы хотя бы Коупленда освоим.

Read Full Post »

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

И вдруг…

 

ВНЕЗАПНО!

 

Этот внезапный вдруг таки случился — лично тов. Алексей Баранцев проведет в Киеве сразу три тренинга для тестировщиков :

Теперь надо подумать о том, как спокойно дожить до первого марта.

Там будет «Метод «шести шляп» де Боно» — значит, надо будет найти себе шляпу.

Там будут «чит-листы» — прихвачу тетрадь в клетчатую полосочку.

Там будет ответ на такой насущный вопрос, как «Что делать между сеансами тестирования?»

Там будет «большое кол-во примеров из жизни» — надо взять с собой свои колвы из своей жизни.

Вроде ничего не забыл?

Read Full Post »

В октябре James Bach посетит Румынию. А еще будет в Эстонии.

Насквозь братская Румыния для Молдовы все равно, что другая планета 😦

Read Full Post »

James Whittaker пишет про James Bach:

“У нас была дружественная беседа. В ходе обсуждения он ничего не упомянул про свой сердитый отклик в блоге о том, что я неправильно использую термин ‘Exploratory Testing’…”

James Bach пишет к James Whittaker открытое письмо:

«Я бы не оценивал нашу беседу как дружественную. Вы, должно быть, так подумали просто потому, что мы не говорили ни о чем существенном, и потому, что в тот момент я не повысил голос. Или потому, что не стукнул вас по морде«.

Read Full Post »

Пять тысяч слов о серьезном и наболевшем.
Без картинок, но с линками и отступлениями.
Думал и писал долго.

Дочитал книгу «Secrets of a Buccaneer-Scholar» (How Self-Education and the Pursuit af Passion Can Lead to a Lifetime of Success) by JAMES BACH.

Книга не о тестировании as is, она о корнях и истоках того, что называется «исследовательское тестирование». ИссТест.

Уместный анекдот, в котором заключается вся суть исследовательского тестирования:
— Бэрримор, что это хлюпает у меня в ботинке?
— Овсянка, сэр!
— Но что она там делает?
— Хлюпает, сэр.

(далее…)

Read Full Post »

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

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

Пытается программист уточнить, зачем эта труба клиенту нужна. Умудренный знает, что клиенту этой информацией делиться нафиг не нужно. Что ему труба нужна. Или пирожок 🙂 Но пытается.

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

«How to test software with dynamic requirements?» — достаточно вменяемая статья на тему нестандартных труб, исходя из всей доступной «широты» этого вопроса.

Решение в этому случае достаточно взвешенное, хотя и местами рисковое — чек-лист.

Кто незамутненно уверен в том, что чек-лист — стопроцентная панацея в работе тестировщика, тот дурак. Зависит от проекта и уровня образования тестировщика. Например, без понимания софта тестировать в таком режиме почти невозможно. А вот по тест-кейсам может тестировать любой товарищ, даже не понимающий, что именно оне изволят-с тестировать и зачем. Доказательство.

Или MindMap.

Вот пример карты в MindMap (required Flash). В примере я показал часть того, что должно было быть сделано программистом в отношении гипотетической задачи «ER-678».

Это все было расписано не в требованиях, а размазано в комментариях к задаче. Занести все это в MindMap и как следует раскидать по логикам вещей — 7 минут. Проще, чем просить письмо с однозначными требованиями и громко предпочитать работать в гетеросексуальном коллективе.

Сколько времени занимает само тестирование — уже не так важно, it’s depends… Важно то, что если какое-то требование будет изменено через час, его изменение займет в этой карте минимальное время, и все равно будет понятно, что и как надо делать. А если будет добавлено что-то новое, то и в карту его добавить несложно.

Интереснее всего то, что будет видно потом. Видно, что в пункте «all the other checkboxes should be unchecked and greyed out» возникли какие-то проблемы… И в комментарии указано, что по этому поводу открыт новый баг в баг-трекере.

MindMap позволяет очень и очень грамотно и гибко сортировать топики по разным признакам — пользуемся Queries.

Read Full Post »

В компании, в которой я сейчас работаю, ввели новую систему учета рабочего времени — eHour. Автор: неизвестная мне компания TE-CON — Java architecture and development.

Система позволяет на стыке значений «Проект» и «День недели» вписывать количество часов и дополнительную информацию о том, что было с этим часами сделано.

«eHour» is a free time tracking tool for companies and organizations who need accurate information on how much time is spend on projects by their people

Есть on-line demo (user/demo).

Слабость системы, как и ожидалось, в подсчёте минут.

Система нормально работает с «целыми» часами. Например, если указать по первому проекту 2 часа, а по второму — 5, то система отобразит итоги дня — 7.00.

Нули программа вписывает самостоятельно. Нужно только после каждого «вписывания» нажимать на кнопку [store].

А если записать 2.30 и 5.00?

Результат — 7.30.

А если записать 2.30 и 5.15?

Результат — 7.45.

А если записать 2.30 и 5.30?

Результат — 7.60 🙂

А если записать 2.30 и 5.45?

Результат — 7.75

Теперь самое интересное: если записать 2.50 и 5.50…

Эти значения честно отображают итог одного дня.

Expected result:
2.00 + 5.00 = 7.00
0.50 + 0.50 = 0.100 = 1.40
7.00 + 1.40 = 8.40 🙂

Но программа показывает 8.00

Машинная логика верна:
2.00 + 5.00 = 7.00
0.50 + 0.50 = 1.00
7.00 + 1.00 = 8.00

Итог: наша компания продолжает пользоваться eHour, делов-то…

Read Full Post »

Весьма рассудительная статья План тестирования на блоге «Про тестинг».

Для тех, кто только что присоединился

Тест план (Test Plan) — это документ описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Резюме статьи краткое:

хороший тест план должен как минимум отвечать на следующие вопросы:

  1. что надо тестировать (объект тестирования: система, приложение, оборудование)
  2. что будете тестировать (список функций и компонент тестируемой системы)
  3. как будете тестировать (стратегия тестирования — виды тестирования и их применение по отношению к тестируемому объекту)
  4. когда будете тестировать (последовательность проведения работ: подготовка, тестирование, анализ результатов, в разрезе запланированных фаз разработки проекта)
  5. критерии начала и окончания тестирования

Это касается формализации тестирования, когда надо Cover Your Ass от возможных претензий, или кого-то по щекам стопкой бумаги похлестать. Или идёт обсуждение с участием многих людей, и все, о чем говорится, должно быть где-то как-то задокументировано.

Но бывают дни, когда тестировщик остается один на один с приложением. И возня с документами для него критична по времени. Например, никому не нужна…

На этот случай есть вариант создания тест-плана без возни с документами. Иногда можно и без тест-кейсов обойтись…

Ну так, рецепт:

  1. Логически разделить приложение на отдельные, независимые друг от друга модули (да, принципиально это возможно).
  2. В каждом модуле перечислить доступные функции.
  3. Для каждой функции написать списки (в виде заголовков тест-кейсов, не более) вероятных проверок для каждой функции. Без спецификаций или подробных документов.
  4. Проверять каждый пункт последовательно.

В этом стиле лучше всего работать с приложением типа MindMap или FreeMind, если Linux. Но в принципе все это можно сделать и в простом Notepad или Excel приложении (второе на порядок удобнее, например, можно модули по страницам разбросать, а потом автоматизировать отчет о количестве уже проверенных пунктов и о результатах проверок). Но так или иначе, главное — чтобы был список.

Со списком можно уверенно и быстро работать, неимоверно рулят принципы GTD. Видно, что можно вычеркнуть, а что важно. Видно, сколько еще софта осталось непроверенным. Многое видно, короче.

Простой тест-план, он же чек-лист, готов.

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

Конечно, я немного лукавлю, называя чек-лист тест-планом. Но все зависит от контекста и ситуации на поле боя.

Важное дополнение: хороший тест-план отвечает на косвенно задаваемый вопрос «Почему?».

Пример: https://ru.scribd.com/document/39391857/TestPlanTemplateV1-0

 

Read Full Post »

В багтрекере появился баг №666 — за моей подписью.

Баг в увлекательной форме описывал то, как в форму в режиме редактирования вклиниваются поля из чужой формы. Короче, не баг, а загляденье.

Но наглые мерзавмиссты растолковали, что они специально, в порядке бреда теста, вклинили именно в эту форму именно эти «левые» поля. Ну просто чтобы удостовериться, что «с наследованием все в порядке». И забыли снять.

И приписали мне: » ISSUE 666 — НЕ БАГ!»

Issue — CLOSED. 😦

Надо было написать в трекере, что «Воспроизведение этого бага гарантированно отформатирует вам винт…»

Read Full Post »

%d такие блоггеры, как: