Здравей,

1. По принцип би било хубаво да са отделни issue-та. Защото може поетапно да ги оправи програмиста. Поне така би било в реална среда. Ако видиш, че те притиска времето ги пусни в едно issue. Също разцъкай малко в JIRA "More" таба на issue-тата. Там има опция Clone, така че можеш едно issue да го клонираш.

2. Можеш да "цапаш" скрийншотите, ако сметнеш, че така по-добре ще разбере човека, на когото репортваш. Понякога даже е силно препоръчително.

3. Неяснотиите по спецификацията се репортват също в тракера. Изпращай ги до отговорния за спецификацията. В случая на изпита това е Project Manager-a.

4. Колкото по-широк е обхватът на автоматизирания тест, толкова по-добре. И в реална среда и на изпита, също. Ако имаш автоматизация, която тества за различни видове атаки, няма да ти се налага всеки ден да го правиш ръчно. Както може да регресира дадена функционалност, така може да регресира и сигурността на приложението. Аз лично препоръчвам преди да стигнеш до автоматизация на сигурността, да минеш през по-основните функционални тестове, като например дали дадената функционалност въобще работи по спецификация. В случая с коментарите на албумите това беше - дали гост може да коментира (съответния error box); дали регистриран може да коментира; дали админ може да коментира. Дали правилно се появява коментара. Дали е от правилния потребител. Дали е с правилната дата. След като минеш през тези, тогава ако остане време автоматизирай тестването на сигурността.

5. Няма one best scenario в тази случка. При логин форма, ако този скрипт мине, най-вероятно ще се логнеш с някой потребител. Евентуално първият в таблицата с потребители, който вероятно е администраторът. Ако си подкарал изпитите при теб, шансовете са, че имаш MySQL. На http://localhost:8023/phpmyadmin (или без 8023, ако не си оправял порта) имаш административен инструмент за достъп до MySQL. Пробвай през него да навигираш до таблицата с потребители на някой от изпитите. Има опция да филтрираш данните. През туулчето избери да филтрираш до някой потребител с парола и то ще ти генерира заявка. Нещо от рода на "SELECT * FROM users WHERE username = 'pesho' AND password = '!$f4553443ef645g457567';". Вземи тази заявка и я пусни в SQL табчето, само че вместо pesho сложи скрипта, и ще видиш какъв де факто е резултатът. SQL injection атаката прави точно това, каквото пише в името й. Инжектира SQL код в заявка, правейки я различна от очакваната за програмиста и евентуално удобна за съответния атакуващ. Най-честият начин да разбереш дали има такава дупка е кодът, който си дал, но може по някога и по-сложни заявки да трябва да се сложат, за да мине атаката (обикновено такива успяват да бъдат намерени, когато приложението е с отворен код).

Надявам се да съм успял да ти отговоря и да е било полезно и за останалите.

Поздрави,

Иван