вторник, 29 декабря 2009 г.

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



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

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

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

Когда я только пришел на работу, централизованно можно было только собрать совещание. Когда я уходил, проектировщики могли выгружать из своей системы данные технологам в их систему. Наши экономисты уже автоматически формировали отчетность, в том формате которую требовали бухгалтеры и финансисты. Централизовано работала электронная почта с одним доменом и службой Active Directory. Централизованно же мы закупали ПО и лицензии. Пытались влиять, опять же централизованно, на закупку/распределение компьютеров. На внутреннем веб-сайте с использованием IIS+IE+Active Directory   работала система одного окна для поисковых систем по архиву, внутренним базам данных. Было чем гордиться. Почти  пять лет я потратил на автоматизацию и объединение разрознненых систем и процессов.

И вот то же самое начало я вижу и сейчас (про то же самое я, кстати, читал и в How We Test At Microsoft): отсутствие централизации в процессе обеспечения качества, и самое главное - отсутствие единого продукта для автоматизации работы специалистов  по обеспечению  качества (и тестировщиков).

Что же мы имеем:

Excel - незаменим при построении тестовых roadmap-ов, собственно тестов и даже для создания документов.

Word - тоже полезен для создания документов. Отчеты, спецификации,... (если бы не корпоративные политики давно бы использовал только Open Office Write и Calc, кстати говоря).

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

MS Project - диаграмму Гантта никто не отменял.

HP Quality Center - хранить тесты, планировать регрессионные тесты...ну хоть что то же нужно автоматизированно готовить - хотя бы регрессионные тесты.

Confluence/TWiki/Sharepoint/ - коллективный разум должен хоть что-то после себя оставлять в виде файлов, ссылок, статей и картинок.

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

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

А что бы я хотел иметь?

Я бы хотел иметь систему. Одну. Чтобы я мог сам построить workflow.  Чтобы я видел версию документа не в SharePoint, а мне приходило оповещение, поскольку я в роли тестировщика указан в данном проекте.

Хочу полноценную систему документооборота с архивом.

Хочу систему управления требованиями в том же виде, что и в Word или Wiki, но если я помечаю абзац как требование - это требование начинает жить своей жизнью: с версионностью, историей изменений, приоритетами и подтверждениями.

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

 А представьте, как прекрасно выглядят деревья тестовых сценариев с различными тегами (или категориями, или ярлыками).

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

А если вам нужно узнать среднее время для прохождения помеченных вами или выбранных системой автоматически тестовых сценариев '=sum(...' уходит в прошлое. Ведь для этого есть специальная колонка!

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

О да, моя система могла бы многое. Если бы вы спрашивали о фиче1, вам бы предлагали фичи, который рассматривались с этой фичей раньше (фича66, фича121).

Моя бы система на вопрос о environment ошибке предлагала бы контакты суппортеров и workaround. Более того, она сама бы рассылала сообщения суппортерам. Ты звонишь по контакту, а он, какое чудо, занимается твоей проблемой уже почти три минуты.

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

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

Моя система сама рассылала бы QA Daily Report и табель.

Моя система сама бы расчитывала показатели: сколько багов найдено и пофикшено, сколько багов пофикшено в текущем релизе, сколько багов на душу населения команды мы прос...ли и получили outages от бизнеса.

Моя система была бы идеальна...

Именно поэтому бы ее никто и не смог использовать.

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

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

И все таки, если уж понеслась такая ярмарка...

Моя система управления процессом обеспечения качества была бы OpenSource.

Моя система была бы модульной и позволяла бы внедрять себя поэтапно. Строилась как конструктор.

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

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

понедельник, 28 декабря 2009 г.

У каждого проекта должна быть своя модель процесса разработки.



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

Agile, XP, CMM...

Фреймворки, методы, методологии...

Стандарты, манифесты, спецификации...

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

У меня не было опыта внедрять что-то целиком. Собственно и полномочий таких тоже не было. Я можно сказал внедрял "серебряные пули" в отдельно взятом процессе, подконтрольному мне. Сначала в системное администрирование и поддержку. Потом в разработку. Теперь в тестирование и обеспечение качества.

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


Есть такой человек Сергей Архипенков, и, вы, его знаете. У него есть книга "Лекции по управлению Программными Проектами", про нее, вы, конечно, тоже слышали. И есть в этой книге пара предложений, до которых я дошел когда-то сам. Но, в силу человеческой природы, нигде не записал. А Сергей записал. Причем даже не он ее придумал, а Алистер Коуберн. Но в свою книгу Сергей все таки записал. И есть в этих двух предложениях то, почему некоторые команды внедряют успешно новое (неважно что), а некоторые нет.

У каждого проекта должна быть своя модель процесса разработки.
У каждой модели - свое время.

Нужно дозреть. Проекту. Процессу. Команде. Специалисту...

