Перейти к содержимому

Фотография

Тестирование программного обеспечения. Базовый курс


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 20

#1 baranceva

baranceva

    Профессионал

  • Admin
  • PipPipPipPipPipPip
  • 4 160 сообщений
  • ФИО:Баранцева Наталья


Отправлено 09 сентября 2015 - 13:13

Представляем книгу Святослава Куликова «Тестирование программного обеспечения. Базовый курс.».

 

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

 

Скачать книгу

 

А мы просим всех, кто прочитал книгу поделиться своими отзывами у нас на форуме.


  • 0
Наталья Баранцева
Тренинги по тестированию ПО

#2 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 906 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 09 сентября 2015 - 18:29

Это не книга, и не учебник. Это расширенный комментарий к бытующей ISTQB-литературе с точки зрения действующего тренера.

 

Это "самое то" для istqb-oriented мидлов. Для начинающих КОТЭгорически не подойдет. Запутает. А мидлам напомнит о некоторых детальках, которые "забываются", и напомнит еще раз, что тестирование — это очень просто, но когда понадобится грамотное тестирование, тогда извините, уже не каждый сумеет.

 

В этом контексте главы про тест-кейсы и дефекты местами шикарны.

 

Весь раздел 2.3 ("Классификация видов тестирования") — невероятно унылая копипаста из istqb-мануалов. Начинающих именно так и надо отпугивать от тестирования.

 

Термины надо ОБЬЯСНЯТЬ, а не просто толковать.

 

Пример жути, которая встречается в этом учебнике:

 

☆☆☆ Попарное тестирование (pairwise testing) — техника тестирования, в которой тест-кейсы строятся по принципу проверки пар значений параметров (переменных) вместо того, чтобы пытаться проверить все возможные комбинации всех значений всех параметров. Эта техника является частным случаем N-комбинационного тестирования (n-wise testing) и позволяет существенно сократить трудозатраты на тестирование (а иногда и вовсе сделать возможным тестирование в случае, когда количество «всех комбинаций всех значений всех параметров» измеряется миллиардами). Попарное тестирование (pairwise testing) — это НЕ парное тестирование (pair testing) ☆☆☆

 

Кагбэ, все правильно, не придраться. Но "выдавать" это новичкам? В разделе 2.7.4 приведено обьяснение pairwise, но ставлю золотой канадский доллар против медной турецкой лиры, что врубиться в это обьяснение сможет только тестировщик, ноги которого уже наполовину закатаны в асфальт колумбийской мафией. ISTQB, одним словом...

 

Удивило описание Exploratory testing: предлагается использовать этот подход, если нет времени на придумывание тест-кейсов. А именно:

  1. Набросать список идей (чек-лист),
  2. Протестировать приложение по этим идеям,
  3. ПРОФИТ!
  4. ?????

Японская япона мать, разве это — исследовательское тестирование? Разве это "одновременное проектирование и выполнение тестов"? Это же пример прекрасного классического тестирования, с непременным (ибо логично), хотя и несколько ускоренным и усеченным, но все-таки предварительным приготовлением идей о том, что надо тестировать ДО ТОГО, как взяться за, соппсно, тестирование.

 

Система обучения, которой придерживается автор http://svyatoslav.bi...jste_trainings/ мною разделяется почти полностью, за исключением проповедничества подхода ISTQB к тестированию.


  • 1

Software Testing Glossary - простыми словами о непростых словах.


#3 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 10 сентября 2015 - 06:27

[skipped]

Система обучения, которой придерживается автор http://svyatoslav.bi...jste_trainings/ мною разделяется почти полностью, за исключением проповедничества подхода ISTQB к тестированию.

 

Алексей, спасибо за отзыв: по многим пунктам согласен и разделяю те же опасения и сожаления. Кроме ненависти :) к ISTQB: часто от заказчиков поступает прямым текстом обозначенное требование, чтобы в команде знали и понимали именно ISTQB-подход (и отклонения от него вызывают гримасу боли и/или непонимание).

 

Да, ISTQB -- не божественное откровение, и им мир не ограничивается. Но если ставить задачу донесения до "юных умов" чего-то единообразного, распространённого и всемирно-известного (да ещё и востребованного заказчиком) -- альтернатив немного, и ни одна из них не выглядит сильно лучшей.

 

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

 

