Мысли о тестировании вслух

О революциях и перегибах

2011-08-13T02:08:00.001+03:00

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

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

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

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

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

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

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

Так что для меня высказанная мысль не является революционной, она - скорее просто перегиб. Как странно думать, что исключительно поиск ошибок ПОСЛЕ реализации может решить проблему качества, так же странна и мысль о том, что исключительно проверка требований ДО реализации спасёт мир. О качестве надо заботиться на каждом этапе, можно менять пропорции заботы на разных этапах, но выбрасывать какой-то этап полностью - вряд ли.

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

если вы смогли посмотреть на проблему с другой стороны - это отлично; если вы при этом решили, что этот взгляд единственно верный - подумайте ещё раз :)

Исповедь трудоголика

2011-07-26T00:17:00.000+03:00

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

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

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

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

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

К счастью, способ преломить ситуацию нашёлся: с трудом до него дожив, я ушла в отпуск. Я уехала в Турцию, на две недели, к солнцу, морю и полному отдыху, заставив себя даже не думать о работе. И - о чудо! - мне это помогло. Именно отпуск вырвал меня из этого ужасного порочного круга, в котором я закрутилась - я снова стала получать удовольствие от жизни и наконец ощутила и вспомнила, что значит жить. Отпуск смог вернуть на место что-то в моём сознании - ведь меня не было целых две недели, и проект за это время не развалился, так значит - и каждый день без нескольких часов моей переработки проект тоже переживёт! Отпуск вылечил меня, ну или поставил на путь выздоровления - уже давно вернувшись в Минск, не без помощи близких мне людей я старательно себя контролирую и верю, что смогу избежать рецидивов :)

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

Банальные мысли об обычном геройстве

2011-04-12T00:38:00.001+03:00

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

Итак:

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

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

- не надо требовать геройства от людей без крайней нужды; иначе когда в геройстве действительно возникнет необходимость - люди геройствовать просто не смогут и/или не захотят;

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

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

Личные качества тестировщика: Top 5

2011-04-04T03:54:00.001+03:00

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

Итак, мои Top 5 по степени возрастания важности.

5-е место

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

4-е место: недоверчивость

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

3-е место: любопытство

То, что тестировщику необходимо любопытство, можно уже считать банальной классикой. Плох тот тестировщик, у которого при тестировании, изучении или наблюдении чего-то не возникает вопрос "А что если?.." Именно любопытство будет толкать тестировщика идти по ещё не хоженым путям, открывая всё новые и новые проблемы и узкие места. И именно врождённое любопытство будет делать тестирование естественным и превращать его в удовольствие.

2-е место: небезразличие

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

1-е место: внимательность

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

А ещё бонусом вне рейтинга хочу назвать ещё одно качество - занудство :) Вне рейтинга - потому что оно, пожалуй, появляется как приобретённое профессиональное заболевание - когда постоянно приходится приставать, обращать внимание, копаться и даже порой действовать на нервы - словом, занудствовать разными способами ради того, чтобы сделать ~~мир~~ ПО лучше :)

Удивительная штука - мотивация

2011-03-28T02:09:00.002+03:00

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

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

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

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

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

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

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

В клубе тестировщиков

2011-02-27T14:43:00.002+02:00

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

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

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

Что меня расстроило, так это то, что встреча длилась всего 2 часа :) Лично для меня эти два часа пролетели просто незаметно, что, с одной стороны, говорит о том, что я увлеклась происходящим, но с другой - меня просто не покидает ощущение, что мы и наполовину не сделали то, ради чего эта встреча и задумывалась. А задумывалась она вроде как для того, чтобы помочь кому-то найти ответы на какие-то вопросы. А реально - по-моему, нашлось только ещё больше вопросов, и не уверена, что хоть какие-то ответы.

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

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

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

"Очаровательный непрофессионал" или "Отвратительный профессионал"?

2011-02-07T01:07:00.003+02:00

Утро пятницы принесло мне информацию, от которой сразу возникло желание уволиться. Но когда эмоции чуть улеглись, я серьёзно задумалась о том, что лучше - работать в команде с человеком, приятным во всех отношениях, но профессионализм которого оставляет желать лучшего, либо с человеком, который по-человечески крайне тебе неприятен, но при этом очень хорошо делает свою работу? Конечно, лучше всего работать исключительно с одновременно приятными и профессиональными людьми. Но увы - в реальности это может оказаться невозможным (да и сама ли я такая?). К сожалению, я не отношусь к тем счастливчикам-пофигистам, которым безразлично, с какими людьми они работают. Так что вопрос для меня оказался непростым. И чтобы найти на него ответ, попробую рассмотреть одну и другую ситуацию подробнее.

Ситуация "Очаровательный непрофессионал"

Итак, мы имеем дело с человеком, который по-человечески приятен во всех отношениях, хороший человек, однако в работе показывает плачевные результаты. Сразу поясню, что я не имею в виду те плачевные результаты, которые, наверное, временами бывают у каждого - по болезни, из-за переутомления или по каким-то ещё временным причинам. Я про _постоянные_ плачевные результаты, когда ситуация со временем не слишком-то меняется.

Несмотря на то, что кажется, что в первую очередь хочется работать с приятными людьми, такая ситуация не слишком привлекательна. Да, с этим человеком приятно общаться и можно даже подружиться. Но что будет, если какое-то время с ним поработать? Если из-за его плохой работы будет страдать эффективность собственной работы и/или работы всей команды, если из-за него тебе придётся перерабатывать, то, вероятно, очень скоро человек перестанет казаться столь уж замечательным. Конечно, в такой ситуации надо пытаться что-то сделать. А вы пробовали сказать хорошему человеку, с которым вы в принципе в хороших отношениях, что результаты его работы неудовлетворительны? Это не очень приятно и не слишком просто. Набравшись духу, это можно сказать, и хороший человек скорее всего признает свои ошибки и пообещает, что сделает всё возможное, чтобы изменить ситуацию. Но такова уж моя смоделированная ситуация, что по тем или иным причинам, результаты его работы особо к лучшему не изменятся. Так что говорить неприятные вещи хорошему человеку придётся снова и снова. И без особых результатов.

Похоже, минусы этой ситуации явно перевешивают её плюсы.

Ситуация "Отвратительный профессионал"

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

Будучи человеком эмоциональным, мне вообще сложно увидеть в такой ситуации какие-то плюсы. Первое, что приходит в голову - мне даже в офис будет приходить каждый день нерадостно, не говоря уж про необходимость общения и взаимодействия с этим человеком. Но попробую отодвинуть эмоции. Человек отлично делает твою работу. Это значит, что из-за него не будет срыва сроков, за него не придётся переделывать работу, т.е. по работе из-за него страдать скорее всего не придётся; а если и будут у него какие-то огрехи, то сказать ему об этом будет не сложно. Кроме того, на фоне потрясающе работающего отвратительного тебе человека, просто нельзя работать плохо - гордость не позволит, ведь он же отвратительный, как же ты можешь работать хуже него? Так что даже как будто дополнительный стимул для работы появляется.