Внедрять новое - это конечно замечательно.  Новое бодрит кровь, делает нас вновь молодыми ;). Но всему свое время.

В садике - игрушкам.

В зрелом возрасте маразму.

Надеюсь, вашему проекту это не грозит.

вторник, 22 декабря 2009 г.

Если вы учите человека чему либо, он этому никогда не научиться.


Бернард Шоу был сто раз прав. Обучение чему либо, без практики это то, что сейчас губит высшее образование и знания вообще.

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

Прошел месяц. Документации оставалось все еще много. Ко мне подошел team lead Юра.
-Читаешь?
-Ага, изучаю - ответил я.
Юра кивнул головой.
- И когда закончишь.
Вот тут до меня, спустя месяц чтения, наконец стал доходить сокровенный смысл того, что я делаю. Я тупо читаю документацию. Я изучаю поведение графического интерфейса по бумажке. Мне вспомнились лекции, которые нам читали в университете. MS Word рисуемый на доске. Программный код программы распечатываемый на бумажке (100-200 страниц 10 шрифтом)...

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

Бернард Шоу остановился только на обучении. Мне кажеться он даже прав - в обучении ты можешь и слышать, и видеть, и делать...и даже ломать ;). Но именно практика делает из студента специалиста, а из специалиста профессионала.

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

Если вы учите человека чему либо, он этому никогда не научиться.

Бернард Шоу

вторник, 15 декабря 2009 г.

If you want to get a high quality product out of test...


Доброго дня суток.
Целый месяц прожил без Интернет. Это было мучительно, больно, скучно и тоскливо. Но я выстоял. А куда деваться если в новой снимаемой квартире его нет.
В итоге цитата недели висит уже месяц. Застоялась однако. Запашок.

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

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

If you want to get a high quality product out of test, you have to put a high quality product into test

Во истину так, ибо каждый отвечает за качество своей работы.


среда, 18 ноября 2009 г.

How We Test At Microsoft - рецензия

Нужно ли читать хорошие книги? - ответ очевиден.

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

Читать нужно стараться все. Но тщательно читать хорошие книги. Плохие книги листать и щуриться. И готовиться писать свои, под другим углом зрения.

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

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

Я бы отнес книгу How We Test At Microsoft к рекламным проспектам Мелкософта с более глубоким профессиональным уклоном. Данная книга не принесет вам большего, если вы уже прочитали хотя бы одну книгу Канера или Майерса или все статьи Блека ;).

Но есть и дополнительное очарование у данной книги. И оно состоит в том,что там куча жизненных кейсов и фактов о тестировщиках. О тестировщиках в известной и самое главное очень успешной компании.

Например то, что тестировщики у них называются Software Development Engenier in Test (SDET) и  они сами занимаются дебагингом и даже программированием!

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

Новичку будет полезно прочитать How We Test At Microsoft, потому что в ней много теории. Человеку, уже читавшему другие книги, полезно будет освежить знания и подумать, что идеальное бывает только на рекламном проспекте, а в жизни все намного скромнее.

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

How We Test At Microsoft важна тем, что там есть правда (что крайне редко можно получить от Мелкософта). И очень надеюсь, что правдивые книжки появяться вскоре и у других компаний. Лично я бы хотел целую серию таких книг.

Как мы тестируем в Яндексе.

Как мы тестируем в Гугле

Как мы тестируем в Sun

Как мы тестируем в Oracle

Как мы тестируем ....






понедельник, 16 ноября 2009 г.

Who Owns Quality

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

Одно из самых распространенных заблуждений ответ, что

  команда тестирования отвечает за качество.

Более "продвинутые" сделают ошибку отвечая что

отдел или специалисты обеспечения качества (для программного обеспечения SQA) отвечают за качество

Но правильным ответом будет :

Все отвечают за качество

На каждом своем участке  работы, специалист отвечает за качество своей работы.

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

понедельник, 9 ноября 2009 г.

Первый полноценный тестировщик в Microsoft

Я продолжаю читать книгу How We Test At Microsoft. Купить ее не сложно. Так же не сложно ее просто найти (делаю многозначительное подмигивание левым глазом).

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



Но есть в этой книге и интересное. Например имя первого тестировщика в компании:

As the story goes, the first-ever tester at Microsoft was a young high school intern by the name of Lloyd Frink, who started in June 1979.

понедельник, 2 ноября 2009 г.

Design is the act of systematically thinknig or planning through a solution before begining implementation

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

Давно хотел достать (не купить конечно же, но достать, не платил за софт так за книгу раскошелюсь - щас, разбежался) книгу How We Test At Microsoft. Можно посетить их сайт http://www.hwtsam.com или если некуда девать деньги и лень искать в сети то купить на Амазоне.

