пятница, 27 ноября 2009 г.

Познакомлюсь с тестировщиком. Москва.

Я ищу к себе в команду инженера по контролю качества с опытом работы в тестировании не менее 2 лет. Не Гербалайф =)

Компания Innova Group.

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


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

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


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

Большим плюсом является опыт в применении автоматизированного тестирования.


Условия, предлагаемые компанией:
- Официальное оформление по ТК РФ
- Работа в офисе
- Занятость - полный рабочий день
- График работы: пн-пт, 10:00 - 19:00
- Работа в передовой и активно развивающейся компании

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


Мой контакт: julia.lorien DOG gmail DOT com





Читать далее...

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

7 plagues of Software Testing by James Whittaker - The plague of blindness

Порок слепоты



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

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

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

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

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

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





Читать далее...

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

Ловушки заказного тестирования

Моё выступление на совместной конференции SEC(R) 2009 + SQA Days 7.
Про отношения :)



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

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

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

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

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

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

СТЕРЕОТИП ПЕРВЫЙ: ЖАДНОСТЬ

«Жадные аутсорсеры пытаются раздуть бюджет» - «Жадный заказчик не хочет платить лишнее».

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

Прецедент создан, стереотип родился.

Что делать команде тестирования?

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

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

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

Что делать заказчику?

- Слушать объяснения команды тестирования.

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


СТЕРЕОТИП ВТОРОЙ: ЛЕНЬ

«Команда не создает формальную документацию» - «Заказчик требует отчетов, но не хочет за них отдельно платить».

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

Прецедент создан, стереотип родился.

Что делать команде тестирования?

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

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

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

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

Что делать заказчику?

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

Заказчик должен быть уверен, что он экономит свои деньги разумно.

СТЕРЕОТИП ТРЕТИЙ: ТУПОСТЬ

«Команда маускликеров» - «Покажите мне сертификаты».

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

Прецедент создан, стереотип родился.

Что делать команде тестирования?

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

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

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

Что делать заказчику?
- Просить аргументацию выбора специалистов именно такого уровня квалификации.

- Настаивать на более высоком, если очень хочется и готовы платить, не воспрещается.


Именно тот факт, что эти проблемы не решаются, и создает те превратные стереотипы о «жадных аутсорсерах» и «неадекватных заказчиках». Заказчики и аутсорсеры должны вместе работать над их разрушением.

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



Ссылки для смеху:

[1] Glenn Livingston, «Outsourcing Sucks, Delegating Sucks, Unless… »

[2] Niyaz PK, «Why Outsourcing Sucks»






Читать далее...

четверг, 19 ноября 2009 г.

7 plagues of Software Testing by James Whittaker - The Plague of Homelessness

Порок бездомности


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

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

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

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

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

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






Читать далее...

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

Где брать тестировщиков: методы поиска, найма и обучения

Многие наверняка уже видели слайдкаст моего выступления на Test Labs 2009. В дополнение я выкладываю сам текст доклада. Он не содержит вставок анализа методов набора сотрудников в зависимости от ситуации на рынке, а вот сам костяк сообщения, которое я хотела до вас донести, здесь есть.



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

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

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



Как же можно набирать людей:

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

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




Способ 1. Набор специалистов с опытом работы в тестировании:

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


Плюсы метода:

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

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



Минусы метода:

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

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




Способ 2. Набор людей без опыта работы в тестировании и обучение их на производстве:

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

Плюсы метода:

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

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



Минусы метода:

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

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





Способ 3. Создание пула тестировщиков, откуда при открытии горящей вакансии сразу же берется нужный человек:

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

Плюсы метода:

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

Минусы метода:

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

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




Способ 4. Организация бекапа снаружи компании – внешняя система обучения:

- Изучаем предложение: смотрим на ВУЗы и студентов;
- Изучаем спрос: смотрим внутрь себя, понимаем, какие специалисты нам нужны в перспективе, чему их нужно научить;
- Создаем программу обучения;
- Стартуем программу, обучаем ребят, снимаем сливки, то есть по мере необходимости приглашаем ребят на работу.

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



Плюсы метода:

- Обучаем «под себя», но достаточно широко;
- Предсказуемость ребят в плане обучаемости и желания работать;
- Предсказуемость ребят в плане способностей и склонностей;
- За время обучения ребята становятся лояльными к вашей компании;

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



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

Минусы метода:

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

Если вы можете себе это позволить – это очень хорошая активность, очень полезная и очень интересная. Главное – определиться с целями и потребностями.