Неужели плюсы этой ситуации перевесили её минусы?

Кажется, с точки зрения разума и рабочей эффективности ответ получен. Но восприятие ситуации и жизнь в целом - это не только разум, но также чувства и эмоции, а чувства - нелогичны (порой я так завидую мужчинам, которые, как правило, гораздо меньше зависят от своих эмоций!). Так что, похоже, я так для себя и не решила, что же лучше было бы для меня. Интересно, а что бы выбрали другие?

Режим тестирования не отключается

2011-01-29T01:02:00.000+02:00

Сегодня я ходила в театр. Увы, именно сегодня Алексей Баранцев читал в Минске открытую лекцию. Но билеты были куплены ещё в прошлом году, и это была премьера, так что, упустив шанс послушать бесплатно живого Алексея Баранцева, я пошла в театр.

Нет, я не собираюсь описывать тут свои впечатления от оперы - этот блог не для того. Это всё-таки заметка о тестировании.

По пути из театра домой я снова заглянула в программку, чтобы ещё раз взглянуть на фамилию понравившейся мне солистки, и прочитала: "Действующие лица и исполнители (по алфавиту)". Ну и какая после этого первейшая мысль пришла мне в голову? Правильно - проверить, действительно ли по алфавиту. Ниже перечислялись: Снегурочка, Лель, Купава, Мизгирь, Весна... Это явно было не по алфавиту. Может роли были отсортированы по фамилиям исполнителей? Тоже не похоже. Баг? Но что-то мне не верилось, что я так просто нашла баг. И через минуту или меньше я поняла, что же имелось в виду под этим "по алфавиту".

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

Когда любимая работа в тягость

2011-01-24T22:31:00.001+02:00

Бывают времена, когда на работу идти не хочется, дни тянутся бесконечно, и с трудом доживаешь до выходных. Нет, любимая работа так и остаётся любимой, но всё как-то не так. Этакий рабочий кризис. Вот и у меня сейчас такой. Но ведь такое случается периодически - то работаешь увлечённо, с горящими глазами, а потом почему-то огонь в глазах гаснет, и руки опускаются. А затем снова подъем, а потом снова спад. И вот так вверх-вниз, вверх-вниз... Но вот если подумать, то из-за чего-то же приходит кризис, и почему-то любимая работа становится в тягость. Возможно, если поставить диагноз, то справиться с таким кризисом станет проще? И я нашла несколько возможных причин.

1. Сизифов труд

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

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

2. Ощущение ненужности

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

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

3. Усталость

Бывают ситуации, когда на работе приходится перерабатывать. Мало ли - срочный релиз, неожиданный сдвиг сроков, чья-то болезнь или внезапная хотелка заказчика. Можно рассуждать о том, что при хорошо поставленном процессе такого быть не должно; и можно искать, кто в таком виноват. Но реальность такова, что всякое бывает. И я всегда с пониманием к подобному относилась. Ну, надо - значит, надо. Поработаю не 8, а 10 или 12 часов в день; выйду на работу в выходной; посижу над документом ночью дома. Но это приемлемо, если такое надо ИНОГДА. А вот если подобное становится нормой - то это становится настоящей проблемой. Увы, канули в Лету те времена, когда я, будучи недавней выпускницей ВУЗа, демонстрировала чудеса работоспособности. Может стареть я стала, но при постоянном перенапряжении я стала явно ощущать накапливающуюся усталость - такую, что КПД неумолимо падает, и как ни заставляй себя работать - толку маловато. Ужасно то, что в таком состоянии не только желание работать, но и все прочие желания, кроме "спать" и "ничего не делать", умирают.

Что делать? Тут, кажется, ответ прост - хорошенько отдохнуть и впредь не перенапрягаться. Однако это проще сказать, чем сделать. Если переработки стали уже пагубной привычкой, то надо себя заставлять от этого отвыкать. А в целом, состояние постоянной необходимости переработок на проекте требует целого комплекса различных мер и на различных уровнях.

Ну вот, пожалуй, это 3 главные причины, с которыми я сталкивалась. Думала написать ещё про скуку, но с ней как-то легче: если работа скучна, но ты не перенапрягаешься, то можно хотя бы усиленно заняться самообразованием, и в этом находить рабочую радость. А эти три проблемы - они более критичны. Если же ещё встречаются их комбинации - то совсем не позавидуешь. Кстати, я сознательно не писала в разделах "Что делать?" вариант смены проекта и работы - не люблю в качестве решения проблемы выбирать бегство. Но в крайнем случае - и такой вариант возможен.

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

О тестировании тестов

2011-01-21T00:51:00.003+02:00

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

Итак, на что же можно обратить внимание при тестировании автотестов:

1. Тест должен делать то, что от него ожидается.

Такая проверка, пожалуй, самая простая и более всего похожая на обычное тестирование. В простейшем случае запускаем тест и удостоверяемся, что он выполняет предписанные действия (кстати, если автотест разрабатывается по написанному сценарию, сценарий тоже полезно тестировать - до ухода в разработку). Специфика, с которой мне пришлось столкнуться, заключалась в том, что при реализации автотестов разработчики могут больше обращать внимание на то, ЧТО должен сделать тест, и меньше - на то, КАК тест должен это делать. Разница может быть в нюансах, но ведь это всё-таки тест, для которого "КАК" может быть наиболее важно - иначе либо что-то не проверится, либо проверится не то, что предполагалось.

Пример 1. При нажатии на кнопку "Закрыть" на какой-то странице автоматически выполняется переход на заглавную страницу приложения. При реализации автотеста, вместо нажатия на кнопку и ожидания автоматического перехода, был реализован прямой переход на заглавную страницу приложения.

2. Если что-то идёт не так, тест должен адекватно реагировать.

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

Пример 2 (мой любимый). При выполнении теста появляется некое окошко с сообщением, которое при обычном использовании приложения блокирует работу, пока это окошко не будет закрыто. Автотест же, взаимодействуя с приложением как-то по-своему, может полностью игнорировать это окошко и бодро продолжать производить действия ПОД этим сообщением - и завершиться, констатировав успешную отработку.

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

В наибольшей степени это вопрос корректной проверки и создания предварительных условий до выполнения теста и выполнения "зачистки" после теста. Когда запущено несколько тестов подряд, недочёты в проектировании тестов по данным вопросам очень хорошо проявляются.

Пример 3 (примитивный). Автотест-1 проверяет корректность создания какого-то объекта. Следующий за ним Автотест-2, проверяющий другой способ создания объекта, завершается ошибкой, поскольку объект уже существует, т.к. был создан и не удалён в рамках предыдущего Автотеста-1.

4. (Развитие п.3) Тест должен корректно отрабатывать как в случае успешного выполнения, так и в случае обнаружения ошибки.

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

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

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

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

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

6. Если тест обнаруживает ошибку, он должен правильно о ней сообщать.

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

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

