Заметка из весны 2017 года.

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

4 года в тестировании – цифра более-менее с потолка. Это не про стаж, а про уверенные навыки в тестировании и опыт разгребания сложных ситуаций.

Но с чем согласна, так с тем, что автотестирование – действительно большая отдельная специальность, которая требует кучи сил и времени для освоения. И идея фулстеков, конечно хороша, когда у человека уже есть все навыки, а вот приходить к этому сложно.

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

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

Хотя в реальности бывает по-разному. И карьеры у людей часто не линейные)

С тех пор кодоцентричность ещё больше выросла, а автотестирование стало таким путем по умолчанию.

Чем-то это все мне напоминает обучение английскому. Много давления, нередко нет связи с целями человека, много историй успеха и мало голосов тех, у кого не получилось.

#адвент
#подпольный_евангелизм

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

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

В категории про то, как понять что-то взято из системного анализа, что-то из математики. Основные техники здесь - это диаграмма состояний и переходов, таблица решений и use case.

Диаграмма состояний и переходов (State-Transition Diagrams) - это специальный граф с состояниями и вариантами перехода между ними. Мне это очень напоминает конечные детерминированные автоматы, цепи Маркова - туда вообщем)

Таблица решений (Decision Table) - это представление в виде таблицы разных сочетаний параметров и ожидаемых действий системы. Помогает понять не пропустили ли мы какие-то сочетания и как система должна на них реагировать.

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

#база_тестирования

С мудростью предков тоже все неоднородно - есть вещи, уже используемые всеми и всегда (как анализ эквивалентных классов и граничных значений), есть просто опыт каких-то других тестировщиков - как чек-листы и чит-листы.

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

Анализ граничных значений исходит из того, что люди часто ошибаются на границе. Было бы хорошо, если бы нам в требованиях сразу писали а-ля а>=b. Так нет, обычно там бывает "не превышая", " не менее" и прочие конструкции естественного языка. Поэтому мы берем границу и проверяем это значение, значение до и после.

Идея pairwaise строится на том, что у нас есть куча параметров и мы не можем проверить их все. Зато можем так построить проверки так, чтобы проверялись все пары значений. Говорят, что это дает до 98% процентов эффективности, хотя свои нюансы здесь есть тоже есть. Техника строится на математических моделях, но обычно достаточно просто описать модель и сгенерить набор в специальной программе. Я рекомендую PICT, потому что там можно в модели задать условия. Потому, что в реальных системах далеко не все сочетания параметров могут существовать на самом деле.

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

А еще есть куча разнообразных эвристик - про то, что у кого-то получилось и было полезным, а мы можем вдохновиться и попробовать у себя. Например, моя любимая про регрессию - http://software-testing.ru/library/testing/general-testing/992-2010-04-20-20-05-53. Вроде бы все очевидно, но все равно полезно.

#база_тестирования

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

Это краткий обзор, более подробно написано у Lee Copeland в "Practitioner's guide software testing".

#база_тестирования

Я хорошо помню тот момент, когда я начала думать над тест-дизайном. Конечно, когда захотела объяснить это другим.

Первые годы моего тестирования я считала тест-дизайн правилами, «делай так – получишь результат». И это работало.

Но когда я вышла на мета-уровень – зачем мы это делаем и почему именно это, какая идея в этом лежит, какие ограничения у метода, то стало сильно интереснее

Недавно разбиралась в методах белого ящика и осознала, что сейчас во многих языках поток данных контролирует IDE. Объявление переменных, использование, области видимости и вот это все. А в классических книжках это предлагают делать ещё вручную.

#адвент

"Ручное тестирование умирает!"

Когда мне говорят, что "ручное тестирование умирает", то первый мой вопрос "ты мне это говоришь, чтобы что?". Если человек не разворачивает свою мысль, я слышу в этом агрессию и заход сверху - "ты занимаешься фигней, твоя работа не нужна". И телесно я реагирую на это тоже как на агрессию - сначала замираю, потом чувствую гнев. И тут мне помогает остановиться, почувствовать себя и подышать.

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

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

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

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

#подпольный_евангелизм

Заметка из декабря 2019 года.

Что ж разговоры про умирающую профессию тестирования без автоматизации я слышу все 10+ лет карьеры. И как-то пока прогнозы не сбываются.

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

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

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

Заменят ли нас роботы. Если верить Сасскинду с «Будущим без работы» – со временем да. Забирая сначала какие-то отдельные функции, а потом и всю работу в текущем виде. Впрочем я думаю, что это произойдет примерно тогда же, когда автоматизируют работу программистов.

Эй, разработчики, вы не боитесь, что ваша профессия умирает?

P.S. Про ChatGPT и истории про то, как им предлагают заменять работу тестировщиков я расскажу как-нибудь отдельно.

#адвент
#подпольный_евангелизм

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

Объявление про запись в исследование и активную помощь себе и науке будет позже, а пока опрос про боль в спине.

#тлен_и_усталость

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

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

Кто-то пытается объяснить команде, что эта дополнительная ценность - выгодна, кто-то уходит из тестирования совсем... Чаще всего это решается сменой команды/компании. И уже в новой команде это выше, быстрее, сильнее становится востребовано.

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

#карьера_в_тестировании

Заметка из ноября 2016.

Несмотря на доминирующее «надо развиваться, а то пиздец» в реальности все гораздо сложнее.

Иногда бывает, что стремление сотрудника развиваться – головная боль для компании. Потому что брали-то они этого сотрудника на конкретные задачи и взять принципиально чего-то нового через полгода неоткуда.

Бывает, что тестировщик хочет развиваться и работать глубже в том же направлении, а компании это не нужно и платить за это она тоже не готова.

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

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

