четверг, 24 декабря 2009 г.

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

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

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

Описание вебинара под слайдкастом.
Приятного прослушивания.



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


1.1 Вид сверху.

Общепринятые определения и что за ними стоит на самом деле. Анализируем.
Делаем выводы, чем чревато следование определениям.

1.2. Вид с разных сторон.

Взгляд программиста. Взгляд менеджера. Взгляд руководителя. Взгляд
тестировщика. Взгляд программного продукта :)
Анализируем. Находим общее видение.

1.3. Каким может видеться тестирование с разных сторон.

Плохим. Хорошим. Полным. Недостаточным.
Анализируем. Делаем выводы, что одного эпитета мало.

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

1.5. А только ли повысить?

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

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

2. Какое тестирование нужно.


2.1. Что нам нужно проверить?

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

2.2. Виды тестирования в разрезе постановки целей.

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

3. Кто должен тестировать?


3.1. Ну, разумеется, тестировщики.

У них есть умение, навыки, знания, окружения, в конце концов, им за это платят.

3.2. Почему не программисты? - «Мы и так пишем хороший код, давайте покажу, что все работает».

Плюсы выделенного тестирования.
Программисты должны программировать!

3.3. Почему не менеджер? – «Я же лучше всех знаю, чего хочет заказчик»

Плюсы выделенного тестирования.
Оставьте менеджеру менеджерово!

3.4. Так почему же все-таки программисты? «Зачем нам тестировать перед сдачей кода? Пусть тестируют тестировщики»

Плюсы пре-тестирования разработчиками.

3.5 Так почему же все-таки менеджер? «Зачем мне прогонять аксептенс, если тестировщики уже все протестировали?»

Плюсы пост-тестирования менеджером.

Выводы:
Главное в тестировании (если это не просто поиск ошибок) – это определить его цель и сообщить о ней всей проектной команде. Тогда каждый сотрудник будет вносить свой вклад в качество программного продукта.

Целевая аудитория


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

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

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

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

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

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





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

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

Конференция Agile Days - отчет

Недавно (9 декабря) посетила конференцию AgileDays, которую делали ребята из ScrumTrek. По этому поводу хочу немного отчитаться :)

Никита Филиппов рассказал про базовое - Обзор Agile . Нужно всем конференциям перенять фишку: делать 1-2 доклада про азы. Потому что часть людей приходит затем, чтобы посмотреть, что такое аджайл (в других случаях – что такое тестирование, что такое анализ требований и пр.), и им нужно это дать, им нужно об этом рассказывать. Потому что им рано и зачастую опасно слушать про техники и инструменты, не понимая общего смысла и цели подхода, не зная основных определений, не понимая исторических особенностей возникновения той или иной техники. Задавать же вопрос «почему вы сделали так?» на докладе, который предполагает базовые знания в этой отрасли – вроде как некомильфо. Так что Никита полностью угодил своей целевой аудитории.

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

Женя Курышев покорил меня (и зал, судя по отзывам) очень легкой подачей experience report’а о том, как яндексоиды внедряли скрам в Моем Круге. Как и все, что делает Яндекс, это делалось для людей и облегчения их работы. То есть, самый правильный подход: процесс для работы, а не работа для процесса. Нужна доска – пожалуйста, сорвали 6 пробковых плиток с потолка – получили доску стоимостью 48 рублей. Распределенные команды – не вопрос, давайте юзать виртуальную доску. Не можем прийти к соглашению – давайте позовем стороннего эксперта, но тогда уже его мнение будет финальным. Вобщем, интересная история на фоне картинок про бакланов – зачет!

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

Очень хотелось попасть на доклады Максима Гапонова, Леши Кривицкого и Наташи Трениной, Стаса Фомина, Артема Марченко. Жду видео.

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