Собственно первую часть книги можно опустить. Ее можно выразить словами Стива Балмера "I love this company!". Все остальное... вот остальное нужно почитать. И даже запомнить.

Выношу в цитату недели небольшую мысль про дезайн тестовых сценариев. И да прибудет с вами сила - противостоять вселенскому злу Редмонского Гиганта  ;)

Design (test case) is the act of systematically thinknig or planning through a solution before begining implementation. 
Alan Page. How We Test At Microsoft


четверг, 22 октября 2009 г.

Карма, пестициды, танцующий медведь и все все все


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

Об избирательности профессионала в комментариях к данной заметке упомянул и Максим Гриневич. Спасибо ему за коммент, который подтолкнул к продолжению темы и написанию данной заметки.

Собственно речь пойдет о парадоксе/эффекте пестицида  - о том, что нам мешает видеть дефекты.



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


В выпуске журнала "Научная Америка" ( Scientific American) за май 1957 года была статья об открытии области мозга, имеющей сетчатую структуру, и лежащей в его основании. Эта область отвечает, главным образом, за доступ к вашему осознанному знанию, это кнопка, которая включает ваше восприятие идей и информации, это то, что позволяет вам спать, даже когда включена музыка, но заставляет вас проснуться, если в соседней комнате заплачет ребёнок.
Подобно компьютеру, ваш мозг наделён функцией поиска, и куда гораздо более совершенной. Кажется, будто она программируется на то, на чём мы сконцентрированы. Этой парадигмы придерживается множество людей, в том числе и мы. Мы замечаем только то, что удовлетворяет нашей внутренней системе восприятия в заранее определённом контексте. Если вы окулист, вы заметите в заполненной комнате всех людей в очках, если вы архитектор, вы заметите детали комнатного дизайна. Если вы прямо сейчас сконцентрируетесь на красном цвете и оглядите комнату на предмет красных вещей, то заметите даже самые маленькие из них.

Выделенное жирным выношу (с большим опозданием) в цитату недели.

Чтобы вас окончательно проняло смотрите ролик.



вторник, 13 октября 2009 г.

Такая добровольная каторга

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

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

понедельник, 12 октября 2009 г.

Randy Pausch - выступление на шоу Опры

Наткнулся в одном из блогов и просто не смог не продублировать. Удивительной силы духа человек Randy Pausch.

Какие у нас проблемы?

Цитата этой недели взята не из книги. Эта фраза одного неизвестного мне менеджера.

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

Какие у нас проблемы?

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

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

В том числе от тестировщика ;).

вторник, 6 октября 2009 г.

Карма тестировщика



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


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

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

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

Я новичок в компании и, следовательно, нужно все пройти с нуля, наприме нужно получить аккаунт к внутренней чат системе. "У вас буде аккаунт через две недели". Ага, сщаз - два месяца жду. Сломался автоматический "раздаватель" аккаунтов, и админ готовит список на более чем 600 лиц требующих нового аккаунта...Уж не знаю проблема процесса появления новичков или просто "счастливая случайность".


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

Есть огромный плюс - я ломаю софт за деньги, но и есть минус - я постоянно замечаю дефекты и вокруг себя. Можно было бы сказать, что у всех то же самое. Согласен. Только не все запоминают ;).

Подводя итог.

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

Это бывает даже очень весело.

Хотя, бывает и немного больно - нос еще побаливает.

понедельник, 5 октября 2009 г.

Be critical, check everything

Опять неделя прошла без цитаты - работа поедает аки питон.

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

Be critical, check everything

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

вторник, 22 сентября 2009 г.

A Good Tester has these qualities:

Есть замечательная статья Classic Testing Mistakes  (залежи полезного тут), в которой приводятся личностные характеристики Хорошего Тестировщика:

- methodical and systematic.
- tactful and diplomatic (but firm when necessary).
- skeptical, especially about assumptions, and wants to see concrete evidence.
-  able to notice and pursue odd details.
- good written and verbal skills (for explaining bugs clearly and concisely).
- a knack for anticipating what others are likely to misunderstand. (This is useful both in
finding bugs and writing bug reports.)
- a willingness to get one’s hands dirty, to experiment, to try something to see what
happens.


Brian Marick// Classic Testing Mistakes

Что тут добавить спросит обыватель тестировщик?  - Я бы добавил еще знание иностранных языков ;-)

четверг, 17 сентября 2009 г.

100 спартанцев из QA-QC....

ПОТОМУ ЧТО МЫ ТЕСТЕРЫ!!!!!

Ну как то так можно начать обзор моего первого опросника на тему "Кем вы были в прошлой жизни"




Собственно я решил остановиться на цифре в 100 проголосовавших и на дней до голосования в 105. Кругленькие цифирки меня радуют (где бы нормального психолога найти чтобы спросить: чего со мной такого в раннем детстве случилось, что меня на кругленькое тянет).