P.S. Положенные в основу книги материалы за десять лет претерпели очень сильное изменение именно в сторону ISTQB. Сначала всё было "красиво, пушисто и самобытно", но потом пришёл "злой энтерпрайз" и всё стандартизировал :).


  • 0

#4 Tishka

Tishka

    Постоянный участник

  • Members
  • PipPipPip
  • 211 сообщений
  • ФИО:Ахрамеев Антон

Отправлено 10 сентября 2015 - 11:44

2.2.2. Важность требований

 

Продуктная документация (product documentation, development documentation49) используется проектной командой во время разработки и поддержки продукта.

Она включает:

o План проекта (project management plan50) и в том числе тестовый план (test plan51).

o Требования к программному продукту (product requirements document, PRD52) и функциональные спецификации (functional specifications53 document, FSD54; software requirements specification, SRS55).

o Архитектуру и дизайн (architecture and design56).

o Тест-кейсы и наборы тест-кейсов (test cases57 , test suites58).

o Технические спецификации (technical specifications59), такие как схемы баз данных, описания алгоритмов, интерфейсов и т.д.

 

Отдал сегодня своим стажерам это на прочтение, на что получил закономерные вопросы:

- "А как тогда тестировать если всей этой документации нет?"

- "Бывают ли вообще проекты со всей этой документацией?"

- "А можно ли требовать это документацию?"

- "У кого ее требовать?"

 

На основе своих наблюдений пришел к выводу:

Начинающий тестировщик, прочитавший данную информацию, придет на свое первое место работы и просто впадет в ступор.

Впадет в ступор потому, что:

- документации всей может не быть

- вообще может не быть документации

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

- восприятие такой информации он может принять за общепринятую стандартизированную практику, которая применяется везде,

но в действительности это далеко не так.

 

Спросил отдел разработки о таком кол-ве документации. На что получил от сеньеров внятный ответ:

"пункты 2 и 5 достаточно часто бывают, 3 реже, но тоже делают"

Так же один из фронтендщиков сказал такое: "А зачем вся эта документация для сайта-визитки?". 

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

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

 

Так же хочу отметить, что 8 этапов в разделе "2.1.2. Жизненный цикл тестирования" перенасыщает начинающего тестировщика

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

 

 

 

P.S. Все это исключительно личное мнение и наблюдение за своими стажерами.


  • 0

#5 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 906 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 10 сентября 2015 - 13:14

Ну, для корпорации я и сам написал бы istqb-like-мануал, но в учебном классе все равно учил бы так, как надо :)

Давайте говорить о принципиальных решениях задачи "как и чему учить начинающих". Все мои претензии именно в этом плане роятся.

Программа ISTQB, которая предполагает учить новичков, строится на следующих уровнях:
Уровень 1: Запомнить.
Уровень 2: Понять.
Уровень 3: Применить.
Уровень 4: Анализировать.

Имхо, это неправильно для обучения начинающих. Взрослым - ок. Но начинающим надо сперва ПОНЯТЬ.

А чтобы понять, надо сперва ПОЩУПАТЬ.

А чтобы пощупать, надо сперва ДОГАДАТЬСЯ о том, что "в ящике есть что-то полезное".

А чтобы догадаться, надо сперва НАЧАТЬ ПОИСК РЕШЕНИЯ ЗАДАЧИ.

А чтобы искать, надо сперва столкнуться с ЗАДАЧЕЙ, которая требует решения.

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

Про альтернативный опыт:

 

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

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

 

Моя задача — объяснить и проверить, понятно ли объяснение. Получается сплав из разговоров, наблюдений, повторов (если надо), поиска наиболее объясняющих образов и упражнений — у каждого своё. До чего дошло — темы, которые я когда-то объяснял на протяжении часа, теперь могу объяснить за 20 минут, бо лишнее отсеялось, практика оставила только самую суть. Итого — объясняю быстро и точно, и давай делать упражнения. И еще упражнения. Только через упражнения я вижу, было ли понятно то, о чем я говорил. На выходе всегда выпускаю ученика, который не только понимает, но и умеет (упражнения же).

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

 

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

