Тестировщик

Такой вопрос задал threads и получил интересные варианты. От Гугла до онлифанса, а еще поработать над своим приложением. Делись своим вариантом тут или там!

Кстати, тут один разработчик пилит интересную аппку yaranga - заметки для людей с большим входящим потоком задач/заметок. Можно попробовать и накидать автору фидбэка. Считаю отличной тренировкой бета-тестирования 😉

P.S.: абсолютно не реклама, решил помочь человеку с которым любезно пообщались в threads.

Всегда хорошо, когда есть альтернатива. Поэтому подписывайтесь сразу на пачку тг-каналов про тестирование.

Тут только топчик каналы. Мы с админами многих других каналов отбираем и ревьюим каждые полгода каналы на актуальность.

Это вам сейчас, но на Новый год 😁

YaC 2024 подъехал 🎉
Серия про нейросети огонь, про людей пушка, в общем советую посмотреть 😊

Привет, друзья!

На выходных поделился постом про то, как мы стали оценивать важность багов не на встречах, а через телегу, и что из этого вышло. Почитать можно тут: https://habr.com/ru/articles/823658/.

Цель поста была в том, чтобы поделиться опытом и идей (без технической реализации). И вот что из этого вышло:
1. Если пишите на хабре, как мне кажется, нужно больше технической реализации
2. А лучше выложить то, что сделали, в общий доступ
3. Даже одна ссылка на свой канал считывается как “Больше рекламы, чем пользы”
4. Но вишенка на торте, это то что кто-то оценил причину почему не понравился пост - “Личная неприязнь к автору или компании”

P.S.: не подумайте, что я жалуюсь, это лишь немного наблюдений и лайфхаков как не потерять карму и не уйти в минусовой рейтинг.

Сейчас этот пост, возможно, вырвал вас из контекста. И чтобы вернуться к предыдущему вам потребуется некоторое время. Все зависит от того насколько разные типы задачи с которых переключаешься. Автор статьи “Context switching” описывает как это происходит и делится техникой как успешно переключаться между контекстами и не терять эффективность:

1. Понять что вас вырвали из контекста.
2. Выгрузить прерванный контекст. Это можно сделать абсолютно другим видом деятельности. Например, писали код, а вас просят поревьюить кейсы. На 5-10 минут идете попить кофе, прибрать рабочее мест, сделать что угодно. Главное выгрузить прерванный контекст из головы.
3. Планировать работа задачами со схожим контекстом.
4. Приоритизировать задачи и дать знать окружающим когда вы не можете отвлекаться. Это могут быть статусы тг, встречи в календаре с пометкой “занят”, а еще можно договориться с коллегами, что если у вас на столе, например, стоит красный флажок, то вас не беспокоить (пример из книги “Гиперфокус”).
5. Медитируйте или делайте дыхательные упражнения. Автор поста говорит, что многие чувствуют неловкость перед коллегами выполняя такие практики. Думаю, у многих так 🙂 Мне помогает прогулка до столовой с коллегами в обед или поболтать на кофепоинте.

P.S.: извините, если вырвал из контекста 🙂

Привет!
Коллеги из Т-банка, Домклика и Банка Точка расскажут про пеерезд с натива в мобильный-веб, стандарты мобильного вебстроения и адаптивность. Митап пройдет 10 июня в 19:00 (МСК). Можно участвовать онлайн. Регистрация: https://meetup.tinkoff.ru/event/tinkoff-design-meetup/

Привет!
Создавал канал с целью делиться опытом, но почему бы не воспользоваться им, как способом решить свою проблему (учитывая что у нас тут большинство средний класс мидл)
У меня тут появилась, тривиальная с виду, задача - обновить библиотеку в django-проекте, но на деле оказалось не очень просто. Текущая библиотека очень устарела, при обновлении на свежую получаю проблемы типа: класс не существует, метод перенесен или переименован и т.п. По релизноутсам будет сложно искать все изменения (разница между версиями 3 года).

Что посоветуете? Какие есть практики в таких случаях? Нужно ли реально все рефакторить? Буду очень благодарен за любые советы, ссылки и т.п. Можно залететь сюда в чат и пошуршать: https://t.me/+hHHg8d7tzlw2MzFi