Удивляет пункт [Другое] = 30%. Т.е. 30 % заходивших ко мне в гости до тестирования были людьми не связанными с IT. Бездумно добавил в опросник [Не IT -шник].  Каюсь. И если суммировать, то среди тестировщиков и прочих специалистов по качеству окажется 39! Не знаю как к этому относиться если честно.

Еще кое что удивляет [Со студенческой скамьи]= 33%. Т.е. 33+39+6 (непостоянных не IT -ов) = 78% людей вышли на желтую дорогу качества программного обеспечения не имея глубоких познаний в IT! Можно же и так эти циферки повернуть?

И получается что  всего 40% (меньше половины) до тестирования были более или менее глубоко (а может и не очень) знакомы с процессами IT\softo-делания и пр.

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

Удачных выходных. А мне еще до выходных в поезде - ту ту!





среда, 16 сентября 2009 г.

Почему люди всегда любят - в массы?

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

Лично я против толпы.

Пугает меня толпа.

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

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

Ого-го-го-го +5 балов! - и индивидум бежит разбрасывая слюну и вопли...

Собственно заметка задумывалась как реклама ресурса http://community.software-testing.ru, получилась антиреклама. Скатился в мрачное брюзжание о собственном глубоко индивидуальном Я (индивидуальность - куда без нее).

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

И к тому же материал на ресурсе сырой. Нет Канеров, Майерсов, Блэков... Баг тут вот нашел, там нашел, тут вот мыслишка пробежала... Хотя ругать себя конечно это прогрессивно, но безрезультативно. Нужно плодить монументальные творения (было бы о чем ).

Теперь взгляд с другой стороны.

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

Пора заканчивать брюзжание.

Есть коммьюнити. Перспективное (надеюсь). Многочисленное (наверное будет). Главное, что там собираются тестировщики - а это поверьте очень веселые и умные ребята (те кто со стажем больше моего ;)) .

понедельник, 14 сентября 2009 г.

Просто тестер - плохой тестер.

Как и почти любая моя цитата недели, текущая имеет свою историю. Книжную.

Я прочитал книгу "Эта странная жизнь" Даниила Гранина... Или даже нет. Сначала я прочитал книгу "Тайм-драйв" Глеба Арханельского, а уж потом книгу Даниила Гранина. Если честно, обе эти книги нужно было прочитать давно. Как минимум полгода назад. Тайм менеджмент - он и у тестировщиков Тайм Менеджмен ж-). Когда нибудь нужно поделиться моей системой расстановки задач и приоритетов. Но не суть - сейчас не об этом.

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

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

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

Роберт Хайнлайн.

Я же вешаю новую цитату дня над своим столом:

"Тестировщик не может быть хорошим тестировщиком, если он только тестировщик".

Это правда. Хороший тестировщик должен знать программирование (из 10 балов где-то баллов 6), проблемную область (тщательнее может быть только бизнесс-аналитик), менеджмент - управление (круче только Стивен Р. Кови, Эндрю Гроув, Ли Якокка...) и конечно быть общительным (почти как HR или PR).

Удачной недели.





вторник, 8 сентября 2009 г.

Вы хотите тестов? - их есть у меня...

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

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

Было у русского работника 200 тест кейсов. Хороших, продуманных тест кейсов. Хозяин возьми и скажи ему: "А сделай в два раза больше тест кейсов и - за неделю".

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

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

Индийцы: "Да, не вопрос".

Через неделю 400 тестов протестированы силами двух индийцев.

Русского сотрудника ругают и переводят в другой проект. Индийцам перепадает проект и перспектива более близкого будущего отношения.

А что собственно сделали индийцы...

Во-первых они разделили 200 тестов на 400. Грубо каждый тест на два.

Во-вторых они протестировали не 400 тестов, а 100 - в случайном порядке.

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

Намечается парадокс.

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

2. Русский проявил упорство и настойчивость (поскольку думал как нужно делать правильно), но получил нагоняй.

Есть конечно вопрос о профпригодности заказчика (ну или его представителей). Но задача была поставлена - кто с ней справился, то и герой.

понедельник, 7 сентября 2009 г.

Ни надежность, ни функциональность...

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

понедельник, 24 августа 2009 г.

Взгляд на трудности с другой стороны.

Иногда в жизни встречаются мысли, которые стоят целой книги.

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

А сколько раз говорили и думали так сами?

Совсем недавно мне встретилась картинка, которая поставила меня на другую сторону вопроса.

Теперь я чаще (не всегда но чаще) задаю себе только вопрос: "А что такого еще я могу сделать?", когда любое из многоточий вдруг случается. Картинка ниже. Текст ее я выношу в цитату недели (копирайт demotivation.ru).


понедельник, 17 августа 2009 г.