Как и любую конференцию, я, в первую очередь, оцениваю по тому, вынесла ли я с неё что-то новое? Знакомство с Артемом Марченко, Светой Топольской, Димой Лобасевым (наконец-то), Женей Курышевым, штук 20 различных идей и мыслей в блокнотике, доделанный на кресле-мешке вебинар, я считаю – хороший результат.

Плюс общение с уже знакомыми мне интересными людьми. Компания подобралась хорошая. Асхат, Ира и Никита умеют собирать людей :)

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






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

четверг, 10 декабря 2009 г.

Вебинар "Работа с требованиями: анализ, тестирование" состоялся. Отчет.

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

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

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

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

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

Второй этап был теоретический:
1. Что такое требования. Методы их фиксации.
2. Какие бывают требования
3. Что с ними можно делать.
4. Где здесь тестирование. Зачем нам это?
5. На что тестировать? Критерии хороших, качественных требований.
6. Методы тестирования требований
7. Заключение

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

И получили домашнее задание.

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

System_Must_Do_All

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

who_should_test

who_actually_tests





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

воскресенье, 6 декабря 2009 г.

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

Порок энтропии.




Математически, энтропия – это мера неопределенности. Скажем, если есть 5 событий, то энтропия будет максимальной, если все они равновероятны, и энтропия будет минимальной, если лишь одно из событий определено, а остальные 4 – невозможны.

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

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

Как бы там ни было, мы ничего не можем сделать, чтобы полностью предотвратить порок энтропии, кроме как создать разработчиков, которые никогда не ошибаются. А раз это маловероятно, мы должны определять, как и когда мы сталкиваемся с энтропией, и делать все, что в наших силах, чтобы ею управлять. Чем больше мы сможем сделать во время разработки, тем лучше. Помогать в code review, вводить наших разработчиков в курс тест-планов, пользовательских сценариев и окружений, чтобы они могли кодировать с меньшим количеством багов, которые нам пришлось бы рапортовать. Выкуривать баги как можно раньше, заводить их пачками и быть уверенными, что мы создаём только высококачественные баг-репорты, причесывая их самостоятельно, концентрируя тем самым мысли программистов на разработке. Написание хороших баг-репортов и быстрая проверка исправлений удержат внимание разработчиков там, где ему положено быть. Фактически это максимизирует определенность «разработчицких событий» и минимизирует количество и влияние багов. Энтропия, таким образом, сходит на минимум

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





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

пятница, 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 адаптируются к этому новому испытанию? И, конечно же, многие наши проблемы тестирования – это те, с которыми мы уже сталкивались.

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





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

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

цитаты

Канер, Фолк, Нгуен, "Тестирование программного обеспечения.":

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


А ты, чукча, покорми собак и ничего не трогай, ага.




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

воскресенье, 25 октября 2009 г.

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

Порок повторяемости



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

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

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

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





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

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

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

«7 plagues of Software Testing» - это цикл постов Джеймса Виттекера, который с мая 2009 года присоединился к команде Google в качестве Test Director. Этот цикл родился из его первого tech talk в Гугле, где его выводы, по признанию самого Джеймса, были признаны ребятами из Гугла достаточно провокационными. Все 7 статей опубликованы в блоге http://googletesting.blogspot.com/.

Перевод первого поста из этой серии я символично выкладываю именно сегодня, во второй день конференции Google Test Automation Conference, которая проходит именно сейчас в Цюрихе, и на которую я не попала. Именно она послужила поводом для моего знакомства с Джеймсом Виттекером. Джеймс разрешил мне переводить и публиковать его статьи, чем я, собственно, и занимаюсь.

Спасибо Тимуру Хайруллину за помощь и терпение :)

Цикл «Семь пороков тестирования» открывает первый пост: «Порок бесцельности».




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

И это именно то, чего нам не хватает в тестировании. Мудрость тестирования? Вы шутите? Где она? Кто же её зажал? Не подскажете?

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

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

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