Блэк и сподвижники затеяли правильную и нужную систематизацию и каталогизацию информации о всех аспектах, из которых складывается тестирование, и постарались сделать систему, по которой можно знания квантовать на малые доли и оценивать. Но они сделали "Университет", если угодно, со всеми понятными преимуществами и последствиями. Там учат ЗНАТЬ. А начинающих тестировщиков надо учить ДЕЛАТЬ.

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

 

"ISTQB creates syllabi and exams that can be graded in a standardized way. Prep courses help students prepare for an exam that will be graded in a standardized way. This leaves less room for variation that reflects personal judgment.

I can respect this as exam preparation. However, many testers take only a few courses. If what they get is simplified and disambiguated, in my view, they are learning the wrong lessons about a field that relies (in my view) intensely on individual judgment".

 

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

Вот если уже взрослый дядька\тётька читает силлабус, и распознаёт, и понимает, что и почему в каких контекстах применимо, тогда ок. Взрослый дядька вообще понимает, что общая канва, которая прослеживается в ISTQB, относится к подходам, которые уже можно характеризовать как "Да пусть они скорее отомрут, сикока можно-то!". Дайте тестировщикам требования, дайте тестировщикам время, дайте тестировщикам ресурсы, и они дадут вам тест-кейсы... Это же Factory school, если этот канеровский термин будет принят. Это жесткач! Это же пресловутое "тестирование принтеров" из трудов Канера Фолка и Нгуена, на которое анадысь Роман Савин жаловался, дескать, фу, засыпаю. Конечно, засыпаю. Это же основы всех сферических велосипедов в вакууме! Но мне кажется невозможным становление мастера, который не изучает основы.

Материалы ISTQB вообще хороши на адвансед уровнях (не для детей). В сфере тест-дизайна их материалы вообще прекрасны, рекомендую каждому тестировщику таки врубиться в тест-дизайн не по блогам, и не ныть, что "в проекте не хватает времени, и вообще, никто же не просит делать этот pairwise". Конечно, не просят. Чистить зубы по утрам тоже никто не просит. Но до адвансед уровней кто доходит? Кто вообще берется за учебу, если в финале не светится вывеска "Тута сертификат дают! Бабла дадут! Тайтл дадут!"?

 

Посему, учить новичков сразу по ISTQB — нехорошо это :)

К слову, у программистов картинка с сертификациями несколько иная - http://www.nh.lv/it/...ru/519/681/692/


  • 5

Software Testing Glossary - простыми словами о непростых словах.


#6 Tishka

Tishka

    Постоянный участник

  • Members
  • PipPipPip
  • 211 сообщений
  • ФИО:Ахрамеев Антон

Отправлено 10 сентября 2015 - 13:39

Алексей, спасибо за пояснение.

 

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

Судя по количеству вопросов от стажеров - нет.

Опираясь на Ваше мнение - нет.

 

Вывод очевиден. 


  • 0

#7 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 906 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 10 сентября 2015 - 15:33

Кстати, мой аналог "лекций для тренера":

  1. https://www.dropbox....41_Pro.jpg?dl=0
  2. https://www.dropbox....16_Pro.jpg?dl=0
  3. https://www.dropbox....44_Pro.jpg?dl=0

 

Сделано для моей корпорации, поэтому существует в единственном экземпляре, всюду пометки про NDA и отлучение от мечети каждого, кто это вздумает читать :)


  • 0

Software Testing Glossary - простыми словами о непростых словах.


#8 lurk

lurk

    Постоянный участник

  • Members
  • PipPipPip
  • 180 сообщений


Отправлено 10 сентября 2015 - 16:08

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

Судя по количеству вопросов от стажеров - нет.

Опираясь на Ваше мнение - нет.

Вывод очевиден. 

Очевидно, что вы не прочли о задачах книги (5 страница). Вывод о Вас очевиден? 

 

Выдержка из предисловия от автора или зачем нужна эта книга:

Эта книга не ставит своей задачей полноценное раскрытие всей предметной области со всеми её нюансами, потому не воспринимайте её как учебник или справочник — за десятилетия развития тестирование накопило такой объём данных, что для его формального представления не хватит и десятка книг. Также прочтения лишь этой одной книги вовсе не достаточно, чтобы стать «гуру тестирования».