Что нужно мне, как новичку в новой компании.

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

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

Я хочу план своего развития в фирме. Если фирма ждет от меня чего то "странного", то я хочу конкретного - как я буду дальше развиваться. Какие курсы готова предложить фирма на 3-6-9-12-24-26 месяцев. Если компания ХОЧЕТ иметь ХОРОШЕГО специалиста то, ЧТО она готова сделать ради меня:
- какие курсы,
- какое повышение оплаты,
- какое продвижение в должности.
Возможно что данный план нужно будет писать мне самому - я и к этому готов.

Я хочу узнать о фирме все, что она готова мне рассказать. Для этого я хочу внятный план лекций либо внятный список людей от которых я могу потребовать (ПОТРЕБОВАТЬ) рассказать мне о той или иной части бизнеса компании (понятное дело, что договариваться о встрече я должен либо сам либо со своим начальником).

Я хочу наставника, куратора, старшего брата, друга - назовите как хотите того человека, который будет первые 3-6 месяцев моей нянькой (понятное дело не 24 часа в день и даже не 8 часов в день, но хотя бы 30-60 минут в начале или конце дня).

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

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

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

Я хочу знать поможет ли компания мне в трудную\счастливую минуту (свадьба, похороны, рождение ребенка и пр)

Я хочу знать кого мне дергать чтобы получить канцтовары, новую веб-камеру или гарнитуру

Я хочу знать, что меня любят и ценят и более того будут любить и ценить, если я и дальше буду продолжать работать хорошо.

И отдельно чего я не хочу.

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

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

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

И все таки, изначально я еще хочу чтобы меня спросили: "Как ты, Саша, хочешь провести свой первый день?"

Цель сообщения об ошибке является ее исправление


Целью сообщения об ошибке является ее исправление

Сем Канер и др. "Тестирование Программного обеспечения"

понедельник, 10 августа 2009 г.

Почему люди верят в магические числа?

Почему люди верят в магические числа? Я вопрошаю о числах в заголовках:
- похудей за 1 месяц!
- выучи язык программирования за 21 день!
- стань менеджером за 2 недели!!!

Кстати о последнем. В околоменеджменсткой литературе наиболее широко принято применять принцип магических чисел :
- 7 навыков высокоэффективных людей С. Кови,
- Правила тестирования (7 правил)
- Правила Ошманова (8 правил)
- 9 навыков лидеров описанных Ли Яккока в книге "Куда подевались все лидеры",
- 11 правил, которые подростки, по мнению Била Гейтса, никогда не узнали бы в стенах школы

Самые мощные из магических чисел , которые встретились мне в Интернет это:
- "Сто правил NASA для руководителей проектов"
- "101 признак того, что ваш проект горит синим огнем!"

Казалось бы ну бери эти правила, формируй эти навыки и флаг тебе в руки. Но!:

- Ли Яккока сам же вопрошает - Черт подери, куда подевались все лидеры (правила то есть!)?

- Существует ли 8,9,10 правило тестирования? Да, конечно. Я думаю и 1024 правило найдется.

- Если убрать 101-ый признак - перестанет ли ваш проект разваливаться? Ну да, конечно - надейтесь.

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

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

Ай да Стивен Кови, ай да сукин сын! - в хорошем смысле этого слова, конечно.

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

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

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

Думай!

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

И принять.

Или не принять.

Но сперва Подумать.

Я ставлю этот глагол цитатой недели. Пусть он не от QA и даже не от IT, но он из жизни и подходит всем.

четверг, 6 августа 2009 г.

Кем вы были в прошлой жизни?

Не секрет, что люди с малых лет не готовятся сознательно стать QA\QC (по крайней мере в России). До того как стать тестировщиком лично я прошел тернистый путь - от студенческой скамьи, до эникейщика, затем до чисто-программиста и только спустя 6 лет после окончания университета меня случайно занесло в QA.

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

Отсюда родился вопрос - кем QA бывают до QA?

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

А Кто Вы были в прошлой жизни?

среда, 5 августа 2009 г.

Анкета допросник SQA

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

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

Анкета опросник для собеседования на позицию QA

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

Вопросы о прошлой компании\месте работы и текущих ожиданиях:

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

Расскажите о вашем текущем месте работы: компания, должность, обязанности.

По тому как человек рассказывает о компании можно судить насколько он интересуется работой. Вовлечен ли он в общий процесс своей текущей работы либо просиживает штаны.

Какой у вас самый любимый проект и почему полюбили?

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

Какой у вас самый нелюбимый проект и почему не любили?

Таких проектов может и не быть. Но лично у меня есть. И если они есть — значит человек не боится признаться в своих ошибках. Это многого стоит.

Как бы вы могли оценить ваш вклад в работу вашей компании?