Пожалуй, список получился простым. И при грамотном проектировании автотестов все эти моменты должны быть учтены. Однако если команда только начинает работать над автоматизацией и не имеет в этом особого опыта - этот список может быть весьма актуальным. Лично у меня по нему при текущем состоянии автотестов ещё масса работы, и это не считая специфических для проекта вещей, которые я не смогла или не посчитала целесообразным обобщить и описать в этой заметке. Успехов всем идущим по пути автоматизации ;)

С Наступающим!

2010-12-31T13:54:00.000+02:00

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

С Наступающим Новым Годом! ;)

Не забывать точить топор

2010-11-19T01:48:00.000+02:00

Меня снова затянула работа. Затянула надёжно и основательно, я стала постоянно проводить в офисе больше восьми часов в день, да ещё часть работы стала временами утаскивать домой и продолжать работать уже дома и даже до глубокой ночи. И хотя работа интересная и любимая, стала наваливаться усталость, от которой уже перестали помогать такие короткие выходные. Времени и сил стало не хватать ни на что, постепенно я перестала даже успевать просматривать ленту тестерских блогов, и даже собственный любимый блог оказался полностью заброшенным. Работа, которой бесконечно много и которую надо сделать здесь и сейчас, а лучше вчера, полностью поглотила мою жизнь, а КПД всё падал...

Не знаю, есть ли ещё среди тестировщиков люди, подобные мне сейчас, но если есть, то для них, но в первую очередь для себя я решила вспомнить в своём блоге любимую байку (в моём вольном пересказе по памяти):

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

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

- Мне некогда точить топор, мне надо рубить лес, - устало ответил дровосек и продолжил своё нелёгкое дело.

"Тестирование чёрного ящика" Бориса Бейзера

2010-08-23T01:19:00.000+03:00

После долгих тщетных поисков, под самым моим носом в родной фирме обнаружилась книга "Тестирование чёрного ящика" Бориса Бейзера (издательство "Питер", 2004), которую я тут же радостно взяла почитать. Почти сразу после начала чтения радость моя слегка поутихла, но мужественно дочитав эту книгу до конца, хочу теперь описать о ней свои (очень субъективные) впечатления.

1. О чём эта книга.

В самом названии книги написано, что она - про "технологии функционального тестирования программного обеспечения и систем" (кстати, написана/издана книга была ещё в 1994 году, это на русском языке её издали в 2004). Если почитать то, что написано на задней обложке, то это книга "практичная и понятная, освещающая основные аспекты тестирования чёрного ящика" и "практическое, доступное руководство по современным методам тестирования чёрного ящика". Наверное, я привожу эти цитаты потому, что у меня сложилось о книге несколько другое впечатление.

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

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

2. Что мне понравилось

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

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

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

3. Что мне не понравилось.

Вот в этом разделе хочется написать очень многое, но попробую сформулировать основное.

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

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

В-третьих, само использование графов (смутные воспоминания о которых с институтских времён у меня весьма положительные) в контексте данной книги не показалось мне особо привлекательным - по разным причинам. Например, сам автор рекомендует использовать чаще не графическое представление той или иной модели (графы), а её текстовое выражение (списки), которое мне совершенно не показалось удобным или наглядным. Для ряда моделей построение графов показалось мне не естественным, а слишком тяжеловесным и притянутым за уши. В целом, я не увидела каких-либо значительных преимуществ в предложенном использовании графов, что, однако, может объясняться с одной стороны, отсутствием у меня опыта работы с ними, с другой - отсутствием адекватных задач для их использования.

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

4. Что ещё хочу отметить.

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

"<...> ручное тестирование уже не работает. Оно никогда не работало очень хорошо, не работает сейчас и не будет работать в будущем. Ручное тестирование является самообманом".

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

Кстати, есть в последней главе несколько мыслей о будущем тестирования, которые сейчас, по прошествии более 15 лет с момента написании книги, любопытно почитать. В основном речь идёт о том, что тестирование исчезнет как отдельная профессия и (если я поняла правильно) больше станет обязанностью самих разработчиков.

5. Выводы.

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

Проще надо быть...

2010-07-30T00:35:00.000+03:00

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

Казалось бы - ну зачем ещё нужны эти лишние потери времени, особенно когда лишнего времени и нет, ведь уже найден путь, как можно воспроизвести проблему? Так почему бы не описать его сразу именно в первоначальном виде? Изначально я стала заниматься упрощением полученного сценария воспроизведения проблемы из соображений гуманизма и эгоизма:

- во-первых, мне было жалко программистов, которым придётся скорее всего несколько раз повторить все эти долгие шаги, пока они будут исправлять ошибку;

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

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

- воспроизведя проблему сложным путём, может создаться ложное ощущение, что проблема в принципе редко встречается при стандартной работе с приложением и, соответственно, не является приоритетной; отбросив же лишнее, можно выяснить, что ключевым для воспроизведения проблемы является какое-либо простое действие, весьма обыденное и часто используемое, что может резко превратить найденный баг в важный, срочный и критичный;

- выкристаллизовав последовательность шагов до нескольких ключевых, проще понять причину возникновения ошибки - как программисту для исправления, так и тестеру для поиска аналогичных и смежных проблем;

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

А ещё мне просто нравится докапываться до сути проблемы, спрятанной порой в пяти процентах всех сложных действий, приведших к обнаружению ошибки - ведь это интересно :)

Увидеть жизнь за тестами

2010-06-30T23:58:00.004+03:00

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

Часто доступная документация к проекту является чем-то техническим - описанием элементов графического интерфейса, их соответствиями полям базы данных, зависимостями между данными, алгоритмами расчётов и т.п. То же, что стоит за всем этим, каким обычным процессам нормальной человеческой жизни всё это соответствует - если и описывается, то часто в разработку и тестирование даже не предоставляется. Вроде как - а и зачем? Ведь для разработки и тестирования вполне достаточно знать, что если поле-1 принимает значение "А", то поле-2 должно принять значение "Б". И многие так и работают, не задумываясь о том, что вообще значат эти поля, эти значения, и почему между ними должна быть именно такая зависимость. А на самом деле задуматься может быть весьма полезно.

Больше всего подобная проблема проявляется, когда работа идёт с НЕ русскоязычными проектами. Тогда за непонятными словами часто видятся просто какие-то объекты, которые принимают какие-то статусы, реагируя на какие-то события.

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

И это как минимум помогает сделать тестирование легче, ведь чем отслеживать изменение статусов по алгоритму, гораздо проще видеть за этим осмысленные сценарии и следовать им при проверке. Мы не просто запоминаем, что вместе с изменением статуса объекта-1 должен измениться статус объекта-2, но понимаем, что если отменилось собрание, то должно отмениться и приглашение на это собрание. Мы не просто проверяем, как статус "А" переходит в статус "Б", а мы уже моделируем историю, как человека пригласили, но потом выяснили, что ошиблись, и изменили приглашение на другое время - и лучше понимаем, на что подобные изменения могут повлиять. Тестирование может стать и более осмысленным, и более реалистичным, и более полезным.

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

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

