Битая там только первая ссылка была -- я поправил, теперь все ссылки работают.Ой.. я попробовала их открыть - ссылки мертвые(
Можно по названиям по гуглить, если интересно :-)
Стиль написания тест-кейсов
Автор hcnik, 25 янв 2011 08:23
Сообщений в теме: 24
#21
Отправлено 26 января 2011 - 15:59
Алексей Баранцев
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#22
Отправлено 26 января 2011 - 17:06
Можно на клаве набрать, можно на экранной, можно Ctrl+VВ том-то и дело, что способ только один. Это все равно что сказать "Наберите в поле password свой пароль путем нажатия клавиш на квалиатуре" вместо "Введите пароль в поле password". Как в 5 шагов описывать рисование прямой линии в пейнте.Второй вариант кажется более лаконичным и понятным, т.к. я пока не знаю сколько способов существует, чтобы сделать A is child of B.
Из-за упускания таких мелочей в описании у разработчиков частенько баги не воспроизводятся.
#23
Отправлено 26 января 2011 - 17:12
Это все мы проходили конечно же, я просто выбрал (как сторонний наблюдатель) наиболее лаконичный и понятный кейс. Я бы вообще по-своему оформил.Все зависит от "угла зрения".
Второй вариант кажется более лаконичным и понятным, т.к. я пока не знаю сколько способов существует, чтобы сделать A is child of B.
#24
Отправлено 29 января 2011 - 10:25
hcnik, а есть у вас такая процедура как review?
Собственно, если да, вы еще на этапе создания коллегами тест плана можете повлиять на результат, выслав свои замечания в ревью и аргументировав почему так как написано не удобно..
На мой взгляд, единые стандарты в рамках предприятия нужны.
Не зря ведь разработчики используют code standards.. Предложите выработать свою внутреннюю test cases policy.
Собственно, если да, вы еще на этапе создания коллегами тест плана можете повлиять на результат, выслав свои замечания в ревью и аргументировав почему так как написано не удобно..
На мой взгляд, единые стандарты в рамках предприятия нужны.
Не зря ведь разработчики используют code standards.. Предложите выработать свою внутреннюю test cases policy.
#25
Отправлено 01 февраля 2011 - 17:01
Старясь короче описать проблему, и упустил некоторые моменты.
Дело не только в том, что человек пишет длинно. Время от времени проскакивают более неприятные вещи.
Например, он написал "Make B child of A". Но дело в том, что это действие можно понять и как "Link B to A", и как "Relink C-to-B into A-to-B" - два разных действия.
Или использовал несуществующий объекта.
Или назвал объект с большой и с маленькой буквы в разных местах. Для программы это - совершенно разные имена.
Не знаю, насколько поможет бороться с последними двумя случаями стандарты, но с первым - точно. Возможно и с остальными, так как боле короткая запись с меньшим количеством избыточной информации более наглядна.
Насколько критичны эти отличия?
Правда ли может быть хоть один адекватный человек с IQ не ниже среднестатистического, который это не поймёт? Сомнительно...
Согласен с вами. Позже я стал более лояльно относиться к чужому стилю.
Можно на клаве набрать, можно на экранной, можно Ctrl+V
Из-за упускания таких мелочей в описании у разработчиков частенько баги не воспроизводятся.
Тоже согласен. Но как раз в этом случае действительно нет другого способа сделать "Link B to A"
Посмотри этот топик - http://software-test...rum/topic/8436/
Спасибо!
hcnik, а есть у вас такая процедура как review?
Есть. Из-за нее я и задал этот вопрос. Только стандартов все равно не было. И получалось, что человек соглашался исправлять только то, что невозможно понять.
Что собственно получилось. Я просто написал вопиющие примеры того, как есть, с одной стороны, и как сделал бы я - с другой. Выслал его QA Lead'у, прописал буквально 3 предлагаемых стандарта, чтоб хоть часть из этого не возникала. После чего у нас был митинг, и большую часть этого приняли. К счастью. Пришлось только постараться, чтоб человек, которого я ревьюил, не обиделся, потому что большинство примеров были взяты у него.
Но, что главное, - лид согласился таки завести доку со стандартами для нас не только на эти тесты, но как стиль написания вообще. И для тест кейсов, и для создаваемых нами багов.
Дело не только в том, что человек пишет длинно. Время от времени проскакивают более неприятные вещи.
Например, он написал "Make B child of A". Но дело в том, что это действие можно понять и как "Link B to A", и как "Relink C-to-B into A-to-B" - два разных действия.
Или использовал несуществующий объекта.
Или назвал объект с большой и с маленькой буквы в разных местах. Для программы это - совершенно разные имена.
Не знаю, насколько поможет бороться с последними двумя случаями стандарты, но с первым - точно. Возможно и с остальными, так как боле короткая запись с меньшим количеством избыточной информации более наглядна.
Насколько критичны эти отличия?
Правда ли может быть хоть один адекватный человек с IQ не ниже среднестатистического, который это не поймёт? Сомнительно...
Согласен с вами. Позже я стал более лояльно относиться к чужому стилю.
Можно на клаве набрать, можно на экранной, можно Ctrl+V
Из-за упускания таких мелочей в описании у разработчиков частенько баги не воспроизводятся.
Тоже согласен. Но как раз в этом случае действительно нет другого способа сделать "Link B to A"
Посмотри этот топик - http://software-test...rum/topic/8436/
Спасибо!
hcnik, а есть у вас такая процедура как review?
Есть. Из-за нее я и задал этот вопрос. Только стандартов все равно не было. И получалось, что человек соглашался исправлять только то, что невозможно понять.
Что собственно получилось. Я просто написал вопиющие примеры того, как есть, с одной стороны, и как сделал бы я - с другой. Выслал его QA Lead'у, прописал буквально 3 предлагаемых стандарта, чтоб хоть часть из этого не возникала. После чего у нас был митинг, и большую часть этого приняли. К счастью. Пришлось только постараться, чтоб человек, которого я ревьюил, не обиделся, потому что большинство примеров были взяты у него.
Но, что главное, - лид согласился таки завести доку со стандартами для нас не только на эти тесты, но как стиль написания вообще. И для тест кейсов, и для создаваемых нами багов.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных