⚛️Поделать на выходных🤪

🟢 Зависнуть на обучающем сайте с симуляциями.
PhET Interactive Simulations 

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

Для доступа нужно зарегистрироваться.
Все работает - пробуйте - не пожалеете👍

P.S. ресурс на английском(интуитивно все понятно)

#саморазвитие #на_выходных
@testorest

⚛️Поделать на выходных🤪

Выбрать курсы для повышения квалификации и саморазвития.

1️⃣Открытое образование
«Открытое образование» - современная образовательная платформа, предлагающая онлайн-курсы по базовым дисциплинам, изучаемым в российских университетах.

2️⃣Лекториум
Образовательная площадка, содержащая открытые образовательные ресурсы для различных аудиторий.

Чего только на данных платформах нет, от гуманитарных до естественно-научных тем.

Возможно найдете для себя что-то интересное 😉

#саморазвитие #на_выходных
@testorest

Проекту с неустоявшимися процессами тестирования/выпуска нужно первый раз выкатить очень важный функционал для пользователей.

Вы попали на проект аккурат при подготовке к первому выпуску версии.

Вопрос:
Какие были бы ваши первые шаги как специалиста по тестированию?

🙃Ответ автора:

Чтобы не получилось так, чтобы

"Хап! И вся скатерть в дерьме!"

Цитата из книги "Кролики и удавы" .

Общий план:

1️⃣Выяснить, что от вас хочет руководство.
2️⃣Составить на основе этого план ваших действий
3️⃣Согласовать его с руководством
4️⃣Начать работать по самым приоритетным направлениям
5️⃣Периодически сверять курс.


Что нужно делать по QA части?

1️⃣ Вести базу тест-кейсов.
Лучшим заделом для будущего регресса являются описанные тест-кейсы. Их должен суметь прогнать Степан, из соседнего отдела, который что-то слышал о вашей системе, но не знает как она работает. Если вам говорят, что руководству тесты не нужны, то да, они им никогда не нужны. А проходить регресс вам. Так что можете у себя в песочнице или где-то в закромах все же готовить базу тестов. Без нее вам не выжить, поверьте.

2️⃣ Накапливать описания настроек системы, лайфхаков, которые поясняют как система работает и что нужно сделать в той и или иной технической ситуации.

3️⃣ Описать информацию по стендам.

4️⃣ Пройти заранее все регрессионные кейсы(по возможности).
Так вы узнаете про функционал и проревьюите кейсы на предмет актуальности.

5️⃣ Ежедневные короткие встречи для тестировщиков для сбивки по задачам.
Стандартный дейли-митинг.

6️⃣ Договориться о том, где и как фиксировать дефекты. На промежуточной стадии и в целевой картине.

7️⃣Управлять обновлением на стенде на котором проводится регресс.
Для отлавливания плавающих багов и корректного проведения тестирования на зафиксированной версии.

8️⃣По возможности, начинать параллельно думать о частичной автоматизации ваших рутинных действий:

- подготовке тестовых данных;
- разворачиванию тестового окружения;
- настройке системы;
- подготовке отчетов о тестировании.


❓А что помогало вам справиться с подобной ситуацией?

#вопрос_недели
@testorest

⚛️Самые распространенные ошибки новичков в тестировании.

1️⃣Проведение только самых поверхностных проверок на поля ввода.
Это частая ситуация. Чтобы ее миновать, можно углубить свои знания по части возможных проверок полей.
В интернете есть примеры таких чек-листов.


2️⃣Отсутствие проверок на общую логику работы фичи.
Т.е. поля обычно проверяют все, а как форма работает в целом - проверить забывают.
Это, конечно, образный пример.
При таком ограниченном ряде проверок теряется множество важных сценариев.


3️⃣Забыть про нефункциональные виды тестирования.
Проверили функциональность, но не проверили как быстро стала работать обработка данных или насколько безопасно новое апи(нет ли к нему доступа извне?) и т.д.

4️⃣Написать чек-лист слишком общими словами.
Тут двояко: либо все кто пользуется чек-листом в одном контексте и понимают то, что в нем хотели проверить.
Либо никто кроме вас не сможет по данному чек-листу что-либо протестировать.
Поэтому тут всегда предпочтительнее писать так, чтобы понять проверки смогли не только вы.
Уровень детализации регулируйте сами.

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

6️⃣Не заводить дефект, в котором сомневаетесь.
Тут тоже накладывается контекст договоренности на проекте. Но по умолчанию наша задача сообщить о любом сомнительном событии в системе.
Можно не заводить дефект сразу, чтобы выяснить детали и убедиться, что он существует.
Но после - лучше это сделать.
Иначе, нет задачи - нет проблемы)) И все о нем благополучно забудут.

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


❓Поделитесь, что вы бы сделали по другому набравшись опыта в QA?

#qa_обучение
@testorest

#изжизниqa

На встрече книжного клуба, которую я смогла, наконец, посетить, у нас был приглашенный гость 🐇

Книга "Кролики и Удавы"
Удава, как вы понимаете, решили не звать.

@testorest