Есть легенда. Спросили у трех камнетесов что они делают. Один ответил что он зарабатывает на жизнь. Второй ответил что точит камни. Третий ответил что он строит храм. Нужно искать третьих.

Почему решили сменить работу?

Это пустой вопрос, но в очередной раз показывает кто перед нами: Камнетес, Зарабатывающий либоСстроящий Храм.

Почему выбрали нашу компанию?

Всегда полезно узнать откуда растут ноги. Здоровому пиару для компании всегда есть место.

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

Пустой вопрос, но может показать многое.

Что вы можете предложить компании - чем бы вы могли ей помочь или навредить. Чем быть полезны и тому подобное?

Пустой вопрос, но может показать многое.


Вопросы по технологиям

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

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

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

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

2 — знаю что такая технология есть, несколько раз сталкивался, знания поверхностны.

1 — слышал что такая технология есть, знаю где достать документацию, могу изучить в течение 1 месяца.

0 — никогда не слышал и не сталкивался.

Вполне очевидно что SQC должен уметь профессионально работать с компьютером - не как неопытный пользователь, а как достойнеший IT спец (умеет переустанавливать Win\Lin - значит мозги уже есть).

Bug Tracking System

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

Знакомы ли вы с другими продуктами по управлению процессами QA.

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

- система управления требованиями,

- система управления тестами (типа TestLnik) и т.п.

Знание Windows

- Что такое файловая система, какие файловые системы для MS Windows вы знаете?

- Какие версии ОС MS Windows вы знаете (желательно что бы человек слышаел не только Vista\Xp но и понимал что есть Home\Basic Professional и пр.)?

- Что такое реестр Windows?

- Какие программные средства работы в среде Windows вы можете еще назвать (те которыми пользуетесь)?

- Каким почтовым клиентом вы пользуетесь? Почему?

- Что используете для time Management

и пр. и пр. и пр.

Вполне очевидно что QA данные вопросы не нужны, но они показывают общий уровень специалиста.

Возможно создать такой же список вопросов по Linux

Прочие технологии

Определить дополительные технологии и программные средства с которыми должен уметь работать QA сложно. Если собеседуется специалист на автоматизированное тестирование, то очевидно должны подбираться языки программирования, DBMS etc.


Вопросы о саморазвитии

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

Какие книги вы прочитали в последние месяц, год?

IT, QA и близкие книги. Впрочем человек должен читать не только профессиональные книги, но это только мое мнение.

Какие сайты/блоги по тестированию знаете?

Если человек может назвать www.software-testing.ru, http://www.rbcs-us.com это очень хорошо.

Ведет ли свой профессиональный блог.

Если человеку есть что сказать и он говорит — это хорошо. Я тому пример ;)

Проходил ли обучение или курсы по тестированию

Если не проходил - то и фиг с ним. Я вот тоже только один вебсеминар прошел, остальное в книгах, блогах и материалах конференций искал.


Вопросы по предметной области

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

Что такое жизненый цикл ПО и цикл разработки ПО.

Комментарии излишни.

Какие модели разработки ПО знаете, в чем они отличаются

Водопад, циклический водопад, Agile: scrum, xp.

Что такое требование к ПО и какие у требования есть аттрибуты


Какие документы при разработке ПО используются

ТЗ\FDD, Sodftware Specifications, Test Plan (test case)

Какие стандарты по разработке ПО вы знаете

Знает что есть 34 и 19 — не плохо, знает IEEE 829 – значительно лучше, знает в добавок ISO 12207 – человек в теме!


Вопросы по QA

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

Какие документы по организации процесса тестирования вы знаете.

Ответы в вопросах ниже

Что такое Test Case и его структура?


Что такое Test Plan и его структура?


Что такое Bug Report и его структура?


Какие виды тестирования вы знаете?

Ответы в вопросе ниже

Что такое и объясните принципы
- Installation / Uninstallation testing
- Perform boundary testing
- Functionality testing
- Virus Check
- Scenario testing
- Perform database testing
- Field Entry testing
- Interface testing
- Regression testing
- Perform application interoperability testing
- Perform OS interoperability testing
- Perform Hardware, Network compatibility testing
- Architecture reviews
- Code reviews
- Functional and Test Spec Review
- Requirements, Design docs Review
- Usability testing
- Specification based testing
- Test Progress and Summary Review
- User Documentation Review
- International/Localization
- Perform error handling testing/Recovery testing
- Performance testing
- Submit testing summary report
- Automated Testing
- Stress testing

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

Чем отличается Severity от Priority

Классика жанра )

Тестирование белого ящика, черного ящика, серого ящика


Что такое бетта тестирование


Что такое Regresion Testing


Что такое Acceptance Testing


Что такое Smoke tests


Что такое модульное, интеграционное и системное тестирование.


Что такое Requirement traceability matrix


Что такое Bug life cycle


