Как-то так, ребятки!
Добавил чуток ссылок, может кому-то будет полезно, если вы новичок в нашем деле:)
http://telegra.ph/QA-Helpful-links-02-07

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

Установка:
git clone https://github.com/wolfcw/libfaketime.git && cd libfaketime && make install

Использование:
faketime -f '@2018-02-21 20:01:00' <команда>
Задаётся начальное время отсчета
либо без знака @
faketime -f '2018-02-21 20:01:00' <команда>
В этом случае время зафиксируется и не будет меняться.

Например:

> faketime -f '@2018-02-21 20:01:00' date
Wed Feb 21 20:01:00 +05 2018

Мне тут стало интересно узнать немного об аудитории.
anonymous poll

Прохожу(-шёл) курсы по тестированию – 17
👍👍👍👍👍👍👍 30%

Не работаю в тестировании, но планирую – 9
👍👍👍👍 16%

Ищу работу – 9
👍👍👍👍 16%

Работаю меньше 1 года – 8
👍👍👍 14%

Работаю от 2 до 3 лет – 7
👍👍👍 13%

Работаю от 3 до 5 лет – 3
👍 5%

Работаю от 1 года до 2 лет – 2
👍 4%

Работаю от 5 до 10 лет – 1
▫️ 2%

Работаю более 10 лет
▫️ 0%

👥 56 people voted so far.

Существует 7 принципов тестирования

1. Тестирование демонстрирует наличие дефектов, а не их отсутствие
2. Исчерпывающее тестирование недостижимо
3. Раннее тестирование сохраняет время и деньги
4. Кластеризация дефектов
5. Парадокс пестицида
6. Тестирование зависит от контекста
7. Заблуждение об отсутствии ошибок

Именно принципы тестирования являются основой всех стандартов, книг, методов и техник тестирования.

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

Как правильно составить резюме, если ты никогда не работал в IT?

Думай как работодатель. Разберем по пунктам:

🌕 1. Оформление. Резюме должно быть оформлено на конкретную специальность. Не нужно указывать желаемую должность "Junior QA Engineer", (просто QA Engineer), а последнее место работы - «Бариста». Если нет релевантного опыта, не пишите. Занимались смежной деятельность? Укажите, если хотите показать, что навыки будут полезны на текущем месте. 1 резюме = 1 специализация.

🌕 2. Место работы. Если мы рассматриваем удаленную работу, указать город - Москва. Зачем? Работодатели из Москвы будут рассматривать вас в первую очередь и ставка по оплате будет выше. На удаленной работе в офис ехать не нужно, а зарплату больше получить реально.

🌕 3. Личные качества. Вы должны показать себя не только как специалист, но и как человек, с которым комфортно работать. Приветствуется: открытость, энтузиазм в работе, желание расти и развиваться в своей специальности, покорять вершины. Если что-то нашли в себе, укажите это в резюме обязательно.

🌕 5. Сопроводительно письмо. Если понравилась вакансия, всегда пишите сопроводительное письмо. Это будет означать вашу заинтересованность, что заставит работодателя открыть ваше резюме среди сотен других и ознакомиться.

🌕 6. Опыт. Что делать, если нет опыта? Учитесь. Постройте план развития и учитесь. С планом развития могут помочь менторы, если не найдете обучающих программ, которые вам понравятся. И повторюсь - всё, что вы узнали, чему научились, — указывайте в резюме. Работодатель увидит ваш энтузиазм и с большим шансом обратит на это внимание.

100+ ВОПРОСОВ…⁉️

📝В этой статье представлен расширенный список вопросов (и ответов), которые потенциальный работодатель может задавать тестировщикам программного обеспечения.

http://getbug.ru/101-voprosov-po-avtomatizatsii-i-testirovaniyu-vruchnuyu/

Как мы поднимаем dev-стэнд(ы) и гоняем полноценные тесты api на каждый коммит

https://habr.com/ru/articles/753444/

Жизненный цикл разработки ПО (SDLC - Software Development Lifecycle)

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

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

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

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

Фазы SDLC:
Сбор и анализ требований (Requirement Gathering and Analysis):
— На этом этапе от клиента собирается вся необходимая информация для разработки продукта в соответствии с их ожиданиями. Любые неясности должны быть разрешены сразу на этом этапе. Бизнес-аналитик и менеджер проекта назначили встречу с заказчиком, чтобы собрать всю информацию, например, что заказчик хочет построить, кто будет конечным пользователем, какова цель продукта. Перед созданием продукта очень важно понимание или знание продукта. Например, клиент хочет иметь приложение, которое включает денежные транзакции. В этом случае требование должно быть четким, например, какие транзакции будут выполняться, как они будут проводиться, в какой валюте они будут проводиться и т. д. После того, как сбор требований завершен, проводится анализ для проверки возможности разработки продукта. После четкого понимания требования создается документ SRS (Спецификация требований к программному обеспечению). Этот документ должен быть полностью понят разработчикам, а также должен быть рассмотрен заказчиком для использования в будущем;

Дизайн (Design):
— На этом этапе требования, собранные в документе SRS, используются в качестве входных данных, и создается архитектура программного обеспечения, которая используется для реализации разработки системы. Создаются два вида дизайн-документов:

Высокоуровневый дизайн (HLD - High-Level Design):
— Краткое описание и название каждого модуля;
— Краткое описание функциональности каждого модуля;
— Отношения интерфейсов и зависимости между модулями;
— Таблицы базы данных, идентифицированные вместе с их ключевыми элементами;
— Полные архитектурные схемы с подробными сведениями о технологиях.

Низкоуровневый дизайн (LLD - Low-Level Design):
— Функциональная логика модулей;
— Таблицы базы данных, которые включают тип и размер;
— Полная детализация интерфейсов;
— Решение всех типов проблем с зависимостями;
— Список сообщений об ошибках;
— Полные входные и выходные значения для каждого модуля.