Тогда зачем же нужна эта книга!?
Во-первых, эту книгу стоит прочитать, если вы твёрдо решили заниматься тестированием, — она будет полезна как «совсем начинающим», так и имеющим некоторый опыт в тестировании.
Во-вторых, эту книгу можно и нужно использовать как опорный материал во время тренингов. Здесь можно и нужно много чёркать, дописывать, отмечать непонятное, записывать вопросы и т. д.
В-третьих, эта книга — своего рода «карта», в которой есть ссылки на множество внешних источников информации (которые могут оказаться полезными даже опытным тестировщикам), а также много примеров с пояснениями.
...
Напоследок: ничто в этой книге не является догмой, к любому термину вы можете найти альтернативное определение, к любой рекомендации — контраргументы. И это нормально. Со временем вы станете понимать контекст ситуации и применимость (полезность!) той или иной информации. Итак, приступим!
 

Книга как опорный материал для тренингов - хороша. (Ставим +)

Книга как карта  и набор полезных ссылок - отлично. (Ставим !)

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

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

PS: Печатный вариант книги как-нибудь получить можно не участвуя в тренингах?


Сообщение отредактировал lurk: 10 сентября 2015 - 16:27

  • 0

#9 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 11 сентября 2015 - 06:40

Отдал сегодня своим стажерам это на прочтение, на что получил закономерные вопросы:

- "А как тогда тестировать если всей этой документации нет?"

- "Бывают ли вообще проекты со всей этой документацией?"

- "А можно ли требовать это документацию?"

- "У кого ее требовать?"

 

На основе своих наблюдений пришел к выводу:

Начинающий тестировщик, прочитавший данную информацию, придет на свое первое место работы и просто впадет в ступор.

Впадет в ступор потому, что:

- документации всей может не быть

- вообще может не быть документации

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

- восприятие такой информации он может принять за общепринятую стандартизированную практику, которая применяется везде,

но в действительности это далеко не так.

 

[skip]

 

Так же хочу отметить, что 8 этапов в разделе "2.1.2. Жизненный цикл тестирования" перенасыщает начинающего тестировщика

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

 

Антон, по первому пункту про отсутствие (или низкое качество) документации ситуация явно выходит за рамки обсуждения книги :). Если вернуться к контексту, то:
1) Я рассматриваю обучение "совсем начинающих" по аналогии с автошколой: сначала учим ПДД и "как правильно". Если есть желание ездить как в "Mad Max: Fury Road", то это это будет потом, в особых случаях при понимании и осознании всех условий и последтвий.
2) У начинающих тестировщиков и так часто бывает ступор, но информация о документации даёт хотя бы какой-то ориентир. Даже если документации нет: появляются идеи о том, какие вопросы задавать.

3) Чем больше будет людей, которых "с пелёнок" приучали к адекватным процессам, тем быстрее эти процессы станут адекватными. Да, не сразу. Но если ничего не предпринимать, ситуация точно не будет улучшаться.

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

5) При этом я не отрицаю справедливость вашего замечания: да, возможно, стоило описать и ситуации работы без документации (и уж тем более подчеркнуть ещё раз, что с ней могут быть проблемы). Признаю, посчитал это самоочевидным (отмечу на будущее для апдейта).

 

По второму пункту (о жизненном цикле): как вы верно заметили, у Савина это описано проще, и я решил не писать ещё одно "Тестирование.com" :).

 

P.S. Коллеги, я ещё ниже вернусь к конкретике, но уже сейчас хочу отметить одну вещь: мне кажется, некоторая часть критики книги происходит из представления картинки "взяли совсем-совсем новичка, дали прочитать книгу, бросили в бой". У большинства из нас есть опыт обучения "подмастерьев" и проведения тренингов, и мы прекрасно понимаем, что там допустим и даже необходим куда более упрощённый (и более индивидуальный) подход. Но! Начиная с какого-то момента джуниоры просят "почитать чего-нибудь посерьёзнее". Вот пусть и читают -- хоть Канера, хоть Коупленда, хоть Куликова: что-то всегда будет понятно одним, и непонятно другим -- это нормально. Пусть подойдут, спросят. Вот здесь автор очень точно подмечает: "отрасли критически не хватает компетенции ". И если изначально с первых же дней не давать правильных ориентиров и понимания необходимости в дальнейшем развитии, получается беда. Я насмотрелся на неё в самых разных проявлениях настолько, что уже больно почти физически. И написанная книга -- одна из попыток улучшить ситуацию. Хотя бы частично. Хотя бы для отдельных людей и отдельных компаний.


  • 1

#10 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 11 сентября 2015 - 07:32

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


Тогда я бы разделил "как" и "чему". И ещё добавил "кого и когда". При проведении тренингов для "совсем начинающих" в EPAM мы требуем, чтобы кандидат на зачисление в группу обязательно прочитал Савина перед подачей анкеты. Ибо Савин тут прекрасен. Есть (ох, сколько же их есть!) и те, кто совершенно ничего не понимает в книге Савина. Есть много тех, кто понимает. Есть достаточно тех, кто понимает много. И т.д. Надеюсь, логика ясна :). Дальше наступает тренинг длительностью 1-2 месяца, где ребятам надо дать основы и показать, куда двигаться. И тут тоже получается очень по-разному, т.к. все люди разные, и чем больше хороших разнообразных подходов мы можем использовать и источников информации предоставить, тем большее число ребят получат что-то, что им "зайдёт". Дальше наступает следующий этап обучения (2-4 месяца full-time) с уже своими нюансами... Но это тема совсем другой беседы :).
 

Программа ISTQB, которая предполагает учить новичков, строится на следующих уровнях:
Уровень 1: Запомнить.
Уровень 2: Понять.
Уровень 3: Применить.
Уровень 4: Анализировать.
Имхо, это неправильно для обучения начинающих. Взрослым - ок. Но начинающим надо сперва ПОНЯТЬ.
А чтобы понять, надо сперва ПОЩУПАТЬ.
А чтобы пощупать, надо сперва ДОГАДАТЬСЯ о том, что "в ящике есть что-то полезное".
А чтобы догадаться, надо сперва НАЧАТЬ ПОИСК РЕШЕНИЯ ЗАДАЧИ.
А чтобы искать, надо сперва столкнуться с ЗАДАЧЕЙ, которая требует решения.


... а чтобы начать решать задачу, надо сначала узнать о её существовании и знать о хотя бы каких-то направлениях "куда копать". При всей верности концепции получаем два неприятных недостатка:
1) Длительность и неочевидность процесса.
2) В предельном случае -- замкнутый круг: "я не знаю, как и что можно решать, и потому я не знаю, что можно решать и как".

Потому я вижу более оптимальный (исключительно с моей точки зрения!) процесс чуть-чуть иначе:
а) Демонстрация. Вот проблема, вот типичные пути её решения. Вот для того и того это нужно, такие-то плюшки приносит.
б) Расширение проблемной области через информирование: проблемы бывают ещё такими-то и такими-то, а решения -- такими-то и такими-то.
в) Практическое закрепление (почти один-в-один ваш алгоритм) через серию заданий, первые из которых почти сводятся к самостоятельному повторению показанного в пункте "а", а каждое следующее ставит всё более сложные задачи (но в рамках той информации, которая уже была донесена). И, наконец, ставятся задачи, способ решения которых надо найти совершенно самостоятельно. Но к этому моменту объём имеющихся у тренингуемого знаний позволяет ему понять, что искать, где искать, и как применить найденное.

 

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

 

В данном случае не имею ни тени возражения. Так оно и есть. Но что делать, когда за год нужно привести на работу 150-250 человек? Не "пропустить через тренинг", а именно отдать в проекты. И отдать не как камень на шею, а как вполне толковых "молодых бойцов", способных толково решать задачи своего уровня. Здесь, конечно, тоже применяется индивидуальный подход в рамках работы менторов с новичками, но продакшн вполне справедливо требует некоего стандарта: чтобы собеседуя джуниора на проект иметь некий универсальный базис, обязательный минимум для всех и каждого. Смею утверждать из десятилетнего опыта, что т.н. "ISTQB-подход" при всех своих понятных недостатках работает.
 
Лирическое отступление: самая жёсткая критика способа обучения, сторонником которого я являюсь, поступала и поступает из "педагогической среды", где предлагают использовать свой огромный арсенал технологий, в предельном случае позволяющий за 700 лет научить попугая автоматизировать тесты с WebDriver. Но это не работает, когда нужно:
а) Дать много людей.
б) Дать их быстро.
в) Дать их готовыми к работе.

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

Про альтернативный опыт:
[skip]

 

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


  • 0

#11 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 11 сентября 2015 - 07:43

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