Что такое процесс управления конфигурацией в разработке ПО и в тестировании


Что такое процесс управления изменениями в разработке ПО и в тестировании


Что такое баг. Приведите пример. Какие типы багов вы знаете

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

Какой по вашему идеальный программный продукт для автоматизации работы QA

Данный вопрос показывает насколько человек понимает что такое QA и чем он отличается от QC. Также можно определить насколько человек понимает принципы автоматизации работы QA.

Какие процессы тестирования могли бы быть автоматизированы.

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

Что такое QA и что такое QC

Данный вопрос для общего развития. Хорошо если собеседуемый понимает что QC включен в QA, и что QA это не тестирование, а обеспечение качества на всем цикле разработки ПО.

Для чего проводится тестирование ПО

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

Нужно ли тестировать документацию?

Ответ — да. Это называется «Тестирование требований к ПО”. Собеседуемый должен понимать, что требования в ТЗ могут быть: неправильно сформулированы, противоречащими и просто нереализуемыми.

Какие цели тестирования вы бы выделили?

Лично я бы выделил три цели:

- поиск багов,

- оценка качества продукта (ни в коем случае не обеспечение качества, от того сколько багов найдено качество ПО не улучшается),

- оценка рисков (поскольку выпуск продукта с малым качеством не есть гуд, всегда найдуться риски — например, что кто то умрет или на вас подадут в суд)




Практические задачи

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

Посадить за комп и дать листок, чтобы напечатал текст.

По тому как человек работает с клавиатурой можно понять - как хорошо он работает с компьютером вообще.

Провести собеседование на английском на одну из тем по QA

Очень легко показывает уровень английского у человека.

По заданной интервьиром теме:
- создать формализованные требования,
- создать формализованные test-cases,
- создать тест план,
- создать предпологаемые баг репорты,

Примеры систем для данного тестирования
- Система авторизации на любом сайте электронной коммерции
- Дана консольная программа. Программа позволяет вводить последовательно три числа. Каждое число подтверждается клавишей Enter. После того как введено первое число, можно вводить второе. После того как введено второе число, может быть введено третье. После того как введено третье число программа сообщает - является ли треугольник с данными сторонами равнобедренным.
- Банка с кофе.
- Стерка
- Авторучка
- Солонка
- Любая другая вещь. Чем неожиданнее будет вешь тем лучше. Еще лучше если с самого начала собеседуемый начнет сам задавать вопросы. Какая именно банка, какая форма, какой материал. Т.е. еще лучше если он изначально сам создать список требований по объекту и начнет эти требования тестировать.

Сколько комнат в нашем офисе

Данная задача на внимательность и подразумевает, что человека проведут по всему этажу.



Задачи на сообразительность


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

Почему крышка от люка круглая?

На самом деле крышка не круглая — в ней есть выступы для того чтобы ее установить.

Ну конечно она имеет круглую форму и очевидно для того чтобы не упасть (любая иная фигура с углами или формы может провалиться в люк).

Есть 10 кроликов

Есть 1000 бутылок с вином

Одна из бутылок содержит яд. Как определить в которой?

Задача на двоичное мышление. Кролик пьет (1) или не пьет (0), соответсвенно мы можем закодировать 2 в 10 позиций

0000000000 — первая бутылка

0000000001 — вторая бутылка и т.п.

Есть дом. В доме четыре стены. У каждой стены по окну. Все окна выходят на север. Сколько таких мест на земле?

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

И тому подобное....

Для получения дополнительных примеров достаточно прочитать книгу Как сдвинуть гору Фудзи (См. Список литературы)


Список литературы:

Книги (все можно найти в электронном варианте):
- Тестирование ПО. Кем Канер и др.;
- Искусство тестирование. Майерс;
- Tестирование dot com. Роман Савин;
- Как сдвинуть гору Фудзи. Уильям Паундстоун;

Сайты:
1) http://www.rbcs-us.com/software-testing-resources/library/basic-library.html (в том числе и особенно Freightliner Test Level Matrix);
2) www.software-testing.ru;
3) Глоссарий терминов используемых в тестировании ПО
http://www.rstqb.org/index.php?id=25,0&sitelang=ru;
4) Более простой глоссарий http://testirovschiki.ru/glossary.php;
5) FAQ по тестированию http://www.ruleworks.co.uk/testguide/;