Порок бесцельности, увы, широко распространен. И нужда в Мудрости очень остра. Nike говорит нам: ‘just do it’, но что применимо к упражнениям, не подходит к тестированию ПО. В следующий раз, поймав себя на ‘just doing’ тестирование, остановитесь на мгновение и спросите себя: «Какова моя цель?» и «Каково назначение этого теста?». И если ответ не приходит к вам моментально, вы в плену бесцельности, «just doing it», положившись на удачу и грубую силу в усилиях по поимке вашей добычи.

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

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

________________________________________________________________________________________

Тестирования. Software Testing. Я осознанно не употребляю практически нигде в тексте выражение "Тестирование программного обеспечения". И так понятно, что стоит за термином "тестирование".

Порок. В оригинале plague, что переводится как чума, мучение, напасть, бедствие. Были предложения перевести plague как "беда" или "зараза". Мне больше всего нравится "порок", это что-то такое, что было в тестирование заложено изначально и от чего практически невозможно избавиться, но можно смягчить. Мне кажется, именно это имел ввиду Джеймс.

Мудрость. В оригинале lore, что означает коллективное знание в какой-либо области (в данном случае - тестирования). Это что-то такое, что собирается многими поколениями и что всегда доступно всем страждущим. Поэтому перевожу как Мудрость. Такая себе коллективная Мудрость всея тестирования.

Кто же её зажал? Джеймс использует глагол boharted, который невозможно перевести на русский, не потеряв обаяния этого слова. Сленговое словечко to bogart родом из наркоманских 60х, означает "зажать что-то, что должно быть передано другим". "Don't bohart that joint!" - "Не зажимай косяк!"". Пруфлинк. Слово это возникло благодаря актеру Хамфри Богарту, известному своей привычкой не выпускать сигарету изо рта (основную известность ему, конечно же, принес кинематограф, а не сигарета. Очень люблю его "Касабланку").





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

среда, 21 октября 2009 г.

Опрос "Соотношение разработчиков и тестировщиков" или "В мире айтишников"

После нашего с Тимуром Хайруллиным выступления на PM-Labs к нам подходили люди и спрашивали, откуда у нас информация о таком соотношении количества разработчиков и тестировщиков в компании? Напомню, что мы иллюстрировали наши наблюдения на примере «самой обычной компании» под названием «Вакуумная сфера», состав которой был следующий:

30 программистов (+3)
5 ПМ (+1)
5-6 тестировщиков (+1)
2 архитектора
2 аналитика
3-5 сисадминов
2 дизайнера / юзабилиста
2-3 бухгалтерия
2-3 sales
2-3 маркетинг
2-3 HR
1-2 ХО

Мы получили несколько комментариев с содержанием, что «соотношение 1 тестировщик на 5 разработчиков – весьма нездоровая ситуация», что «такая компания не может нормально работать и производить хорошие продукты», что «компании стали взрослее и понимают ценность тестирования» и проч.

Хотелось бы уточнить, что это соотношение было приведено не как среднее, а как обычное. Интуитивно мы понимаем, что это не из ряда вон выходящая ситуация, но ответить на вопрос «Откуда вы взяли, что такое соотношение является нормальным» мы не смогли.

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

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

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

Судите сами.

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


Итак, в опросе приняли участие представители 246 компаний, так или иначе имеющих отношение к разработке программного обеспечения, из стран СНГ+ (айпишники мы не анализировали). Общий портрет участника таков:

Тип компании

Количество респондентов

Из них:

Маленьких (<30 человек)

Небольших (31-100 человек)

Средних (101-300 человек)

Больших (301-1000 человек)

Гигантов (>1000 человек)

Аутсорсинговая

77

47

20

6

0

4

Продуктовая

83

47

16

9

5

6

IT-отдел

94

52

24

5

8

5





Если не делать никаких выводов, а лишь посмотреть на картинку, то можно увидеть, что

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



А что же внутри этих семейств? Как у наших родовых объединений обстоят дела с ролевым распределением?

