Как пересдавать ДЗ на курсах, чтобы было меньше итераций

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

И это нормально — если вы пришли на курс и делаете все ДЗ с первого раза, то зачем тогда курс? Вы и так всё знаете! А если пока не знаете, то первый блин будет комом. Второй, скорее всего, тоже... Так как сократить эти пересдачи?

Если ДЗ сдается в ворде / гуглодоке / аналоге

1. Выпишите замечания тренера
2. Напишите, что именно исправили по каждому замечанию. 
3. Покажите это цветом

Например, вот так:

Зачем это надо — чтобы тренер понял ход вашей мысли. Потому что бывает, что тренер ожидает правку в месте 1, а студент исправил место 2. В итоге студент получает замечание "не исправлено" и возмущен — ведь он исправил!

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

Как задавать вопросы на обучении

 

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

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

1. Как задать вопрос — общие принципы

1. Укажите номер домашнего задания и его название — обычно хватает названия, чтобы вспомнить "о чем речь в ДЗ".
2. Дайте ссылку на ДЗ, если она сейчас под рукой — если точно не помнишь условия, можно легко перейти и вчитаться в текст ДЗ
3. Дайте контекст (зависит от типа вопроса):
1. Что именно непонятно в самом ДЗ / комментарии тренера?
2. На каком конкретно этапе возникли трудности?
3. Что уже пытались сделать?
4. Как у вас сейчас выглядит проблемное место? (именно проблемное место, а не всё ДЗ целиком). 
5. Как вы думаете его исправить? — если вы думаете в неправильную сторону, вам сразу это подсветят
6. Почему вы считаете, что ваш вариант и так правильный — это может дать бонус "пока писал вопрос, сам понял ответ", см о нем ниже в пункте 4
7. Если у вас проблема в коде, скиньте его текстом, а не картинкой!

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

В любом случае, когда тебе может ответить не 1 человек, а 10-20-50, то ответ будет явно быстрее. При этом если говорить о других студентах, то нужно иметь в виду, что они не видят ваше ДЗ, поэтому без контекста ответить не смогут.

JIRA: как найти задачу, где когда-то был исполнителем

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

assignee was olgak — olgak был хоть раз назначен исполнителем по задаче. И можно найти свои задачи, которые через тебя проходили. Например, задачу сначала делал Ваня, потом Коля, потом вообще Никита. А ты помнишь, что Ваня ею занимался, как найти?

Потестила на одной из задач, забрала себе, вернула исполнителю:

text ~ "Часть из названия" and assignee = olgak  — Пусто, сейчас задача не на мне

text ~ "Часть из названия" and assignee was olgak — Работает 🙈😃

Список вопросов для собеседования тестировщика

 Утро, в офисе почти никого нет. Тут мне в скайп прилетает сообщение от начальницы:

- Оль, проведешь собеседование? А то Вася опаздывает, а больше никого в офисе нет. Человек придет через 15 минут.

Э-э-э-э… Что?? о_О

Нет, конечно, я тогда уже 5 лет работала в тестировании, но на собеседованиях всегда была “по другую сторону баррикад”. Да и в компании работала недавно и по их меркам была джуном. 

А тут — первый собес! И некого позвать на помощь… И человек придет опытный, на зарплату в 2 раза больше моей! Как я его уровень проверить то смогу?! Мамочки!

Отчет о тестировании — что это такое

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

Что важно? Если начальник просит вас сделать отчет, уточните, зачем это и как будет использоваться. И присылайте максимально краткий отчет. Его быстрее читать и писать. Не стоит тратить кучу времени на то, что, возможно, читать-то не станут.

Вот, например, в работах студентов есть описание исследовательских туров  — как они по ним проходили. Фактически, это — отчет о проделанной работе, о проведенном тестировании. И он может быть кратким!

Что почитать, дабы не краснеть перед заказчиками и коллегами за свои письма

Наш директор по маркетингу «Дадаты» Максим Пименов дал совет, что почитать, чтобы грамотно формулировать свои мысли. И чтобы книга была не с советскую энциплопедию толщиной! 

Дальше уже со слов Максима:

*****************************************************************************

Друзья, еще раз порекомендую замечательную книгу Максима Ильяхова «Текст по полочкам». В личке у меня регулярно спрашивают, что бы почитать, дабы не краснеть перед заказчиками и коллегами за свои письма. Вот эту книгу я в 100% случаев и советую.

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

Обычно ни в быту, ни на работе нам не нужно выдрючивать стоп-слова, искать сильную синтаксическую основу предложения или переживать о параллелизме. А нужно нам, чтобы получатели письмо а) прочитали б) поняли. Или не письмо, а презентацию. Или не презентацию, а отчет в confluence. Вот это все «Текст по полочкам» замечательно поможет подтянуть.

В книге всего 176 страниц, она простая и максимально прикладная.

После, если будет желание, — хоть «Пиши, сокращай», хоть «Ясно, понятно», хоть в Школу редакторов Ильяхова. Но для ежедневных рабочих задач я бы порекомендовал именно «Текст по полочкам».

*****************************************************************************

Я «Текст по полочкам» ещё не читала, зато читала «Новые правила деловой переписки». Тоже кратко и по делу, очень рекомендую! 

Как тестировать методы REST API

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

Ссылка на ХАБР (там кликабельное содержание, очень удобно)

Когда ручного тестировщика впервые просишь проверить метод REST API, того охватывает паника: «Как это делать? Я вообще почти ничего не знаю про API. Что делать? Как это тестировать?»

Спокойно. Без паники =) Я уже рассказывала на простом языке, что такое API. А сегодня я расскажу о том, как его тестировать. На самом деле почти также, как GUI: в первую очередь это тест-дизайн и придумывание проверок, а потом уже всякие API-штучки. Но и про них не стоит забывать.

Я дам вам чек-лист, к которому вы сможете обращаться потом — «так, это проверил, и это, и это. А вот это забыл, пойду посмотрю!». А потом мы обсудим каждый пункт — зачем это проверять и как.

После теории будет практика! Для неё возьмем метод doRegister системы Users — он находится в открытом доступе, можете дергать по ходу чтения и проверять =) 

Что тестировать в ответе метода REST API

Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование ответа)

Когда мы получаем ответ в REST-методе, надо проверить тело ответа и его статус код. Давайте разберемся, как это делать.

Тело ответа

Чек-лист проверки:

1. Какие поля вернулись в ответе?
2. Значения в полях
3. Текст ошибок 

Поля в ответе нужно:

• сравнить с ТЗ
• сравнить между собой SOAP \ REST 

Тестируем смену типа запроса в REST API

Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование типа запросов)

Что будет, если мы “подменим” тип запроса?

POST → GET (совсем разные типы запросов)

POST → PUT (похожие типы)

Как система отреагирует? Она может или отработать “словно так и надо”, или выдать ошибку. И тут следим за тем, чтобы ошибка была внятной и понятной.

Как тестировать URL в REST API

Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование URL)

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

Тестируем точно также, как если бы параметр был в теле:

1. Правильный параметр (из примера)

2. Обязательность (что, если параметр не указать?)

3. Бизнес-логика (тест-дизайн)

4. Регистрозависимость (если параметр текстовый)

Как тестировать тело запроса (body) в REST API

Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование тела сообщения)

 

Что мы тут тестируем:

1. Правильное тело (пример)

2. Различные параметры (обязательность, работа параметров)

3. Бизнес-логика

4. Ошибки: бизнес-логика

5. Перестановка мест слагаемых

6. Регистрозависимость

7. Ошибки: не well formed xml / json

 

Как тестировать заголовки (headers) в REST API

Это отрывок из статьи Как тестировать методы REST API. Мне хочется, чтобы было возможность дать ссылку именно на тестирование заголовков)

Заголовки должны где-то обрабатываться:

— на сервере;

— на клиенте;

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

Так что разработчики используют «Принцип меньшего зла»: заголовок или кем-то обрабатывается, или он вообще не нужен.

Если заголовка нет:

— используется дефолтный, прописанный в коде;

— он вообще не нужен;

Телеграм бот как помощь в воспроизведении багов (видео)

 

Ссылка на youtube

Уже опубликовано видео моего доклада с SQA Days 30! 

Напомню его аннотацию =)

Телеграм-бот как помощь в воспроизведении багов

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

Мы прошли длинный путь такой диагностики. Сначала собирали данные через SQL-скрипты, потом автоматизировали их и даже внедрили в систему. А потом упростили задачу разворачивания билда, делегировав это… Телеграм-боту!

Postman — как посмотреть, какой запрос ушел на сервер

Допустим, мы вызываем метод doRegister в Users (для просмотра ТЗ использовать эти данные). Так как ФИО и email должны быть уникальными, используем динамические переменные из Postman. Получается такой запрос:

