Хорошо.

Помните, как-то весной я рассказывал, что у нас в городе побывала Наталья Руколь?
У меня еще появился прикольный календарик с автографом.

На днях она еще раз приезжала к нам рассказать о планированиии и проектировании тестов.

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

Раз:

Альбом: office

А унутре у нее неонка автограф, ага.

Альбом: office

P.S. Ну и еще руководство всяко хвалило сей тренинг, да.

Lesson 42

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

Примерно так выглядит небольшая часть диаграммы работ у программистов:

Альбом: office

Оно же ИРЛ:

Альбом: office

А вот так - у автотестеров:

Альбом: office

Оно же ИРЛ:

Альбом: office

Как то так.

Слово Канеру:

Путаница это инструмент тестировщика.

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

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

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

Так

Переводить текст с английского не могу под музыку со словами.

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

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

Как-то так.

Так

А из нашего окна, ну, типа, зима видна.

Альбом: office

ЗВ

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

И кто на темной стороне?

Lesson 41

Слово Канеру:

Если вы пропустили ошибку — проверьте, была ли это случайность или естественный результат вашей стратегии тестирования.


Если вы подбрасываете монету и загадываете решку, но продолжает появляться орел, не значит ли это, что вы приняли неверное решение? Независимо от какого-либо рационального стандарта. Если это не фокус, то у нас есть 50% шанс на выпадение решки и выпадение орла будет просто невезением, а не чем-либо удивительным.

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

Lesson 40

Слово Канеру:

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


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

Если вы знаете, что вас легко обмануть, то вы становитесь немного более внимательным. Вы и ваш ум сильнее и подробнее работают с деталями стратегии тестирования. Это один из самых быстрых путей совершенствования начинающего тестировщика, так как сознание того, что вы дурак — это отношение, а не навык или знание. Проблема начинающих тестировщиков в том, что для них этот принцип — просто вера («Мне сказали, что я должен думать, что меня можно обмануть...»); в то время как чувства и рефлексы опытных тестировщиков были разбужены и обострены болью от постоянного накручивания («Я помню большой возврат 94-го. Мы не могли представить себе, что вирус может заразить наш золотой мастер-диск. Я потерял свою невинность в тот день.»)

Процент багов найденных различными техниками.

Проценты багов найденных различными техниками.

Альбом: bug

Обнаружено у А. Селяева, ориджинал контент тут.

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

Опытные товарищи говорят, что львиная доля приходится на - Personal desk checking of code, да и reviewsстоят недешево.

UPD: Там и дальше интересно:

non-critical bugs are twice as expensive to fix after release, on average. However, the multiplier becomes much, much larger for severe bugs: according to several estimates severe bugs are 100 times more expensive to fix after shipping than they are to fix before shipping.

Осенним вечером

Меняю пособие "Радость шизофрении" и вторую личность на чертежи ионного бобролёта.
Баш.

Раз

Альбом: randompics4lj

Два

Альбом: randompics4lj

Три

Альбом: randompics4lj

Таки ура.

Большое спасибо Михаилу Макушеву и Ирине Шорновой.

Альбом: randompics4lj

Летс листен!

Ненависти пост.

Ubuntu 11.10
Поставил, оценил интерфейс unity.
И грязно выругался.
Буду либо даунгрейдиться на выходных, либо привыкать к плохому.

Рутина

: баг или фича? =)
: чувствуется фича

Это пять, ящетаю. Революционное чутье ...

ы!

Хочу от Оргов вообще и Баранцева в частности какой-нибудь ништячок.
Я собрал на просмотр confeT&qa 10 человек. Кто больше?

З.Ы. Бита с автографом - хороший ништячок.

Lesson 39

Тестероконференция ок, но народ идет неохотно, ссылаются на заняты и поздно.

На доклады по автоматизации не идут:
Автоматические тестировщики - говорят, что все это уже знают,
Ручные утверждают, что ничего не понимают.

Расстрелял бы.
Слово Канеру:

Ты не можешь избежать предубеждения, но ты можешь управлять им.


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

Несколько популярных предубеждений:

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

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

Lesson 38

Слово Канеру

Используйте эвристику для быстрой генерации идей тестирования.

Эвристика это правила мышления, способы делать обоснованные предположения. Это слово произошло от греков, означает «служащее для обнаружения». Эвристика не гарантирует правильного ответа, но тем не меняя, она полезна. Основополагающая книга по эвристике: How to Solve It (Polya 1957).

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

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

Чтоб правильно использовать эвристику нужно знать: в ней нет мудрости. Мудрость в вас. Все, что делает эвристика — дает вам гипотезы. Слепо следуя эвристикам вы не придете к хорошим практикам тестирования. Когда вы их собираете, попытайтесь понять и обосновать все условия, при которых они работают.

Lesson 37

Слово Канеру

При тестировании сложного продукта: погружайтесь и выходите

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

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

Lesson 36

Переехали в комнату с большими окнами и впятеро меньшим количеством народу.
Тут тихо и работоспособно.