Если вы в Казахстане или будете 27 июня не пропустите возможность посетить умную юрту, поговорить с Алисой на казахском или просто потусоваться с коллегами на Медеу: https://yandex.kz/qday.

Если, к сожалению, вы не сможете быть оффлайн, то смотрите прямую трансляцию на yandex.kz.

Я тут подумал, а почему бы нам не познакомиться ближе!
Возможно, вам будет интересно узнать чем живет инженер по тестированию из Яндекса. Посмотреть можно тут: https://www.instagram.com/testirovshit/. Там пока только фоточки городов, где побывал, но обещаю скоро выложу пост про себя и буду больше делиться личным (не все же про тестирование, входы в IT, всеобъемлющие баги и т.п.). А еще заглядывайте в X: https://x.com/testirovshit

P.S.: по старой доброй традиции - взаимная подписка 😁

Привет, коллеги!
На долго пропал, надеюсь не потеряли совсем. Были праздники, отпуск и срочные семейные дела. И все это вылилось в то, что на первом релизном дежурстве сделал небольшой факап (хотя казалось бы, вроде отдохнул). Факап совсем несерьезный, но он сподвигнул пойти и предложить коллегам добавить автоматизации в процесс. Следом подумал, что нужно почитать и вспомнить про то, когда нужна автоматизация, как понять что и когда автоматизировать и все что с этим связано. Нашел интересную статью: https://clck.ru/3Awae2. Не стал полностью переводить и пересказывать, но для затравки предлагаю вспомнить или узнать про знаки говорящие о том, что пора автоматизировать процесс:

1. Много рутинных задач. Если у вас забирают много времени и сил повторяющие задачи, то это мощный сигнал что стоит подумать над автоматизацией процесса.
2. Задержки и узкие места. Когда производительность всей системы зависит от одного звена и/или есть задержки/отставания от планов.
3. Человеческий фактор и неточности. Кейсы в которых люди забывают что-то сделать или делают не в полной мере, как должно быть (отправить письмо, пингануть коллегу, перевести задачу в статус, etc).
4. Ответ на рост требований и ожиданий клиентов. Бизнесу всегда нужно быстрее, дешевле и качественнее. Чтобы угнаться за требования нужно быть точнее/оперативней/etc. Все это, чаще всего, может обеспечить только автоматика.
5. Оптимизация затрат и ресурсов. Когда ощущается повышение издержек на ручной труд, то это еще один мощный сигнал необходимости автоматизации.
6. Необходимость собирать аналитику в реальном времени. Если нужно собирать различные метрики о продукте/услуги, то это 100% автоматизация процессов сбора, обработки и хранения информации.
7. Масштабирование и рост. Невозможно расти и развивать продукт без автоматизации. Сразу на ум приходит регрессионное тестирование. Чем больше продукт, тем больше потребности в его автоматизации с каждым новым релизом.
8. Соответствие требования и нормативам. Соблюдение законов, постановлений тоже причина привлекать автоматизацию. Тут будет и точность, и оперативность. Но очень важно следить за процессами, чтобы случайный сбой не стал причиной нарушения этих требований и нормативов.
9. Тренды индустрии. Если конкуренты растут и внедряют автоматизация, то вам, как минимум, нужно задумать об этом.

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

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

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

На всех уровнях тестирования держим в голове мысль “продукт не готов к запуск, есть блокирующие баги и мне нужно их найти”. Если после тестирования у вас есть ощущение “что-то упущено”, то это отлично! Значит вы делали все чтобы поймать баги и не выпустить поломанный продукт. Ведь он делает жизнь пользователя проще, а если он поломан, то он усложнит или сделает жизнь пользователя невозможной.

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

Еще хотел бы поделиться своим постом на хабре “ТОП-10 ошибок тестировщиков, что приводят к блокерам”.

Удачных выходных ;)

Выходной даджест новостей из мира IT. А так Алиса видит роботакси в 2024 году.

