Очень вдохновляющая статья и крутой результат.

Разделяю боль вставания на 6 утра в бассейн: три месяца мучалась и все надеялась, что привыкну. И какой же кайф был вернуться на вечерний слот.

Не АйТі ШДК: 100 грн з людини або 500 з команди
АйТі ШДК: 4000 грн з команди для Київа

Дякую за запрошення, але якось пограємо без "податку на галузь"🤣🤣🤣

Треш )))
Автору бы корону поменьше, а знаний — побольше, тогда б не позорил профессию.

Итак:
> Это сложно/дорого.
Тестировщик Михаила: ой, девелопер ленивая скотина не хочет работать
Нормальный тестирировщик: выясняет/прикидывает какой % юзеров аффектится этой багой, какие прямые и непрямые потери? И исходя из этого корректирует приоритет баги, настаивает на ее исправлении/отправляет в топку. Да, иногда это дорого. Сложно. И никому не надо. Не все баги должны быть исправлены.

> Это делал не я
Тестировщик Михаила: ой ужас, багу будет править не тот, кто накосячил
Нормальный тестировщик: у девклоперов есть свои задачи и приоритеты. Это нормально, когда разработчик, в коде которого бага занят/болеет/в отпуске/уволился. Если не срочный фикс (см выше, срочных фиксов реально мало), то можно подожать, а не дергать разработчика. Если реально горит — отдать в общий котел разработчиков/лиду разработчиков/менеджеру — они лучше знают загрузку дев тимы и разберутся, кого можно кинуть на пожар

> Обьясни как, тогла сделаю
Тестировщик Михаила: ой ужас, разработчики не могут выбрать реализацию, ща я им расскажу
Нормальный тестировщик: реализация и ее детали — это ответственность разработчика. Они лучше знают код, знают архитектуру и понимаю, как реализовать ту или иную фичу. Все, что я могу сделать — описать сценарии использования, чтобы они понимали, кто как и при каких условиях будет пользоваться фичей. И то, в том случае, если нет БА.

>Так никто не делает / Это невозможно / Я не знаю, как это делать
Тестировщик Михаила: отправлю-ка девелоперу ссылку на Stack Owerflow
Нормальный тестировщик: комбинация 1 + 3.

> В спеке это не сказано / сказали делать только это / согласовал с менеджером
Тестировщик Михаила: сейчас я вам всем расскажу, как нужно реализовывать! Вот ссылка на Stack Owerflow!!!!
Нормальный тестировщик: комбинация 1+3

> а я что должен?
Тестировщик Михаила: бежит жаловаться менеджеру, что его фуфло-тикеты никто не хочет править
Нормальный тестировщик: даже не сталкивается с такой проблемой, потому что является частью команды. И разработчики знают, что если он сказал исправить — значит это действительно важно, нужно и принесет пользу проекту.

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

Профит

Чтобы попасть на курс, нужно заполнить анкету (ссылка будет в ФБ проекта). Ориентировочное начало набора в этом году — конец октября-начало января.
На данный момент есть только qa

І знов не вгадали 🤣🤣🤣

Ви так вперто намагаєтесь довести, що квест ми не пройшли, що аж незручно. Не бачу сенсу далі щось пояснювати — вочевидь вам цікавий не досвід, можливості чи процес, а довести що опонент олень, і ви маєте рацію. Вважаєте, що квест не реальний — ок, ваше право

Нам щоб отримати візу треба було донести одну справку. Оскільки плани змінились, то ми цього не стали робити.

По-перше, відмова — то не «можливості нема». Після отримання відмови при бажанні отримати візу є два шляхи: подати апеляцію по тому ж пакету документів чи виправити те, через що відмова і податися знову. При чому знову можна подаватись одразу, немає періоду який треба чекати. % вдалих других спроб дуже великий.
По-друге, відмова у нашому конкретному випадку обумовлена пандемією, а не якимись іншими «неможливостями».
Хто хоче — шукає можливості, хто не хоче — відмовки.

Речь шла не о том, живем ли мы фактически в Испании, а о возможности уехать туда простым смертным, без золотых виз и чемоданов бабла.

Тот факт, что у нас в процессе переезда поменялись приоритеты, говорит только о том, что поменялись приоритеты, а не о том, что переезд по no lucrativa невозможен.

Все не просто, но и не сложно. Мы с мужем прошли этот квест и оформили все документы для no lucrativa, причем сами — по комментариям с того же ДОУ. Очень неспешно (вот прям от слова совсем неспешно) процесс занял с октября по февраль.

Но мы «счастливчики» — подались за неделю до локдауна в конце февраля 2020. В августе того же 2020 получили отказ и переезд сорвался. Можно было бы попытаться снова, но предпочтения по стране проживания поменялись. В целом квест проходим и не очень сложен

Задовільні для іншого тестувальника. Питання, що задали автору — це класика питань на співбесіді тестувальника рівня джун/мідл. Так само, як і відповідь на нього.

Вы меня так спрашиваете, словно это я собеседование проводила :)

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

Например, на вопрос про особенности тестирования Android, ответ, который удовлетворит 90% итервьюеров — множество девайсов и сложность их отбора для тестирования. При этом в компании может быть как своя ферма, так и тестирование на одном девайсе — на личном телефоне тестировщика — то есть проблема выбора девайсов, вообще может не стоят. Но вопрос зададут.

И, конечно, у мобайла есть достаточно много других проблем и особенностей, но ответ, приведенный выше, на уровне джуна/мидла будет зачтен как удовлетворительный. Типа, если знает основы — можно дальше копать и обсуждать, если нет — то нет смысла тратить время.

Аналогично для iOS и веба: там свои достаточно банальные ответы :)

Вивернути можна все, що завгодно. Ми зараз не про те. А про те, що не сказав автор, щоб його відповідь на співбесіді QA вважалась задовільною.

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

Поэтому ответ был бы более уместным ответ в стиле:
стандартные функциональные тесты (тут про ваш тестовый базис, риски и приоритеты) + типы тестирования, характерные для десктопа. Например:
* тестирование инсталляции / деинсталяции
* тестирование взаимодействия с третьими приложениями, в частности с антивирусами
* нагрузочное тестирование в разрезе поведение системы после Хчасов/дней беспрерывной работы (сколько памяти сожрет, будет ли работать корректно, будет ли тормозить)
* конфигурационное тестирование с разными поддерживаемыми версиями ОС, разными конфигурациями железа и тд.

Аналогично, для других типов приложений: говорим про стандартное функциональное тестирование + про виды тестов, характерные именно для вашего типа приложения. У веба будет свое, у мобайла — свое.

Для ответа на этот вопрос слишком мало вводных о проекте. Потому что то, что выстрелит в одном домене будет абсолютно до лампочки в другом. Плюс непонятно, где узкие места.

Вне тестирования:
* выяснить, где боль кастомера и решить ее. Даже, если это не совсем относится к тестированию напрямую. Здесь может быть все, что угодно: от наведения порядка в документации до посильной помощи тому же саппорту, БА и тд.

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

В тестировании:
* помимо грубого деления на manual и automation в тестировании есть еще масса интересных веток. Можно провести секьюрити или юзабилити аудит и по результатам включить этот вид тестирования в основную операционку.
* можно оптимизировать процессы чтобы сократить значения в ключевых для кастомера метриках.
* можно смотреть в сторону статического тестирования и внедрения ревью требований/сторей.

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

Что-то я не поняла, человек, который еще не тестировщик и который не работает, учит других теории тестирования?)))))

Охохоюшки. Если вы начинаете со " Strong knowledge теории тестирования«, то было бы неплохо этот knowledge продемонстрировать. Какой уровень прототип??? Какой уровень отладка? Для себя вы можете выделять, все, что угодно, но именно «уровни тестирования» как термин давно определены. И для джуниора, типа вас их всего 4: unit, integration, system и acceptance.

Exploratory тестинг — это не тестирование, которое диктуется особенностями приложения, а то самое «простое исследовательское тестирование». Которое вообще-то не простое, если делать его нормально, ибо предполагается два варианта:
* вы либо получаете знания о продукте для последующего их использования. В том числе для написания ТК
* рассматриваете продукт с разных, нетривиальных точек зрения, основываясь на своем опыте, знаниях и интуиции.

В общем, «не зачет» школе тестировщиков. Учили, учили да не выучили. От старой доброй темы на Доу про теорию тестирования и то больше толку.

Что-то я не поняла про пример 1. Чтение файлов — это простая функциональная задача, которая решается стандартными и банальными specification-based техниками тестирования, в данном случае — классами эквивалентности. Есть файл (валидный, не валидный) /нет файла и тд — это все хорошо прокачанный джун напишет на коленке за пару часов. Тем более, вы пишите, что с требованиями было все ок и по ним была проделана отличная работа. К чему эти танцы с бубном и трата времени в пустую, если задачка решается банально и просто?

Первое, что нужно знать о релокации, так это то, что «В», а не «На».

Да, но про эти тестовые карты от конкретной платёжной системы тоже нужно знать. Там же тоже не рандомный набор цифр для получения успешного ответа.

Так а тестовые стратегии тут причем? То, что описано в статье — это не более, чем описание реализации тестового процесса, причем, практически не отличающегося от классического, описанного в ISTQB.

Но процесс тестирования и тестовая стратегия — это как бы несколько разные вещи.

1. Люди с инвалидностью — не всегда колясочники. Внезапно, да? Есть еще инвалидность по зрению, слуху, и т. д. Это люди все ещё с особыми потребностями, но без необходимости и пандусах и туалетах не коптерках.
2. Да, не во всех офисах есть соответствующие условия, но если компании готовы меняться, то вай нот?
3. Предложить работу в качестве кассира в Ашане в качестве альтернативы в сегмента IT. Серьезно?
4. В статье написано 6 из 10 — трудоустроены. Не прошли внутренний тест. Не получили диплом. Четко, черным по белом написано «ТРУДОУСТРОЕНЫ». Мало того, в комментариях есть представители этих трудоустроеных студентов (и даже открою секрет, как раз колясочник, которому по вашему мнению лучше кассиром). Но «неееет, не верю, мне кааажется, это невооозмооожно» . Возникает вопрос — у кого тут проблемы с мышлением, кругозором и чтением и кому в кассиры — самое оно, в конце концов,