Слово Канеру:

Не путайте тесты и тестирование


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

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

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

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

Так

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

Не, нормальная книжка, но после нее, сука, осталось ощущение, что пони накакали радугой тебе прямо в душу. Через недельку надо перечитать Йордана или Сирилла.

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

Так

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

Пошли дальше.
Контора заботится о нас, и, как я рассказывал, дала погоняться читалку. Как водится, с напутствием: читать только полезную литературу по работе. Конторе я отчитаюсь позднее, а пока вам.
Читалка: Amazon Kindle 3
Стоит тыщ 5, fb2 не понимает поэтому Calibre обязательна к установке. Проблем с настройкой никаких, девайс прост как флешка - залил и читай.Комрады тут стонали, что нет древовидной иерархии книг, на что я могу ответить:
- На страницу помещается десять книг, а это много больше месяца чтения, так что не надо звездеть. И так нормально.

О главном - о том как читать. Читать - отлично. Последние лет пять в бумажном виде я читаю только каждую пятую книгу, остальные с экрана, от киндла я ждал чего-то подобного. Сел в кресло, включил... и понял, что это хоть и электронная, но, блин, бумага! В темноте не почитать.
В остальном - отлично лежит в руке, легкая, листать приятно.

Альбом: Быстрая загрузка

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

Теперь о книгах.
1. Сэр Терри Пратчетт, Патриот
2. Том ДеМарко, «Deadline. Роман об управлении проектами»
3. E. Dusting, Automated Software Testing
4. А. Сапковский, Божьи Воины

Lesson 35

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

Слово Канеру:

В конце концов, все, что у вас есть, это представление о продукте.


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

Lesson 34

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

Да, чуть не забыл! Мне дали на недельку офисный киндл погоняццо. Буду лабать обзор же! Ну киндла и книжки, что я с него прочту. Если я вас не обману, это будут Пратчетт, Демарко ну и Дастин, например.

Слово Канеру:

«Это работает» на самом деле означает, что некоторые требования в определенной степени удовлетворены.


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

Что «это»? О какой части продукта мы говорим?
В каком виде? Что именно наблюдалось?
Какие требования были проверены? Корректность? Производительность?
В той ли степени выполнены требования, чтоб пройти тест? Это работает только нормально или в высшей степени отлично?
Когда это работает? В каких обстоятельствах продукт был покрыт тестами? Насколько эти обстоятельства можно безопасно обобщать?

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

Рутина

Альбом: office

Lesson 33

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

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

Слово Канеру:

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


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

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

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

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

Для себя

http://download.naumen.ru/upload/SD/2011-08-30_19.31_ST_GTD_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-08-31_19.39_ST_Comm_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-03_14.02_ST_Confr_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-07_22.47_ST_UML_Webinar_part_1.wmv
http://download.naumen.ru/upload/SD/2011-09-08_22.31_ST_UML_Webinar_part_2.wmv
http://download.naumen.ru/upload/SD/2011-09-09_20.04_ST_Scrum_Team_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-13_19.32_ST_IssueTracker_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-14_19.31_ST_Scrum_Requirements1_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-15_19.34_ST_Scrum_Requirements2_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-22_19.32_ST_CSD_Webinar.wmv
http://download.naumen.ru/upload/SD/2011-09-23_22.30_ST_DMA_Webinar.wmv

Воскресный потрындец.

О тестировании.

Вот тут мне сказали:

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

и так может повториться и еще раз, и еще раз..

Соответственно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"



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



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

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


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

Взгуглил. Пояндексил. 84 и 24 ссылки. Нифига себе. Подумал и взгуглил на мунспике. 800 миллионов ссылок. Черт, так и знал, страна ориджинал контента, чтоб ее. Даже книжку написали, супостаты.

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

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

Альбом: bug

Продвинутый ватерфалл предлагает чуть допилить схему:

Альбом: bug

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

А в масштабе групп разработки нормальный такой скрам - с планированием, итерациями, митингами и демо:

Альбом: bug

Это - дано. А потом Реальность донесла свое видение ситуации:

1. Интеграционное автоматизированное тестирование ну никак не вписывалось в скрам программистов, а потому работало на викли и дейли версии и релизы.
2. Полное(и не очень) ручное тестирование релиза - не укладывалось в ежедневный и еженедельный ритм жизни и требовало себе несколько дней, несколько людей и отдельную очередь, прием по записи, крупным провайдерам, пенсионерам и сотовым операторам - без очереди и скидки
3. Тестирование требований оказалось очень мощной практикой(хитрожопые аналитики моментально прочухали, что тут есть люди, которые могут делать их работу), поэтому стало отдельной от полного сопровождения фичи опцией
горжусь и хвастаюсь: слева от меня сидит девочка, ПМы подкрадываются к начальству и шепотом просят - а можно Наташу на эту задачку? Быть может, будут предлагать денег, цветы и коньяк в виде взятки

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

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

Альбом: bug

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

Заявка - пакет работ - попадает на ответственного тестировщика,

Альбом: bug

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

То есть получается этакий тестировщик микроПМ, клиентом которого становятся ПМы.

Альбом: bug

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

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

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

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



Выводы: надо почитать, что народ пишет по ссылкам, что я нагуглил. Ну и всегда интересны ваши версии на все эти счета.

P.S. Близким манером вроде бы в Иннове работают тестировщики. У Юли Нечаевой. Вот тут она рассказывает. Ну, у нее конечное все связней и по пунктам написано. Зато у меня хендмейд картинки.

P.P.S. Это не я такой прям заебись молодец, все так красиво (или не очень) настроил. Это создавалось до меня, вместе со мной, помимо меня и кое-что против моей воли :). Ну я в том смысле что у меня замечательные коллеги, да.

P.P.P.S. Я сейчас отнюдь не занимался описанием процесса тестирования в отдельно взятом воображении отделе. Я развивал мысль о том, как мы идем в сторону Testing as a Service.

Воскресный потрындец.

Обо всем подряд.

Купил себе кресло. Хотел новое такое:

Альбом: office

Но купил не новое такое:

Альбом: office

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

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

Так

О тех, у кого стоит поучиться.
Контекст - умение говорить, доносить мысль.


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

Пример два. Немного пафосней, отрывок, пара минут буквально. Это Вадим Демчог(если хоть одна скотина скажет "Купидман" ...) в роли какого-то там исторического деятеля.

Я хочу уметь так разговаривать.

Рутина

Натравил на код продукта другой статический анализатор. Выпало порядка 1500 замечаний.
Натравил только на код тестов. Выпало 20.
Посчитал концентрацию. В общем коде - 1,5 на 1000 строк. В коде тестов - 0,4 на 1000. Порадовался.
Посмотрел историю. Замечания коммитил не я. Еще раз порадовался.
Исправил половину. Теперь концентрация замечаний в коде тестов 0,2 на 1000 строк. Опять порадовался.
Подумал. Понял, что я не коммитил замечания просто потому что не умел так хачить. Погрустил, но счет все равно 3:1 в мою пользу.

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

Теперь смотрю в сторону детектора копипасты...

Альбом: office

UPD: Ненене у нас не дремучая контора. И эти необходимые для программистов вещи используются. Но сильно не везде. Так что я изобретаю велосипеды и радуюсь.

Задачки пост

Спасибо okularik за задачку: "какое четырехзначное число при умножении на четыре дает четырехзначное число записанное наоборот"

У меня решение заняло 30 минут. Долго, но 10 минут я искал багу в расчетах - ошибся в знаке.

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

Альбом: office

Альбом: office

Альбом: office

Lesson 32

Дорогое мироздание. Сегодня весь день я вручаю разным людям ништяки.

Я вручил кота.
Я вручил кружку.
Я вручу колонки.

Дорогое мироздание. Я хочу пива. Гиннес, желательно.
Примерно так:

Альбом: home

Ну или так:

Альбом: home

Ну хотя бы так:

Альбом: home

Слово Канеру:

Вы получите требования совещаясь, делая выводы и проверяя ссылки.


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

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

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

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

Отличная книга об этом: Exploring Requirements: Quality Before Design (Gause and Weinberg 1989).

Lesson 31

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

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

Кстати, у Канера всего 293 урока. Я перевел 31. Как вы думаете, на сколько меня хватит?

Слово Канеру:

Требование качества или некоего условия имеет значение для тех, кто принимает решение.


Ты можешь выбирать из многих условий или требований. Это определение хорошо работает для тестировщиков. Как тестировщик ты должен знать, чье мнение о качестве является определяющим. Узнайте, чего они хотят и чего не хотят. Этот взгляд на требования уберет различия между разработкой ПО «по требованиям»(набор положений, определенный в списке требований и утвержденный людьми, имеющими на это право) и по другим видам спецификаций. Для целей тестирования в требовании должны быть описаны все состояния или качества, которыми должен обладать продукт.
Разные клиенты хотят разных вещей от продукта, они даже не обязательно знают, чего они хотят, и чего будут хотеть через некоторое время. Это делает нашу работу более интересной. Добро пожаловать в тестирование.

Так

Читая чужие резюме...
Стране нужны тестировщики, а в СНГ одни assurance`ы, их столько, что quality на всех не хватает.

Lesson 30

Мне протянули интернеты.

Посылаю лучи ненависти техподдержке провайдера Кабинет. Мало того, что у них на сайте не указана почта - телефон они тоже игнорируют.

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

Слово Канеру:

Используй логику гипотезы и опровержения для оценки продукта

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

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

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


Кстати, френды, помогите перевести последние два предложения. Что-то я не могу уловить суть.

- Beware of tests that purport to validate or certify a product in a way that goes beyond the specific tests you ran. No amount of testing provides certainty about the quality of the product.

Заранее спасибо.

лекции, bret pettichord, lessons learned in software testing, james bach, chapter 2, cem kaner, жизнь