Как показано выше, у нас с Алексеем разница во взглядах во многом обусловлена разницей тех условий, в которых мы работаем. Я полностью признаю, что в практике Алексея моя книга может быть бесполезной, но я ведь никого и не заставляю её использовать.

 

Что до вопросов от стажёров, то:
а) Ещё не вечер :). На широкую аудиторию книга была анонсирована всего неделю назад.
б) Стажёры же не только здесь вопросы задают.

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


  • 0

#12 Tishka

Tishka

    Постоянный участник

  • Members
  • PipPipPip
  • 211 сообщений
  • ФИО:Ахрамеев Антон

Отправлено 11 сентября 2015 - 08:02

 

Антон, по первому пункту про отсутствие (или низкое качество) документации ситуация явно выходит за рамки обсуждения книги :). Если вернуться к контексту, то:
1) Я рассматриваю обучение "совсем начинающих" по аналогии с автошколой: сначала учим ПДД и "как правильно". Если есть желание ездить как в "Mad Max: Fury Road", то это это будет потом, в особых случаях при понимании и осознании всех условий и последтвий.
2) У начинающих тестировщиков и так часто бывает ступор, но информация о документации даёт хотя бы какой-то ориентир. Даже если документации нет: появляются идеи о том, какие вопросы задавать.

3) Чем больше будет людей, которых "с пелёнок" приучали к адекватным процессам, тем быстрее эти процессы станут адекватными. Да, не сразу. Но если ничего не предпринимать, ситуация точно не будет улучшаться.

 

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

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

3. Абсолютно согласен, что надо приучать "с пеленок". Правда можно донести до читателя(новичка), что бывает не всегда так и стоит стремиться к таким "адекватным процессам".

 

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

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

Я не имею такого опыта, как у вас, в прокачке 150-200 человек в год. Возможно в этой ситуации книга полезна.

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


  • 0

#13 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 11 сентября 2015 - 08:19

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


Антон, с этим утверждением скорее склонен согласиться. Хотя меня не покидает ощущение, что под "начинающий тестировщик" кто-то может понимать "человек, только-только услышавший о тестировании", а кто-то -- "нуу... это всего 1-2 года опыта" :).

P.S. Ваше мнение услышал, воспринял и учёл. Спасибо!


  • 0

#14 clipsa

clipsa

    Специалист

  • Members
  • PipPipPipPipPip
  • 527 сообщений
  • ФИО:Ермолаева Ольга
  • Город:Москва


Отправлено 11 сентября 2015 - 12:28

Святослав, а есть книга в формате fb2? Хотелось бы с телефона почитать, а в pdf не очень удобно :)


  • 0

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


#15 astenix

astenix

    Специалист

  • Members
  • PipPipPipPipPip
  • 906 сообщений
  • ФИО:Лёша Лупан
  • Город:Кишинев


Отправлено 11 сентября 2015 - 12:57

Дальше наступает тренинг длительностью 1-2 месяца, где ребятам надо дать основы и показать, куда двигаться. Затем следующий этап обучения (2-4 месяца full-time) с уже своими нюансами.

 

Наши типичные проекты выглядят так: "Надо сделать очередной интернет-магазин для очередного международного брэнда на основе очередной CMS для разруливания интернет-магазинов. Ура! Ура! Ура!".

 

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

 

В каком-то смысле, это задачи спецназа, если будет допустимо такое сравнение, а спецназ — это не массовка. Поэтому за год "привести к присяге" 200 человек — нет, "это не наш метод" :)

Поэтому и подготовка другая, всегда личностная.

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

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

 

У нас был этой зимой опыт работы с группой, которую мы не отбирали предварительно, нам ее передали "как есть", и результат был крайне плох, с ними было трудно разговаривать, после итоговых собеседований мы взяли на работу только двоих из десяти, из этих двух один парень "сгорел" за две недели.


У тех, кто "выжил" и был нанят, начинается стандартный для всех трехмесячный период врубания в проектную жизнь. Это как бы продолжение обучения, со своими нюансами, но так или иначе, этоn испытательный срок необходим, бо есть люди, которые не выдерживают. Или "не тянут". Или тянут, но неожиданно не в ту сторону.

 

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


  • 1

Software Testing Glossary - простыми словами о непростых словах.


#16 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 11 сентября 2015 - 20:55