Сейчас я думаю про развитие и карьеру как сотрудничество – есть интересы компании и есть мои интересы. Мы пытаемся найти пересечение, а если не получается – расстаёмся.

#адвент
#учить_и_учиться
#карьера_в_тестировании

Думаю про то, как работать в авариайных ситуациях.

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

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

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

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

Спасибо коллегам из отдела эксплуатации Туту.ру, которые про это рассказали. Подобнее про это все в книге Site Reliability Engineering: How Google Runs Production Systems.

Книга есть онлайн доступе, глава про управление инцидентами - https://landing.google.com/sre/book/chapters/managing-incidents.html

#книги
#менеджерское

С тех пор SRE book перевели на русский (плохо), поэтому рекомендую читать именно в оригинале.

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

Зачем это тестировщикам?

Иногда мы активно участвуем в том, чтобы разобраться в проблеме на продакшене.

А иногда прямо сейчас мы ничего технического полезного сделать не можем. Но даже тогда мы можем помочь – информировать заинтересованных лиц и не давать дергать разработчиков.

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

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

#адвент
#менеджерское
#книги

А следующим постом будет запись в исследование. Помогите науке и почините свои спины!

Понедельник - отличное время, чтобы начать что-то новое. Например - починить уже боль в спине, с которой вы живете больше 3 месяцев (а может быть и всю сознательную жизнь)!

Как многие уже знают, я делаю магистерское исследование по "физической реабилитации при хронической неспецифической боли в грудном отделе позвоночника", это, стало быть, когда больше 12 недель болит где-то в грудном отделе, может по центру, может у лопаток, в сторону отдает, может еще и в руки - случай разный, главное, чтобы не меньше 12 недель назад это несчастье с вами случилось (и не исключительно в пояснице, по пояснице уже все писано-переписано). А с остальными нюансами мы с вами разберемся в ходе подготовки к тренировочной программе, или внутри самой программы. планах ежедневные не потные микро-упражнения на 2 месяца и вдумчивый разбор вашей конкретно ситуации.

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

Лайк, шер, репост, чем больше людей удастся набрать в работу - тем лучше будет доказательность результатов и людей без боли!

А эта цитата поддерживала меня в сложные времена на работе:

"Во многих других компаниях такой же бардак как в вашей

Многие тестировщики в ужасе от количества багов в их продукте и путаницы в компании. Это не необычная ситуация даже в хорошей компании. Тестировщики видят то, что идет не так и это выглядит как косяки. Это не всегда приятно.

Статистически вы можете находиться в худших 10% компаний. Но, вероятней всего, у этих компаний даже нет тестировщиков. Общение с тестировщиками из других компаний поможет вам понять перспективы."

Lessons Learned in Software Testing в переводе Макса Захарова
http://wolonter.blogspot.com/2013/03/lesson-252.html#comment-form

#база_тестирования
#книги

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

Нигде нет работы мечты идеальной для всех. С интересными всем задачами и подходящими всем процессами.

Работы мечты нет, но есть хороший HR-бренд. И часто он сопровождается заговором молчания о реальной работе там.

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

Как говорила одна моя знакомая много лет назад, когда Яндекс считался корпорацией добра, «в Яндекс приходят, гордясь и хвастаясь, а уходят из него очень тихо».

Если вы верите в «работу мечты», то возможно вы мало о ней знаете.

#адвент
#карьера_в_тестировании

Говорили на консультации про скорость тестирования. Я сама часто сталкивалась с тем, что мне говорили или ожидали, что я буду тестировать быстрее. И я хочу поразмышлять над этим.

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

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

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

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

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

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

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

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

И балансировать скорость/качество.

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

#менеджерское
#консультации_по_тестированию

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

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

Но профессиональные разговоры о скорости тестирования другие. Это одна из граней проектного треугольника в целом – скорость, качество, деньги. Надо быстрее? Можно сократить скоуп тестирования и увеличить риски (и это может быть ок). Или можно попробовать что-то поделать с процессами. Или привлечь еще людей. @evrdrnn подробно рассказывала про это на техлидской подлодке.

Как же понять не слишком ли я глубоко тестирую? Или наоборот недостаточно глубоко?

Katrina Clokie предлагает модель маятника. В одной точке – слишком глубоко, в другой – слишком поверхностно. И мы ищем свой баланс для конкретного проекта и конкретной команды.

Чтобы найти это положение, можно смотреть на эмпирические маркеры.

1. Количество багов.

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

2. Обратная связь от коллег.

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

3. Обратная связь от менеджмента.

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

#менеджерское
#адвент

Видела вчера вариант шутки "QA Engineer walks into a bar. Orders a beer. Orders 0 beers..."

QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.

First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.

И если первая еще более-менее смешная и описывает одну из техних тест-анализа, то эта уже нет. Она сводит работу тестировщика только к поиску багов, в то время как реальные пользователи ведут себя по-разному.

На самом деле мы как тестировщики обычно начинаем с того, как пользователи будут применять наш продукт.

Я бы перефразировала этот анекдот на русском так.

Тестировщица заходит в бар. Заказывает 1 кружку пива. Заказывает 1 кружку безалкогольного пива. Заказывает 1 бутылку воды. Заказывает 1 стакан чая. Заказывает 1 стакан кофе. Заказывает еду здесь. Заказывает еду на вынос. Спрашивает, где находится туалет. Просит сделать музыку тише. Спрашивает бармена "за жизнь".

#подпольный_евангелизм

Читатели дополняют, что надо еще добавить "соблазняет бармена", "напивается", "громит кабак" и "выходит из бара" )

#подпольный_евангелизм