Нет верного ответа на все времена «как лучше и эффективнее нанимать тестировщиков». Перед тем, как принимать решение, где и как мы будем искать человека, нужно сесть и подумать: ЗАЧЕМ?

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

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





Читать далее...

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

Аналитика для тестировщиков

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

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


Серию семинаров «Аналитика для тестировщиков» открывают два первых семинара:

«Работа с требованиями: анализ, тестирование» (10 декабря, 13:00-15:00)

  • Когда и зачем привлекать тестировщиков к анализу и тестированию требований.

  • Критерии качественного требования.

  • Свойства требований.

  • Функциональные и нефункциональные требования.

  • Явные и неявные требования.

  • Методики тестирования требований.

  • Полномочия и компетенции тестировщиков при работе с требованиями.



«Работа с требованиями: управление изменениями» (24 декабря, 13:00-15:00)

  • Требования будут изменяться. Всегда!

  • Влияние изменений в требованиях на тестирование.

  • Изменения объема.

  • Изменения сути.

  • Изменения конфигурации.

  • Конфликты и гибкость требований и тестов.

  • Трассировка изменений требований.

  • Повторное использование.


Семинары в формате вебинаров будут проходить совместно с порталом http://Software-Testing.Ru. Условия участия здесь.

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

Когда Филиппа Крухтена спросили, что такое качество продукта, он ответил: «Качество — это соответствие ожиданиям Заказчика/Пользователя».


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

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

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

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

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

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

Что же, если у вас в команде свои аналитики? Соглашусь с высказываением, что каждый должен заниматься своим делом. Действительно, тестировщик никогда не сравнится со «специально обученным» аналитиком. Ну и не нужно равняться. Нужно делать то, что по силам, и то, что работает на улучшение качества программных продуктов. Предотвращение дефектов – это уже не контроль качества (Quality Control), а элементы его обеспечения (Quality Assurance).

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

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


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





Читать далее...

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

7 plagues of Software Testing by James Whittaker - The Plague of Boredom

Порок скучности .


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

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

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

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

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

Скучность. Вообще-то, boredom – это скука, но скучность больше подходит для передачи именно свойства, присущего тестированию. Скука – это его следствие.





Читать далее...

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

7 plagues of Software Testing by James Whittaker - Plague of Amnesia

Порок амнезии.



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

Тестировщики ПО подвержены двум типам порока амнезии. У нас есть командная амнезия, которая заставляет нас забывать наши прежние проекты, наши прежние баги, тесты, сбои и так далее. Требуется время для построения коллективной памяти, которая помогла бы нам остановить повторение наших ошибок. Каждый проект – это не старт с нулевой точки, это всего лишь новая цель для уже более опытной команды. Звездный корабль Enterprise сохраняет бортовой журнал. Это дневник, в котором описаны все приключения его экипажа и к которому можно обратиться за деталями, которые возможно помогут людям выбраться из текущего очередного переплета. Я не пропагандирую ведение дневников для команд тестирования, но я действительно хочу иметь механизм для сохранения знаний. Идея в том, что мы как команда основываемся на наших коллективных знаниях и успехах. Чем длиннее память экипажа Enterprise, тем лучше её можно использовать.

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

Второй тип проблем с памятью – амнезия индустрии. Когда я упоминал Бориса Бейзера и его пестицидный парадокс в моем предыдущем посте, скольким из вас пришлось искать, что это такое? А те из вас, кто знал, - как у вас со знаниями AJAX? Будьте честными: да, есть ребята, которые в курсе как исторического ракурса, так и современных технологий, но они так редки, так редки... Наше знание, кажется, не коллективное. Оно ситуативное. Те, кто помнит идеи Бориса Бейзера, работали в мире, где AJAX не было. Тем, кто без проблем говорит на языке web, не хватает фундаментального мышления и мудрости. Запоминание – вот что у нас есть, но это не настоящая память.

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

Позвольте мне завершить эту колонку, показав пальцем внутрь: Как же мы [Гугл] будем тестировать недавно анонсированную ОС Chrome? Сколько коллективной памяти мы сохранили после Chrome и Android? Сколько из того, чему мы научились, тестируя Android, поможет? А сколько из этого будет переиспользоваться? Как легко тестовые команды Chrome и Android адаптируются к этому новому испытанию? И, конечно же, многие наши проблемы тестирования – это те, с которыми мы уже сталкивались.

Запомним ли мы?





Читать далее...