четверг, 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, вводить наших разработчиков в курс тест-планов, пользовательских сценариев и окружений, чтобы они могли кодировать с меньшим количеством багов, которые нам пришлось бы рапортовать. Выкуривать баги как можно раньше, заводить их пачками и быть уверенными, что мы создаём только высококачественные баг-репорты, причесывая их самостоятельно, концентрируя тем самым мысли программистов на разработке. Написание хороших баг-репортов и быстрая проверка исправлений удержат внимание разработчиков там, где ему положено быть. Фактически это максимизирует определенность «разработчицких событий» и минимизирует количество и влияние багов. Энтропия, таким образом, сходит на минимум

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





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