Issue Document - need help! срочно
#1
Отправлено 14 октября 2010 - 21:34
Это моя первая тема на форуме, так что не судите строго, если что. ))))
Я начинающий тестировщик. Сейчас устраиваюсь на работу. В ответ на резюме, отправленное в одну из компаний, мне пришло предложение выполнить тестовое задание, которое заключается в том, чтобы найти как можно больше issues на бета-версии сайта. В ответ от меня ожидается issue document. Погуглив, я обнаружил несколько template'ов issue document, однако мне не совсем понятно, что с ними делать (а точнее, практически, совсем не понятно) .
Пожалуйста, подскажите, как лучше составить этот самый issue document(я имею в виду в основном оформление, есть ли какие-то стандарты?), чтобы произвести хорошее впечатление на HR отдел компании. Да, чуть не забыл. На все про все у меня всего пару дней. Очень прошу, не медлите с ответами.
Заранее благодарен за полезные ответы и рекомендации.
#2
Отправлено 15 октября 2010 - 01:05
Ищите другую компанию.
Keep your soul undamaged, ей-богу.
"Issue" на языке англичанинов означает "вопрос, который надо обсудить". Односложно на русский язык это слово перевести сложно, поэтому большинство произносит его как "ишшу".
Например, в рулезнейшем баг-трекере Mantis каждая запись называется issue. Баг там записан, или задача, или вопрос - это все issues.
Они вам предложили просто, весело, задорно и бесплатно протестировать их приложение, и предоставить им максимально большой список багов.
Если вы действительно хотите очаровать HR-отдел, то не ищите шаблоны issues. Вам нужен шаблон написания багов.
Шаблон такой:
1. Сделать это. 2. Сделать то. 3. Сделать то-то. [...] сделать то-то и это-то. ОЖИДАЕМЫЙ РЕЗУЛЬТАТ Такой-то. ПРОБЛЕМА Происходит то-то и сё-то. Скриншот прилагается.
Software Testing Glossary - простыми словами о непростых словах.
#3
Отправлено 15 октября 2010 - 05:23
у Вас на сайте это расписано более объемно и интересно :)Такое домашнее задание пахнет насилием и обманом.
Ищите другую компанию.
Keep your soul undamaged, ей-богу.
.....
#4
Отправлено 15 октября 2010 - 06:22
#5
Отправлено 15 октября 2010 - 06:29
А так - поскольку опыта у вас нет, то это действительно может быть как практическое занятие для вас, понаходить баги и посоставлять отчёты. Обязательно только просите обратной связи от компании. Даже если они вас не примут - считайте, что у вас появился мизенрный стаж и мизерный опыт.. ))
#6
Отправлено 15 октября 2010 - 06:46
И кстати, Freiman, а о каком сайт идет речь?
#7
Отправлено 15 октября 2010 - 07:16
Всегда надо что-то делать. Например, зайти на главную страницу сайта :). При документировании орфографической ошибки логично указать страницу (главная страница сайта), раздел, где помещена информация с ошибкой, ну и само слово с ошибкой + правильный вариант. Ошибку лучше всего как-нибудь выделить (прописной буквой, жирным начертанием, и.т.д.)Спасибо, frei_by. Остались еще кое-какие вопросы. Ну а как, скажем, лучше описывать баги, для которых не надо делать то-то и это-то, а вот, к примеру, при первом же рассмотрении сайта, мной обнаружена банальная орфографическая ошибка. Или там недочеты дизайна как описывать? И еще, есть ли смысл присваивать багам ID и прочие формальные атрибуты типа там приоритетности? Стоит ли составлять какие-либо тест-кейсы (я имею в виду не в голове, а в файле или на бумаге) или лучше просто поимпровизировать в свободном полете?
ID любая система баг-трекинга проставляет автоматически, а вот приоритет стоит написать в любом случае.
Тест-кейсы стоит составлять прежде всего для себя и в том формате, в котором вам удобно. Вас же не просили предоставить список кейсов. Кейсы всегда изначально в голове придумываются, но лично у меня часто все в голове не помещается, и я важные моменты фиксирую на бумаге: что надо не забыть проверить + таким образом удобно структурировать придуманные кейсы и легче видеть, что осталось непроверенным уже придуманными кейсами.
В предложении Freiman есть вся необходимая информация. Он отвечает Алексею (Astenix) и говорит про его сайт — блог http://testitquickly.com/, который ведет Алексей и ссылка на который есть в его профиле. Умение самостоятельно находить нужную информацию — одно из важнейших качеств тестировщика.И кстати, Freiman, а о каком сайт идет речь?
SQL для тестировщиков
Тренинги по HP QTP и автоматизации тестирования
Если минарет, значит выше всех (с)
#8
Отправлено 15 октября 2010 - 07:22
ссылка на страницу, скриншот с обведенной ошибкой.Ну а как, скажем, лучше описывать баги, для которых не надо делать то-то и это-то, а вот, к примеру, при первом же рассмотрении сайта, мной обнаружена банальная орфографическая ошибка.
нумеровать желательно. критичность - обязательно.И еще, есть ли смысл присваивать багам ID и прочие формальные атрибуты типа там приоритетности?
можно использовать такой шаблон
[Number] - ID, номер
[Title] - заголовок, краткое описание проблемы
[Steps to reproduce] - шаги для воспроизведения
[Expected Result] - ожидаемый результат
[Result] - реальный результат
[Severity] - важность/критичность
[Files] - скриншоты и прочие файлы
ну и конечно надо указывать окружение, на котором все проверялось
импровизировать в свободном полете не надо: продумайте, что и как надо протестировать. Но описывать это в тест-кейсах в файле/на бумаге в данном случае бессмысленно - вы просто потеряете время.Стоит ли составлять какие-либо тест-кейсы (я имею в виду не в голове, а в файле или на бумаге) или лучше просто поимпровизировать в свободном полете?
http://testitquickly.com/2010/10/15/ratiunea-cheama-ajutoare/И кстати, Freiman, а о каком сайт идет речь?
#9
Отправлено 15 октября 2010 - 07:44
Умение самостоятельно находить нужную информацию — одно из важнейших качеств тестировщика.
Ценное замечание! Пристыдили.)))) Спасибо Вам.
Спасибо, Freiman, за шаблнчик. Остался вот только вопрос. А критичность выставлять исходя из своего субъективного мнения в соответствии с собственной шкалой?
#10
Отправлено 15 октября 2010 - 08:11
ага, только так, если никакой другой информации Вам не предоставили.Спасибо, Freiman, за шаблнчик. Остался вот только вопрос. А критичность выставлять исходя из своего субъективного мнения в соответствии с собственной шкалой?
#11
Отправлено 15 октября 2010 - 08:28
В качестве дополнительной информации прошу в гости на наш сайт: http://www.protestin.../bugreport.html
Умение самостоятельно находить нужную информацию — одно из важнейших качеств тестировщика.
Ценное замечание! Пристыдили.)))) Спасибо Вам.
Спасибо, Freiman, за шаблнчик. Остался вот только вопрос. А критичность выставлять исходя из своего субъективного мнения в соответствии с собственной шкалой?
Что не поймете, спрашивайте...
Про Тестинг
#12
Отправлено 15 октября 2010 - 08:58
В качестве дополнительной информации прошу в гости на наш сайт: http://www.protestin.../bugreport.html
Что не поймете, спрашивайте...
Спасибо огромное! Полезнейший сайт!
Спасибо Freiman! В том-то и дело, что абсолютно никакой дополнительной информации мне не предоставили. Определю сам себе правила и буду по ним играть.
#15
Отправлено 15 октября 2010 - 14:55
#16
Отправлено 15 октября 2010 - 15:08
#17
Отправлено 15 октября 2010 - 15:23
http://validator.w3.org/
Дизайнеры в восторге.
#18
Отправлено 15 октября 2010 - 15:27
в любом случае опыт вы получите - а это уже хорошо, учитывая, что у вас его пока мало.Не сказал бы, что компания очень большая, просто это выглядит, как возможность, которую не хочется упускать. С другой же стороны, я прекрасно понимаю, что проведут такое тестирование, предположим, 5 человек, а на работу примут только одного, и получится, что те, кого не возьмут, проделают очень крупный кусок работы даром.
допустим, лично вас на эту должность не взяли, то:
а) если компания хорошая и приличная, то вам объяснят, почему вы не подходите, укажут на недостатки в тестовом задании - считайте это бесплатным обучением (консультацией).
б) если компания "неадекватная", то вы должны быть рады, что вас туда не взяли :)
#19
Отправлено 15 октября 2010 - 15:42
Не думаю, что в моем случае реакцией на это будет восторг. )))))))))страницу в валидатор - и в баг прикрепляю ответ валидатора.
http://validator.w3.org/
Дизайнеры в восторге.
Arel, Freiman, огромное спасибо. Вывод однозначный - тестировать. )))))))
По поводу простого списка багов вот только не уверен. Все же репорт с описанием шагов и тому подобного произведет лучшее впечатление, хотя мне, честно говоря, и самому не хочется возиться с этими формами.
#20
Отправлено 15 октября 2010 - 16:31
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных