Привет 🐞
В этом канале я буду писать свои мысли и чувства по поводу моей любви, моей радости, моей работы — процесса обеспечения качества в общем и тестирования как одного из его аспектов.
Я пишу как картошка, мои мысли не претендуют на правильность — это просто опыт, который оказался полезен лично мне, так что буду рада фидбеку, дискуссиям или если вы просто подбросите интересную ссылку.
Начнём ☀️
В этом канале я буду писать свои мысли и чувства по поводу моей любви, моей радости, моей работы — процесса обеспечения качества в общем и тестирования как одного из его аспектов.
Я пишу как картошка, мои мысли не претендуют на правильность — это просто опыт, который оказался полезен лично мне, так что буду рада фидбеку, дискуссиям или если вы просто подбросите интересную ссылку.
Начнём ☀️
👍2❤1😐1
Про романтизацию
Буквально вчера я подумала, что романтизация процесса QA — одна из главных причин мой огромной любви к работе. Кроме того, что само по себе обеспечение качества — это такое удивительное, классное и многогранное дело, сочетающее в себе и технические навыки, и внимательность, и аналитическое мышление, и мои любимые soft skills, я не перестаю радоваться, что оно даёт мне возможность пофантазировать на тему супергероизма.
Только представить: bug busters, bug hunters, вот это все — как же здорово! Перед глазами встают образы крутых ребят в темных хромированных костюмах, которые (ребята, не костюмы) уже стоят на изготовке, чтобы смело броситься в битву со злыми Багулинами и защитить от них наших любимых Пользователей.
Или, например, другой образ: хакеры. Вы сидите в клетчатой рубашке с кружкой кофе, вокруг бумаги и книги, волосы слегка взъерошены, пальцы бегут по клавиатуре, набирая код заветного скрипта... Есть! Атака прошла успешно, баг зарепорчен. Можно погладить себя по лохматой голове и сгонять за печенькой :)
Или ещё: иногда мне приходилось быть капельку аналитиком. Тогда приходит другой образ: ты строгий и собранный специалист, чья задача — продумать как можно больше классных реализаций разных сценариев действий пользователя. Гигабайты информации проходят через твой разум, и ты, словно хорошо отлаженный андроид или Доктор Стрейндж, видящий 14 миллиардов возможного развития событий, анализируешь и документируешь то, что в дальнейшем будет воплощаться в реальность.
Возможно, глупости и детские игрушки. Но! Только эти глупости и спасали в периоды напряжённой работы, когда силы были на исходе, а желание поставить качественный продукт сохранялось.
Потому что быть супергероем, хакером или андроидом намного веселее, чем просто тыкать кнопочки. И, как показывает опыт, почему-то эффективнее 😄
Буквально вчера я подумала, что романтизация процесса QA — одна из главных причин мой огромной любви к работе. Кроме того, что само по себе обеспечение качества — это такое удивительное, классное и многогранное дело, сочетающее в себе и технические навыки, и внимательность, и аналитическое мышление, и мои любимые soft skills, я не перестаю радоваться, что оно даёт мне возможность пофантазировать на тему супергероизма.
Только представить: bug busters, bug hunters, вот это все — как же здорово! Перед глазами встают образы крутых ребят в темных хромированных костюмах, которые (ребята, не костюмы) уже стоят на изготовке, чтобы смело броситься в битву со злыми Багулинами и защитить от них наших любимых Пользователей.
Или, например, другой образ: хакеры. Вы сидите в клетчатой рубашке с кружкой кофе, вокруг бумаги и книги, волосы слегка взъерошены, пальцы бегут по клавиатуре, набирая код заветного скрипта... Есть! Атака прошла успешно, баг зарепорчен. Можно погладить себя по лохматой голове и сгонять за печенькой :)
Или ещё: иногда мне приходилось быть капельку аналитиком. Тогда приходит другой образ: ты строгий и собранный специалист, чья задача — продумать как можно больше классных реализаций разных сценариев действий пользователя. Гигабайты информации проходят через твой разум, и ты, словно хорошо отлаженный андроид или Доктор Стрейндж, видящий 14 миллиардов возможного развития событий, анализируешь и документируешь то, что в дальнейшем будет воплощаться в реальность.
Возможно, глупости и детские игрушки. Но! Только эти глупости и спасали в периоды напряжённой работы, когда силы были на исходе, а желание поставить качественный продукт сохранялось.
Потому что быть супергероем, хакером или андроидом намного веселее, чем просто тыкать кнопочки. И, как показывает опыт, почему-то эффективнее 😄
👍2🥱1
Про soft skills
Недавно думала о том, что очень рада росту ценности софт скиллзов в сфере ИТ.
Что я вкладываю в это понятие? Умение общаться, слушать и слышать. Умение решать проблемы без ссор и сглаживать уже существующие конфликты. Когда надо, быть лидером. Уважать товарищей, уметь искренне радоваться результату чужого труда. В каком-то роде для меня soft skills — это просто быть хорошим человеком.
Что они значат для тестировщика?
Во-первых, умение не просто зарепортить баг или предложить улучшение, а сделать это корректно, без обвинений и наездов.
На курсах QA обязательно учат правильной структуре баг-репорта, но мало кто уделяет внимание такому аспекту, как деловая вежливость.
Проблема письменной речи в том, что мы не можем передать эмоции на экране компьютера, так что второпях брошенная фраза без хотя бы одного «волшебного слова» (вроде «пожалуйста», «не мог(ла) бы ты», etc) может восприняться как грубость.
Иногда я ставлю себя на место разработчика: представляю, как стараюсь, пишу код, оптимизирую его, а потом мой коллега возвращает мне задачу с небрежным «Ничего не работает, почини вот тут». Обидно. И мотивация сразу падает.
Мне было бы гораздо приятнее получить нечто вроде «Очень здорово, посмотрел(а) фикс. Правда, тут осталась ещё одна проблема:
...
Можешь, пожалуйста, починить её?
Спасибо!»
И потом думаю: а если мне было бы приятнее, то, вполне возможно, разработчику тоже. Потому что, камон, все мы любим, когда наш труд ценят, и работать становится сразу легче и приятнее, что положительно влияет на качество конечного продукта.
А качество и есть цель QA, так что все по канону! ^_^
Во-вторых, я много вкладываю в понятие уважения. Любой труд важен, любой труд нужен. Помимо упомянутого бенефита от уважительного общения в команде (что качается не только разработчика, но и всех её членов!), это иногда бывает критически важно в общении с заказчиком, в котором QA тоже приходится принимать участие время от времени (по крайней мере, в аутсорсе. Это пока мой единственный опыт :) ).
В ситуации, когда по какой-то причине надо рассказать клиенту, как правильно использовать систему, уважение может проявляться в подробном и качественном, понятном описании функций. Это приносит плоды и в том, что значительно снижается вероятность ошибок использования, принятых заказчиком за баги, и в том, что хорошее отношение как будто проецируется обратно на команду, и в итоге общение становится дружелюбным и приятным обеим сторонам. Опять же, в таких условиях работать приятнее, и мотивация сделать хорошее решение, а не просто «сдать поскорее», чтобы отделаться от неприятной задачи. Итог — качество. То, к чему мы стремимся :)
В общем-то, на этих моментах важность софт скиллзов не заканчивается, но, думаю, я продолжу эту тему позже. Так или иначе, как было сказано в одной из моих любимых книг,
«журнальчика нашего распрекрасного не будет, если мы не станем одним целым – на то время, пока его делаем. Больше, чем пресловутой «командой», натурально одним существом, с ясной целью и твердым намерением». А стать одним целым гораздо проще, если вы все друг другу приятны, так что развитие в себе навыков «хорошего человека», как мне кажется — одна из лучших инвестиций. И в себя, и в окружающий мир, который, несомненно, не станет хуже от капельки доброты и тепла ☀️
Недавно думала о том, что очень рада росту ценности софт скиллзов в сфере ИТ.
Что я вкладываю в это понятие? Умение общаться, слушать и слышать. Умение решать проблемы без ссор и сглаживать уже существующие конфликты. Когда надо, быть лидером. Уважать товарищей, уметь искренне радоваться результату чужого труда. В каком-то роде для меня soft skills — это просто быть хорошим человеком.
Что они значат для тестировщика?
Во-первых, умение не просто зарепортить баг или предложить улучшение, а сделать это корректно, без обвинений и наездов.
На курсах QA обязательно учат правильной структуре баг-репорта, но мало кто уделяет внимание такому аспекту, как деловая вежливость.
Проблема письменной речи в том, что мы не можем передать эмоции на экране компьютера, так что второпях брошенная фраза без хотя бы одного «волшебного слова» (вроде «пожалуйста», «не мог(ла) бы ты», etc) может восприняться как грубость.
Иногда я ставлю себя на место разработчика: представляю, как стараюсь, пишу код, оптимизирую его, а потом мой коллега возвращает мне задачу с небрежным «Ничего не работает, почини вот тут». Обидно. И мотивация сразу падает.
Мне было бы гораздо приятнее получить нечто вроде «Очень здорово, посмотрел(а) фикс. Правда, тут осталась ещё одна проблема:
...
Можешь, пожалуйста, починить её?
Спасибо!»
И потом думаю: а если мне было бы приятнее, то, вполне возможно, разработчику тоже. Потому что, камон, все мы любим, когда наш труд ценят, и работать становится сразу легче и приятнее, что положительно влияет на качество конечного продукта.
А качество и есть цель QA, так что все по канону! ^_^
Во-вторых, я много вкладываю в понятие уважения. Любой труд важен, любой труд нужен. Помимо упомянутого бенефита от уважительного общения в команде (что качается не только разработчика, но и всех её членов!), это иногда бывает критически важно в общении с заказчиком, в котором QA тоже приходится принимать участие время от времени (по крайней мере, в аутсорсе. Это пока мой единственный опыт :) ).
В ситуации, когда по какой-то причине надо рассказать клиенту, как правильно использовать систему, уважение может проявляться в подробном и качественном, понятном описании функций. Это приносит плоды и в том, что значительно снижается вероятность ошибок использования, принятых заказчиком за баги, и в том, что хорошее отношение как будто проецируется обратно на команду, и в итоге общение становится дружелюбным и приятным обеим сторонам. Опять же, в таких условиях работать приятнее, и мотивация сделать хорошее решение, а не просто «сдать поскорее», чтобы отделаться от неприятной задачи. Итог — качество. То, к чему мы стремимся :)
В общем-то, на этих моментах важность софт скиллзов не заканчивается, но, думаю, я продолжу эту тему позже. Так или иначе, как было сказано в одной из моих любимых книг,
«журнальчика нашего распрекрасного не будет, если мы не станем одним целым – на то время, пока его делаем. Больше, чем пресловутой «командой», натурально одним существом, с ясной целью и твердым намерением». А стать одним целым гораздо проще, если вы все друг другу приятны, так что развитие в себе навыков «хорошего человека», как мне кажется — одна из лучших инвестиций. И в себя, и в окружающий мир, который, несомненно, не станет хуже от капельки доброты и тепла ☀️
👍2❤1🎉1
«Если бы все люди были такого же интеллектуального уровня, как я, то человечество бы застряло в каменном веке»
Честно: иногда ловлю себя на этой мысли. Особенно остро она упирается в висок, когда рядом находится опытный разработчик, продвинутый коллега или кто-то моего возраста с незаурядными достижениями (или старше, но с уровнем, который я, объективно говоря, не потяну в ближайшие несколько лет).
Самое дурацкое, что в такой момент сразу хочется резко поумнеть. Рациональные мысли вроде «всё придёт со временем» больше не кажутся такими правильными, начинается паника: «Я должна как можно скорее улучшить свои навыки». Отсюда два пути: в лучшем случае я резко начинала поглощать знания (пройти туториал по программированию за вечер, записаться на онлайн курсы по линейной алгебре), в худшем просто думать о том, что я уже упустила шанс быть «нормальной», и вряд ли у меня внезапно получится все изменить и стать продвинутым инженером или офигенным сисадмином, и начинала сидеть и уНыВаТь о своей тупости.
Но фишка в том, что потом мало-помалу приходит осознание важной истины: мир не вертится вокруг одной меня. Самолеты строит не один человек. Мосты и города — тоже. Это, кажется, касается любой профессии: врачи не работают по одному ни на скорой, ни в операционной; лингвисты переводят книги со штатом редакторов, корректоров и помощников.
Один разработчик — это труд не только самого разработчика, но и менторов, и тех, кто писал книги и создавал библиотеки и фреймворки, и тех, кто отвечал ему на StackOverFlow, и ещё многих, многих людей. Даже на то, чтобы сделать простой (но качественный) веб-сайт, работают команды от 2-3 до 10-12 человек!
Получается, не стоит ждать от себя феноменальных результатов, и изучать новый ЯП за вечер глупо, потому что время будет потеряно, а язык все равно забудется через пару дней (исключение, конечно, случай, когда вы искренне кайфуете от этого изучения и проводите его не в порыве отчаяния, а осознанно ковыряетесь просто потому что хочется).
В этот момент снова становится актуальным вопрос об общении, грамотной коммуникации и командной работе. И если бы все в мире были такого же интеллектуального уровня, как я, то люди не застряли бы в каменном веке, потому что никто не обязан справляться один, когда рядом есть такое классное, удивительное и готовое разделить с тобой заботы по строительству мостов, самолетов и городов человечество.
Честно: иногда ловлю себя на этой мысли. Особенно остро она упирается в висок, когда рядом находится опытный разработчик, продвинутый коллега или кто-то моего возраста с незаурядными достижениями (или старше, но с уровнем, который я, объективно говоря, не потяну в ближайшие несколько лет).
Самое дурацкое, что в такой момент сразу хочется резко поумнеть. Рациональные мысли вроде «всё придёт со временем» больше не кажутся такими правильными, начинается паника: «Я должна как можно скорее улучшить свои навыки». Отсюда два пути: в лучшем случае я резко начинала поглощать знания (пройти туториал по программированию за вечер, записаться на онлайн курсы по линейной алгебре), в худшем просто думать о том, что я уже упустила шанс быть «нормальной», и вряд ли у меня внезапно получится все изменить и стать продвинутым инженером или офигенным сисадмином, и начинала сидеть и уНыВаТь о своей тупости.
Но фишка в том, что потом мало-помалу приходит осознание важной истины: мир не вертится вокруг одной меня. Самолеты строит не один человек. Мосты и города — тоже. Это, кажется, касается любой профессии: врачи не работают по одному ни на скорой, ни в операционной; лингвисты переводят книги со штатом редакторов, корректоров и помощников.
Один разработчик — это труд не только самого разработчика, но и менторов, и тех, кто писал книги и создавал библиотеки и фреймворки, и тех, кто отвечал ему на StackOverFlow, и ещё многих, многих людей. Даже на то, чтобы сделать простой (но качественный) веб-сайт, работают команды от 2-3 до 10-12 человек!
Получается, не стоит ждать от себя феноменальных результатов, и изучать новый ЯП за вечер глупо, потому что время будет потеряно, а язык все равно забудется через пару дней (исключение, конечно, случай, когда вы искренне кайфуете от этого изучения и проводите его не в порыве отчаяния, а осознанно ковыряетесь просто потому что хочется).
В этот момент снова становится актуальным вопрос об общении, грамотной коммуникации и командной работе. И если бы все в мире были такого же интеллектуального уровня, как я, то люди не застряли бы в каменном веке, потому что никто не обязан справляться один, когда рядом есть такое классное, удивительное и готовое разделить с тобой заботы по строительству мостов, самолетов и городов человечество.
👍3🤯1
Про скорость работы
В последнее время как-то слишком часто обсуждали этот момент с друзьями/коллегами, и вот захотелось про него тоже написать.
Нормально ли работать не очень быстро? Ок ли тратить на задачу 3 часа, из которых 30 минут непосредственно тестируешь, а 2.5 часа - вникаешь в структуру, логику и всё такое?
Мне приходилось разбираться со сложными задачками, где без ̶б̶у̶т̶ы̶л̶к̶и̶ разработчика не поймешь буквально ничего, и иногда я успевала сделать за день совсем немного. Более того, мне было стыдно спрашивать что-то типа "как это тестировать?", потому что подобный вопрос казался распиской в собственной некомпетентности и слабости. Однако задачи надо было решать, дела - делать, и, выдохнув, я звонила коллеге и просила объяснить мне детали того или иного вопроса.
В общем, желание достичь хорошего результата пересилило боязнь показаться слоупоком. И это было к лучшему!
Во-первых, спустя какое-то время количество часов на задачи стало сокращаться, потому что пришло понимание того, как работает система. Во-вторых, я начала передавать знание о системе дргим членам команды, и, получается, потраченные часы начали окупаться. В-третьих, честный тайм-репортинг (а я ловила себя на желании переработать, чтобы записать в систему трекинга времени поменьше часов, мол, вон какая я быстрая) помог мне (и, надеюсь, моей команде) оценить возможности и примерную скорость пути от теста до деплоя.
Ну и, собственно, так происходит до сих пор: чем больше вовлеченность в проект, тем меньше времени уходит на задачи. Тут главное не увлечься за скоростью ради скорости и помнить, что лучше чуть пересидеть за одной задачей, но сделать её качественно, чем выпустить скоп сомнительно протестированного функционала. Вроде да, очевидно, но иногда почему-то приходится себе об этом напоминать.
О, и ещё помогает поговорить с кем-то. На начальных этапах я обращалась к менеджерам (тем, кто, собственно, отвечает за распределение времени и сроки), и мне повезло работать с компетентными, спокойными людьми, которые говорили: "всё хорошо, разбирайся столько, сколько надо, главное, чтобы ты поняла и вникла в проект". Такое отношение вселяло уверенность, что всё номрально.
Потом, бывало, обсуждала аналогичные темы с другими QA (в том числе из других компаний, будь то проукт или аутсорс), и, кажется, все рано или поздно задумывались, не слишком ли медленно они работают. Это тоже забавно: знать, что вас, замороченных, много :) Короче, общаться - классно, 10/10.
Есть ещё один классный скилл - проиритизация. Если, например, объективно не успеваешь сделать всё, лучше выбрать то, что наиболее сильно влияет на качество основного функционала, и работать над этим. Но такое умение с нуля доступно избранным :D, остальным надо тренироваться. Мне кажется, я до сих пор нормально не научилась расставлять приоритеты: каждый раз, когда приходится что-то игнорировать (даже во имя благой цели), чувствую боль. Приходится вспоминать аксиому о том, что протестирвоать продукт на 100% невозможно.
Короче, между скоростью и качеством выбираю качество. И честность о том, сколько времени на это качество требуется.
В последнее время как-то слишком часто обсуждали этот момент с друзьями/коллегами, и вот захотелось про него тоже написать.
Нормально ли работать не очень быстро? Ок ли тратить на задачу 3 часа, из которых 30 минут непосредственно тестируешь, а 2.5 часа - вникаешь в структуру, логику и всё такое?
Мне приходилось разбираться со сложными задачками, где без ̶б̶у̶т̶ы̶л̶к̶и̶ разработчика не поймешь буквально ничего, и иногда я успевала сделать за день совсем немного. Более того, мне было стыдно спрашивать что-то типа "как это тестировать?", потому что подобный вопрос казался распиской в собственной некомпетентности и слабости. Однако задачи надо было решать, дела - делать, и, выдохнув, я звонила коллеге и просила объяснить мне детали того или иного вопроса.
В общем, желание достичь хорошего результата пересилило боязнь показаться слоупоком. И это было к лучшему!
Во-первых, спустя какое-то время количество часов на задачи стало сокращаться, потому что пришло понимание того, как работает система. Во-вторых, я начала передавать знание о системе дргим членам команды, и, получается, потраченные часы начали окупаться. В-третьих, честный тайм-репортинг (а я ловила себя на желании переработать, чтобы записать в систему трекинга времени поменьше часов, мол, вон какая я быстрая) помог мне (и, надеюсь, моей команде) оценить возможности и примерную скорость пути от теста до деплоя.
Ну и, собственно, так происходит до сих пор: чем больше вовлеченность в проект, тем меньше времени уходит на задачи. Тут главное не увлечься за скоростью ради скорости и помнить, что лучше чуть пересидеть за одной задачей, но сделать её качественно, чем выпустить скоп сомнительно протестированного функционала. Вроде да, очевидно, но иногда почему-то приходится себе об этом напоминать.
О, и ещё помогает поговорить с кем-то. На начальных этапах я обращалась к менеджерам (тем, кто, собственно, отвечает за распределение времени и сроки), и мне повезло работать с компетентными, спокойными людьми, которые говорили: "всё хорошо, разбирайся столько, сколько надо, главное, чтобы ты поняла и вникла в проект". Такое отношение вселяло уверенность, что всё номрально.
Потом, бывало, обсуждала аналогичные темы с другими QA (в том числе из других компаний, будь то проукт или аутсорс), и, кажется, все рано или поздно задумывались, не слишком ли медленно они работают. Это тоже забавно: знать, что вас, замороченных, много :) Короче, общаться - классно, 10/10.
Есть ещё один классный скилл - проиритизация. Если, например, объективно не успеваешь сделать всё, лучше выбрать то, что наиболее сильно влияет на качество основного функционала, и работать над этим. Но такое умение с нуля доступно избранным :D, остальным надо тренироваться. Мне кажется, я до сих пор нормально не научилась расставлять приоритеты: каждый раз, когда приходится что-то игнорировать (даже во имя благой цели), чувствую боль. Приходится вспоминать аксиому о том, что протестирвоать продукт на 100% невозможно.
Короче, между скоростью и качеством выбираю качество. И честность о том, сколько времени на это качество требуется.
👍1👏1
Собор парижской автоматизации, или задачка про Квазимодо и Эсмеральду
А сегодня будет не размышление, а дилемма, и это как раз тот случай, когда я буду очень, очень, очень рада совету/отклику в личные собщения, потому что тема для меня важная.
QA - обепечение качества. Но что насчёт качества инструментов обеспечения качества?
Допустим, с вопросом писать или не писать автотесты я давно уже для себя всё решила: ускорить работу и избавиться от рутины вроде проверки наличия всех элементов/текстов на странице или возможности залогиниться/зарегистрироваться оказалось крайне приятно.
Другое дело, что встала новая проблема: оказывается, у тестов есть архитектура и шаблоны проектирования, и мои пошаговые сценарии - это лишь начальная ступень огромного неопознанного мира автоматизации (о чем я, конечно, знала, но от этого не стало менее больно осознавать, что твои нынешние тесты - фигня).
Собственно, ситуация такова: я умею писать простые пошаговые сценарии без всяких наворотов: просто кликнуть ссылку, ввести данные в инпут, отправить форму, проверить, что на странице есть текст и т.д. Я пишу их быстро, но сама понимаю, что это... чтобы не использовать слово "говнокод", буду называть их тесты-Квазимодо.
Ещё я (не так давно) научилась писать более красивые и универсальные тесты с некоторым подобием структуры (тут очень хочется сказать спасибо моему старшему коллеге Антону за терпеливые объяснения и готовность всегда помочь), но времени на них уходит значительно больше, потому что, откровенно говоря, с архитектурой кода любого рода я пока скорее на "Вы". Это будут тесты-Эсмеральда.
Передо мной большой проект, требующий регулярной регрессии хотя бы каких-то базовых функций - то есть смоук-тестирования - и рядом с ним два стула.
Стул №1: покрывать проект тестами-Квазимодо, но тратить на это немного времени, и таким образом автоматизировать - и сократить время на - регрессию.
Стул №2: пытаться в архитектуру, призывая тесты-Эсмеральду, но делать это медленно.
Отягощающие факторы: проект скоро закончится, то есть мой запас времени на написание тестов ограничен; кроме написания регрессионных тестов надо успевать тестировать новые фичи. Я понимаю, что обеспечить покрытие регрессии тестами-Эсмеральдой у меня не выйдет.
С другой стороны, элементы и локаторы в проекте довольно стабильны, так что для тестов-Квазимодо не возникает проблемы поддерживаемости кода.
Все обстоятельства как будто подталкивают меня к Квазимодо, и я даже не против. Однако пугают два момента:
1. Не стану ли я в целом кодить хуже, если сейчас намеренно сделаю шаг назад и вернусь к простым и некрасивым тестам?
2. Как вообще жить, зная, что ты несешь в этот мир плохой код, когда можешь делать его лучше? То есть ты пишешь плохо не потому, что не умеешь иначе из-за отсутствия опыта, а потому, что сама решила продолжать писать именно так, а не развиваться.
Стоит ли идти на сделку с совестью? Что лучше: покрыть проект такими вот проверками (результат будет хорошим, но я-то знаю, что под капотом всё плохо и уродливо) или уже продолжать тестировать всё руками, но делать это однозначно качественно?
Я вот для себя пока так и не решила. И это тот самый момент, когда очень жалеешь об отсутствии достаточного опыта, потому что автоматизировать очень хочется, но хочется это, как и остальную работу, делать хорошо.
А сегодня будет не размышление, а дилемма, и это как раз тот случай, когда я буду очень, очень, очень рада совету/отклику в личные собщения, потому что тема для меня важная.
QA - обепечение качества. Но что насчёт качества инструментов обеспечения качества?
Допустим, с вопросом писать или не писать автотесты я давно уже для себя всё решила: ускорить работу и избавиться от рутины вроде проверки наличия всех элементов/текстов на странице или возможности залогиниться/зарегистрироваться оказалось крайне приятно.
Другое дело, что встала новая проблема: оказывается, у тестов есть архитектура и шаблоны проектирования, и мои пошаговые сценарии - это лишь начальная ступень огромного неопознанного мира автоматизации (о чем я, конечно, знала, но от этого не стало менее больно осознавать, что твои нынешние тесты - фигня).
Собственно, ситуация такова: я умею писать простые пошаговые сценарии без всяких наворотов: просто кликнуть ссылку, ввести данные в инпут, отправить форму, проверить, что на странице есть текст и т.д. Я пишу их быстро, но сама понимаю, что это... чтобы не использовать слово "говнокод", буду называть их тесты-Квазимодо.
Ещё я (не так давно) научилась писать более красивые и универсальные тесты с некоторым подобием структуры (тут очень хочется сказать спасибо моему старшему коллеге Антону за терпеливые объяснения и готовность всегда помочь), но времени на них уходит значительно больше, потому что, откровенно говоря, с архитектурой кода любого рода я пока скорее на "Вы". Это будут тесты-Эсмеральда.
Передо мной большой проект, требующий регулярной регрессии хотя бы каких-то базовых функций - то есть смоук-тестирования - и рядом с ним два стула.
Стул №1: покрывать проект тестами-Квазимодо, но тратить на это немного времени, и таким образом автоматизировать - и сократить время на - регрессию.
Стул №2: пытаться в архитектуру, призывая тесты-Эсмеральду, но делать это медленно.
Отягощающие факторы: проект скоро закончится, то есть мой запас времени на написание тестов ограничен; кроме написания регрессионных тестов надо успевать тестировать новые фичи. Я понимаю, что обеспечить покрытие регрессии тестами-Эсмеральдой у меня не выйдет.
С другой стороны, элементы и локаторы в проекте довольно стабильны, так что для тестов-Квазимодо не возникает проблемы поддерживаемости кода.
Все обстоятельства как будто подталкивают меня к Квазимодо, и я даже не против. Однако пугают два момента:
1. Не стану ли я в целом кодить хуже, если сейчас намеренно сделаю шаг назад и вернусь к простым и некрасивым тестам?
2. Как вообще жить, зная, что ты несешь в этот мир плохой код, когда можешь делать его лучше? То есть ты пишешь плохо не потому, что не умеешь иначе из-за отсутствия опыта, а потому, что сама решила продолжать писать именно так, а не развиваться.
Стоит ли идти на сделку с совестью? Что лучше: покрыть проект такими вот проверками (результат будет хорошим, но я-то знаю, что под капотом всё плохо и уродливо) или уже продолжать тестировать всё руками, но делать это однозначно качественно?
Я вот для себя пока так и не решила. И это тот самый момент, когда очень жалеешь об отсутствии достаточного опыта, потому что автоматизировать очень хочется, но хочется это, как и остальную работу, делать хорошо.
👍1
Здравый смысл и разговор с парой замечательных людей помогли. Решила в итоге автоматизировать не ради автоматизации. План таков: тестировать руками все необходимое, параллельно писать автотесты с нормальной архитектурой (привет, Эсмеральда). Учиться писать тесты-Эсмеральду быстрее. Становиться хорошим специалистом, учиться не жертвовать ни качеством, ни темпом. Звучит как утопия. А может быть, как цель?
❤1
Например, сегодня отошла на пару минут, заблаговременно поставив подгружаться страничку, которую планировала тестировать, и заблокировав комп. Вернулась, разблокировала - а тут вот это. Я чуть не поседела от неожиданности, а это просто аватарка админа на весь экран растянулась по какому-то мистическому обстоятельству.
Сиди и думай после этого: это я тестирую всё вокруг или просто всё вокруг позволяет мне тестировать себя и подкидывает такие забавности? 🤔
Сиди и думай после этого: это я тестирую всё вокруг или просто всё вокруг позволяет мне тестировать себя и подкидывает такие забавности? 🤔
❤1
Субъективность понятия бага
В честь дня тестировщика немного философская тема о фундаментальном: что такое баг.
Примерно пару недель назад мы с другом арендовали машину в небезызвестной системе каршеринга, и установленное бесплатное 20-минутное бронирование подошло к концу до того, как мы дошли до автомобиля. По-еврейски не желая платить по 2,5 рубля в минуту, мы сбросили бронирование и тут же назначили новое, не зная, чего ожидать. Совершился лучший из возможных сценариев: счетчик снова вернулся на отметку “20”, и мы благополучно дотопали до машины, не переводя транспортное средство в платный режим.
И вот сегодня утром мы вспоминали тот случай, после чего я сказала: “Да, отличная фича”. “Но это не фича же”, - возразил друг. “Для владельцев системы, как для тех, кто получает с неё прибыль, это, конечно, баг. А для меня, как для пользователя - фича”, - я не могла согласиться.
Так где же вообще лежит эта граница между багом и фичей?
Если покопаться в определениях, мы найдем такие варианты:
Баг — запись (или «дефект») в системе отслеживания ошибок. (Википедия)
Баг — это отклонение фактического результата от ожидаемого результата (Р. Савин, Тестирование дот ком)
Дефект — расхождение ожидаемого и фактического результата (С. Куликов, Тестирование программного обеспечения)
Первая формулировка довольно малоинформативна, потому что рассматривает баг не как абстрактную неточность в работе программы, а просто привязывается к его оформлению в документах (грубо говоря, это как если бы чаем называли не сами сухие чайные листья, а пакетики, в которые их фасуют). Если следовать такому определению, то реши тестировщик занести в систему отслеживания ошибок запись с отрывком из пушкинского “Медного всадника”, формально это тоже будет багом.
Вторая и третья формулировки намного лучше, потому что определяют баг именно как факт несоответствия, расхождения, то есть нечто абстрактное и субъективное. И вот тут начинается самое интересное: ожидаемый результат предполагает наличие какой-то спецификации, требований к продукту, некоего унифицированного источника истины для вот этой конкретной программы/приложения.
А что делать, если спек нет? Чьё ожидание принимать за точку опоры, как в случае с тем же каршерингом: пользователя, который хочет подольше удерживать машину на месте бесплатно, или создателя, который хочет получить свои 25 рублей за 10 минут ожидания сверх нормы? Возможность забронировать одну машину два раза подряд - это недосмотр тестировщиков приложения или намеренное допущение со стороны владельцев продукта? От ответа зависит, в какую категорию - багов или фич - попадает наше открытие.
То, что было багом вчера, сегодня может стать фичей (или даже вполне себе задокументированным функционалом). Поэтому всегда стараюсь подумать, что будет удобно пользователю, чего хочет заказчик, что уже реализовано, каким образом это сделано. Это помогает расставить приоритеты: на первый план выходят именно ошибки, которые мешают системе выполнять её основные функции или не соответствуют заявленной документации, а уже после них можно подумать о спорных моментах вроде багофич, в которых многое зависит от глаз смотрящего. Тем не менее, стараюсь занести в систему багтрекинга всё, потому что если сомнительный момент окажется фичей, ничего не стоит закрыть задачку, однако если это будет пропущенный баг - упс.
Противоречива, конечно, работа тестировщика: вроде как имеешь дело с такой субъективной штукой, как баги, но при этом надо мыслить критически, объективно окидывать взглядом то, что имеешь, и выносить на обсуждение непонятки :)
<offtopic> Критическое мышление - ещё один момент, за который я обожаю своё заниятие.</offtopic>
В честь дня тестировщика немного философская тема о фундаментальном: что такое баг.
Примерно пару недель назад мы с другом арендовали машину в небезызвестной системе каршеринга, и установленное бесплатное 20-минутное бронирование подошло к концу до того, как мы дошли до автомобиля. По-еврейски не желая платить по 2,5 рубля в минуту, мы сбросили бронирование и тут же назначили новое, не зная, чего ожидать. Совершился лучший из возможных сценариев: счетчик снова вернулся на отметку “20”, и мы благополучно дотопали до машины, не переводя транспортное средство в платный режим.
И вот сегодня утром мы вспоминали тот случай, после чего я сказала: “Да, отличная фича”. “Но это не фича же”, - возразил друг. “Для владельцев системы, как для тех, кто получает с неё прибыль, это, конечно, баг. А для меня, как для пользователя - фича”, - я не могла согласиться.
Так где же вообще лежит эта граница между багом и фичей?
Если покопаться в определениях, мы найдем такие варианты:
Баг — запись (или «дефект») в системе отслеживания ошибок. (Википедия)
Баг — это отклонение фактического результата от ожидаемого результата (Р. Савин, Тестирование дот ком)
Дефект — расхождение ожидаемого и фактического результата (С. Куликов, Тестирование программного обеспечения)
Первая формулировка довольно малоинформативна, потому что рассматривает баг не как абстрактную неточность в работе программы, а просто привязывается к его оформлению в документах (грубо говоря, это как если бы чаем называли не сами сухие чайные листья, а пакетики, в которые их фасуют). Если следовать такому определению, то реши тестировщик занести в систему отслеживания ошибок запись с отрывком из пушкинского “Медного всадника”, формально это тоже будет багом.
Вторая и третья формулировки намного лучше, потому что определяют баг именно как факт несоответствия, расхождения, то есть нечто абстрактное и субъективное. И вот тут начинается самое интересное: ожидаемый результат предполагает наличие какой-то спецификации, требований к продукту, некоего унифицированного источника истины для вот этой конкретной программы/приложения.
А что делать, если спек нет? Чьё ожидание принимать за точку опоры, как в случае с тем же каршерингом: пользователя, который хочет подольше удерживать машину на месте бесплатно, или создателя, который хочет получить свои 25 рублей за 10 минут ожидания сверх нормы? Возможность забронировать одну машину два раза подряд - это недосмотр тестировщиков приложения или намеренное допущение со стороны владельцев продукта? От ответа зависит, в какую категорию - багов или фич - попадает наше открытие.
То, что было багом вчера, сегодня может стать фичей (или даже вполне себе задокументированным функционалом). Поэтому всегда стараюсь подумать, что будет удобно пользователю, чего хочет заказчик, что уже реализовано, каким образом это сделано. Это помогает расставить приоритеты: на первый план выходят именно ошибки, которые мешают системе выполнять её основные функции или не соответствуют заявленной документации, а уже после них можно подумать о спорных моментах вроде багофич, в которых многое зависит от глаз смотрящего. Тем не менее, стараюсь занести в систему багтрекинга всё, потому что если сомнительный момент окажется фичей, ничего не стоит закрыть задачку, однако если это будет пропущенный баг - упс.
Противоречива, конечно, работа тестировщика: вроде как имеешь дело с такой субъективной штукой, как баги, но при этом надо мыслить критически, объективно окидывать взглядом то, что имеешь, и выносить на обсуждение непонятки :)
<offtopic> Критическое мышление - ещё один момент, за который я обожаю своё заниятие.</offtopic>
❤1
Я всё это веду к тому, что в мире тестирования (и это одна из тех вещей, за которые я так люблю его) нет ничего фундаментального, каменно истинного, такого, что нельзя как-то ситуативно опровергнуть. Тестирование - это гибкость и некоторая субъективность, это огромная привязанность к ситуации и целям продукта, к приоритетам и, в конце концов, тому, как будет лучше для команды и конечного пользователя. А обеспечение качества - это забота, и начинается она изнутри.
❤1
Пространные рассуждения о профессиональной деформации QA
Ну раз уж у нас сегодня свой праздник ;)
Одна из моих любимых книг - знаменитое “Тестирование.com” Романа Савина. Я люблю её по многим причинам, несмотря на то, что многие моменты оттуда уже устарели (или просто не очень актуальны в аутсорсе). Например, это было первое, что я нашла, когда решила попробовать развивать себя в направлении QA, и я до сих пор помню ощущение трепета от новых, интересных знаний, поджидавших меня на страницах. Я честно выполняла все задания и следовала рекомендациям автора, одной из которых (едва ли не в первой же главе) стала следующая:
Находите в реальной жизни несоответствия ожиданий и реальности и мысленно отмечайте их: “баг”.
И вот примерно с весны 2017 - то есть с момента, когда я загорелась идеей стать QA - я стала искать “баги” в реальной жизни, но уже скоро они сами стали меня находить.
Шутки про мигающие лампочки - не шутки. Техника вокруг начинает вести себя непредсказуемо, внезапно вокруг появляются кучи неточностей, да и сам мир, кажется, иногда плывёт текстурами :D Я слышала шутки, что у тестировщиков есть “интуиция на дефекты”. Мне кажется, у этого явления вполне логичная природа.
Когда учишься постоянно наблюдать за происходящим, обращая внимание на максимум мелочей, который сможешь удержать в фокусе, рано или поздно это занятие превращается если не в рутину, то во что-то привычное. Тогда и думаешь: а это “интуиция” говорит мне, что страница ещё не готова, или просто я краем глаза заметила какую-то фигню, и теперь надо внимательно просканировать функционал и вид, чтобы понять, что именно вызвало этот подсознательный дискомфорт? Мне кажется, где-то тут начинается проф. деформация :)
Забавный пример: на днях шла пешком и услышала звук приближающейся из-за спины сирены. “Скорая”, - с уверенностью подумала я и не ошиблась. Потом в голову пришло, что в окружении того места, где я была, много больниц, а ещё, проходя мимо затора на дороге, я краем глаза заметила машину “скорой помощи”. Задумалась: было ли то, что я угадала машину, просто совпадением, или мозг в фоновом режиме соотнес факты выше и подсказал логично вытекающий ответ?
Как сказал мне коллега Влад, “возможно, многие тестировщики хоть раз мечтали стать детективами”. Трудно поспорить с этим: более того, я думаю, из большинства тестеров вышли бы отличные сыщики. Во всяких книжках про Шерлока Холмса зацепки, позволяющие раскрыть преступление, лежат в мелочах, а все - абсолютно все - мои знакомые QA эти мелочи отлично подмечают, будь то очепятка в тексте или маленькая тень эмоции на лице человека, которую тот пытается скрыть.
Интересно, то ли в QA идут те, кому не лень искать эти мелочи, то ли работа приучает их видеть. Но, на мой взгляд, такие загадки только добавляют шарма обеспечению качества 😏☺️
Ну раз уж у нас сегодня свой праздник ;)
Одна из моих любимых книг - знаменитое “Тестирование.com” Романа Савина. Я люблю её по многим причинам, несмотря на то, что многие моменты оттуда уже устарели (или просто не очень актуальны в аутсорсе). Например, это было первое, что я нашла, когда решила попробовать развивать себя в направлении QA, и я до сих пор помню ощущение трепета от новых, интересных знаний, поджидавших меня на страницах. Я честно выполняла все задания и следовала рекомендациям автора, одной из которых (едва ли не в первой же главе) стала следующая:
Находите в реальной жизни несоответствия ожиданий и реальности и мысленно отмечайте их: “баг”.
И вот примерно с весны 2017 - то есть с момента, когда я загорелась идеей стать QA - я стала искать “баги” в реальной жизни, но уже скоро они сами стали меня находить.
Шутки про мигающие лампочки - не шутки. Техника вокруг начинает вести себя непредсказуемо, внезапно вокруг появляются кучи неточностей, да и сам мир, кажется, иногда плывёт текстурами :D Я слышала шутки, что у тестировщиков есть “интуиция на дефекты”. Мне кажется, у этого явления вполне логичная природа.
Когда учишься постоянно наблюдать за происходящим, обращая внимание на максимум мелочей, который сможешь удержать в фокусе, рано или поздно это занятие превращается если не в рутину, то во что-то привычное. Тогда и думаешь: а это “интуиция” говорит мне, что страница ещё не готова, или просто я краем глаза заметила какую-то фигню, и теперь надо внимательно просканировать функционал и вид, чтобы понять, что именно вызвало этот подсознательный дискомфорт? Мне кажется, где-то тут начинается проф. деформация :)
Забавный пример: на днях шла пешком и услышала звук приближающейся из-за спины сирены. “Скорая”, - с уверенностью подумала я и не ошиблась. Потом в голову пришло, что в окружении того места, где я была, много больниц, а ещё, проходя мимо затора на дороге, я краем глаза заметила машину “скорой помощи”. Задумалась: было ли то, что я угадала машину, просто совпадением, или мозг в фоновом режиме соотнес факты выше и подсказал логично вытекающий ответ?
Как сказал мне коллега Влад, “возможно, многие тестировщики хоть раз мечтали стать детективами”. Трудно поспорить с этим: более того, я думаю, из большинства тестеров вышли бы отличные сыщики. Во всяких книжках про Шерлока Холмса зацепки, позволяющие раскрыть преступление, лежат в мелочах, а все - абсолютно все - мои знакомые QA эти мелочи отлично подмечают, будь то очепятка в тексте или маленькая тень эмоции на лице человека, которую тот пытается скрыть.
Интересно, то ли в QA идут те, кому не лень искать эти мелочи, то ли работа приучает их видеть. Но, на мой взгляд, такие загадки только добавляют шарма обеспечению качества 😏☺️
❤1
О саморазвитии
Мой первый наставник однажды отметил, что один из нюансов работы тестировщика - то, что приходится регулярно развиваться самостоятельно. Мне кажется, это вообще для IT вполне характерно, но особенность QA в том, что это относительно молодая область, поэтому материалов не так много, единой теории почти нет, терминология часто варьируется… Приходится копать и непрерывно анализировать, думать: насколько авторитетен источник? Не чушь ли пишет? Короче, примерно как при выборе лит-ры для диплома в универе :)
Поэтому я, почесав репу, выделила чисто для себя несколько хороших практик выбора и освоения материала для изучения. Хочу систематизировать их (ну и заодно вдруг кому-нибудь пригодится?) и попросить фидбека: возможно, есть какие-то советы, которые помогли лично вам? Для меня самообучение - приятный, но утомительный процесс, так что я ищу помощь с любой стороны!
Заранее прошу прощения за возможное кэпство: цель поста в первую очередь разложить всё по полочкам в своей голове, а для привнесения новизны у меня маловато опыта :)
1. Обращать внимание на дату публикации.
Слишком новые материалы могут быть ещё не проверены опытом, слишком старые - заменены чем-то поудобнее.
2. Источник и автор очень важны, но это не панацея от неточностей.
Блог IT-компании или авторитетного человека вроде Джеймса Уиттакера (http://www.docjamesw.com/), Джеймса Баха (http://www.satisfice.com/) или Святослава Куликова (https://svyatoslav.biz/) скорее всего будут надежнее, чем блоги простых тестировщиков, которые только учатся анализу и интроспективе (вроде вот этого телеграм-канала, например :D). С другой стороны, в менее авторитетных блогах можно встретить необычные идеи и интересные взгляды, а ещё они хороши, когда хочется убедиться, что не только у тебя бывают факапы.
3. Мыслить критически.
Тестировать, постоянно тестировать входящий поток информации. Чем абстрактнее тема, тем более критически мыслить.
4. Выбирать максимум источников.
Для кого-то это может быть сомнительный совет, но мне помогает :) Я люблю прочитать по теме всё, что найду, и подвести собственный итог, где выберу самое, на мой взгляд, полезное отовсюду.
5. Приоритизировать и расставлять ресурсы в очередь.
Чтобы не сойти с ума от многообразия статей и книг, воспользовавшись предыдущим советом :D Самое интересное/важное в начало, потом менее релевантные ресурсы.
6. Не дочитывать до конца.
Да, прям так! Сейчас многие специалисты по здоровому питанию твердят, что не стоит заставлять детей есть обед до конца и предлагают позволять им не доедать суп, чтобы сформировать здоровое отношение к пище. Примерно то же я отметила для себя в применении к информации: чтобы не отбить у себя желание изучать насовсем, нужно позволять себе не поглощать книги и статьи целиком, а выбирать только самое “вкусное”. В какой-то момент я даже выписала себе небольшие напоминалки, чтобы знать, в какой книге/статье какую тему можно посмотреть, потому что часто бывает, что, несмотря на общую “хорошесть” источника, есть какая-то основная глава-пуля, которая несет супер полезную информацию и характерна именно для этой книги.
7. Не торопиться и повторять.
Жизнь длинная, экзаменов пока не предвидится, так что можно перевести дыхание и спокойно учить то, что нужно, не умирая от переутомления. Лучше выбрать одну небольшую тему и долбить её, пока не отложится в голове, потом брать следующую, и так далее. Плохо с точки зрения моментального видения результата, но я на личном опыте поняла, что этот результат будет гораздо менее качественным, чем то, что дается многократным повторением и практикой.
8. Сразу применить знания на практике.
По возможности. Так запомнится лучше, плюс будет реальный опыт того, где можно использовать новые навыки :)
Мой первый наставник однажды отметил, что один из нюансов работы тестировщика - то, что приходится регулярно развиваться самостоятельно. Мне кажется, это вообще для IT вполне характерно, но особенность QA в том, что это относительно молодая область, поэтому материалов не так много, единой теории почти нет, терминология часто варьируется… Приходится копать и непрерывно анализировать, думать: насколько авторитетен источник? Не чушь ли пишет? Короче, примерно как при выборе лит-ры для диплома в универе :)
Поэтому я, почесав репу, выделила чисто для себя несколько хороших практик выбора и освоения материала для изучения. Хочу систематизировать их (ну и заодно вдруг кому-нибудь пригодится?) и попросить фидбека: возможно, есть какие-то советы, которые помогли лично вам? Для меня самообучение - приятный, но утомительный процесс, так что я ищу помощь с любой стороны!
Заранее прошу прощения за возможное кэпство: цель поста в первую очередь разложить всё по полочкам в своей голове, а для привнесения новизны у меня маловато опыта :)
1. Обращать внимание на дату публикации.
Слишком новые материалы могут быть ещё не проверены опытом, слишком старые - заменены чем-то поудобнее.
2. Источник и автор очень важны, но это не панацея от неточностей.
Блог IT-компании или авторитетного человека вроде Джеймса Уиттакера (http://www.docjamesw.com/), Джеймса Баха (http://www.satisfice.com/) или Святослава Куликова (https://svyatoslav.biz/) скорее всего будут надежнее, чем блоги простых тестировщиков, которые только учатся анализу и интроспективе (вроде вот этого телеграм-канала, например :D). С другой стороны, в менее авторитетных блогах можно встретить необычные идеи и интересные взгляды, а ещё они хороши, когда хочется убедиться, что не только у тебя бывают факапы.
3. Мыслить критически.
Тестировать, постоянно тестировать входящий поток информации. Чем абстрактнее тема, тем более критически мыслить.
4. Выбирать максимум источников.
Для кого-то это может быть сомнительный совет, но мне помогает :) Я люблю прочитать по теме всё, что найду, и подвести собственный итог, где выберу самое, на мой взгляд, полезное отовсюду.
5. Приоритизировать и расставлять ресурсы в очередь.
Чтобы не сойти с ума от многообразия статей и книг, воспользовавшись предыдущим советом :D Самое интересное/важное в начало, потом менее релевантные ресурсы.
6. Не дочитывать до конца.
Да, прям так! Сейчас многие специалисты по здоровому питанию твердят, что не стоит заставлять детей есть обед до конца и предлагают позволять им не доедать суп, чтобы сформировать здоровое отношение к пище. Примерно то же я отметила для себя в применении к информации: чтобы не отбить у себя желание изучать насовсем, нужно позволять себе не поглощать книги и статьи целиком, а выбирать только самое “вкусное”. В какой-то момент я даже выписала себе небольшие напоминалки, чтобы знать, в какой книге/статье какую тему можно посмотреть, потому что часто бывает, что, несмотря на общую “хорошесть” источника, есть какая-то основная глава-пуля, которая несет супер полезную информацию и характерна именно для этой книги.
7. Не торопиться и повторять.
Жизнь длинная, экзаменов пока не предвидится, так что можно перевести дыхание и спокойно учить то, что нужно, не умирая от переутомления. Лучше выбрать одну небольшую тему и долбить её, пока не отложится в голове, потом брать следующую, и так далее. Плохо с точки зрения моментального видения результата, но я на личном опыте поняла, что этот результат будет гораздо менее качественным, чем то, что дается многократным повторением и практикой.
8. Сразу применить знания на практике.
По возможности. Так запомнится лучше, плюс будет реальный опыт того, где можно использовать новые навыки :)
❤1👍1