Логи тестировщика

2021-07-25 19:16:52 На днях я изучил вопрос, о котором шла речь в предыдущем посте и нашёл хорошее решение — приватный чат.

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

Очевидно, под наши задачи подходит. Значит, вводная следующая:

1. Каждую неделю я буду публиковать в данном чате 1-2 слитых курса для полностью бесплатного скачивания;

2. Доступ к данному чату могут получить все подписчики нашего канала. На днях напишу бота, который будет регулярно проверять всех участников на выполнение данного условия;

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

4. В перспективе напишу бота — стол заказов для чата. Чтоб как-то это дело все автоматизировать.

5. Для того, чтоб получить доступ к чату (одноразовую ссылку или личное приглашение), нужно написать мне: @QALib

Такие дела.
Информация должны быть свободной.

P.S. Что касается новостей — меня радует, что зарождается комьюнити Открыть/Комментировать

2021-07-19 12:02:05 За этот пост меня зашеймят в чатах по QA. Поскольку, большинство из них держат инфоцигане разного помола.

Провёл небольшой опрос и мониторинг по чатам и обнаружил, что вопросы слитых курсов в душах джунов резонируют все больше и больше. ШТОШ, этих курсов есть у нас.

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

У меня скопился гигантский (сотни гигабайт) архив курсов по IT, сейчас думаю над тем, как сделать удобное их распространение и не схватить бан.

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

В общем, следите, скоро придумаем как решить этот вопрос и открыть доступ к слитым курсам. Открыть/Комментировать

2021-07-18 22:54:30 ​В последние недели не писал ничего в лог. Уровень нагрузки на работе резко возрос, потому, что один из наших тестировщиков ушёл в отпуск и его задачки упали на меня.

Однако, за это время произошло много событий. Кратенько:
1. 90% задач связанных с мобильным тестированием решаю самостоятельно без обращения к более опытным товарищам;
2. Начал вникать в вэб-часть продукта, выполняя задачи товарища ушедшего в отпуск. Тестирование вэба значительно проще (возможно потому, что я занимался вэб-разработкой), но менее интересно, чем мобильное;
3. Начал тестировать API фотохранилища продукта. Апишку я люблю, понимаю, умею. 100% задач, связанных с API, решаю сам;
4. На выходных (да-да) по доброй воле занимаюсь рабочими вопросами. Сегодня, например, начал реализовывать нагрузочное тестирование, которое в компании не представлено.

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

Начал покрывать автотестами API фотохранилища продукта. Однако, у меня язык не поворачивается называть автотестами те автотесты, которые делают в Postman. Но, делаем так, как принято в компании.

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

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

Также написал первый, маленький, бесполезный, но рабочий автотест для мобильного приложения на Squish, Appium + Python.

За последние две недели добавилась уверенность в собственных силах, комплекс самозванца стал проявляться реже. Также, появилась ясность в направлении развития. Ну и пара идей для новых pet-проектов.

Такие дела. Открыть/Комментировать

2021-07-15 22:58:46 Где начинающему тестировщику получить первый опыт. Проект: «Хомячки»

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

2021-07-01 21:29:50 ​Код для тестировщиков (автотесты)

Сегодня начал пробовать писать автотесты для регресса на наши проекты и, в процессе, вскрылась одна интересная вещь. Я посчитал необходимым зафиксировать ее в логе.

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

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

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

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

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

Точку в дискуссии поставил тимлид сказав: Код предложенный разработчиком хорош для матёрых кодеров, а по моему коду хорошо учится и даже человек не знающий Python поймет че вообще происходит. Мы пишем код автотестов не для матёрых кодеров, а для тестировщиков.

Нужно просто определиться, вам шашечки или ехать?
На том и порешили. Открыть/Комментировать

2021-06-27 21:52:52 Открыть/Комментировать

2021-06-20 13:27:52 Салют!
Хорошие новости завезли, правда, ещё в конце прошлой недели.
Мой испытательный срок на позиции Junior QA Engineer прекращен досрочно с переводом меня в штат постоянных сотрудников компании.

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

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

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

2021-06-06 19:02:21 ​Первый месяц опыта.

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

В пылу работы, за звоном мечей изучения новой информации я не заметил как пролетел первый месяц моей официальной работы на позиции Junior QA Engineer. И есть ряд мыслей, которые хотелось бы зафиксировать.