Что такое Pairwise Testing, и с чем его едят

2010-06-11T00:29:00.004+03:00

Не так давно (век живи - век учись) я наткнулась на понятие "pairwise testing" (переведу в лоб как "попарное тестирование", но лучше буду использовать английский термин), заинтересовалась и решила разобраться, что это такое. Достаточно быстро поняв, как работает данная э… техника, у меня сразу возникли вопросы по поводу причин и смысла её использования, найти ответы на которые на днях у меня наконец дошли руки. Обо всём этом я и решила написать (длинно, но короче не вышло :( ).

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

1. Что же это такое

Раз уж я взялась писать о pairwise testing, то, видимо, надо попытаться объяснять, в чём состоит суть данной техники. Не уверена, что у меня получится объяснить понятно и корректно, но я всё-таки попробую :)

Итак, pairwise testing - это техника формирования наборов тестовых данных. Сформулировать суть можно, например, вот так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. Выходит не слишком понятно (и не факт, что правильно), так что можно попробовать объяснять на примере :)

Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей - получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол - мужской или женский; возраст - до 25, от 25 до 60, более 60; наличие детей - да или нет. Для проверки правильности расчётов можно, конечно, перебрать все комбинации значений всех параметров:

№	пол	возраст	дети
1	мужчина	до 25	детей нет
2	женщина	до 25	детей нет
3	мужчина	25-60	детей нет
4	женщина	25-60	детей нет
5	мужчина	старше 60	детей нет
6	женщина	старше 60	детей нет
7	мужчина	до 25	дети есть
8	женщина	до 25	дети есть
9	мужчина	25-60	дети есть
10	женщина	25-60	дети есть
11	мужчина	старше 60	дети есть
12	женщина	старше 60	дети есть

А можно решить, что нам не нужны сочетания значений всех параметров со всеми, а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров. Т.е., например, с точки зрения параметров пола и возраста мы хотим убедиться, что мы точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, ну и женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, мы можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды):

№	пол	возраст	дети
1	мужчина	до 25	детей нет
2	женщина	до 25	дети есть
3	мужчина	25-60	дети есть
4	женщина	25-60	детей нет
5	мужчина	старше 60	детей нет
6	женщина	старше 60	дети есть

Такой подход примерно и составляет суть техники pairwise testing - мы не проверяем все сочетания всех значений, но проверяем все пары значений.

2. Что в этом хорошего

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

Наверное, по приведённому выше примеру может показаться, что разница между этой техникой и перебором всех значений не так и велика. Но это только при таком незначительном количестве параметров и их значений, а чем их больше - тем значительнее разница. Допустим, если есть 50 параметров, каждый из которых может принимать 2 значения, то для полного перебора потребуется количество комбинаций равное 2 в степени 50, т.е. 1 125 899 906 842 624 :) А при использовании pairwise testing можно обойтись всего четырнадцатью комбинациями!

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

3. Почему пары

Лично у меня при знакомстве с этой техникой сразу возник вопрос - а почему именно пары? Почему не тройки значений или не какое-либо "квартетное тестирование"? Есть ли у такого подхода, например, какое-либо математическое обоснование, либо это с потолка взято?

Мне удалось найти вот такое объяснение: когда-то, на основании кем-то выполненного анализа по каким-то реальным данным был сделан вывод о том, что причиной возникновения большинства ошибок являются либо отдельные значения, либо сочетания пар значений (источник тут). Это соображение судя по всему и легло в основу развития pairwise testing.

В принципе, обоснование более ли менее разумное, ведь какие-то исследования были проведены. Однако из такого объяснения также понятно, что правило это не однозначно верное и что справедливо оно будет далеко не для всех случаев. К тому же стоит задуматься и о понятии "большинство ошибок" :)

4. Как же и когда это (не) применять

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

Вот если, например, у нас просто есть формочка с каким-то количеством разных полей, данные из которых просто сохраняются в базу данных, то применение этой техники практически не имеет смысла, ведь данные не взаимодействуют друг с другом (хотя и могут быть нюансы, как эти данные сохраняются в базу)! А pairwise testing - это та техника, применять которую стоит именно в случае взаимодействующих значений (для невзаимодействующих - чаще всего достаточно просто отдельной проверки каждого из параметров).

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

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

В любом случае, если не сравнивать pairwise testing с исчерпывающим тестированием (exhaustive testing), то понятно, что даже применение этой техники достаточно трудоёмко. И в иных случаях, возможно, лучше протестировать несколько наборов наиболее часто используемых реальными пользователями данных, чем затратить массу усилий и протестировать множество сгенерированных наборов, в которые действительно популярные комбинации могут и не попасть.

5. Так что же я хотела сказать

Конечно, я назвала только пару-тройку, но есть большое количество соображений, которые стоит принять во внимание, принимая решение о применении техники pairwise testing - стоит хотя бы обратиться к упомянутым выше статьям (их вообще стоит почитать при наличии интереса к данной теме). А pairwise testing - это просто инструмент, который, как и прочие инструменты, требует использования с умом.

О разработчиках

2010-05-31T23:50:00.002+03:00

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

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

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

Отдельный вопрос - это география: до сих пор не могу смириться с тем, что на работе когда-то выделили "отдел тестирования" и отсадили всех тестеров в отдельную комнату. И до сих пор я помню, как я сидела в одной комнате с группой разработчиков, и мы выдавали самую высокую совместную производительность, которую я видела.

Оглядываясь назад, я понимаю, что моё удовольствие от работы в большой степени обусловлено тем, какие люди попадались мне в качестве программистов на проекте. Я рада, что хороших разработчиков на моём профессиональном пути было много, но наверное, это моё отдельное тестерское счастье, что очень долго я работала с человеком, с которым мы сильно совпадали в отношении к работе - в небезразличии, в увлечённости, в стремлении делать свою работу лучше.

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

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

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

Как мы НЕ автоматизировали тестирование

2010-05-24T23:55:00.002+03:00

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

Итак, ситуация: большой проект, написанный на JAVA; большая распределённая команда - бОльшая часть разработчиков и тестеров на нашей стороне, аналитики и практически всё начальство (тестерское и не только) на стороне немцев.

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

Вывод-1 (элементарный): если автоматизацией не заниматься, то никакой автоматизации не получится, даже если специально для неё купить инструмент :)

Вывод-2: при выборе инструмента важно оценить, насколько он подходит (или может быть адаптирован) под тестируемое приложение.