Конфереции:
SQADays (например http://it-conf.ru/ru/content/190.htm);

Обучение тестировщиков:
http://www.luxoft-training.ru/training/school/72;
http://www.avalon.ru/PPS/QA/Courses/About/?CourseID=905.

вторник, 4 августа 2009 г.

Mustread для управленца.

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

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

Так вот. Читая про т.н. timemanagement заметил - умные мысли по управлению собой и своим окружением можно подчеркнуть и не из совсем подобных книг. Например книги "Выживают только Параноики" Эндрю Гроува или "Куда Подевались Лидеры" Ли Якокка и Кэтрин Уитни весьма и весьма способны прокрутить мозги в разных направлениях (смотреть с разных сторон очень полезно, проблема только - найти это самое место, откуда твоя сторона считается другой). Натыкаясь на сайты складировал упоминаемые книги и их рецензии, но сегодня наткнулся на сайт Mustread, на котором это все делается в постоянном режиме.

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


понедельник, 3 августа 2009 г.

Профессионализм тестировщиков дело рук самих утопающих


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

Во истину так.

среда, 29 июля 2009 г.

Хорошие новости нужно часто повторять!
















Не могу пройти мимо хорошей новости. Хорошие новости нужно повторять.

Selenium обзавелся очередным дополнением Selenium Inspector.

Библиотечка позволяет содержит всякие вкусности для облегчения работы с табличками, assert-ами, легким парсингом DOM модели. Короче немножко улучшений и со вкусом.

В купе с тем что Selenium RC обновился до 1.0.1 и в скором времени обещают объединение с Web Driver - это вообще становиться мечта практикующего QA автоматизатора.

понедельник, 27 июля 2009 г.

Программная ошибка как артефакт существующей и правильной спецификации

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

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

Одним из распространенных определений программной ошибки является - расхождение между программой и ее спецификацией. Не пользуйтесь этим определением. Расхождение между программой и ее спецификацией является ошибкой тогда, и только тогда, когда спецификация существует и она правильна.
Сем Канер и др. Тестирование ПО

А если спецификации нет или она неправильна? - Скачите Шура, скачите.

среда, 22 июля 2009 г.

Паттерны тестирования: Condition\Time waiters

Количество велосипедов растет. Это радует.

Долгое время (ну, как долгое - месяца полтора) мучился, пытаясь сделать тесты Selenium-а более стабильными и не зависимыми от задержек AJAX. В конце концов наделал кучу TimeWaiter - ов. Хотел даже заметку написать. Похвалиться. Типа очередной велосипед готов. Но удачно наткнулся на более фундаментальный труд ;) Решил что данный труд претендует на более продвинутый паттерн.

Имя паттерна: Condition waiter
Назначение паттерна: Разработка автоматизированных тестов ориентированных на изменение состояний объекта.

Перепечатывать не буду - дам ссылку: http://blog.vitorg.ru/webtesting/2009/07/14/selenium-ojidanie-zaversheniya-ajax

понедельник, 20 июля 2009 г.

Цитата недели от Сема Канера: ценность плана тестирования

Ценности в жизни QA - это вообще отдельная ветка размышлизмов. Но сегодня будем цитировать мудрых. Например Сема Канера. У одного их столпов QA выявление ценностей звучит с легким бюрократическим уклоном:

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

среда, 15 июля 2009 г.

Паттерны тестирования. Timestamped Name

Я уже упоминал про желание складировать полезные мысли о проектировании автоматизированных тестов - паттернах и стратегиях тестирования. Данная запись одна из, надеюсь, многих и связана с использованием времени - как одного из вспомогательных факторов при создании объектов в процессе тестирования.

Timestamped Names

Имя паттерна: Timestamped Names
Назначение паттерна: Создание уникального имени для объекта

Во время прогона тестов, часто возникает ситуация когда необходимо создать новый объект. У любого объекта есть, как минимум, две характеристики: уникальный идентификатор и имя. Уточним, что имя должно быть более или менее понятным после прочтения (Good, Project etc), т.е. изначально все таки задается текстовая константа, по которой объект и будет именоваться.

У нас есть несколько путей задания задания константы:
- hardcoded константа,
- константа в конфигурационном файле.

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

Случается, что имя объекта также должно быть еще и уникальным. И тут указание имен в конфигурационные файлы выносить проблематично. Создаваться может несколько объектов одного типа, но требуются разные имена. Создавать для каждого объекта отдельную константу - слишком сложно (например имена для 1000 объектов). Нужен smart dynamic name. В данном случае - добавление временного префикса или постфикса к имени объекта. Само имя может как задаваться hardcoded, так и храниться во временном файле.

Например мы создаем товар Goods и и после выполнения timestamped операции получаем имя Goods_<...>, где <...> - это timestamped индекс. В будущем если мы захотим найти товар, с вероятностью 99,99999 мы найдем по данному имени только один товар. Оставшийся 0,00...1% я оставляю на проблемы с потоками, из за которых могут возникнуть два товара с одинаковым именем. Эта проблема известна и решаема, в каждом языке программирования - по своему.

В качестве альтернативы Timestamped Names можно использовать Indexed Name. Данный паттерн к имени создаваемого объекта добавляет числовой префиск или постфикс, который после именования очередного объекта увеличивается на единицу или на определенный шаг.