Molechka

В первую очередь надо проверять позитивные сценарии.

Узнаете у босса, что ему надо от тестировщика (мало ли, может там вообще хочушки из серии "чтобы багов вообще не было", это не только от вас зависит). 

Приступать к тестированию чем раньше, тем лучше. Сделал разработчик кусочек? Вы проверили.

Пока делает — выпишите себе:

1. Основные функции сайта. Это то, что должно работать всегда. То, что надо проверять в первую очередь.

Пользователь должен что? Увидеть товар, отфильтровать по своим критериям, положить в корзину, оплатить... Вот это все. Распишите основные сценарии использования.

2. Главные косяки текущего сайта. 

Почему решили с нуля переписывать? Что-то было неудобно? Что-то неустраивало? Это надо прямо явно прописать, чтобы не забыть исправить. Иначе сделают новое, а толку ноль

У Джеймса Баха есть отличная книжка на эту тему — Secrets of a Buccaneer-Scholar.

«Школа — не главное. Главное — обучение». Ты можешь учиться в школе (на курсах), можешь без них.

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

Если умеешь учиться сам — почему бы и нет) Хотя, безусловно, на курсах ты то же самое гораздо быстрее усвоишь. Но, «все зависит от курсов».

 

Это понятно, но я имел ввиду работу в команде, когда процессом занимается несколько человек и есть кому подсказать в случае чего.

Ну так вы и пишите "научить меня бесплатно", а не "я помогу бесплатно":

А может быть посоветуете где можно попрактиковаться в составлении тестов на реальном проекте? Помочь людям за бесплатно так сказать :)

Эта фраза читается как "я горю желанием помочь другим, еще и бесплатно".

Но помочь бесплатно — это когда профи пришел и все сделал. А когда новичок делает первые шаги, то не он команде помогает, а она ему. Руководители и аналитики будут тратить время на то, чтобы объяснить, "что да как работает". Разработчики "в случае чего" подскажут, где вы налажали в коде... Вот только им тогда проще это все сделать самим )

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

А зачем вы обещали начальнику что-то показать, если даже с компьютером на "вы" — селениум даже установить не можете. Как вы собрались писать на нем тесты? А, главное, зачем?

Спасибо!

user12, эту информацию присылали на почту "поздравленным" — скидки даются на год

Ее не надо закрывать, она же не мешает.

Ерничать про "умников" тоже не стоит. Тестировщик должен уметь гуглить, а не просто приходить с вопросом "сделайте за меня".

Если бы вопрос звучал по другому: "Вот дали задание. Я нагуглил то и то, но не понял вот это, поясните, пожалуйста", то и ответы были бы другие

Качество когда конечно очень важное. Но и на старуху бывает проруха. 

Недавно нашли багу на продакшене, которая там уже пол года висела. А висела потому, что програмист писал по TDD и был уверен своих юнит тестах, а юните тесте был баг. 

И дальге по цепочке - автоматизация это тоже не покрыла, а тестировщик тоже не проверил этот edge-case. И тут пролема в основном тетсировщике, а не в программистах ...

А юнит-тесты за разработчиком лучше ревьюить! Причем даже за хорошим разработчиком :)

А то всякое бывает, напишут три тестика и типа спокойны :)

 

Ну курсов много. Этот портал, например, у меня в подписи так же.

Видео на youtube полно, вплоть до полноценных лекций.

Что вы уже нашли и изучили, что считаете, что информации очень много?

Пока только Савина дочитал, из книг нашел Дэвид Платт "Софт отстой и что с этим делать", Сэм Канер "Тестирование ПО", James A. Whittaker "Как тестируют в Google" и еще много всякого, непонятно что лучше почитать, да и старые они все 2000 - 2010 года издания. Видео нашел портнова, мэйлру, ну и так много всяких отдельных видео, которые все не пересмотришь и может еще какие курсы я не нашел... Хотелось бы как-то выделить самое необходимое, чтобы не тратить слишком много времени на поиски и изучение ненужного или одного и того же в разных источниках.

 

Список книг по тестированию и не только — берете must read в секции тестирования и читаете.

Багов вокруг дофига, вот примеры из жизни. Если вы не сможете написать "бесплатный тест-кейсы" и найти баги на открытых площадках, то и на бирже тоже не найдете. Читайте книги и тренируйтесь. 

http://bfy.tw/6tev

 

Одной прочитанной книги мало в любом случае.
Я советую пройти ещё какой-нибудь практический тренинг или два, плюс прочитать что-нибудь еще по тестированию/SQL/современным технологиям, и тогда уже можно искать себе работу Junior QA.

Заодно, кстати, можно походить на собеседования, поинтересоваться, что требуется в компаниях от тестировщиков.

А какие тренинги и книги можете порекомендовать хорошие, чтобы не зря время на них тратить? Хотел еще пофрилансить, чтобы было что показать на собеседовании, что мне необходимо сделать в этом направлении?

 

Чтобы было, что показать на собеседовании, даже денег платить не надо — пишите тест-кейсы и чек-листы на любой публичный сайт.

Оформляете баги и вуаля, портфолио готово.

Где начинающим тестировщикам получать опыт?

вопрос о результативном тестирование)
как вы думаете , можно ли в один тест кейс объединять проверку нескольких однотипных функций приложения?

 

конкретно мой пример:
нужно протестировасть некий набор способностей персонажа.

можно объединить это в один кейс, мол:

1. Зайти в бой.

2. Поочередно проверить 4 активных способности персонажа..

 

Либо это неправильный подход к тест-кейсам?

У меня смутные ощущения, потому что , по моему, в этом случае тест-кейс становится похож на чек-лист..

Хотя с другой стороны, это разгрузит от огромнейшего числа отдельных тесткейсов

Вопрос об абстрактном коне в вакууме или для работы надо?

Важное отличие тест-кейсов от чек-листов → тест-кейс можно отдать новичку, которые впервые видит, в данном случае, игру. И он сможет его выполнить. 

А в чек-листе просто будет написано "проверить способность А, Б, С". А как их включить? Как именно проверять, как оно должно работать? Ты уже должен знать или знать, где искать.

См отличие тест-кейсов от чек-листов.

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

Но, с другой стороны, в фирме может быть подход "один тест-кейс = одна проверка". И если тест-кейс упал, мы точно знает, какая способность не работает. А если упал кейс "Проверка способностой летать, нырять и плавать", то как понять, что именно не работает?

Допустимо все, что допустимо :)

Я за то, чтобы убирать лишнюю копипасту, если это не влияет на способность любого джуниора пройти ваш тест-кейс

Навык тестирования мобильных приложений

Ну так сделайте хороший отчет об ошибке автору :)

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

Навык выделения классов эквивалентности с примерами:

Диаграмма нужна для того, чтобы наглядно показывать (подсказывать), какие состояния есть в системе и какие переходы возможны между ними.

Если читабельность падает, лучше разделить одну диаграмму на несколько (верхнеуровневая и отдельные кусочки) или что-то объединить.

Например, если говорить о телефонах, то есть возможность вернуться назад. Любой переход может обломать:

— входящий вызов;

— севший аккумулятор;

— оборвавшееся соединение;

— push-сообщение от игрушки;

— ....

Но если рисовать весь этот простор мысли, диаграмму только захламим. Причем это фактически "копипаста", то, что можно проверить на любом приложении. А вы ведь хотите отобразить именно уникальные состояния вашего ПО. Я бы рисовала именно их. "Назад" телефонную можно добавить, если этот переход важен или он возвращает нас в неожиданное место =)