{

    "email": "test{{$randomInt}}@mail.com",

    "name": " Машенька{{$randomInt}}",

    "password": "1"

}

На как понять, что при этом уйдет на сервер? Какое именно число?

Можно нажать на кнопку code справа

Как продумать тесты для автоматизации (в двух словах)

Продолжение статьи «Что такое автоматизация»

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

Бывает, что автоматизировать этот функционал ОЧЕНЬ сложно. Разработка автотеста займет много времени, причем разработчика, а не тестировщика — это не окупится, быстрее проверить вручную. 

 

Бывает, что чек-листов у вас очень много. Тогда надо выбирать те, которые нужно автоматизировать в первую очередь. По каким принципам выбирать? 

1 автотест = 1 проверка (на примере Postman-a)

Вообще это правило и ручных тестов касается, но сегодня поговорим на примере автоматизации в Postman. Итак, общее правило тестов, особенно автоматических:

1 тест = 1 проверка

Почему именно так? Да потому что проще будет понять "почему всё упало".

Давайте посмотрим на примере Users. Дергаем метод http://users.bugred.ru/tasks/rest/getuser:

{

  "email": "test_cu_11@mail.com"

} 

* Email может меняться, так как система живая, данные создаются и удаляются.

Итак, мы хотим проверить ответ и пишем такой автотест:

Логи в enterprise системах (DUMP 2022)

Ссылка на youtube мой и с канала DUMP (они одинаковые)

Вышло видео доклада с конференции DUMP 2022! Я рассказала про наш опыт развития логов в enterprise-продукте. Главное ограничение такого продукта — к логам доступа нет. И исходно даже не предполагалось: развернули решение, за ним потом следит админ на стороне заказчика. 

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

А потом про проблемы и решения для:

• сбора логов
• их анализа

Плюс подсветила некоторые моменты, о которых стоит подумать заранее. Например, если будете мониторить ошибки в логах, сразу подумайте об ошибках, которые "не ошибки" — ошибки не на вашей стороне, другая сторона знает о них, но не сильно торопится решать. Чтобы вас не спамило, надо такие ошибки сразу учиться игнорить... Как именно? Смотрите в видео =)

Собаседник — тренажер поиска багов

 

Ссылка на тренажер — https://qahacking.guru/

Полезняшки от автора тренажера — https://qahacking.ru/

Да-да, это ненастоящий сайт питомника, так что его можно смело тыкать и ломать, учась искать баги!

Пара вступительных от автора сайта:

Я, Юлия Горшкова, лид тестирования и джун автотестирования, в рамках своего проекта QAHacking сделала тренажер поиска багов https://qahacking.guru/. В планах добавить туда еще немного стабильно кривого, чтобы начинающим тестировщикам было проще находить и описывать дефекты.

Классная штука! Тренировка — это всегда полезно.

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

Ну и самый смак для ленивых — на сайте есть список багов. Попробуйте найти хотя его 😁

PS — сайтик добавила на портал Testbase в раздел тестовых площадок, дабы не потерялся

Анализ тестов — как выкидывать лишнее

 Анализ тестов — это выкидывание лишнего из вашего чек-листа. Работа из серии «сесть и подумать»:

• какие проверки можно объединить?

• какие и вовсе выкинуть?

Было бы здорово дать некий алгоритм, который поможет всегда и везде, но нет, увы. Универсальная фраза здесь только «сесть и ПОДУМАТЬ». А самое главное: «вместе с водой не выплеснуть ребенка». Убирайте тесты аккуратно, особенно в первые годы работы. Возможно, выкинутое было отнюдь не лишним...

Но общий принцип анализа примерно такой:

1. Объединить позитивные тесты.

2. Выкинуть одинаковые классы эквивалентности.

3. Не тестировать один функционал 10 раз: проверять его в одном месте, а в остальных лишь то, что он в принципе работает.

Рассмотрим каждый пункт по отдельности. 

Ссылка на Хабр

Нагрузочное тестирование

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

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

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

• Данные могут побиться, деньги потеряться где-то посреди трансфера — со всем этим придется разбираться после того, как приложение поднимут.
• Колл-центр завалят звонками — создадут высокую нагрузку уже на операторов.

Во время нагрузочного тестирования важно проверить:

• Производительность — насколько шустро приложение работает под нагрузкой?
• В какой момент наступит отказ?

См также: Тестирование производительности