Вторая попытка была гораздо интереснее, возможно, потому, что инициатива исходила не от немцев (но с их одобрения). В качестве инструмента был найден Marathon - бесплатный и, вроде, заточенный под Java. Также был выделен программист, который не только писал скрипты сам (по предоставленным ему сценариям), но и описывал какие-то общие и доступные всем функции и методы. На нас никто не давил, мы могли писать скрипты по своим нуждам и своему разумению, и - о, чудо! - даже заработали несколько первых моих скриптов. К сожалению, продлилось это всё недолго - сначала на проекте перешли на новые версии компонентов, и скрипты начали ломаться; а потом об автоматизации снова заговорили немцы и Marathon сразу забраковали, поскольку он бесплатный, что как минимум означает потенциальное отсутствие поддержки данного инструмента. И выделенного программиста по каким-то причинам забрали. Примерно так вторая попытка и закончилась, а выводы мои таковы:

Вывод-3: не всегда хорошо, когда используемый инструмент бесплатен; в определённых условиях бесплатные инструменты могут быть сочтены неприемлемыми.

Вывод-4: хорошо, когда созданием фреймворка для автоматизации занимается человек, имеющий представление о программировании.

Вывод-5: автоматизация должна быть своевременной (либо глобальные изменения в проекте должны быть своевременными :) )

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

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

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

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

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

Вывод-7: будущим автоматизаторам желательна хотя бы минимальная подготовка в смысле программирования.

Вывод-8: необходимо, чтобы у автоматизации были чётко поставленные цели.

Вывод-9: желательно автоматизировать сценарии, пригодные для автоматизации.

Вывод-10: на реализацию автоматизации необходимо специально выделенное время.

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

P.S. Ох и сложно после отпуска войти снова в обычное русло, тем более - начать писать что-то чуть менее легкомысленное, чем впечатления от отпуска в своём ЖЖ :)

Ирония опечатки

2010-04-30T00:54:00.000+03:00

Проверяя подключение к Интернету, запустила Internet Explorer, в котором открылась страница с какими-то настойками параметров. Ничего тут настраивать я не собиралась, но всё-таки вскользь страничку просмотрела - и запнулась на каком-то странном слове. В конце концов "слово" я прочитала, осознав, что проблема была просто в пропущенном пробеле. Но прочитав целиком всю фразу с ранее смутившим меня "словом", я рассмеялась - какая ирония! :)

Фрагмент страницы на картинке (открывается в читабельном размере), "слово" подчёркнуто. Оцените - улыбнитесь :)

Даже ошибки могут поднимать настроение, приятного всем тестирования! :)

P.S. Прошу прощения, если бородато...

Тестирование в (моей) жизни

2010-04-28T22:55:00.000+03:00

Недавно в моём подъезде поменяли лифт. Для меня как для человека, живущего на девятом этаже, событие это было знаменательное. Однако интересно то, что и для меня как для тестера это событие тоже не осталось незамеченным.

Нет, я не пыталась нажимать все кнопки подряд, прыгать в лифте и т.п., пытаясь вызвать его сбой. Это было скорее любопытное наблюдение над собой :)

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

Первым делом я для себя отметила, что в моём лифте нет ни одной из двух кнопок, упоминающихся в третьем пункте правил. Меня смутил странный запрещающий знак в левом нижнем углу - какой-то у него неочевидный смысл. Я слегка мысленно поморщилась из-за того, что два из трёх запрещающихся действий сформулированы существительными, а третье - глаголом. Также глаз мой споткнулся о фразу "О всех неисправностях сообщайте дежурному…" - по-русски говорят "обо всех". Ну а то, что не указан телефон, по которому надо обращаться, - это вообще детский "баг".

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

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

Так к чему я всё это? Видимо, к тому, что тестирование - конечно, не просто работа. И не хобби. Я правда не назову это и образом жизни - мне больше нравится формулировка "образ мировосприятия" :)

P.S. Если у Натальи в блоге был опрос/вопрос, то можно считать это моим ответом.

Linux глазами чайника

2010-04-26T00:48:00.000+03:00

Каждому тестеру приходится осваивать достаточно много программного обеспечения, будь то специальные тестерские инструменты, само тестируемое приложение или нечто вспомогательное. Мне же сейчас, в надежде на новый проект, надо хоть немного освоить Linux.

Начав с установки дистрибутива Fedora на виртуальную машину, несложности которой я уже радовалась в своём блоге, я стала понемногу продвигаться дальше.

Сначала был восторг - красивая графическая среда, всё на вид просто и интуитивно понятно, и даже некоторые привычные из винды сочетания клавиш - и те тут работали. А сколько программ, сразу установленных при установке дистрибутива - это же просто фантастика! Графические редакторы, браузеры, офисные приложения и ещё масса всего. А количество установившихся игр - это даже неприлично, потому что среди них нашлась та единственная с удивительным восточным названием "Ши-сен-сё", на которую меня угораздило подсесть. Казалось, мои отношения с Linux с самого начала обречены на успех.

А потом пришло прозрение - прекратив радостно тыкать мышкой в то, что я изначально получила при установке дистрибутива, я попыталась сделать что-то хоть капельку более сложное, например, установить какую-то программу, скаченную из интернета, и поняла, что всё тут не так просто. Да, это не были привычные архивы с таким знакомым setup.exe, который надо запустить и послушно прокликать Next/OK до полной установки. Тут оказалось нечто совсем другое - тут программы даже может быть необходимо перед установкой откомпилировать из исходного кода. Конечно, я узнала, что существует множество вариантов установки софта - и из исходного кода, и из достаточно удобных rpm-пакетов, и с помощью менеджера пакетов yum из интернет-репозиториев… Но мои розовые очки были безнадёжно разбиты - Linux оказался не так прост, как я до этого размечталась.

Понемногу я прочитала две книжки - "Linux для чайников" и "Fedora 8. Руководство пользователя". Обе что-то мне дали и чему-то меня научили. Я даже умудрилась в ходе своих экспериментов по одной из книг добиться того, что моя красивая графическая оболочка GNOME перестала грузиться, и что я даже смогла побороть, робко тыкаясь в текстовом режиме. Но, наверное, главное, что я поняла - это что освоение Linux, хотя бы на уровне даже не самого продвинутого пользователя, требует значительных вложений с моей стороны - хотя это и так было изначально ясно.

Так что на данный момент я, по собственной оценке, - ещё самый что ни на есть настоящий чайник в Linux-е, и мне ещё придётся попыхтеть, прежде чем я дорасту до уровня продвинутого пользователя, который мне надо достичь. Вот только надо бы ещё разобраться, что же должен уметь в Linux-е продвинутый пользователь - может кто-нибудь подскажет? :)

О смене рода деятельности

2010-04-19T00:42:00.000+03:00

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

Интересная всё-таки мысль - менять род занятий каждые десять лет. Конечно, придумано это не только что, и мнение это весьма распространённое. Но вот откуда взялась такая идея? Я подумала, что, вероятно, это сказано для тех, кто чем-то занимается, но не получает от этого удовольствия, и если даже за десять лет удовольствие так и не возникло, то надо что-то менять. А моя сестра предположила, что это придумали для тех, кто чувствует, что достиг в своей профессии всего, чего только можно было достичь, и развиваться уже некуда. И я попробовала примерить всё это на себя.

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

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

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

