«Да никто не использует тест-дизайн в реальной жизни!»
Говорят мне в чатах и на собеседованиях. «Ну не будет же мидл сидеть и придумать классы эквивалентности и граничные значения, он это делает интуитивно». Люди считают это теорией.
Нет, конечно есть неосознанная компетентность. Это в целом легко проверить тестовым заданием — применяет ли человек какие-то идеи или нет. Качество результатов очень разное.
Но в моем опыте с ростом опыта и уровня задач тестировщики возвращаются обратно к уровню осознанной компетентности. Только теперь они не внимательно делают по правилам, а смотрят на границы применимости и контекст. Типовых задач, которые можно делать на автомате, становится меньше.
Ну и я ожидаю, что к собеседованию кандидат или кандидатка порефлексируют над тем, что именно они делают и зачем.
Но чаще всего авторы тезиса из заголовка сами не очень умеют применять тест-дизайн. Возможно потому, что считают, что это не нужно.
#база_тестирования
Говорят мне в чатах и на собеседованиях. «Ну не будет же мидл сидеть и придумать классы эквивалентности и граничные значения, он это делает интуитивно». Люди считают это теорией.
Нет, конечно есть неосознанная компетентность. Это в целом легко проверить тестовым заданием — применяет ли человек какие-то идеи или нет. Качество результатов очень разное.
Но в моем опыте с ростом опыта и уровня задач тестировщики возвращаются обратно к уровню осознанной компетентности. Только теперь они не внимательно делают по правилам, а смотрят на границы применимости и контекст. Типовых задач, которые можно делать на автомате, становится меньше.
Ну и я ожидаю, что к собеседованию кандидат или кандидатка порефлексируют над тем, что именно они делают и зачем.
Но чаще всего авторы тезиса из заголовка сами не очень умеют применять тест-дизайн. Возможно потому, что считают, что это не нужно.
#база_тестирования
Опрос про тест-дизайн в вашей жизни
Я много разговариваю в разных местах про тест-дизайн, его применимость и почему для меня это hard skill тестировщика. Мои коллеги из ПК Podlodka QA Crew разделяют мою любовь к этой теме, поэтому мы думаем сделать курс про тест-дизайн в реальной жизни — то, что выходит за рамки примеров из статей и обучающих видео.
Расскажите, пожалуйста, про ваш опыт с тест-дизайном. Какие методы используете и как часто? Что кажется сложным? Используете ли вы эвристики? И прочие вопросы про вашу жизнь)
Опрос проводим до 1 мая.
Буду очень благодарно за ваш опыт!
#учить_и_учиться
#база_тестирования
Я много разговариваю в разных местах про тест-дизайн, его применимость и почему для меня это hard skill тестировщика. Мои коллеги из ПК Podlodka QA Crew разделяют мою любовь к этой теме, поэтому мы думаем сделать курс про тест-дизайн в реальной жизни — то, что выходит за рамки примеров из статей и обучающих видео.
Расскажите, пожалуйста, про ваш опыт с тест-дизайном. Какие методы используете и как часто? Что кажется сложным? Используете ли вы эвристики? И прочие вопросы про вашу жизнь)
Опрос проводим до 1 мая.
Буду очень благодарно за ваш опыт!
#учить_и_учиться
#база_тестирования
Google Docs
Все о тест-дизайне
Тест-дизайн - кажется, что про него слышал каждый QA-инженер, но все мы по-разному понимаем и применяем техники. Хотим узнать чуть больше о вашем опыте. По итогам опроса обязательно поделимся результатами
Testing is not part of Computer Science
... but knowing Computer Science helps.
Если выбирать одну идею, которая повлияла на меня в тестировании, то скорее всего я назову именно эту.
Две тысячи одиннадцатый. Я работаю в техподдержке и смотрю, что такое тестирование. Нахожу Савина, какие-то блоги и видео Джеймса Баха «Becoming a Software Testing Expert». И это была главная идея выступления для меня тогда.
Но что же тестирование такое, если не часть Computer Science? Social Science!
Мы работаем с прежде всего с людьми. Это люди придумывают что-то новое и экспериментируют, это люди недооценивают риски, не так понимают друг друга и плохо предсказывают последствия своих действий. А программы выполняют ровно то, что мы им сказали сделать (ну по крайней мере большинство из них).
Подробнее про это можно посмотреть в программной работе Канера «Software Testing as a Social Science» и серии постов «What testing can learn from social science».
#подпольный_евангелизм
#база_тестирования
... but knowing Computer Science helps.
Если выбирать одну идею, которая повлияла на меня в тестировании, то скорее всего я назову именно эту.
Две тысячи одиннадцатый. Я работаю в техподдержке и смотрю, что такое тестирование. Нахожу Савина, какие-то блоги и видео Джеймса Баха «Becoming a Software Testing Expert». И это была главная идея выступления для меня тогда.
Но что же тестирование такое, если не часть Computer Science? Social Science!
Мы работаем с прежде всего с людьми. Это люди придумывают что-то новое и экспериментируют, это люди недооценивают риски, не так понимают друг друга и плохо предсказывают последствия своих действий. А программы выполняют ровно то, что мы им сказали сделать (ну по крайней мере большинство из них).
Подробнее про это можно посмотреть в программной работе Канера «Software Testing as a Social Science» и серии постов «What testing can learn from social science».
#подпольный_евангелизм
#база_тестирования
Forwarded from Тестирование и жизнь (Olga Artemyeva)
Рассказывала в очередной раз про тест-дизайн. Общая концепция в голове есть, а детали приходится каждый раз уточнять. И у меня получается каждый раз какой-то свой набор этого всего. В этот раз положу черновые заметки здесь.
С моей кочки техники тест-дизайна делятся на две группы - это либо "как понять, что надо сделать и найти пропущенную инфу", либо "мудрость предков" - опыт других тестировщиков, где искать проблемы.
В категории про то, как понять что-то взято из системного анализа, что-то из математики. Основные техники здесь - это диаграмма состояний и переходов, таблица решений и use case.
Диаграмма состояний и переходов (State-Transition Diagrams) - это специальный граф с состояниями и вариантами перехода между ними. Мне это очень напоминает конечные детерминированные автоматы, цепи Маркова - туда вообщем)
Таблица решений (Decision Table) - это представление в виде таблицы разных сочетаний параметров и ожидаемых действий системы. Помогает понять не пропустили ли мы какие-то сочетания и как система должна на них реагировать.
В use case мы обращаемся к тому, что пользователь будет делать с нашей системой. В идеальном мире это все уже сделал аналитик, в реальном иногда приходится нам.
#база_тестирования
С моей кочки техники тест-дизайна делятся на две группы - это либо "как понять, что надо сделать и найти пропущенную инфу", либо "мудрость предков" - опыт других тестировщиков, где искать проблемы.
В категории про то, как понять что-то взято из системного анализа, что-то из математики. Основные техники здесь - это диаграмма состояний и переходов, таблица решений и use case.
Диаграмма состояний и переходов (State-Transition Diagrams) - это специальный граф с состояниями и вариантами перехода между ними. Мне это очень напоминает конечные детерминированные автоматы, цепи Маркова - туда вообщем)
Таблица решений (Decision Table) - это представление в виде таблицы разных сочетаний параметров и ожидаемых действий системы. Помогает понять не пропустили ли мы какие-то сочетания и как система должна на них реагировать.
В use case мы обращаемся к тому, что пользователь будет делать с нашей системой. В идеальном мире это все уже сделал аналитик, в реальном иногда приходится нам.
#база_тестирования
Forwarded from Тестирование и жизнь (Olga Artemyeva)
С мудростью предков тоже все неоднородно - есть вещи, уже используемые всеми и всегда (как анализ эквивалентных классов и граничных значений), есть просто опыт каких-то других тестировщиков - как чек-листы и чит-листы.
Анализ эквивалентных классов строится на том, что мы ищем то, что не похоже на все остальное. Мы не можем проверить все значения, поэтому считаем, что на любое значение из выбранного набора система реагирует одинаково. Главное найти эти наборы) Если не учтем что-то - то можем пропустить проблему.
Анализ граничных значений исходит из того, что люди часто ошибаются на границе. Было бы хорошо, если бы нам в требованиях сразу писали а-ля а>=b. Так нет, обычно там бывает "не превышая", " не менее" и прочие конструкции естественного языка. Поэтому мы берем границу и проверяем это значение, значение до и после.
Идея pairwaise строится на том, что у нас есть куча параметров и мы не можем проверить их все. Зато можем так построить проверки так, чтобы проверялись все пары значений. Говорят, что это дает до 98% процентов эффективности, хотя свои нюансы здесь есть тоже есть. Техника строится на математических моделях, но обычно достаточно просто описать модель и сгенерить набор в специальной программе. Я рекомендую PICT, потому что там можно в модели задать условия. Потому, что в реальных системах далеко не все сочетания параметров могут существовать на самом деле.
Идея туров Виттакера в том, что система - это незнакомый город, а тестировщик - это турист с каким-то определенным планом. Например, идти строго по путеводителю (по справочным материалам сайта) или найти все денежные функции своего продукта и проверить их. Мне кажется, что это дает новый взгляд на свой продукт.
А еще есть куча разнообразных эвристик - про то, что у кого-то получилось и было полезным, а мы можем вдохновиться и попробовать у себя. Например, моя любимая про регрессию - http://software-testing.ru/library/testing/general-testing/992-2010-04-20-20-05-53. Вроде бы все очевидно, но все равно полезно.
#база_тестирования
Анализ эквивалентных классов строится на том, что мы ищем то, что не похоже на все остальное. Мы не можем проверить все значения, поэтому считаем, что на любое значение из выбранного набора система реагирует одинаково. Главное найти эти наборы) Если не учтем что-то - то можем пропустить проблему.
Анализ граничных значений исходит из того, что люди часто ошибаются на границе. Было бы хорошо, если бы нам в требованиях сразу писали а-ля а>=b. Так нет, обычно там бывает "не превышая", " не менее" и прочие конструкции естественного языка. Поэтому мы берем границу и проверяем это значение, значение до и после.
Идея pairwaise строится на том, что у нас есть куча параметров и мы не можем проверить их все. Зато можем так построить проверки так, чтобы проверялись все пары значений. Говорят, что это дает до 98% процентов эффективности, хотя свои нюансы здесь есть тоже есть. Техника строится на математических моделях, но обычно достаточно просто описать модель и сгенерить набор в специальной программе. Я рекомендую PICT, потому что там можно в модели задать условия. Потому, что в реальных системах далеко не все сочетания параметров могут существовать на самом деле.
Идея туров Виттакера в том, что система - это незнакомый город, а тестировщик - это турист с каким-то определенным планом. Например, идти строго по путеводителю (по справочным материалам сайта) или найти все денежные функции своего продукта и проверить их. Мне кажется, что это дает новый взгляд на свой продукт.
А еще есть куча разнообразных эвристик - про то, что у кого-то получилось и было полезным, а мы можем вдохновиться и попробовать у себя. Например, моя любимая про регрессию - http://software-testing.ru/library/testing/general-testing/992-2010-04-20-20-05-53. Вроде бы все очевидно, но все равно полезно.
#база_тестирования
software-testing.ru
Эвристики ХРОНИЧеского регрессионного тестирования
Software-Testing.Ru - портал специалистов по тестированию и обеспечению качества ПО
Forwarded from Тестирование и жизнь (Olga Artemyeva)
Я не беру здесь техники для белого ящика - мне кажется, это больше все-таки для юнит-тестирования. А вот все, что выше применимо в принципе всеми, в различных случаях.
Это краткий обзор, более подробно написано у Lee Copeland в "Practitioner's guide software testing".
#база_тестирования
Это краткий обзор, более подробно написано у Lee Copeland в "Practitioner's guide software testing".
#база_тестирования
Forwarded from Тестирование и жизнь (Olga Artemyeva)
А эта цитата поддерживала меня в сложные времена на работе:
"Во многих других компаниях такой же бардак как в вашей
Многие тестировщики в ужасе от количества багов в их продукте и путаницы в компании. Это не необычная ситуация даже в хорошей компании. Тестировщики видят то, что идет не так и это выглядит как косяки. Это не всегда приятно.
Статистически вы можете находиться в худших 10% компаний. Но, вероятней всего, у этих компаний даже нет тестировщиков. Общение с тестировщиками из других компаний поможет вам понять перспективы."
Lessons Learned in Software Testing в переводе Макса Захарова
http://wolonter.blogspot.com/2013/03/lesson-252.html#comment-form
#база_тестирования
#книги
"Во многих других компаниях такой же бардак как в вашей
Многие тестировщики в ужасе от количества багов в их продукте и путаницы в компании. Это не необычная ситуация даже в хорошей компании. Тестировщики видят то, что идет не так и это выглядит как косяки. Это не всегда приятно.
Статистически вы можете находиться в худших 10% компаний. Но, вероятней всего, у этих компаний даже нет тестировщиков. Общение с тестировщиками из других компаний поможет вам понять перспективы."
Lessons Learned in Software Testing в переводе Макса Захарова
http://wolonter.blogspot.com/2013/03/lesson-252.html#comment-form
#база_тестирования
#книги
Blogspot
Lesson 252
Блог о тестировании вообще и обо мне в частности. Хроники тестировщика.
Forwarded from Тестирование и жизнь (Olga Artemyeva)
Продолжаю читать Lessons Learned in Software Testing в переводе Макса Захарова.
И сегодня думаю над главой 136.
"Тестируемость продукта часто является лучшей инвестицией, чем автоматизация.
Во многих случаях тесты можно поддержать улучшением тестируемости (поддержка тестов в продукте, обеспечивающая контроль и отображение объектов). Некоторые примеры:
- После установки продукта пользователям (или тестировщикам) приходится искать в логе ошибки установки, если таковые появились. Как можно автоматизировать эту проверку? Первая мысль — написать скрипт, который ищет в логе установки возможные ошибки. Вторая неплохая идея заключается в интеграции такой проверки в продукт. Возможно, это улучшит тестируемость и принесет выгоду пользователям.
- Тестировщикам необходимо сэмулировать ошибки на ленте бекапов ПО, чтоб поверить корректность восстановления из бекапа. Скорее всего, потребуется эмулятор накопителя на магнитной ленте. Вместо этого тестировщики могут работать с программистами, чтоб на низком уровне создать некорректные записи на ленту.
- Проверки значений в коде, которые сигнализируют об ошибке, если значение некорректно. Проверки могут быть помещены непосредственно в код приложения и проводиться до тестирования. Это часто поще и эффективней, чем писать внешний код для проверки приложения."
#база_тестирования
#книги
И сегодня думаю над главой 136.
"Тестируемость продукта часто является лучшей инвестицией, чем автоматизация.
Во многих случаях тесты можно поддержать улучшением тестируемости (поддержка тестов в продукте, обеспечивающая контроль и отображение объектов). Некоторые примеры:
- После установки продукта пользователям (или тестировщикам) приходится искать в логе ошибки установки, если таковые появились. Как можно автоматизировать эту проверку? Первая мысль — написать скрипт, который ищет в логе установки возможные ошибки. Вторая неплохая идея заключается в интеграции такой проверки в продукт. Возможно, это улучшит тестируемость и принесет выгоду пользователям.
- Тестировщикам необходимо сэмулировать ошибки на ленте бекапов ПО, чтоб поверить корректность восстановления из бекапа. Скорее всего, потребуется эмулятор накопителя на магнитной ленте. Вместо этого тестировщики могут работать с программистами, чтоб на низком уровне создать некорректные записи на ленту.
- Проверки значений в коде, которые сигнализируют об ошибке, если значение некорректно. Проверки могут быть помещены непосредственно в код приложения и проводиться до тестирования. Это часто поще и эффективней, чем писать внешний код для проверки приложения."
#база_тестирования
#книги
Blogspot
Lesson 136
Блог о тестировании вообще и обо мне в частности. Хроники тестировщика.
Пятничный дайджест
И снова то, что я в последнее время посмотрела, послушала и прочитала.
• Podlodka Podcast про тест-кейсы, а на самом деле про тестовую документацию с разных сторон. Спасибо Насте Заречневой за два часа разговора. Рекомендую всем – и если вы только краем уха слышали, что тестировщики пишут тест-кейсы и если вы сами уже много лет в тестировании.
• What I Mean When I Say I'm Autistic: Unpuzzling a Life on the Autism Spectrum. Annie Kotowicz. Годная вводная книжка про аутизм от лица взрослой аутистки. И личный опыт, и объяснения как работает нейроотличных мозг и советы, как можно сделать себе жизнь комфортнее.
• Эпизод подкаста «Стакан воды» про отдых. Почему нам так сложно отдыхать? Как понять, что я правильно отдохнула? И отдых ли смотреть сериалы?
• Архитектурные карточки. Несколько лет показал @BasilianRay и я их героически переводила с немецкого. А теперь они все на английском.
Они про то, как с разных сторон можно посмотреть на вашу архитектуру и процессы. Мои любимые – «нарисуй архитектуру своего приложения на подставке под пиво» , «что должно произойти, чтобы вы выбросили вашу систему в мусорную корзину?» и «решения, которые вы не выбрали»
#дайджест
#база_тестирования
#тлен_и_усталость
#diversity
И снова то, что я в последнее время посмотрела, послушала и прочитала.
• Podlodka Podcast про тест-кейсы, а на самом деле про тестовую документацию с разных сторон. Спасибо Насте Заречневой за два часа разговора. Рекомендую всем – и если вы только краем уха слышали, что тестировщики пишут тест-кейсы и если вы сами уже много лет в тестировании.
• What I Mean When I Say I'm Autistic: Unpuzzling a Life on the Autism Spectrum. Annie Kotowicz. Годная вводная книжка про аутизм от лица взрослой аутистки. И личный опыт, и объяснения как работает нейроотличных мозг и советы, как можно сделать себе жизнь комфортнее.
• Эпизод подкаста «Стакан воды» про отдых. Почему нам так сложно отдыхать? Как понять, что я правильно отдохнула? И отдых ли смотреть сериалы?
• Архитектурные карточки. Несколько лет показал @BasilianRay и я их героически переводила с немецкого. А теперь они все на английском.
Они про то, как с разных сторон можно посмотреть на вашу архитектуру и процессы. Мои любимые – «нарисуй архитектуру своего приложения на подставке под пиво» , «что должно произойти, чтобы вы выбросили вашу систему в мусорную корзину?» и «решения, которые вы не выбрали»
#дайджест
#база_тестирования
#тлен_и_усталость
#diversity
Пятничный дайджест #6
• Невидимый город – новый подкаст от Либо🔺Либо про женское феминистское движения в России 19 века.
• Доклад о медузах. Аудио спектакль театра «Глобус»
История про девочку в спектре (нам про это не говорят, но это понятно). Про ее дружбу и смерть подруги, про попытку найти причину, как делать исследование и конечно про медуз.
• Перевод статьи Майкла Болтона про то, что метод граничных значений не такая простая штука, как кажется на первый взгляд.
• Подробный рассказ про то, как декомпозировать задачи при планировании и оценке.
• Матрица доверия и прозрачности при взаимодействии с начальством. И зачем нужны все эти отчёты.
#дайджест
#менеджерское
#книги
#база_тестирования
• Невидимый город – новый подкаст от Либо🔺Либо про женское феминистское движения в России 19 века.
• Доклад о медузах. Аудио спектакль театра «Глобус»
История про девочку в спектре (нам про это не говорят, но это понятно). Про ее дружбу и смерть подруги, про попытку найти причину, как делать исследование и конечно про медуз.
• Перевод статьи Майкла Болтона про то, что метод граничных значений не такая простая штука, как кажется на первый взгляд.
• Подробный рассказ про то, как декомпозировать задачи при планировании и оценке.
• Матрица доверия и прозрачности при взаимодействии с начальством. И зачем нужны все эти отчёты.
#дайджест
#менеджерское
#книги
#база_тестирования
Дайджест #11
Пока я собираю сложные тексты, снова пришло время дайджеста.
• Капитанские правила для REST API
Как сделать API удобным для использования, в том числе и нами. Конечно, само API создают программисты, но мы можем обращать внимание на детали и хорошие практики.
• Заметка про нехватку языковой диверсити в международной компании и какие проблемы это рождает
• Кира Кузьменко и главное слово кандидата на собеседовании. Предлагает прямо наклеить стикер на монитор.
• Как понять, где проблема – на бекенде или на фронтенде?
• Перевод статьи про то, что невозможно знать все и это ок
«Даже в области, где вы много знаете и считаетесь «экспертом», будет масса того, чего вы не знаете или пока еще не знаете. Это нормально. Никто не ожидает, что вы знаете все».
Привет всем тем, кто стыдит нас за то, что это должен знать джун/миддл/кто-угодно.
#дайджест
#карьера_в_тестировании
#база_тестирования
Пока я собираю сложные тексты, снова пришло время дайджеста.
• Капитанские правила для REST API
Как сделать API удобным для использования, в том числе и нами. Конечно, само API создают программисты, но мы можем обращать внимание на детали и хорошие практики.
• Заметка про нехватку языковой диверсити в международной компании и какие проблемы это рождает
• Кира Кузьменко и главное слово кандидата на собеседовании. Предлагает прямо наклеить стикер на монитор.
• Как понять, где проблема – на бекенде или на фронтенде?
• Перевод статьи про то, что невозможно знать все и это ок
«Даже в области, где вы много знаете и считаетесь «экспертом», будет масса того, чего вы не знаете или пока еще не знаете. Это нормально. Никто не ожидает, что вы знаете все».
Привет всем тем, кто стыдит нас за то, что это должен знать джун/миддл/кто-угодно.
#дайджест
#карьера_в_тестировании
#база_тестирования