Use case и тестирование требований
Хорошая статья про тестирование требований и разработку use case. Очень люблю это метод, мне он позволяет сфокусироваться на разных типах пользователей и их потребностях.
#база_тестирования
#записная_книжка
Хорошая статья про тестирование требований и разработку use case. Очень люблю это метод, мне он позволяет сфокусироваться на разных типах пользователей и их потребностях.
#база_тестирования
#записная_книжка
Хабр
Тестирование требований: как я нахожу ошибки в бизнес-логике фичи прежде, чем их закодят
Привет, Хабр. Меня зовут Ольга, я работаю в тестировании с 2013 года, специализируюсь на тест-анализе и тест-дизайне. Сегодня хочу рассказать, как при планировании тестирования сохранить фокус на...
Терпимость к неидеальности
Тестирование часто связывают с перфекционизмом, а я думаю про терпимость к неидеальности. К тому, что всегда будут баги, которые решили не чинить и всегда будет неидеально. К тому, что совершенство недостижимо, но все равно надо продолжать работать.
Я думаю, что для тестировщиков очень важна грань «достаточно хорошо». Чтобы и не цепляться к мелочам, и не сваливаться в цинизм «а смысл, все равно это никому не нужно». Для меня это похоже на баланс в домашних делах. Невозможно сделать идеально и раз и навсегда, но можно делать регулярно уборку и поддерживать достаточно хорошо.
#база_тестирования
Тестирование часто связывают с перфекционизмом, а я думаю про терпимость к неидеальности. К тому, что всегда будут баги, которые решили не чинить и всегда будет неидеально. К тому, что совершенство недостижимо, но все равно надо продолжать работать.
Я думаю, что для тестировщиков очень важна грань «достаточно хорошо». Чтобы и не цепляться к мелочам, и не сваливаться в цинизм «а смысл, все равно это никому не нужно». Для меня это похоже на баланс в домашних делах. Невозможно сделать идеально и раз и навсегда, но можно делать регулярно уборку и поддерживать достаточно хорошо.
#база_тестирования
Мифы и легенды о тестировании
Вышла моя статья на хабре про тестирование для нетестировщиков. Спасибо всем, кто помогал в этой работе.
#база_тестирования
#longread
Вышла моя статья на хабре про тестирование для нетестировщиков. Спасибо всем, кто помогал в этой работе.
#база_тестирования
#longread
Хабр
Мифы и легенды о тестировании
Тестирование — не то, чем кажется. Я работаю тестировщицей больше десяти лет и встречала разные мифы о своей работе. В этой статье я разберу самые популярные из них. Автор статьи — Ольга Артемьева,...
Настя и Саша написали отличный гайд про то, что делать, если хочешь стать тестировщицей или тестировщиком.
#база_тестирования
#база_тестирования
Клиент-сервер, API и все-все-все
Хорошая вводная информация про клиент-серверное взаимодействие, HTTP и JSON в бесплатной части курса «Системный аналитик» от Яндекс.Практикума.
Мне понравились аналогии с рестораном и простые задания на понимание. Рекомендую глянуть новичкам.
#база_тестирования
Хорошая вводная информация про клиент-серверное взаимодействие, HTTP и JSON в бесплатной части курса «Системный аналитик» от Яндекс.Практикума.
Мне понравились аналогии с рестораном и простые задания на понимание. Рекомендую глянуть новичкам.
#база_тестирования
Как тестировать десктоп
Когда четыре года назад пришла в КритоПро, то первый раз столкнулась с тестированием десктопных приложений. Это была и клиентская и серверная винды, и разные линуксы.
Я опиралась на свой опыт десятилетней давности с убунтой и книжку Робачевского (также известную как книжка про UNIX c черепахой). Но разбираться все равно пришлось много — где здесь смотреть логи, как работать с реестром, как поставить и настроить IIS и т.д.
Моя коллега из Крипто-Про начала вести канал про тестирование десктопных приложений. Очень его рекомендую — тема достаточно узкая, инфы по ней сейчас мало, а Лена пишет с азов.
#база_тестирования
Когда четыре года назад пришла в КритоПро, то первый раз столкнулась с тестированием десктопных приложений. Это была и клиентская и серверная винды, и разные линуксы.
Я опиралась на свой опыт десятилетней давности с убунтой и книжку Робачевского (также известную как книжка про UNIX c черепахой). Но разбираться все равно пришлось много — где здесь смотреть логи, как работать с реестром, как поставить и настроить IIS и т.д.
Моя коллега из Крипто-Про начала вести канал про тестирование десктопных приложений. Очень его рекомендую — тема достаточно узкая, инфы по ней сейчас мало, а Лена пишет с азов.
#база_тестирования
Telegram
DesktopQA (inside and out)
Размышления о тестировании десктопных приложений (немного занудно)
Мои любимые способы что-нибудь глубоко изучить — обложить себя интересными материалами, много думать, применять на практике, а потом рассказывать другим людям в лекциях или статьях. Из всего, что нас не убивает, получится статья)
Но иногда бывает и наоборот.
Начала вести лекции по тестовой документации. Я про нее в целом знаю, но в моей опыте был изрядный перекос в сторону чек-листов и минимальной отчетности. Я никогда не писала высокоуровневые тест-планы в реальной жизни, а тест-кейсы у меня были только на двух работах и одна из них была очень давно. Это не моя любимая тема тест-дизайна и тест-аналитики, про которую я готова поговорить в любое время дня и ночи.
На подготовку к одной лекции я потратила 10 часов чистого времени, а к другой — 6.
И это при том, что база материала у меня уже была. Структурировать материал, вспомнить важное из моего опыта, подобрать примеры, придумать Concept Checking Questions, отрепетировать это все и понять тайминг...
И это еще не конец...
Я провожу лекцию и дальше отвечаю на вопросы студентам. Рассказываю, что в нашем деле нет алгоритмов "раз-два-три". Есть хорошие практики, есть какие-то соображения, но многое зависит от контекста и постигается на опыте. Но какие-то опоры все равно нужны и их формулировать тоже интересная задача. Понимаю, что хорошо бы добавить в следующий раз в явном виде.
Я не проверяю домашние задания, но с ними работают мои коллеги и тоже рассказывают, что лучше добавить и рассказать подробнее.
Никогда я столько не думала про тестовую документацию!
#учить_и_учиться
#база_тестирования
Но иногда бывает и наоборот.
Начала вести лекции по тестовой документации. Я про нее в целом знаю, но в моей опыте был изрядный перекос в сторону чек-листов и минимальной отчетности. Я никогда не писала высокоуровневые тест-планы в реальной жизни, а тест-кейсы у меня были только на двух работах и одна из них была очень давно. Это не моя любимая тема тест-дизайна и тест-аналитики, про которую я готова поговорить в любое время дня и ночи.
На подготовку к одной лекции я потратила 10 часов чистого времени, а к другой — 6.
И это при том, что база материала у меня уже была. Структурировать материал, вспомнить важное из моего опыта, подобрать примеры, придумать Concept Checking Questions, отрепетировать это все и понять тайминг...
И это еще не конец...
Я провожу лекцию и дальше отвечаю на вопросы студентам. Рассказываю, что в нашем деле нет алгоритмов "раз-два-три". Есть хорошие практики, есть какие-то соображения, но многое зависит от контекста и постигается на опыте. Но какие-то опоры все равно нужны и их формулировать тоже интересная задача. Понимаю, что хорошо бы добавить в следующий раз в явном виде.
Я не проверяю домашние задания, но с ними работают мои коллеги и тоже рассказывают, что лучше добавить и рассказать подробнее.
Никогда я столько не думала про тестовую документацию!
#учить_и_учиться
#база_тестирования
Telegram
Прописи преподки
— Понятно? — спрашивает преподка философии в конце двухчасовой лекции.
Эти два часа наша группа тихо писала в чат "о чем вообще речь?", "что происходит?", "мне нужна психологическая поддержка" и "я хочу домой".
У меня перед внутренним взором всплывает…
Эти два часа наша группа тихо писала в чат "о чем вообще речь?", "что происходит?", "мне нужна психологическая поддержка" и "я хочу домой".
У меня перед внутренним взором всплывает…
«Да никто не использует тест-дизайн в реальной жизни!»
Говорят мне в чатах и на собеседованиях. «Ну не будет же мидл сидеть и придумать классы эквивалентности и граничные значения, он это делает интуитивно». Люди считают это теорией.
Нет, конечно есть неосознанная компетентность. Это в целом легко проверить тестовым заданием — применяет ли человек какие-то идеи или нет. Качество результатов очень разное.
Но в моем опыте с ростом опыта и уровня задач тестировщики возвращаются обратно к уровню осознанной компетентности. Только теперь они не внимательно делают по правилам, а смотрят на границы применимости и контекст. Типовых задач, которые можно делать на автомате, становится меньше.
Ну и я ожидаю, что к собеседованию кандидат или кандидатка порефлексируют над тем, что именно они делают и зачем.
Но чаще всего авторы тезиса из заголовка сами не очень умеют применять тест-дизайн. Возможно потому, что считают, что это не нужно.
#база_тестирования
Говорят мне в чатах и на собеседованиях. «Ну не будет же мидл сидеть и придумать классы эквивалентности и граничные значения, он это делает интуитивно». Люди считают это теорией.
Нет, конечно есть неосознанная компетентность. Это в целом легко проверить тестовым заданием — применяет ли человек какие-то идеи или нет. Качество результатов очень разное.
Но в моем опыте с ростом опыта и уровня задач тестировщики возвращаются обратно к уровню осознанной компетентности. Только теперь они не внимательно делают по правилам, а смотрят на границы применимости и контекст. Типовых задач, которые можно делать на автомате, становится меньше.
Ну и я ожидаю, что к собеседованию кандидат или кандидатка порефлексируют над тем, что именно они делают и зачем.
Но чаще всего авторы тезиса из заголовка сами не очень умеют применять тест-дизайн. Возможно потому, что считают, что это не нужно.
#база_тестирования
Опрос про тест-дизайн в вашей жизни
Я много разговариваю в разных местах про тест-дизайн, его применимость и почему для меня это 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 создают программисты, но мы можем обращать внимание на детали и хорошие практики.
• Заметка про нехватку языковой диверсити в международной компании и какие проблемы это рождает
• Кира Кузьменко и главное слово кандидата на собеседовании. Предлагает прямо наклеить стикер на монитор.
• Как понять, где проблема – на бекенде или на фронтенде?
• Перевод статьи про то, что невозможно знать все и это ок
«Даже в области, где вы много знаете и считаетесь «экспертом», будет масса того, чего вы не знаете или пока еще не знаете. Это нормально. Никто не ожидает, что вы знаете все».
Привет всем тем, кто стыдит нас за то, что это должен знать джун/миддл/кто-угодно.
#дайджест
#карьера_в_тестировании
#база_тестирования
Тестирование и жизнь
Подумала, что лучшее введение в исследование, которое я знаю — «Доклад о медузах» Али Бенджамин. Электронной книги нет, но есть бумажное издание и потрясающий аудиоспекталь от театра «Глобус».
Это фикшн, про взросление аутичной девочки, ее дружбу, смерть подруги и попытки справиться с горем. А еще про то, как делать исследования. Пусть школьный проект по естествознанию, но все равно настоящее исследование.
У большинства из нас этого никогда не было в школе и далеко не всех этому учили в институтах, так что рекомендую)
#книги
#diversity
#база_тестирования
Это фикшн, про взросление аутичной девочки, ее дружбу, смерть подруги и попытки справиться с горем. А еще про то, как делать исследования. Пусть школьный проект по естествознанию, но все равно настоящее исследование.
У большинства из нас этого никогда не было в школе и далеко не всех этому учили в институтах, так что рекомендую)
#книги
#diversity
#база_тестирования
Никто не скажет, как понять именно вам, когда остановить тестирование. Но с помощью карты от Даши можно поразмышлять о разных критериях.
#база_тестирования
#база_тестирования