1. В работе тестировщика, с технической стороны вопроса, нет совершенно ничего сложного. Вот вообще. Даже в моем случае, когда мне стало очевидно, что окладом джуна заткнули позицию минимум мидла. То есть, базовую информацию по тестированию я, в режиме лайт, в рабочее время, освоил где-то за две недели, тратя на это по часу-два НЕ каждый день. Потому, теперь знаю пару возрастных дам тестировщиков, которые были бухгалтерами, юристами, и прочими менеджерами по продажам.

2. Основная прорва времени и сил, в моем случае, уходит на то, чтоб вникнуть в архитектуру приложения, структуру базы данных приложения, протокола взаимодействия приложения и остальных узлов продукта компании. Разбирать логи, ошибки записи в SQL таблицы (а порой и ошибочные запросы SQL) и вот это вот все. Да, требования явно не джуновские =)

3. Если бы позиция реально была джуновская и требовалось бы именно тестирование, без последующего поиска причины бага и возможных путей его устранения (если таковой был найден), дело пошло бы куда проще. Ну, то есть, если мы рассматриваем тестировщика как человека который: тестирует требования\продукт\функцию etc. (с попутным созданием артефактов), находит ошибку, документирует ее, передает разработчику или иному ответственному лицу. — это один момент, который усваивается на раз-два и далее требуется лишь оттачивание навыков и приобретения опыта по отдельным кейсам.

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

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

6. Да, отдых в течении дня крайне необходим. Иначе, когда много часов подряд, без перерыва бьешь какую-то задачу, глаз замыливается и качество исполнения работы ООООочень сильно падает.

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

8. Уже сейчас стало ясно, что если хочется профессионального роста на ниве тестирования — надо менять место работы хотяб один раз в пару лет. Иначе, со временем ты повышаешь не свою специализацию в тестировании как таковом, а свою специализацию в продукте компании. Что никак не сказывается на твоей рыночной стоимости как специалиста.

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

P.S. Также, начал попутно писать статьи по QA, разъясняющие все, что изучил сам. Пока в стол, как способ закрепления полученных знаний. Но, возможно, скоро начну публиковать их на отдельной платформе в виде профессионального блога. Открыть/Комментировать

2021-05-16 19:53:59 ​Пара мыслей об обязанностях тестировщика в нашей компании.

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

В компании, где я тружусь, от тестировщика требуется несколько большее. Помимо всего вышеописанного, тестировщик должен вскрыть мобильное приложение, вытащить из него логи и базу и проанализировать их. Если проблема в самом приложении, то разобраться в ее природе, после чего подробно указать причину и природу самого бага, если нет, продолжить поиск. Где? На стороне сервера. Основываясь на том, как работает сбоящая функция, необходимо начать распутывать клубок непосредственно под капотом приложения, перейти на сторону сервера, залезть в базу на сервере и проанализировать все те места, с которыми общается приложение. Также, возможно, проверить некоторые узлы посредничающие в передаче информации (не могу описывать архитектуру решения).

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

Это круто, с точки зрения профессионального роста, и не очень, с точки зрения объема рабочих обязанностей. Справедливости ради я, как джун, в процессе поиска природы бага достаю всех вокруг вопросами, расспросами и опросами, чтоб понять логику той доработки, где этот баг возник. Такие вот у нас требования к тестировщикам, начиная с джунов. Открыть/Комментировать

2021-05-10 10:00:31 ​​Между началом ведения данного лога и трудоустройством есть небольшой тайм-лаг, а потому, компенсирую его частотой и объемом постов. В будущем, частота публикаций и их объём должны синхронизироваться и немного уменьшиться.

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

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

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

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

Освоил дымный тест, разобрался в том, что такое чек-листы с тест-кейсами, как и с чем их едят. Ещё один момент: старт моих рабочих дней выпал на конец апреля — начало мая и вышло так, что из двух недель у меня было 7 рабочих дней. За эти семь дней, с небольшими переработками, я вроде как начал интегрироваться в процесс и даже полностью самостоятельно успел выполнить тестирование (правда, по готовому чек-листу) новой доработки в приложении. Найдя и задокументировав пару багов.

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

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

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

Планы по развитию
Сейчас, в свои выходные и свободное время, помимо отдыха (который критически необходим) я приступил к изучению курсов по тестированию и некоторым смежным вопросам.

Также, в ближайшее время планирую завести профессиональный блог, в котором буду писать статьи исключительно по тестированию и смежным областям. Просто, мне тут подсказали, что самый лучший способ научиться и понять что-то — попробовать научить этому другого. Ну и вообще, с годами живой профессиональный блог будет лучше любого портфолио и весомым аргументом в переговорах по вопросу зарплаты. Открыть/Комментировать