Сегодня, после «релиза», одним из первых (надеюсь =)) прочитал отличную книгу, написанную Славой Панкратовым, которая называется «
Черная книга менеджера». Эту книгу я назвал бы сборником мыслей и фраз, с которыми хозяин\директор компании может говорить с подчиненными менеджерами. Причем, именно тех мыслей, которые возникают в негативных, я бы даже сказал конфликтных ситуациях. Это придает книге своеобразную изюминку, заставляя читателя прочувствовать на себе те мысли, которые старается донести автор. То, что эти мысли описаны в негативном ключе, делает их более запоминающимися и выворачивает мозг наизнанку. Особенно если принять во внимание общую атмосферу «фана» в ИТ и такой огромной обеспокоенности человеческим фактором в индустрии. Эта книга опускает на землю IT «ЗВЬОЗД». Надеюсь что, прочитав её, Вы не наступите на грабли и не сделаете того, что заставит владельцев компании, и Ваше начальство относится к Вам, так как описано в этой книге. Слава,
[...]
Мы не останавливаемся на достигнутом в стремлении повысить полезную составляющую нашего клуба. Замотивировав сами себя первым письмом так,что захотелось делать еще и еще, мы решили дать больше полезных материалов. Чтобы усилить практическую составляющую Клуба практического тестирования, мы решили добавить в программу Клуба специальный бонус: «Пакет рабочих листов и контрольных списков для тестировщиков». В пакет этой документации войдут краткие одно-двух страничные рабочие документы для тестировщиков и команд тестирования: 
Все никак не утихнет буря вокруг опроса "чего не хватает тестировщикам" и "что им мешает". В разговоре с 
[...] 
В последнее время довольно много уделяют внимание таким терминам как исследовательское тестирование и Ad Hoc тестирование. Даже именитые 
Для меня конференция началась еще за долго до её официального начала. Для меня все началось в один прекрасный майский день. Когда я читал закрытый форум участников сообщества Стратоплан, я подумал о том, что было бы неплохо провести мини конференцию подобную прошедшей в Питере и планирующейся в Москве. Ну, вот мысль пришла и после двухчасовых терзаний своего мозга, и безуспешных попыток найти минусы в этой идее я решил, что было бы неплохо спросить у харьковских участников сообщества. Идея была поддержана и прочно укрепилась в моей голове. Собственно это для меня и стало началом подготовки к конференции. Был проработан костяк программы, из рядов стратоплановцев с помощью естественного отбора были набраны докладчики. Изначально я планировал сделать «домашнюю конференцию», основной целью которой было бы даже не получение, новых знаний по менеджменту, а нетворкинг. Хотелось познакомиться со всеми участниками клуба, пообщаться с умными людьми, послуш 
Приветствую всех. Я давно не писал ничего нового в блог. С одной стороны это было вызвано большой загрузкой по работе, с другой стороны это было вызвано именно тем событием, которое неприклонно приближается и стартует завтра - SQA Days 9. Хочу поделиться последними часами подготовки и своими планами с Вами. Итак, Я прибыл на место проведения SQA Days 9 в город с более чем тысячелетней историей, 3-ю «столицу» России, гордый и непреклонный город – Казань. Город встретил меня серым небом и кучами снега в аэропорту. Мне, как туристу, повезло найти разговорчивого таксиста татарина, родившегося тоже в Украине, «земляки» сказал он мне и рассказал немного про город. Он удивлялся, почему так много людей в приезжает на ближайшие пару дней в Казань, мне пришлось приподнять завесу тайны, сказав ему, что здесь будет проходить конференция, связанная с «компьютерными технологиями». Я не стал мучить его вопросом «Кто такие тестировщики?», мы же все таки «земляки» =).
Хочется выразить некоторые мысли о метриках, которые можно использовать, когда на проекте ведется разработка с использованием гибких методологий. Этот список не претендует на полноту, а скорее призывает использовать его как основу для принятия решения, какие метрики помогут именно на вашем проекте. Также нужно всегда помнить, что метрики ради метрик еще никогда никому не помогали. Количество незавершенных задач из прошлых спринтов, перенесенные в текущий спринт – с помощью этой метрики можно предсказать, как будет эволюционировать качество разрабатываемого продукта. Чем больше незавершенных задач переносится, тем хуже. Чем меньше, незавершенных задач вообще, тем лучше =)). Довольно логично использовать также предел переносимых незавершенных задач, для того чтобы контролировать это число(призрак Kanban маячит на горизонте :=)). Когда лимит будет пройден нужно постараться обратить основные усилия на решение тех юзер стори, которые путешествуют из спринта в спринт, ну или Product Ownerу пр 
Новость, которая не относится к тестированию на прямую, но довольно интересна сама по себе. Крупнейшая софтверная корпорация мира Microsoft планирует в четверг подать официальную жалобу в Еврокомиссию в связи с неконкурентными действиями Google Inc. на рынке интернет-поисковиков. Об пишет в своем блоге старший вице-президент и главный юрист Microsoft Брэд Смит. Как сообщает The New York Times, это первая в истории Microsoft антимонопольная жалоба.
Ловлю себя на мысли что практически всегда при выборе покупки отдаю предпочтения вещам с гарантией качества. Раньше за собой такого не наблюдал, но вот сейчас заметил, что стандарты ISO, IEEE, ГОСТы, все-таки придают уверенность при выборе и покупке. В IT индустрии так же существует множество стандартов, следования которым предают уверенности и приносят новых клиентов компаниям разработчикам ПО. Естественно, что сертификация ради сертификации или следование стандарту ради самого стандарта не имеет смысла и не приносит денежных накоплений компаниям.
Коллеги доброго времени суток, Хочу сделать анонс доклада, который я буду презентовать в эту пятницу. Тема доклада «10 подводных камней в тестировании. Взгляд со стороны заказчика». К сожалению поприсутствовать на докладе удастся только жителям славного города Харькова или гостям «первой столицы Украины», которые в пятницу будут находиться в городе. Полный анонс доклада Вы сможете прочитать на сайте 
Вышла в свет 4-я часть повествования о том, как Google тестирует. Еще пару частей и можно будет возводить эту тему в ранг сериала для тестировщиков =). Эта часть повествует о конфигурационном менеджменте и тестовых окружениях. Тема довольно интересная и поэтому кроме цитирования частей статьи я немного поделюсь своим опытом работы с тестовыми окружениями. Гугл использует 4-х уровневую структуру, через которую должна пройти функциональность, перед тем, как попасть к реальным пользователям. Canary Channel is used for code we suspect isn't fit for release. Эта фраза говорит обо всем. В своей практики я не видел такого уровня, с таким предназначением. Обычно, каждый разработчик устраивал этот уровень у себя на рабочей станции или с использованием виртуальной машины, отлаживая написанный им код, экспериментируя с различными подходами в разработке.
Начинаю восстанавливаться после болезни, готовлюсь к конференции в Казани и вот буквально сегодня ко мне пришло осознание того, что я давно не читал около профильной литературы. Осознание пришло не само, осознание пришло вместе с ссылкой на книгу Хенрика Книберга и Маттиаса Скарина «
Я думаю, любой человек в своей жизни задавался вопросом, того, как формируется цена на определенный товар. Например, почему батон одного завода производителя стоит одни деньги, а другого, другие или почему цена на автомобиль «ВАЗ», отличается от автомобиля марки «Toyota». Немаловажную роль в формировании цены на любой товар играет качество производимой продукции. «Чем качественнее, тем дороже» - это утверждение знакомо всем еще с детства. В отношении ценообразования информационные технологии не отличаются от других областей производства. Цена на программное и аппаратное обеспечение зависит от того, насколько качественно будет сделана работа и какие именно процессы тестирования и QA предлагает компания разработчик.
В последнее время замечаю у себя признаки прокрастинации. Не восторге от этого чувства, поэтому собрался с силами и решил выложить на блоге свои мысли о командах. Управляя командой тестирования на большом тяжеловесном проекте, невольно задумываешься о том, сколько денег заказчик вкладывает в качество (отдел тестировщиков 40+ человек), а потом всплывают в голове слова представителей Google, о том, что автоматизация + ответственность программистов за качество это наше будущее и невольно задаешь себе вопрос «В чем сила, брат ?». Считаю, что правильного ответа нет и у каждого своя правда. Хотел поговорить об одном феномене, который в своей книге «Человеческий фактор» описали ДеМарко и Листер и который я прочувствовал на себе. А именно о ситуации, когда клиент в начале проекта нанимает такое количество сотрудников, которое совсем не нужно и понадобится лишь к середине проекта, а может и позже. Зачем такое делать. Давайте подумаем.
Сегодня хочется поговорить о концепции тестирования в Гугл, перевод поста Джеймса Виттейкера, о том каким образом эта компания добивается практически безупречного качества своих сервисов и продуктов. Наслаждайтесь. В Google качество не равно тестированию. Да и я уверен, что это также и где-либо еще. «Качество не может быть протестировано» это утверждение должно быть правдой. От автомобилей до ПО, если продукт с самого начала сделан не правильно, то правильным он уже никогда не станет. Спросите любого производителя автомобилей, которому хоть раз доводилось массово отзывать модель автомобиля с рынка, насколько это дорого не обращать внимание на качество. Как бы то ни было, это совсем не так просто и верно как звучит. В то же время, несмотря на то, что качество не может быть протестировано, также очевидно то, что без тестирования невозможно создать, что-либо качественное. Как может кто-то решить что, то, что Вы сделали, обладает высоким качеством, без тестирования. Простым ре� 
«Аутсорсинг», модное слово уже на протяжение более чем 10 лет. Всю свою карьеру я работаю в компаниях, предоставляющих именно такие услуги, услуги аутсорсинга программного обеспечения. Когда я был еще студентом, мне нравилось хвастаться, тем, что я работаю в аутсорсинговой компании. Я был уверен, что вся разработка и тестирование только так и построена, на разработке ПО для иностранных заказчиков. Через несколько лет я стал более опытным тестировщиком и просто перестал задумываться об этом термине и это естественно, работы стало больше, ответственность и обязанности тоже росли. Поэтому, на вопрос «Где Вы работаете?» я бездумно отвечал «в аутсорсинге тестирования ПО», не задумываясь о смысле своих слов. Как говорится «все приходит с опытом», а я еще и могу добавить, что, если повезет, то и вовремя. В один прекрасный момент мне стало интересно, а какие еще есть виды разработки ПО. Какой выбор предоставляется для компании, рассматривающей вариант разработки коробочного пр� 
В январе появилась отличная инсайдерская статья о том, как происходит процесс работы в Facebook. Меня вообще интересуют такие утечки информации, ну и, естественно, было очень интересно, как ребята тестируют свои продукты. Итак, вот выдержка из текста статьи про отдел качества в Facebook 
Для успешной карьеры специалисту довольно важно понять к чему он стремится, что именно, из профессиональных знаний, стоит развивать в первую очередь, где есть пробелы и что нужно, чтобы их устранить. В этом Вам может помочь информация из 
Публикую перевод второй части интервью с Тест Директором компании Google - Джеймсом Виттейкером. Это интервью было проведено в середине 2010-го года, спустя год после первого интервью с Джеймсом. В этой части освещены темы противостояния Google и Microsoft, отношение Джеймса к SCRUMу, размышления о платформах тестирования и многое другое. Напомню, что перевод первой части, взятой в 2009 году, Вы можете прочитать по этой 
Издавна существовала традиция передачи легенд и сказаний от одного поколения другому. Считаю, что традиция хорошая и продолжу её в 21м веке =). Сегодня поделюсь историей о «Черной Команде» В 60х годах прошлого века, в одной большой американской компании, занимающейся разработкой ПО, руководство озаботилось проблемой качества разрабатываемых продуктов. Проанализировав производительность сотрудников отдела качества, руководители заметили, что некоторые тестировщики работают лучше других, они находят больше багов, справляются с нетривиальными задачами, более внимательны и делают работу быстрее, чем другие. И тогда руководством компании было принято решение выделить самых лучших тестировщиков и создать отдельную команду экспертов, целью было отдавать этой команде тестировать только самые критические области разрабатываемого ПО, только самые сложные задачи
Чем выше должность, тем меньше механической, бездумной работы приходится выполнять. Это хорошо, мозг работает, человек шевелит извилинами и не даёт себе засохнуть. Но иногда бывают такие моменты, когда есть задача, а ты вот не знаешь, как к ней подступиться. Думаешь, как написать эти тест кейсы, чтобы эдакого написать в секции критериев окончания тестирования в тест плане, уже изнемогаешь над метриками плотности дефектов за итерацию. А мысль так и не приходит. В такой ситуации человек может допустить много ошибок, начинает приплетать ненужную информацию, лить много воды в документы, уменьшая их значимость. Ведь работу сделать надо и раз задача поставлена, то результат нужен к определенному сроку. Однозначно это не правильно и нужно не делать работу, создавая видимость, а приносить ценность и пользу для проекта. Тут может помочь хороший способ, который называется "Inversion".
Приветствую Всех, сегодня хочу поговорить о гиганте индустрии. Компании, в которую мечтают попасть тысячи IT профессионалов. Мы поговорим о Google. Я пользуюсь сервисами этой корпорации ежедневно. Я думаю что они очень хороши (и это не реклама =) ). 
Не уверен, что кто-либо публиковал эту новость до меня. Поэтому, с Вашего позволения, рад сообщить о новогоднем подарке, сделанном нам компанией Google. Я говоорю о том, что стали доступны видео материалы и слайды презентаций с конференции GTAC#5, которая проводилась 28-29 октября 2010 года в городе Hyberabad, Индия. Также, Вы можете 
Довольно давно читаю, периодически всплывающие, темы полезности и важности сертификаций по тестированию. В основном, это касается аттестаций проводимых International Software Testing Qualifications Board. Вот и московское сообщество тестировщиков задалось темой аттестации. Хочу высказать своё IMHO по теме. Прежде всего, хочется отметить, что сам я имею 2 сертификата ISTQB (Foundation level, Advanced Test Manager level). Я довольно серьезно подхожу к любой сертификации и начинаю готовиться заранее, по книжкам, стараясь разобраться в предметной области. И первая и вторая сертификации не были исключением в моем случае. Пошёл сдавать я их, в силу своего характера, в своих целях, я люблю ставить себе высокие планки и доказывать, что я могу достичь их. Понимаю тех людей, которые из принципа не хотят сдавать экзамены и считают их бесполезными, такое мнение так же имеет право на жизнь. Поддерживаю мнение, что «чем больше сертификатов в мире, тем меньше их ценность». Согласен с утверждением, что «наличие сертификата само по себе, не говори 
Во времена повсеместной «аджайлизации» проектов, мы работаем с необходимым минимумом документации. Это облегчает жизнь клиенту, это облегчает жизнь менеджеру, это облегчает жизнь команде. А всегда ли это идет на пользу проекта? Хм… ответ не однозначен. Я согласен, что короткие итерации, позволяющие нам увидеть какую-то часть работающего продукта - это хорошо, но вместе с тем, в таких итерациях, мы допускаем те ошибки, которые мы в принципе могли бы не допустить, имея более полную документацию и дизайн системы. При этом эти ошибки не всегда отлавливаются на этапе итераций и могут дожить до релиза системы. Такие дефекты-динозавры стоят очень дорого при исправлении. Моё мнение, что минимум документации или наличие лишь высокоуровневой документации (по типу use caseов) ведет к возникновению "false positives" и "false negatives". Немного пролью свет на эти понятия. 
Коллеги, приветствую! В новый год принято приходить с новыми начинаниями, идеями и проектами. Несмотря на то, что мой блог еще очень молод, я не хочу отходить от доброй новогодней традиции. Поэтому, рад представить Вам новую рубрику блога «Тестирование, Backstage», посвященную жизни и профессиональной деятельности инженеров по тестированию и обеспечению качества на просторах, пост советского пространства. Я думаю, что Вам будет интересно почитать о том, как работают люди в других компаниях. Как там у них все построено, какие процессы, как относятся к обучению сотрудников, какие люди вообще работают. И так, первый пост в этой рубрике появится буквально «на днях». Буду очень рад Вашим отзывам о такой рубрике, насколько она полезна, о ком бы Вы хотели там почитать, какие вопросы хотели бы там видеть. 
Мы рады представить Вам гостя программы «Tesing the Limits" - Рекса Блека. Широко известного гуру в мире тестирования. Рекс является одним из самых успешных авторов, спикеров и практиков в индустрии. К слову, его последняя книга 
Помню свой первый опыт в роли ведущего тестировщика на проекте. Тогда ко мне пришел руководитель проекта и дал задачу поставить на колеса процесс тестирования, определить жизненный цикл дефекта и вообще процесс, по которому эти самые дефекты будут эффективно обрабатываться. Задача была очень интересная, в то время мы стали активно пользоваться возможностями автоматизации процессов Microsoft Visual Studio, я взялся за изучение Team Foundation Server. Эта надстройка студии позволяла пользоваться очень большим фреймворком для работы с дефектами, запросами на изменения и т.п. Всё шло довольно хорошо, до того как я не набрел в TFS, на 2 таких интересных понятия как Severity и Priority. Сначала я не придал особого значения тому, что в этой системе (а потом, как оказалось и в большинстве систем с багтрекинг функциональностью) есть разделение между «Критичностью» и «Приоритетом». Мой предыдущий опыт подсказывал, что можно обойтись одним значением «Приоритета» и не задавать больше ни� 
Каждый день мы встречаемся с рисками, выходя на улицу, мы рискуем упасть и сломать себе что-нибудь, рискуем быть ограбленными, рискуем быть уволенными с работы, рискуем получить по голове кирпичом с крыши. Мы повсеместно и ежесекундно окружены рисками. Тем не менее, эволюцией в нас заложены инстинкты самосохранения, так же у нас есть здравый смысл, проявление эмоций и чувств, мы умеем мгновенно анализировать различные ситуации. Все это помогает нам снизить до нуля или уменьшить влияния определенного риска на нашу жизнь. Часто мы даже не замечаем, как предпринимаем, какие-либо действия для избегания риска. Это все отлично работает с рисками в повседневной жизни, но почему то идет прахом в профессиональной деятельности. С этим сложно, что-то поделать, возможно, через несколько миллионов лет, эволюцией в нашем организме будет заложен новый ген, отвечающий за подсознательное предотвращение рисков в работе. Ах мечты, мечты… =) Какие же риски поджидают тестировщико� 
Представьте ситуацию, Вы приходите работать в уже существующий проект, на должность инженера по тестированию. Ваш первый рабочий день, куратор вводит Вас в курс дела, рассказывает мегабайты информации по проекту, гигабайты особенностей тестирования и подводных камней. Со скоростью 1 клик в минуту открывает разнообразные экраны, страницы и закладки приложения, которое Вам предстоит тестировать. Через час или 2, он спрашивает все ли Вам понятно, сочувственно смотрит на Вас, подбадривающе похлопывает по плечу и со словами: «ну, а теперь сам\а поразбирайся», уходит работать или на совещание, или еще куда-нибудь. С чем остаетесь Вы? С гигабайтами проектной каши в голове. После нескольких часов исследовательского тестирования (скорее всего безуспешного), Вы понимаете, что так можно месяцами разбираться в проекте. Вы идете к куратору с вопросами, в ключе «А есть что-нибудь почитать по проекту? Тест Планы, тест кейсы, требования, мануалы? Чаще всего ответ бывает � 