Все графики построены по следующему принципу:
По оси абсцисс у нас количество разработчиков в компании на одного тестировщика. По оси ординат – количество таких случаев.

 

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





 

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

 





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

 

 





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

 





Выводов мы, как и обещали, не делаем. Просто смотрите на картинку и понимайте ситуацию. Есть компании, которые живут и, мы верим, процветают при минимальном (а то и нулевом) количестве тестировщиков на десяток разработчиков. Компании, проходя свой жизненный цикл, проскакивают цифры 7, 8 и 9, и сразу переходят на следующий уровень с цифрой 3-5 программистов на одного тестировщика. Таких большинство. Это не плохо, и это не хорошо. Это просто так есть.
Немногие могут себе позволить соотношение 1:1 тестировщиков и разработчиков, но такие компании есть. И они позволяют себе это. Мы не можем назвать ни причин сложившейся ситуации, ни условий её возникновения, это факт.

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

 


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





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

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

Test-Labs 2009

Test-Labs состоялся, ура!

Первая на моей памяти конференция для тестировщиков на территории Украины. Будучи причастной к организации Software Quality Assurance Days, а также к QA Club, я вижу нехватку профессионального общения в нашей, тестировщицкой среде. Да, есть блоги, да, есть информационные площадки. Но живое общение этим никогда не заменишь. Спасибо Славе Панкратову лично и всему учебному центру Люксофт за предоставленную возможность.

Ничего не скажу про организацию. Блокноты, ручки, одна_остановка_на_такси, мягкие стулья – что ещё нужно, если ты приехал не за этим? Мне понравилось.

Буду говорить про важное. То есть про доклады и про аудиторию.

Игорь Лужанский. Решила посетить, потому что уж очень хвалили Игоря после его выступления на PM-Labs.

Игорь – отличный докладчик. Живой и горящий. Уверена, что он такой же и в работе, а это значит, что его команде повезло :)
Хороший, четкий, структурированный доклад. Очень полезные и нужные вещи. Ничего нового для меня лично, но, вспомнив себя пару лет назад, вполне представляю, сколько информации могли почерпнуть слушатели, которые не сталкивались с тестированием требований, либо начали это делать вот только сейчас. Вобщем, требования должны быть и они должны тестироваться. По дополнению Леши Колупаева, столь формализованного процесса может в проекте и не быть, от этого проект не станет менее успешным. Важно понимать, зачем мы делаем это или не делаем.

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

Юлия Нечаева. Взгляд с точки зрения докладчика. Очень отзывчивая аудитория.

Говорила о методиках набора тестировщиков, о их "покупке" и обучении, и когда что выгоднее. Рада, что технические специалисты понимают, что проекты и ПО делают люди, а не технологии и не методологии. И что самое важное для успеха проекта – это его фундамент, его команда. Когда после слов Игоря, модерировавшего эту секцию: «Есть вопросы к Юле?», - взметнулось рук 10 одновременно, стало очень тепло. Значит донесла. Значит актуально.
В итоге доклад с пост-обсуждением занял больше часа, затем кулуары. И ещё стены пивного ресторана «Сундук» до самого его закрытия внимали разговорам на тему «Нетехнические скиллы для тестировщиков».
Слушателей заинтересовала программа обучения, которую я веду в рамках сотрудничества Никсов с ВУЗами Харькова. Здорово, что такие инициативы есть не только у нас, что они развиваются и приносят свои плоды.

Привет ребятам из Молдовы и из Днепропетровска. Если у ваших команд такие менеджеры, то все у вас получится :)

Александр Александров. Человек с фамилией Ходить_на_все_его_доклады (ц).

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

Спасибо Тимуру Хайруллину за интересные комментарии о perceptive quality.

Ну и «Сундук». Становится традицией завершать люксофтовские конференции именно там. Пиво, колбаски и интересные собеседники. Макс, Рома и Никита, доклады ваши я, к сожалению, не слушала, но вы жгли и после :)

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

Ещё отчет здесь. Ждем материалов.





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