Был на форуме it4business.ru вопрос про специфику Context-Driven подхода в тестировании. Автор вопроса не понимал, как именно этот подход соотносится с тестированием. А как это объяснить, а? Чем-то напомнило пресловутое “объясните мне эти абстракные вещи на конкретных предметах“. Я такой ответ сформулировать не смог.
Нашлось достойное объяснение за подписью LeshaL.
Стоит внимательно перечитать на каждом досуге.
Раньше, я не понимал этих школ и жарких споров возникающих из-за их различий, понимания тех или иных принципов или их трактовки.
Теперь, вроде как, все встало на свои места.
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.
Перевод: “Только посредством рассудительности и мастерства, применяемых в течение всего периода работынад проектом, мы сможем делать своевременные действия направленные на эффективное тестирования продукта.”
Применение в тестировании: тут и добавить-то особо нечего. Не верьте, если вам говорят, что все работает – проверьте. Делайте так, как считаете нужным, если вы уверены, что эти действия принесут максимальную пользу. Помните, что выпасть из контекста легко, вернуться – сложно. Участвуйте в обсуждениях, старайтесь узнать о грядущих изменениях до того как они случились (в смысле произошли :). Помогите людям сделать эти изменения.
Это все либо ваш стиль работы – либо нет. Независимо от процессов разработки и тестирования вы можете применять эти принципы. При этом, больше шансов, что о вас будут думать как о человеке, который пытается решать проблемы, а не создавать их.
Автор вопроса не считает данное объяснение достойным.
Всегда ваш, автор вопроса.
По указанной мною во вступлении причине, я склонен считать ваше “несчитание” сугубо вашей траблой 😉
Сентенции подобного уровня не требуют уточняющих вопросов типа “как именно это относится именно к тестированию” просто потому, что перед вами попытка принципиального подхода (абстрактный уровень), а не фактического определения (материальный уровень).
Верно сглаголено – нет специфики. Есть принципы. Их воплощение ничем не регламентируется.
даа. есть к чему стремиться.
жаль, я немного скована и не могу сразу так начать предлагать услуги по тестированию.
и я понимаю, что вообще не в контексте. в этой компании тестеров игнорируют – не зовут на обсуждения проектов. да я там и не пойму многого. но постепенно наверно бы въехала в “контекст”.
видимо, надо бороться, чтобы с нами считались. хоть нас всего 2 тестера ))
а) работодателей тоже выбирают.
б) просто так на обсуждение проектов никого не зовут. Каждый, кто входит в обсуждение, должен быть способным оценить ситуацию, и выдать полезный feedback.
Если организаторы обсуждений не считают, что от тестировщиков будет отличный фидбэк (“да я там и не пойму многого”), то и приглашения не будет.
Не бороться надо, а начинать изменяться, причем очень издалека. Вникать в проект на глубинный уровень. Задавать вопросы. Если в какой-то момент организаторы скажут “Епрст, а вот об этом надо спросить у наших тестировщиков!” – получите свой плюс и приглашение.
Но, еще раз, см. пункт “а)”. Существует великое понятие инерции. Например, работник стал опытным волком, но окружающие его все еще считают мелким новичком. Тогда ему нужно будет уйти в другую “стаю”, а не доказывать всем, что он изменился.
Багира называла Маугли лягушонком, несмотря на то, что она уже резал хвосты у диких собак и нацеливался снять шкуру с Шер-Хана 🙂
Во-вторых, нам свойственно подлаживаться под существующую систему, а не быть “самим собой”. И если система не считает необходимым общаться с тестировщиками, то изменений она не примет. Она тебе, скорее, кнопки в кресло подсунет, чем оценит по заслугам 🙂 Это тоже дело инерции.
Ну, а поскольку в каждой компании собственная система, то говорить о частностях с системной точки зрения не представляется возможным.
А также самостоятельно сложно оценить, насколько ты изменяешься. Это познается в сравнении. Иногда сравнение доступно только при смене системы.
Спасибо за ответ )
Сходила на 2 собрания – мне понравилось ) я уже немного ‘в контексте’ )