Мои 12 недель в году. Часть 21 (запуск ПОТ, ДР, военкомат)

Первый опыт, второй, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20

 

Что это за техника

Вы собираетесь с друзьями в группу и ставите себе цели на 12 недель (3 месяца). Это могут быть как рабочие, так и личные задачи. Такие, которые вы вроде как хотите сделать, но вечно откладываете, так как «некогда, потом, щас, вот только мелочевку разгребу и тот пожарчик потушу».

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

Результаты кратко

Основной план был:

— закончить длинный ШНАТ

— книга: пройти ревью редактора

— статья на ХАБР!

План не просто выполнен, а перевыполнен! Длинную версию ШНАТ (ПОТ) я не просто закончила — я успела его запустить! И сейчас идет первый поток, вот уже третья тема вышла...

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

Статью я написала, да не просто статью, а статеющу (голосом Нагиева)! В исходнике она занимает 40 листов гуглодоки =))) Это мой топ года по статьям. А ещё статья участвует в конкурсе Технотекст 2022!

Ну и по мелочи. Соберем всё в кучу:

1. Вышла электронная версия первой книги!
2. Вторая книга, по тест-дизайну: 
1. Закончили редактуру
2. Выверила верстку
3. Выверила все картинки после переноса текстов
4. Оплатила первый тираж — всё, теперь просто ждем до марта!
3. Длинный курс (ПОТ):
1. Записала с нуля 10 тем ＼(〇_ｏ)／
2. Часть уже даже обработала)))))
3. Подготовила СДО, придумала домашки итд
4. Запустила первый поток! (чтобы был стимул закончить обработку поскорее)
4. Лицензия на ИП: получила ещё 3 отказа (попытки 4-6)
5. Лицензия на ООО: сделали программу и первый раз подались!
6. Посты из книги, пополняя бесплатный онлайн-вариант — всего одна  (╯︵╰,)
7. Улучшалки по текущим курсам — они небольшие, но они есть =)
1. Улучшалки по ШНАТ — 18 штук!
2. Рест — 6 штук
3. Постман — 10 штук
4. Регулярки — 2 штуки
8. Статьи на Хабр — 1 штука, но какая! 💝
9. Пополнила свой youtube-канал — 2 видео (((
10. Testbase — 1 улучшалка!
11. Настроила гостевой доступ в конфлюенсе
12. Сходила на конференцию iSpring
13. Продала ШНАТ в ЮЛ, немного допилила под них
14. Провела обучение по курсу
15. Зарегалась на вебмани (нужно будет для передачи домена)
16. Подняла смоук-сервер для соседнего проекта
17. Расписала флоу данных в своем проекте! Большой труд вышел))
18. Написала руководство пользователя для своего проекта
19. Провела обучение на работе по нашим тестам
20. Создала доку по обучению тестам на обновление
21. Купила ноутбук! Для конференций))
22. Купила маме ноутбук =))
23. Инструменты 12 недель — продолжаю вести файлик DONE, это все еще очень круто
24. ДР был, отмечали)
25. Катались к моей маме
26. Слетали к Сашиным родителям на юбилей
27. В гости к друзьям тоже выбрались!
28. Закупилась настолками ^_^
29. Играли в настолки почти каждую неделю!
30. Ходили в кино
31. Ходили в театры!
32. Ходили в детские театры! 
33. Даже в караоке сходили ))
34. А ещё в Питер смотались пару раз. С друзьями встретились и в театры сходили.
35. Великий Устюг — с Владом ездили на ДР Деда Мороза. Прикольный опыт, но Владу ещё рановато.
36. Фотосессия на Хеллуин с разукрашенными лицами
37. Фотосессия подводная!
38. Фотосессия новогодняя с ребенком
39. Всё ещё ходим в бассейн, нравится!
40. Заплатила налог как ФЛ
41. Добавила себе ИНН Влада в налоговой
42. Сходила в спа салон Ангел (через весь город)
43. Доехала до «Принц Плаза», нашоппилась, купила вечерних платьев новых себе))
44. Досмотрела «Постучись в мою дверь» — турецкий сериал на 200+ серий, начали сначала))) Первые 30 после последних прикольно пересмотреть. Милота, романтика и куча хохмы
45. Военкомат по повестке — 2 раза... Слава богу, пока отпустили...

Результаты подробнее

Отправили первую попытку получить лицензию на ООО

 

Уф, успели в этом году, отправили первую попытку на лицензию! Урааааа!

Теперь будем ждать фидбек, исправлять по нему, снова отправлять... В общем, растянется на полгода (и я не просто так пессимист, уж поверьте). Но внутренний оптимист надеется получить лицензию к весне 2023! 👀✌

Как тестировать методы 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. Мне хочется, чтобы было возможность дать ссылку именно на тестирование заголовков)

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

— на сервере;

— на клиенте;

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

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

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

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

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

Большое обновление в ШНАТ — теперь у нас есть Dev Tools!

Школу для начинающих тестировщиков я обновляю постоянно. Но обычно это какие-то минорные правки. Тут добавили доп материал, там изменили условие ДЗ... Курс ведь уже обкатан в течение 6 лет, поэтому глобально там менять особо нечего.

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

Было

7.5 недель лекций + 1.5 недели на хвосты

Под конец идут простенькие темы, которые нужны для того, чтобы ребята успели сдать свои хвосты. Это темы без ДЗ или с 1-2 небольшими дз:

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

 

Ссылка на youtube

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

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

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

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

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