Привет 🐞
В этом канале я буду писать свои мысли и чувства по поводу моей любви, моей радости, моей работы — процесса обеспечения качества в общем и тестирования как одного из его аспектов.
Я пишу как картошка, мои мысли не претендуют на правильность — это просто опыт, который оказался полезен лично мне, так что буду рада фидбеку, дискуссиям или если вы просто подбросите интересную ссылку.
Начнём ☀️
В этом канале я буду писать свои мысли и чувства по поводу моей любви, моей радости, моей работы — процесса обеспечения качества в общем и тестирования как одного из его аспектов.
Я пишу как картошка, мои мысли не претендуют на правильность — это просто опыт, который оказался полезен лично мне, так что буду рада фидбеку, дискуссиям или если вы просто подбросите интересную ссылку.
Начнём ☀️
👍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