Книга "Foundations of Software Testing"

2010-04-14T01:01:00.000+03:00

Я давно хотела написать про книгу "Foundations of Software Testing" ("Основы тестирования ПО", авторы Dorothy Graham, Erik van Veenendaal, Isabel Evans, Rex Black) - не как про книгу для подготовки к сдаче экзамена на получение сертификата ISTQB, но как просто про книгу о тестировании.

Когда я прочитала эту книгу, я была удивлена, что никогда не встречала, чтобы её кто-то рекомендовал для прочтения. Хотя в принципе, в этом нет ничего удивительного - ведь книга позиционируется и написана именно для подготовки к сдаче экзамена ISTQB (Foundation level - базовый уровень). Да и сама я её читала именно ради этого. Но не рекламируя саму сертификацию, книгу эту я стала рекомендовать всем знакомым тестерам.

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

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

Второй критерий - это понятность излагаемого материала в книге. Меня очень порадовало во время чтения, как неплохо тут всё объясняется. Например, достаточно большой объем книги посвящён дизайну тестов; и различные техники, применяемые при дизайне, тут описываются и объясняются понятно, с использованием примеров. И краткость книги в этом смысле не помеха - необходимые объяснения, делающие изложенный материал понятным, есть практически всегда. Кстати, примеры экзаменационных вопросов, приведённые в книге, могут тоже оказаться полезными - ведь это своего рода упражнения (с ответами в конце книги!), дающие возможность проверить, правильно ли понята, допустим, какая-то техника.

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

С точки же зрения человека неопытного, мне книгу оценивать, конечно, сложно. И насколько я знаю, среди новичков популярна книга "Тестирование Дот Ком" Романа Савина. Но, не оценивания эту самую книгу "Тестирование Дот Ком", скажу, что с моей точки зрения, хотя бы после её прочтения очень нелишним будет прочитать книгу "Foundations of Software Testing" - для получения более серьёзного и систематичного представления о тестировании.

P.S. Сдача ISTQB экзамена - личное дело каждого; и прошу ни в коем случае не рассматривать данную заметку ни как рекламу, ни как антирекламу ISTQB сертифицирования. Однако при желании обсуждения данной темы - добро пожаловать в комментарии.

Про обезьянок в тестировании

2010-04-08T21:03:00.002+03:00

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

Буквально на днях в одном из тестерских блогов речь шла, в частности, про какую-то работу, ориентированную на «манки-тестеров». Мне вот интересно - неужели кто-то действительно считает других людей, работающих рядом, тупыми обезьянками? Сколько пренебрежения в подобных словах, но неужели те люди, про которых так говорят, этого действительно заслуживают?

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

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

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

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

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

Книга Джеймса Баха "Secrets of a Buccaneer-Scholar"

2010-04-06T16:41:00.005+03:00

Вчера я дочитала книгу Джеймса Баха (на данный момент известного консультанта в области тестирования и одного из "отцов-основателей" исследовательского подхода в тестировании) "Secrets of a Buccaneer-Scholar" и не могу не поделиться своими впечатлениями. Вот только впечатлений много, а в слова они вяжутся плохо. Боюсь неуклюжим отзывом отвадить кого-то от прочтения этой книги, поэтому начну с конца. :) Книга стоящая. Книга не о тестировании непосредственно, но прочитать её стоит. А теперь попытаюсь объяснить, почему я так думаю, и если мои объяснения не смогут вас заинтересовать, то просто плюньте на них и попробуйте прочитать книгу. :)

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

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

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

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

Ещё польза в описанных им методах - тоже часто таких естественных, о которых, читая, думаешь «ну конечно!» или «как интересно...». Какие-то из них хочется сделать своими или даже приписать себе :) И всё, чему вроде как учит эта книга, не воспринимается как поучение - наверное, потому, что всё это передано через призму собственной жизни Джеймса Баха. Это просто его жизнь, его методы, его идеи и его решения, которые он никому не навязывает, но которыми просто делится.

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

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

"<…> I like running with a pack, but not following a herd" ("<…> мне нравится бежать со стаей, но не следовать за стадом")

Конечно, пойти по пути Джеймса Баха может не каждый, да и надо ли? А вот пойти по своему собственному пути, наверное, под силу любому. Может ли помочь в этом книга? Ну, по крайней мере, стоит попробовать её прочитать :)

"Perhaps the secret of happiness is finding the games we love to play, instead of learning how to win at games we hate" ("Наверное, секрет счастья в том, чтобы найти те игры, в которые нам нравится играть, вместо того, чтобы учиться выигрывать в тех играх, которые нам ненавистны").

От книги остаётся любопытное ощущение, как будто в уютной обстановке за чашечкой чая я поговорила о жизни с интересным собеседником. И эта беседа явно не останется просто приятным воспоминанием :)

Исследовательское тестирование: заблуждение об "изучении"

2010-04-02T02:53:00.004+03:00

Во время дискуссии, развернувшейся вокруг моего поста про исследовательское тестирование (ET), всплыло много вопросов, с которыми я решила последовательно разбираться. И чтобы сразу стало понятно, с чем именно я решила разбираться в первую очередь, приведу цитату из комментариев к моему посту:

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

Подобные мысли никак не соответствовали моему представлению о ET и не вязались с моими собственными тестерскими убеждениями.

Но насколько я поняла, высказанная мысль - это достаточно популярное заблуждение, касающееся ET, проистекающее, возможно, из самого его определения (одного из них, наиболее популярного, благодаря его краткости):

исследовательское тестирование - это одновременное изучение, дизайн тестов и их выполнение (exploratory testing is simultaneous learning, test design, and test execution)

Похоже, именно слово "изучение" (learning) может вводить в заблуждение и заставлять думать, что ET предполагает получение информации о тестируемом продукте исключительно в процессе его тестирования, т.е. взаимодействия с ним.

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

К счастью, развёрнутое объяснение этого самого "изучения" в ET нашлось в документе "A Tutorial in Exploratory Testing" Кема Канера, начиная с такого определения на с.41:

Изучение: всё, что может направить нас в том, что тестировать, как тестировать или как распознать проблему (Learning: Anything that can guide us in what to test, how to test, or how to recognize a problem)

Сразу становится понятно, что "изучение" - это не просто знакомство с программой в ходе её тестирования, а нечто гораздо большее. Это очень многое, включая и анализ всевозможных источников информации о явных и неявных требованиях к продукту, и даже изучение того, как надо изучать. Всё, что пишет Кем Канер по этому поводу, лучше у него и читать - лично я не рискну даже пытаться пересказать это всё своими словами, т.к. слишком уж это объёмно, многогранно и подлежит основательному осмыслению.

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

Люблю ли я TDD (test-driven development)

2010-03-31T14:05:00.001+03:00

Недавно в разговоре с одним знакомым я сказала, что не люблю TDD (test-driven development, разработка через тестирование). Наверное, первая мысль, которая возникает после такого заявления - это как тестер в здравом уме может вообще говорить подобные вещи?

