Feeds:
Posts
Comments

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, она о корнях и истоках того, что называется «исследовательское тестирование». ИссТест.

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

(more…)

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 »

Older Posts »

%d bloggers like this: