Сообщений в теме: 45

[Clauster]

Однако, в каком виде вы, ребята, представляете заказчику отчет о тестировании? В количестве протестированных функций? В % соотношении проверенного кода? В ощущениях? Или отчет тоже нужно отбросить (так же как и тест-план), как нечто устаревшее и не достойное высокого исскуства тестирования?

(пытается вспомнить когда последний раз писал отчет о тестировании)
Это было больше трех лет назад на позапрошлой работе. В компании был ИСО 9001 и согласно процедурам нужно было писать отчеты определенного образца. Их никто никогда не читал, только проверяли соответствие образцам во время очередных аудитов по ИСО 9001. А реальные отчеты, которые действительно были нужны и полезны мы писали для себя в удобном нам виде и на самом деле это были Wiki-чек-листы с рабочими пометками (в детали вдаваться не буду). Та же самая ситуация обстояла с планами, спеками и методиками. Заказчика как такового не было - собственный продукт.

[Sapiens]

barancev

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

Clauster

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

Ну это тоже понятно :)

Они и должны быть абстрагированы. Иначе их будет гораааааздо больше.

Еще раз повторюсь

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

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

[dlg99]

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

в какой-то момент начали осознавать, что все вроде по науке, а все равно что-то не то получается. и времени не хватает никогда.
'инициативная группа товарищей' выступила с идеей о том, что тестирование, возможно, ближе к медицине, где многое зависит от знаний и опыта врача, его способности думать и смотреть на проблему с разных сторон. Доктор Хаус, короче ;)
и что как в медицине мы знаем отдельные приемы, некоторые из них даже наукой отдают, но зачастую - шаманство чистой воды, не смотря на все ультра-современные инструменты.
и что, иногда, опыт и знания важнее алгоритмически прекрасного процесса, и что 'однозначно правильно' не бывает.
получился CDT.

ну а про agile разговор особый. ;)

[Alfa]

Вы же это и спрашивали? Это описано в книжке Lessons Learned in Software Testing (A Context-Driven Approach) Kaner, Bach, Pettichord. В электронном виде не встречал, в печатном на английском языке. Видел в блогах переводы некоторых "уроков".

Ну раз спрашивал, значит ответ получил :) Буду думать и искать книжку. В общем спасибо всем за разъяснения.

[LeshaL]

В чем специфика Context-Driven подхода в тестировании.
...
Вот и встал вопрос адептам Context-Driven Testing (которые тут водятся!). В чем же особенность этого подхода именно в тестировании? Что в тестировании такого, что что делает контекстый подход отличающимся от его аналогов в других областях (пример про кулинарию)?

Я не отрицаю полезности этого подхода, просто хочу узнать о его специфике именно в тестировании, которой не вижу.

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

1. The value of any practice depends on its context.
Перевод: "Ценность любых действий зависит от условий, в которых они выполняются."
Применение в тестировании: выполняйте те тесты, которые в данный момент времени принесут максимально-полезный результат.
Если по плану вы должны гонять сегодня тест "А", сперва подумайте, а нет ли другого теста "Б", результаты которого сейчас всем нужнее.

2. There are good practices in context, but there are no best practices.
Перевод: "В конкретных условиях существуют хорошие решения, но нет идеального решения на все случаи (т.е. есть лекарства, но панацеи не существует)."
Применение в тестировании: перед началом тестирования, подумайте над тем, что вы тестируете. Не выполняйте тупо все предписания чек-листа или все тест-кейзы. Возможно, нужно сделать только часть или надо придумать новые тест-кейзы, которых не было. Прежде чем прогонять тест - изучите то, что вы собираетесь тестировать именно сейчас - возможно ситуация поменялась.

3. People, working together, are the most important part of any project's context.
Перевод: "Люди работающие над проектом - самая важная составляющая конкретной ситуации."
Применение в тестировании: спрашивайте у коллег, а что в данный конкретный момент важнее всего. Чем вы максимально эффективно можете помочь. Узнавайте у разработчиков как это работает и почему это работает именно так. Не говорите девелоперу, который попросил вас прогнать пару тестов на его приватном билде, что не будете этого делать ибо по плану вы другими делами должны заниматься. Может быть, в данный момент, изучить такой приватный билд - это самая актуальная задача и вы съэкономите кучу времени себе и другим в будщем.

4. Projects unfold over time in ways that are often not predictable.
Перевод: "Во время работы над проектом случаются непредсказуемые вещи (shit happens, "C'est la vie")."
Применение в тестировании: будьте готовы к тому, что походу проекта будет появляться необходимость в новых тестах(сделайте их), старые тесты могут стать ненужными(забудьте про них). Вполне возможно, потребуется изучение чего-либо, для того чтобы повысть эффективность тестирования (изучите это). Будьте готовы ко всему. Например к тому, что в какой-то момент вам приется сделать более поверхностное тестироваение, чем вам бы хотелось, но для большего объема функциональности. В противном случае вы ничерта не успеете и вывалитесь из контекста.

5. The product is a solution. If the problem isn't solved, the product doesn't work.
Перевод: "Каждый продукт предназначен для решения какой-то задачи. Если эта задача не решена, значит продукт не работает."
Применение в тестировании: Самое важное, чтобы продукт делал то, что от него хотят. Это ваш приоритет в тестировании - сначала убедитесь, что то, для чего предназначена программа - работает. Не уводите разработчиков в сторону, пытаясь заставить их решать какие-либо дурацкие проблемы. Перво-наперво пытайтесь заставить программу ошибиться в главном.

6. Good software testing is a challenging intellectual process.
Перевод: "Хорошее тестирование - напряженный интеллектуяльный процесс."
Применение в тестировании: Не ждите, что придет кто-то и скажет вам что надо делать (хотя и будут приходить). Предлагайте услуги по тестированию. Придумывайте новые услуги, новые тесты.
Составьте свое мнение о качестве продукта, о том какое оно должно быть. Подталкивайте коллег к тому, чтобы достичь такого уровня качества. Не перестарайтесь ;) - помните: идеальных решений не бывает - к вашему продукту это тоже относится.

7. Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
Перевод: "Только посредством рассудительности и мастерства, применяемых в течение всего периода работы над проектом, мы сможем делать своевременные действия направленные на эффективное тестирования продукта."
Применение в тестировании: тут и добавить-то особо нечего. Не верьте, если вам говорят, что все работает - проверьте. Делайте так, как считаете нужным, если вы уверены, что эти действия принесут максимальную пользу. Помните, что выпасть из контекста легко, вернуться - сложно. Участвуйте в обсуждениях, старайтесь узнать о грядущих изменениях до того как они случились (в смысле произошли :). Помогите людям сделать эти изменения.

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

[Clauster]

2. There are good practices in context, but there are no best practices.
Перевод: "В конкретных условиях существуют хорошие решения, но нет идеального решения на все случаи (т.е. есть лекарства, но панацеи не существует)."
Применение в тестировании: перед началом тестирования, подумайте над тем, что вы тестируете. Не выполняйте тупо все предписания чек-листа или все тест-кейзы. Возможно, нужно сделать только часть или надо придумать новые тест-кейзы, которых не было. Прежде чем прогонять тест - изучите то, что вы собираетесь тестировать именно сейчас - возможно ситуация поменялась.

Надо абстрагироваться от процесса. Потому что процесс это тоже practices in context, but there are no best practices. Чек-листов и кейсов может и не быть вовсе и возможно даже придумывать их не надо будет. Такой процесс может быть неоптимальным. А вообще, этот принцип - основополагающий в Context-Driven.