1. Google добавит функцию Lookup для определения кто звонил (ждем функцию в яндекс браузере :))
2. На Mashable собрали слухи о iPhone 16: дата релиза, цена, характеристики, фичи и многое другое.
3. Сможет ли Маск запустить роботакси 08.08?
4. Microsoft скоро запустит фичу ограничивающую потребление RAM в Edge.
5. Google продолжает развивать возможность трансформации Android в десктопную ОС.
6. И опять новости от Google, в Chrome появилась тестовая фича “привязка кук к устройству”. Это должно защитить от кражи кук и последующего взлома.

⭐️ Канал “Тестировщик” - все о тестировании ПО и о мире IT

Привет!
Делюсь с вами некоторыми размышлениями на тему написания тест-кейсов.

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

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

Несмотря на то, как тестировщик относится к написанию кейсов, есть практики позволяющие избежать техдолга и снизить риски пропуска багов в регрессе. Делюсь теми, что встречал за годы работы:
1. Не использовать тест-кейсы. Чаще всего такие команды используют чек-листы (ЧЛ). Как мне кажется, один из признаков крупной компании/проекта в том, что тестирование может себе позволить писать ТК, а еще и гонять их в регрессе.
2. Автоматизировать процесс написания ТК. Сюда входит использование TMS, создание ботов призывающих тестирование к написанию кейсов после проверки тасок, а кто-то привлекает ИИ к созданию артефактов и т.п.
3. Процессно регламентировать написание кейсов. Например, нельзя перевести задачу в статус "Протестировано" пока не будет написан ТК и прилинкован к таске. Тут половина дела решает договоренность в команде, а половина автоматизируется, т.е., как в примере, система управления проектам блокирует переход, пока не будет кейса.

Кстати, если у вас есть какие-то предложения, вам нужна консультация или есть вопросы, то смело пишите мне @Sovetkali. С удовольствием поделюсь опытом!

А еще когда-то давно публиковал карточки по Git, возможно, будет полезно.
Также были карточки по fiddler.
Полистайте канал на досуге, много всякого было 😉

Привет!
Невозможно не поделиться такими крутыми бесплатными курсами практикума:
- Основы работы с Git
- Основы работы с базами данных и SQL

Делитесь в комментах курсами, которые проходите 🙂

Добрый день, друзья!
Подсмотрел у разработчиков крутые шпаргалки, делюсь с вами:

1. SQL: sqltutorial.org
2. Git: cheatography.com
3. Bash: devhints.io/bash
4. HTML: htmlcheatsheet.com
5. CSS: htmlcheatsheet.com/css
6. JavaScript: quickref.me/javascript.html
7. Python: quickref.me/python.html

Если есть что добавить, то велком в комменты 🙂

Привет!
Традиционный новостной дайджест и не менее традиционная картинка от Алисы на запрос: старичок gmail в 2024 году.

1️⃣ Google Podcasts закрывается и просит пользователей переехать в Youtube Music. Пока что в США.
2️⃣ Некоммерческая организация по свободе интернета призывают Apple и Google ограничить использование inapp-браузеров. Они, по их мнению, угрожают безопасности и конфиденциальности пользователей. Ждем изменений.
3️⃣ Наверное, заметили как часто в новостях говорят о судах с Apple. Например, замена lightning на USB-C в ЕС. Так вот тут рассуждения на тему того, как это все влияет на Apple.
4️⃣ Почувствуйте себя старыми - Gmail 20 лет! Как гугл ворвался с 1 Гб, когда ящикам выдавали 15Мб. Читайте в лонгриде на The Verge.
5️⃣ На MacWorld рассуждают какие фичи WWDC24 были очень ожидаемы. Я бы с удовольствием посмотрел на Siri 2.0 и, точно бы пользовался, многопользовательским режимом в iPad.
6️⃣ Instagram тестирует фичу Blend, которая освободит от необходимости пересылать прикольчики друзьям. Теперь рекомендации будут выдаваться на основе ваших общих интересов.
7️⃣ И напоследок, обновите свой iPhone, Chrome и многое другое. Март был щедрым на уязвимости.

⭐️ Канал “Тестировщик” - все о тестировании ПО и о мире IT