Заметка из ноября 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 стакан кофе. Заказывает еду здесь. Заказывает еду на вынос. Спрашивает, где находится туалет. Просит сделать музыку тише. Спрашивает бармена "за жизнь".

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

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

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

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

Я тут думаю, что я бы еще проверила оплату мобильными приложениями)

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

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

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

Люди вокруг впитывают это некритично, а потом это становится тем, что «все знают». Видела кучу людей, которые хотят стать тестировщиками и приходят вот со всем этим в голове.

У юмора две коммуникативные цели: своих (адресата) рассмешить, чужих (объект) принизить. И для объектов «шутки» – это уже не шутка, а речевая агрессия. Даже если вы не хотели никого оскорбить или обидеть.

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

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

«Все хорошо, но язык надо будет подтянуть»

Мария Ковина-Горелик пишет про то, что может скрываться за этой фразой после оффера. На примере английского языка.

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

Дальше цитирую Марию.

«Кандидата берут на работу с единственным условием: «Нужно будет подтянуть английский язык». Кандидат радостно соглашается.

Дальше происходит следующее. Новое рабочее место требует огромного напряжения всех ресурсов организма. Конечно же, никаких лишних сил на дополнительные занятия языком, как правило, не оказывается. При этом кандидат – а теперь уже работник – довольно быстро попадает в ситуации, где нужен именно тот английский язык и именно те компетенции в нем, которые идут рука об руку с job description. Начинается столь нелюбимое мною «продуцирование из дефицита». Дефицит не всегда так уж связан со знаниями – он может быть связан, например, с общей стрессовой ситуацией (все новое, все страшно, от страха язык прилип к гортани, забыл, все, что знал). Но работать нужно – уже сейчас.

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

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

Во-вторых, человек в принципе привыкает все время действовать в языке из стресса и как результат – смертельно устает. Дополнительные занятия становятся все менее и менее реальными, потому что – ну кто же добровольно будет засовывать себя обратно в этот кошмар, когда только что закончилось ежедневное восьмичасовое подневольное потение. Даже если, понимая всю безвыходность своего положения, наш герой идет на какие-то занятия, там его не ждет ничего хорошего, потому что он не идет туда с запросом: «научите меня языку» — он уже идет туда с запросом: «избавьте меня от этого повседневного ужаса», но на этот запрос на курсах или частных уроках языка ответа нет и быть не может. Это работа психотерапевтического и методического толка, потому что нужно объяснить человеку: куда он попал, почему он чувствует то, что чувствует, почему стандартный поступательный вариант обучения ему больше не годится, а также какие есть теперь пути решения. Почему придется медленно и с большим откатом назад. Почему еще долго то, что будет происходить на уроках, никак не будет отражаться на работе, и как в этих условиях сохранить веру в будущий прогресс.

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

…и тут как раз подступает счастливая пора оценки первого года работы. Более или менее формальная, приуроченная к мандаринам с шампанским или к шашлыкам с пивом – это все неважно. Важно, что рано или поздно начинается давление: «мы говорили о необходимости улучшить язык, он улучшился – но недостаточно, что вы делаете для того, чтобы его улучшить?» Вариант: «Мы вам дали преподавателя, организовали занятия, мы их оплачиваем – но прогресс не такой, какой мы ожидали, в чем дело?» (о корпоративных занятиях языком поговорим в другом тексте).

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

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

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

Коллеги обещают помогать и отвечать на вопросы, предлагают делать по аналогии и вместе...

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

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

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

Вот цитата из перевода статьи про ошибки автоматизации.

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

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

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

Часто компании ожидают, что люди научатся программировать за неделю и немедленно начнут производить хорошую автоматизацию тестирования. Это безумие. Почему мне дается неделя, чтобы узнать об «ifs» и «elses» в колледже, но человеку без опыта дается всего одна неделя, чтобы изучить все инструменты, необходимые для базового программирования?»

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

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

Тестирование vs QA

Я считаю себя тестировщицей. В наших краях тестирование и QA то смешиваются, то вкладываются одно в другое.

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

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

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

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

До сих пор встречаю негодующее «я не просто тестировщик, я – QA» и «давайте переходить от тестирования к QA»

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

Ко всему этому стоит относиться критично, как и в целом к базе тестирования.

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

В мире контекстного тестирования, с которым я в основном сталкивалась, все выглядит иначе.

Есть четкие проверки (и их проще автоматизировать), есть тестирование как интеллектуальная исследовательская деятельность и есть общая работа, чтобы сделать качественный продукт.

Тестировщики, хватит заниматься обеспечением качества!

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

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

Продолжаю читать Lessons Learned in Software Testing в переводе Макса Захарова.

И сегодня думаю над главой 136.

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

Во многих случаях тесты можно поддержать улучшением тестируемости (поддержка тестов в продукте, обеспечивающая контроль и отображение объектов). Некоторые примеры:

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

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

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

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

Книжка про выученные уроки 2001 года, часть примеров устарела, но суть актуальна и поныне.

Когда подбирала материалы к разговору про тестирование для разработчиков, отдельно смотрела про тестируемость. И рекомендую доклад Игоря Любина на SQA Days. В заголовке там автотесты, но принципы подходят к любому тестированию.

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

#адвент