Michael Bolton
Disposable Time
www.developsense.com/2010/01/disposable-time.html
Воскресенье, 17 Январь 2010

Время в вашем распоряжении

В нашем классе Экспресс-тестирование www.developsense.com/courses.html Джеймс Бах и я любим говорить о недооцененном ресурсе тестера: время в вашем распоряжении. Время в вашем распоряжении — это время, которое вы можете позволить себе без проблем выкинуть.

Обратите внимание — что мы подразумеваем под «выкинуть»? Не в смысле целенаправленно транжирить время. Возможно, вы хотите потратить его разумно. Речь о том, что вы не пострадаете, если получится, что вы его растранжирили впустую. Время в вашем распоряжении по отношению к Вашим рабочим часам — то же, что и доход в вашем распоряжении по отношению ко всему Вашему личному доходу. (На самом-то деле, строго говоря, даже так не совсем правильно. Мы на самом деле подразумеваем дискреционный (остаточный) доход, остающийся в распоряжении работника после уплаты налогов и оплаты всего необходимого). То есть деньги, оставшиеся после оплаты всего, за что вы ОБЯЗАТЕЛЬНО платите: продовольствие, жилье, основная необходимая одежда, медицина и налоги. Те деньги, которые люди называют располагаемым доходом правильней называть дискреционным доходом. Как говорит английская Википедия en.wikipedia.org/wiki/Disposable_income: сумма «игровых денег, которые не жалко проиграть (в казино или на торгах)» отложенных, чтобы их потратить или сохранить. Ну ладно. Поехали дальше с неправильной, но популярной интерпретацией «в вашем распоряжении».)

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

Лимончелли в «Тайм-менеджменте для сисадминов» даёт советы, заточенные для сисадминов. А где дают советы по личному управлению временем, заточенные для тестировщиков (не лидов)? Интересуют интструменты повышения продуктивности, Ваш негативный и позитивный опыт, постановка мозгов в разных подходах к тестированию.

Примеры в кучу:

0). To find unexpected problems, elusive problems that may occur in the field, or more problems quickly in a complex product…
1. Start from different states (not necessarily clean).
2. Prefer complex, challenging actions.
3. Generate tests from a variety of models.
4. Question your lab procedures and tools.
5. Try to see everything with open expectations.
6. Make the test hard to pass, instead of easy to reproduce.

1). Обнаруживайте серьезные проблемы быстро
    * что изменилось а потом остальное
    * основные функции перед второстепенными
    * работают ли функции в принципе прежде чем детально углубляться в проверку работы каждой из них в различных условиях
    * обычные ситуации и данные раньше
    * распространенные опасности и  нагрузки раньше экзотических
    * сначала проблемы, которые принесут большой ущерб в случае сбоя
    * востребованные области раньше незапрошенных
будете находить важные проблемы раньше, если узнаете как можно больше о продукте, программном обеспечении и оборудовании, с которым он должен взаимодействовать и людях, которые будут его использовать bugsclock.blogspot.com/2008/12/blog-post.html

2). «выполняя миссию, тестировщик часто что-то замечает „в стороне“. И тут нужен компромисс — с одной стороны, хорошо бы это зафиксировать, с другой стороны — нельзя отвлекаться сильно, иначе миссия не будет выполнена, и это не есть гут. Поэтому в журнале делается отметка об отклонении от миссии, чтобы потом это отдельно проанализировать. А хорошие инструменты ещё и следят, чтобы время проведённое on opportunity не было слишком большим, и время от времени напоминают о необходимости вернуться к выполнению миссии»

3). " “Планарий”. Кстати, очень хорошее приложение, рекомендую обратить на него внимание любителям GTD"

Возможно будут тренинги по личному тайм-менеджменту для тестировщиков.

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

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

(In the Cisco program, you're given the task of fixing a broken router. If your process is reasonable, and if you can articulate it, then you pass the test, maybe even if you don't fix the router. This emphasizes that even a skilled network engineer and appropriate heuristics can be fallible; you might not have fixed the thing because you were unlucky. On the other hand, if your process is not reasonable or you can't articulate it, then you'll fail the test, even if you fix the router. The issue is that even an incompetent engineer and an unreasonable process can be lucky, but we'd just as soon not depend on that.) www.developsense.com/2007/12/why-i-am-not-yet-certified-eurostar.html

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

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

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

Например, такой текст описывает как был найден баг: 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

Проблема: из-за битых ссылок читатели не воспринимают прошлогодние статьи так, как задумано автором.
Либо вынуждены долго вручную собирать статью из «модулей».
en.wikipedia.org/wiki/Link_rot

1. Здесь team.custis.ru/2008/12/agiledays-2008.html Алексей Баранцев пишет «остальные картинки, если заинтересовали, можно найти тут [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11] ).» Ссылки 403 Forbidden:
www.etoday.ru/uploads/2008/01/20/ado_calendar01_box.jpg
www.etoday.ru/uploads/2008/01/20/ado_calendar12_rhytmic_gymnastics.jpg
www.etoday.ru/uploads/2008/01/20/ado_calendar03_track_cycling.jpg
...
нужно (точнее «пока можно») поменять на
www.outzone.ru/wp-content/uploads/2008/07/ado_calendar01_box.jpg и тд

Как узнал правильную ссылку?
Поглив в кавычках «ado_calendar01_box.jpg» и перейдя на www.outzone.ru/post/2987/

2. Там же Алексей Баранцев пишет «была конференция SQA Days 4 на которой был доклад «Funny testing: как добавить драйва в работу»». Из двух ссылкок 404 Not Found:
it-conf.ru/ru/content/34.htm
it-conf.ru/reports/presentations/ru/Orlov_Presentation.zip
вторую нужно поменять на
it-conf.ru/sqa4/reports/presentations/ru/Orlov_Presentation.zip
(Best practices предполагают редирект, которого не было на it-conf.ru, если только Алексей не забыл вставить sqa4).

Как узнал правильную ссылку?
Перешел по первой, Ctrl+F Орло

3. С битыми ссылками часто помогает живая ссылка на сохраненную копию в кеше гугла, яндекса или Wayback Machine.
Но
deadurl.com/http://www.etoday.ru/uploads/2008/01/20/ado_calendar12_rhytmic_gymnastics.jpg
deadurl.com/http://it-conf.ru/reports/presentations/ru/Orlov_Presentation.zip
не помогает:
No Archive.org Links Found, ни в кэше гугла.

Как решать проблему?
1. Продолжать писать статьи в таком виде, как прежде, но найти инструмент, который бы периодически проверял, что ссылки не битые (типа Xenu) и контент по ним (в важной автору и читателю части) не отличается от задуманного. Желательна фича замены ссылки на небитую или хотя бы замены ссылки на простой корректный текст. Какой инструмент?
2. Давать более живучие ссылки за счет распределенности, избыточности (например, не конкретный URL документа, а URL поисковика по хэшу конкретного документа, аля торрент). С бинарниками сложнее, с текстовыми вместо хэша достаточно проиндексированной поисковиками последовательнасти слов. Как?

en.wikipedia.org/wiki/Dead_link

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

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



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

Бейзер в Тестировании черного ящика пишет: «Существует большое число моделей на основе специальных языков для разработки тестов и связанных с ними инструментальных средств… Я верю, что рано или поздно тесты будут преимущественно создаваться такими вот инструментами.»

Где можно пощупать такие инструменты?
Какие из них рекомендуете?
В чем не оправдались прогноз и вера Бейзера в середине 1990-х?