Я примерно представляю, в чём смысл TDD, я слышала про него от разработчиков, я почитала немного о нём в Интернете. И насколько я понимаю, TDD - это в принципе отличная штука! Мало того, что это как минимум реализация модульного тестирования, которое не так часто в реальной жизни и встретишь, так TDD ещё и позволяет сделать код более качественным, легче переносящим изменения, рефакторинги и т.п. В результате получается гораздо меньше потенциальных проблем. Ну и какому тестеру это может не понравиться?

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

С таким подходом мало того, что можно и не получить возможность когда-либо поработать на проекте, где используется TDD, так можно ещё и без работы остаться. Как будто TDD - это панацея какая-то. Ну и как при этом можно TDD любить?..

Конечно, моя нелюбовь вовсе не связана с самим TDD, а относится к тем, кто так чудесно TDD трактует и воспринимает. Но всё-таки просто поразительно, как часто и с какой изобретательностью могут извращаться хорошие идеи...

Бесконечное хождение по лестницам

2010-03-26T11:36:00.002+02:00

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

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

Ступенька 1 - "Всё хорошо". Это удобная мягкая ступенька, на которой скорее сидят. Это значит, что человека в общем-то всё устраивает. Хорошо периодически отдыхать на первой ступеньке. Но это редко длится долго.

Ступенька 2 - "Что-то не так". Рано или поздно человек понимает, что что-то всё-таки не так. То ли прозрел, то ли что-то разладилось, то ли носом ткнули. На этой ступеньке уже не посидишь - она очень неудобная: проблема уже осознана, а решений пока нет. Если застрять на этой ступеньке, то в конце концов станешь очень несчастным. Так что лучше выбрать одно из двух: либо вниз на "Всё хорошо", убедив себя или действительно убедившись, что осознанная проблема и не проблема вовсе; либо карабкаться дальше вверх.

Ступенька 3 - "А как надо?". Тут начинаются поиски того, как же должно быть, вместо осознанного "не так". Очень неспокойная ступенька - то сам чего-то придумать пытаешься, то книги умные ищешь, то людей опытных расспрашиваешь... И застрять тут можно надолго, и важно не забыть в процессе поиска, зачем сюда вообще пришёл. И если тут не потеряться, то вариантов снова в общем-то два: если не повезёт, и никаких приемлемых ответов не нашлось, то с грустным "нет в жизни счастья" переползаешь на ступеньку вниз; а если повезло и нашлось что-то вдохновляющее - тут самый путь дальше наверх.

Ступенька 4 - "Ну, и как оно работает?". Если на предыдущей ступеньке было неспокойно, то на этой может быть ещё хуже: пытаться подружить найденную теорию с реальной практикой - дело очень непростое. В борьбе за идею можно и здоровье подорвать. И если ничего не получается, то хорошо, если на одну ступеньку назад вернёшься, а в худшем случае - и вовсе кубарем на две ступени вниз скатишься. Так что счастлив тот, кто умудрился воплотить идею в жизнь и ещё и не разочароваться в результатах. Тогда снова попадаешь на первую ступеньку - уже следующего этажа.

Вот так и ходим туда-сюда по ступенькам в надежде одолеть ещё этаж. Кто-то стремительно взлетает вверх, кто-то чуть карабкается. Лестница в любом случае бесконечная, но очень грустно осознавать, сколько времени потеряно где-то посреди этажей.

P.S. Ну вот, хотела написать про саморазвитие в области тестирования, а получилось, похоже, про жизнь вообще :)

Спасибо, Джеймс Бах! (Про исследовательское тестирование)

2010-03-22T11:30:00.001+02:00

Я много раз встречала понятие "исследовательское тестирование" ("exploratory testing") и интуитивно понимала, что это - именно то, чем я в значительной степени занимаюсь на протяжении лет. Однако это понятие упоминалось в тех же книгах обычно вскользь, как просто один из существующих подходов; но как основной подход, принятый в качестве стандарта, неизменно описывалось тестирование по предварительно написанным тест кейсам.

И вдруг я прочитала статью Джеймса Баха (James Bach) "Exploratory Testing Explained". Мне сложно передать всю ту гамму чувств, которую я испытала! Вот оно - вот описание и обоснование того, к чему я когда-то сама пришла. Вот тот человек, который осмелился заявить во всеуслышание, что такой подход не просто имеет право на существование, но ещё и разумен и эффективен.

О, как долго книги и люди пытались внушить мне, что так работать неправильно. И какое счастье почувствовать, что ты не одинок, и что есть те, кто думает подобно тебе. Спасибо, Джеймс Бах и люди вроде Вас, за то, что вы ведёте эту борьбу и заставляете исследовательское тестирование заявить о себе!

У меня всегда вызывало искреннее недоумение стремление написать заранее все необходимые тест кейсы и тестировать строго по ним. Конечно, в определённой степени предварительное написание тест кейсов уместно, но разве могут проверки по ним полностью заменить и сравниться с гибкостью и адаптивностью исследовательского тестирования, выполняемого умелым тестером, который вкладывает в это все свои опыт, знания, инстинкты и вдохновение?!

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

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

P.S. Испытывая столь значительный эмоциональный подъём, я даже решилась написать Джеймсу Баху письмо, что для такого несмелого и нерешительного человека как я практически невообразимо. Написать - чтобы как минимум действительно сказать ему спасибо, а как максимум - уточнить у него, правильно ли я в принципе понимаю суть исследовательского тестирования. Каковы же были мои удивление и радость, когда на следующий же день я получила ответ! В целом, Джеймс Бах подтвердил, что я на правильном пути. Конечно, теперь мне ещё предстоит очень многое прочитать, узнать, осмыслить и, вероятно, многому научиться. Но направление теперь понятно; и известно, где искать помощь и совет в случае необходимости.

Сказка про тестеров, которые боролись-боролись, да не то выбороли

2010-03-18T13:03:00.002+02:00

Решила я описать одну поучительную и правдивую историю.

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

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

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

И вот через какое-то время пришёл одному из тестеров первый новый документ на тестирование. Был тот документ страниц под 100, написан он был всё больше псевдокодом и SQL-запросами, со множеством перекрёстных ссылок и минимумом пояснений, т.е. мягко говоря сложновоспринимаемый. И дали этому тестеру пару дней сроку, чтобы документ протестировать и все свои замечания письменно сформулировать, потому что через пару дней запланировано за границей совещание, где этот документ и обсудится.

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

А тем временем Большой Начальник с проекта ушёл - то ли на повышение, то ли просто на другой проект. И поняли тогда тестеры, что и надеяться им больше не на кого. И шло как-то дальше введённое "тестирование", проводили за границей по документам собрания, да только толку от всего этого по сути не было, хотя формально и добились тестеры всего того, что они просили.

Вот такая вот грустная история.