А мне понравилось.

Да, согласен, что книга в многом — «расширенный силлабус ISTQB». Но если к ней прилагается тренер и практические задания, то книга — отличный способ запомнить/упорядочить/уточнить/углубить и т.д., эдакий «конспект лекций».


  • 0

#17 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 14 сентября 2015 - 07:21

Святослав, а есть книга в формате fb2? Хотелось бы с телефона почитать, а в pdf не очень удобно :)

 

Ольга, увы, в fb2 нет. В книге есть некоторое количество картинок и таблиц, которые ну никак не "ужимаются" без потери здравого смысла. Потому даже в бумажной версии оставлен формат А4.


  • 0

#18 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 14 сентября 2015 - 07:58

В каком-то смысле, это задачи спецназа, если будет допустимо такое сравнение, а спецназ — это не массовка. Поэтому за год "привести к присяге" 200 человек — нет, "это не наш метод" :)
Поэтому и подготовка другая, всегда личностная.
[skip]
Итого - пять месяцев обучения для людей, которые приходят в тестирование "с нуля", в условиях, максимально приближенных к боевым.


Интересно то, что у нас очень похожая схема.
1) Отбор на т.н. "внешний тренинг" (на группу в 30 человек приходит от 300 до 800 заявок). Тут проходит отбор с рекрутёрами и техническими специалистами. Тренинг длится около 1.5 месяцев.
2) После внешнего тренинга проходит повторный отбор (в среднем, отбирается 20 человек из 30) с участием технических специалистов и тест-менеджеров. Эти отобранные попадают в т.н. "тест-лабораторию", где 2-4 месяца сидят full-time и обучаются на специально разработанных учебных проектах. С ними работают "специально обученные люди" :), которые в т.ч. могут обеспечить достаточно индивидуальный подход.
3) По мере того, как менеджер лаборатории считает тех или иных ребят "готовыми к бою", их показывают менеджерам с продакшн, проходит ещё одно собеседование. Прошедшие это собеседование попадают в продакшн в должности джуниора, где их показывают заказчику, постепенно включают в настоящий рабочий проект и доучивают (в т.ч. через индивидуальных менторов).

Этот подход вполне позволяет привести за год в компанию пару-тройку сотен человек, реально готовых работать (т.е. успешно проходящих собеседование с заказчиками). Проверено годами, результативность крайне высокая.
  • 0

#19 svyatoslav

svyatoslav

    Новый участник

  • Members
  • Pip
  • 11 сообщений
  • ФИО:Святослав Куликов
  • Город:Минск

Отправлено 14 сентября 2015 - 08:35

А мне понравилось.
Да, согласен, что книга в многом — «расширенный силлабус ISTQB». Но если к ней прилагается тренер и практические задания, то книга — отличный способ запомнить/упорядочить/уточнить/углубить и т.д., эдакий «конспект лекций».


Андрей, спасибо за тёплый отзыв. Во многом для того эта книга и задумывалась.
  • 0

#20 desper79

desper79

    Новый участник

  • Members
  • Pip
  • 8 сообщений
  • ФИО:Артём
  • Город:Москва

Отправлено 10 декабря 2015 - 09:45

Доброго дня,

в целом книга понравилась, по крайней мере своим сотрудникам я рекомендовал читать её перед ISTQB а не после :).

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

 

Есть некоторые вопросы:

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

Как вы тогда на практике решаете следующую ситуацию:

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

 б) При этом требования к блокам дополняются/изменяются в течение спринта.

Как я рекомендую поступать:

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

Этим мы существенно экономим время на обновление всех X тестов при изменении требований к блоку.

 

2. В блоке 'Исходные данные' (стр. 122) вы настоятельно не рекомендуете описывать действия по подготовке, которые выполняются в  самом тестируемом приложении.

a) Пример 1: Как тогда вы будете проверять таблицу на отображение только 10 первых строк (если её наполнение происходит средствами приложения): первые шаги теста будут заключаться в наполнении таблицы данными, а не в непосредственном тестировании требования ?

б) Пример 2: Есть некоторый длинный бизнес процесс и у нас в конце есть форма, которую нам надо проверить. И есть сквозной смоук тест, проходящий по данному процессу.

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

Соответственно сам тест начинается уже с действий уже на нужной нам форме.


  • 0


Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных