Future

Есть какие-то достижения? А то получается что вроде бы работали, но как-то без энтузиазма что ли.

Я привык к 4-ёх уровневой системе, где 1-ый уровень это критикал, а 4-ый минорный. Я бы поставил данному дефекту 3-ий уровень, с приоритетом 2 (где 1, делаем сегодня, а 2 в ближайший выпуск, 4 -ый как-нибудь). Объясняю почему, приложение запускается, если да, то это уже не 1-ый уровень. Функционал работает как надо, при условии корректных данных - ответ да, значит не второй.

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

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

Во-первых в голове у меня есть умный пользователь, и проблемный пользователь. В процентном соотношение втестах получается 1/9. Т.е. 90% тестов будут т.н. негативные.

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

В-третьих, начинаю смотреть безопасность (как правило на достаточно поверхностном уровне).

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

В-пятых, начинаю проверять юзабилити продукта.

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

Теперь если брать вашу задачу. У нас есть веб магазин.

Я бы тестировал так:

1) Разделил бы тестирование админки и пользовательской части (далее буду писать только для пользователя)

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

3) Попробовал бы что-то купить и удалить что-то из покупок.

4) Зарегистрировал бы проблемного пользователя, со всевозможными ситуациями при авторизации (почитайте про тестирование безопасности).

5) Затем проверил бы негативные сценарии, например вы совершаете покупку, но не нажимаете подтвердить, а закрываете браузер и заходите снова, на каком этапе у вас будет процесс? Тут сами подумайте

6) Тут проверил бы кросс браузерность, а так же поигрался бы с различным разрешением на мониторе (жалетельно иметь монитор поддерживающий больше чем FullHD)

7) Т.к. в вашем случае юзеров пока нет, то посмотрел бы просто на сайты конкурентов и из этого сделал бы какие-то выводы для себя.

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

Какая смысловая нагрузка в параметре дата обнаружения? Может лучше заменить на версию, если уж вам так хочется. Я бы добавил степень критичности, ибо одно дело шрифт не красивый и другое дело пропущен пункт меню.

Попробую ответить на вопрос в топике (основываюсь на своём опыте + опыт друзей)

1) Базовые знания Linux, SQL.

Крайне расплывчатая формулировка. По линуксу могут спросить отличия директорий в Win и Linux, могут спросить как найти файл (довольно частая процедура, я бы был удовлетворён если бы просто назвали команду find, точный синтаксис я и сам не помню, для этого есть гугл и ман). Про SQL скорее всего попросят написать что-то с джоином и сделать запрос с вложенным селектом (это обычно база).

2) Базовые знания СУБД, желательно Oracle.

Сложнее сказать, лучше пусть подскажут коллеги, могут спросить чем отличается Оракл от MySQL например.

3) Знание методологии тестирования ПО

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

4) Умение составлять тест-планы и сценарии тестирования

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

5) Опыт работы с Test Link приветствуется

Не знаю, не работал.

6) Опыт работы с системами сопровождения дефектов приветствуется

Всегда считал это самым глупым вопросом, ну какая разница работал человек с жирой или багзилой или нет. Если он понимает, как делается пункт 4, то уж и с этим справится. А тут совет, просто на википедии почитайте что такое багтрекинговые системы, типа bugzilla, jira.

7) Английский язык - базовый уровень

Обычно не такая формулировка, а спрашивают обычно технический английский. Ну тут всё зависит от самой компании, у меня бывало что переходили в процессе собеседования на инглиш, а бывало что просто просили перевести кусок документации, все зависит от самой компании.

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

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

2-е, использовать шаблоны какой-то компании (пусть даже большой и известной это очень и очень плохо). Причина проста, они это делают для своей внутренней разработки потому что им так удобно, ваше резюме должно быть универсально и посылаться в разные компании. Если вы работник с небольшим опытом работы, то ваше резюме не может быть больше 1 страницы А4 никак, т.к. у вас еще нет достижений каких-то по работе. А то что вы будите писать, что когда-то там написали курсовой, ну это конечно прикольно, но только если тематика курсового хоть как-то имеет отношение к компании. В общем прежде чем писать что-то почитайте и подумайте над тем что вы пишите, поставьте себя на место работодателя. Резюме это как экзаменационный лист вопросов, именно по нему будут вас спрашивать на собеседовании. Поэтому если вы что-то там написали, то готовьтесь нести за это полную ответственность.

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

Хм... странно, вроде бы управленец, а резюме написано как у студента.

Вспомнился один ролик КВНовский



Как раз про тестирование и их виды ))))

Не знаю может быть вам поможет такой простой совет, возьмите selenium и поизучайте его возможности. Что - то новое придумать довольно сложно, а вот что - то доработать это всегда пожалуйста.