Давняя эта история, да вот сейчас я задумалась: поучительная история - это спору нет, а вот чему она учит - не так и просто сказать. Больше всего приходят на ум мысли грустные - мол, всегда оно так, с инициативой снизу и получается, все хорошие идеи при реализации и испоганятся. Да только мысли это всё неконструктивные.

Но вот нашлись как будто мысли разумные:

- если уж пытаться за что-то бороться, то надо продумывать заранее, что именно в результате получить желательно;

- и продумывать надо всё детально и предлагать решение чёткое и с конкретными условиями, чтобы даже при формальном подходе к реализации испортить всё оказалось хотя бы очень затруднительно;

- потому что если вдруг и появляется реальный шанс что-то изменить, то не факт, что позже будет возможность внести ещё какие-то коррективы;

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

Вот такие у меня получились выводы.

"Автоматизированное тестирование программного обеспечения"

2010-03-15T11:48:00.002+02:00

Вероятно, в жизни каждого тестировщика рано или поздно наступает момент, когда встаёт вопрос об автоматизации тестирования. Именно поэтому я решила прочитать и описать свои впечатления от книги "Автоматизированное тестирование программного обеспечения. Внедрение, управление и эксплуатация" (авторы: Э.Дастин, Дж. Рэшка, Дж.Пол; издательство "Лори", 2003).

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

1. О чём эта книга.

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

2. Что мне понравилось.

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

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

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

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

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

3. Что мне не понравилось.

То, что я для себя выделила в книге как негативные моменты, в основном очень субъективно, но, тем не менее, перечислю:

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

- периодически у меня создавалось впечатление, что достаточно часто какая-то часть информации в книге излишне повторяется;

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

4. Что ещё хочу отметить.

Примерно пятую часть книги занимают приложения, которые представляют в той или иной степени отдельную ценность:

- статья про тестирование требований;

- обзор существующих инструментов тестирования (на момент написания книги);

- план развития тестировщиков (с уклоном в автоматизацию);

- пример тестового плана (также учитывающий внедрение автоматизации);

- и кратко изложенные рекомендуемые методы и советы по организации работ с учётом внедрения автоматизации (со ссылками на главы из книги).

5. Выводы.

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

Этот (не)страшный зверь Linux

2010-03-10T14:06:00.002+02:00

Наверное, существуют ещё люди типа меня, которые никогда не сталкивались с Linux. И, вероятно, именно таким людям может быть интересно краткое описание моего первого опыта самостоятельной установки Linux.

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

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

Из книги "Linux для чайников" я наконец выяснила, что же означают загадочные слова типа Ubuntu, Suse и т.п., которые мне приходилось слышать - так называются дистрибутивы Linux, т.е. что-то типа "обёрток" для ядра Linux, отличающихся, в частности, включенными утилитами и программами установки. Для своего эксперимента я выбрала бесплатный дистрибутив от компании Red Hat - Fedora; выбрала только потому, что именно этот дистрибутив описывался в купленной мной книге.

Итак, запасшись
- программой установки VMware workstation v.6.5.1,
- дистрибутивом Fedora core 10 (в виде образа диска),
- и несколькими часами свободного времени,
я приступила к установке Linux.

Процесс в принципе оказался несложным:

Шаг-1. Установка VMware: простое Windows-приложение, типовая установка, подвохов нет.

Шаг-2. Создание новой виртуальной машины: жмём на кнопку "New Virtual Machine" и пошагово отвечаем на вопросы мастера создания виртуальной машины. Из "сложностей" - выбор источника для установки ОС (указание пути к образу диска с дистрибутивом) и определение типа ОС (я выбрала Linux и из-за отсутствия Fedora в списке версий - наобум "Other Linux 64-bit").

Шаг-3. Подготовка к установке Linux: процесс начинается автоматически после завершения создания виртуальной машины. У программы установки симпатичный интерфейс и достаточно стандартные для установки ОС вопросы типа выбора языка (есть русский!), часового пояса, способа создания разделов на диске (для виртуальной машины совсем не страшно) и т.п. Из подвохов - странный вопрос о проверке корректности установочного диска: после подтверждения корректности появилось сообщение об отсутствии этого самого диска; так что лучше, наверное, от этой проверки вообще отказаться.

Шаг-4. Установка Linux: после завершения предыдущего шага начинается непосредственно установка всех необходимых пакетов. Процесс достаточно длительный – я не засекала, но что-то в районе часа (возможно, я выбрала слишком много дополнительных приложений к установке). Главный подвох - после установки всех 1551 пакета установка зависла на сообщении "Установка загрузчика…". На свой страх и риск я при этом перезагрузила свою виртуальную машину.

Шаг-5. Завершение установки: к моей радости, процесс продолжился после перезагрузки виртуальной машины - пошла загрузка системы, и я попала на экран "Добро пожаловать". Тут последовало ещё несколько вопросов типа корректировки времени и создания пользователя для моей системы, и всё.

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

Оказалось, что установить Linux - как-то даже совсем и не страшно. Мне не понадобилась для этого ни купленная книжка, ни даже звонок другу. Конечно, это только установка только одного дистрибутива и только на виртуальную машину; и, разумеется, разобраться в этой системе – это то, что мне ещё предстоит, и там явно всё не так и просто; но зато теперь я Linux больше не боюсь, это не такой и страшный зверь :).

P.S. Не могу отделаться от ощущения, что название для этого дистрибутива придумал кто-то русский с чувством юмора - ведь "Fedora Core" так похоже на "Федорино горе", неужели это совпадение?!

Первая аксиома тестирования

2010-03-05T11:43:00.010+02:00

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

Мой первый проект был для меня своего рода испытанием. Я тогда была совсем зелёной девочкой, с самым поверхностным представлением о тестировании, и при этом оказалась единственным тестером на проекте.

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

тестировщик лучше всех должен знать, как должно работать приложение

Возможно, цитата уже не точная, и вероятно, можно поспорить, что кто-то что-то в проекте может это знать так же хорошо, или даже лучше - суть не в этом.

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

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

Зачем (мне) этот блог

2010-03-04T11:30:00.003+02:00

Удивительно, но у меня возникло внезапное желание завести свой блог.

Казалось бы, зачем он мне нужен, при том, что и так-то времени на всё не хватает.

Но похоже, что блог - штука действительно полезная, вот из каких соображений:

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

2) если ставишь себе какую-то цель и озвучиваешь её в блоге - то как бы подписываешься под тем, что обязуешься эту цель достичь. Т.е. блог дисциплинирует.

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

Что ж, кажется, что это вполне весомые причины завести свой блог.

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

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

Поэтому и писать я собираюсь в этом блоге примерно на тему тестирования:

- о том, что было, т.е. о своём опыте (хоть выясню, какой он у меня - профессиональный опыт :) );

- о том, что есть, т.е. мысли о делах текущих и насущных;

- о том, что будет, т.е. о своих планах и их реализации.

И пусть всё это будет кому-нибудь полезно, хотя бы мне :)