Перейти к содержимому

Публикации LeshaL

81 публикаций создано LeshaL (учитываются публикации только с 29 марта 2023)



#96098 регрессионное тестирование - это реально?

Отправлено автор: LeshaL 24 октября 2011 - 11:10 в Про тестирование обо всём подряд

Я знаю точно, невозможное возможно... :acute:

При этих словах просто необходимо давать ссылку



#105198 поиск битых ссылок

Отправлено автор: LeshaL 04 мая 2012 - 21:50 в Автоматизированное тестирование



сам искал такое.
Если найдете, сообщите пожалуйста.

Ничего вы не искали.
Вот пример поиска: http://software-test...ch&fromsearch=1
А вот то, что я рекомендую, чем пользовался 7 лет: http://software-test...ch&fromsearch=1 (но есть недостатки).
Ну и конечно есть linkchecker который мне же на этом форуме и посоветовали.

Ок. Спасибо. Только поправьте первые две ссылки.
Linklint - не староват? как понимаю, вы им пользуетесь?
A xenu хорошь тем, что в virtualbox работает с куками IE, а у нас внутренние порталы с авторизацией.

Ссылки не поправляются ибо мудрые создатели IPBoard-а считают, что давать ссылку на результаты поиска никому не надо. Я уже отредактировал коммент.

linklint староват. Сейчас уже ничем не пользуюсь, но для наших целей на прошлой моей работе его хватало (API Javadoc тестировать). У нас его кто-то немного допиливал самостоятельно и много он не умеет (например https). Смотря для чего надо.

А linkchecker поумнее.



#93070 Что считать багом?

Отправлено автор: LeshaL 23 августа 2011 - 19:51 в Тест-дизайн и ручное тестирование

Просто в случае, который я описала для исправления бага нужно было потратить много времени и перелопатить всё фичу. Поэтому решили, что дешевле оставить так (реальный пользователь всё равно врядли наткнётся).
А вообще (по моим наблюдениям) отношение программистов "мне лень чинить" идёт не от них, а от руководителей. Если руководитель относится к найденной проблеме: "ой, это не важно, всё равно в реальной ситуации на это не наступят" - это передаётся программистам. И потом начинается: "я не буду чинить, пока это кастомер не найдёт" и т.п. Но это уже совсем другая история.

Конечно, случаи разные бывают. Но из описания понятно, что баг не исчез, а остался. Меня-то это зацепило.
И сделать сообщение об ошибке, в случае если exception ожидаем ничего не стоит. Абсолютно. 5 минут фикс + 25 тестирование программистом, если конечно в программе вообще есть унифицированный механизм сообщения об ошибках.
Пользователю, в подавляющем большинстве случаев exception ничего не скажет, но сообщение вида "Ошибка возникла потому, что вы нажали сюда, а потом сюда. Так делать нельзя. Сначала надо нажать туда, а потом сюда" - скажет. И это решит проблему. Повторюсь. Это ничего не стоит и нормальный программист сможет легко найти путь исправления, и убедить руководителя, что 30 минут его времени будет потрачено не зря.



#94240 Чем отличаются методы, технологии и техники тестирования?

Отправлено автор: LeshaL 16 сентября 2011 - 04:24 в Тест-дизайн и ручное тестирование

Вопрос актуальный в контексте собеседования тестировщика.
Я придерживаюсь такой позиции, что не важно как называть эти вещи, главное, чтобы человек умел их применять.
Но иногда сталкиваюсь с ситуацией, когда нужно просто знать точное определение.
Какой, например, должен быть ответ на вопрос "Перечислите методы тестирования, которые вы знаете?"
На сколько я понимаю, методы - это более широкое понятие. Типа метод "белого" и "черного ящика". Техники - это подходы в рамках какого-то метода. Типа Equivalence partitioning и Boundary-value analysis. Технологии - просто слово из рефератов и резюме.
Поправьте, если я ошибаюсь.

Похожего вопроса касались вот тут: http://software-test...9272#entry49272



#100489 Уровень абстракции тестов

Отправлено автор: LeshaL 05 февраля 2012 - 17:15 в Автоматизированное тестирование

...

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

Что касается ваших примеров:
1. Изменились параметры корректного пользователя
Есть (или будут) такие тесты, которые это проверяют. Поэтому весьма штатная ситуация, предусмотренная реализацией типа User. Для всех трех вариантов тестов это не проблема. Наверное следует отметить, что в данном случае объект User - это не объект пользователя, зарегистрированного в системе, а некий тестовый субъект решивший зарегистрироваться или залогиниться в систему.

2. Изменилась форма логина: нужно ввести дополнительный код (инвайт)
Тут два подхода. Наиболее логичным, на мой взгляд, является изменение типа User, у которого помимо атрибутов "имя" и "пароль" будет еще и "инвайт", т.к. этот "инвайт" также является объектом для написания нескольких тестов.
Второй подход - это создание отдельного типа Invite, который в паре с пользователем будет передаваться в метод login. Можно написать два метода login(User u) и login(User u, Invite in), сохраняя неизменными те тесты, где нам неинтересно значение поля Invite. Очевидно, что первый укороченный вариант метода login будет только создавать внутри правильный Invite и вызывать второй метод, как это обычно и делается. Здесь третий вариант проигрывает, т.к. не имеет отдельного метода и возникнет необходимость менять все тесты на эту функциональность.

3. Изменилась проверка того, что пользователь успешно залогинился
Здесь вообще следует отметить, что на практике (при тестировании других объектов) зачастую возникает необходимость делать одинаковые проверки в разных тестах и логично при этом все такие проверки (asserts) выносятся в приватный метод внутри тестового класса. Поэтому, что в первом, что в 3м варианте все-равно будет метод checkIsLoggedIn, в который и надо будет внести изменения. Во втором варианте тестов этот метод принадлежит не тесту, а типу User.



#100162 Уровень абстракции тестов

Отправлено автор: LeshaL 29 января 2012 - 18:47 в Автоматизированное тестирование

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

Пишу селениумные тесты. Скажите плз, какой из вариантов на ваш взгляд выглядит лучше и будет более удобен на практике (и для написания тестов и для их поддержки). Учтите, что тесты пишутся в среде, где все умеют так или иначе программировать.
=============
http://pastebin.com/Wc6K4z4K
=============
1) 1й вариант - то что есть сейчас. Требует компромисса между скоростью написания и читабельностью. Неплохо приспособлен к изменениям, но требует определенных затрат на это.
2) 2й вариант требует затрат на фреймворк, без выигрыша по скорости написания, но с превосходной читабельностью и замечательной реакцией на изменения.
3) 3й вариант - почти "сырой" - т.е. почти никакой не нужен фреймворк и достаточно быстрое написание тестов. Но никакая читабельность и солидные затраты на изменения.

----
На данный момент все подходы применимы, некоторые в экспериментальном варианте. Нужно выбрать. Прошу мнений.
Есть еще подвариант второго варианта
http://pastebin.com/kDf6e9xh

Вообще второй вариант задуман для отвязки проверок от используемого фрейворка (junit, testng etc) и ради возможности следить за тем, чтобы не было тестов без проверок и еще ради возможности найти все ошибки сразу, а не падать на первом же ассерте. Хотя при написание тестов и проверок требует больших затрат.



#100548 Уровень абстракции тестов

Отправлено автор: LeshaL 06 февраля 2012 - 12:43 в Автоматизированное тестирование

Если вам нужно писать тесты на workflow, пишите машину, которая будет уметь генерировать workflow, а не проходить один и тот же сценарий из раза в раз.

Интересная идея, надо обдумать. Хотя она не отменяет прохождение по специфицированным (читай acceptance) сценариям. А тестирование сценариев, конечно же, не отменяет функционального тестирования.



#100600 Уровень абстракции тестов

Отправлено автор: LeshaL 07 февраля 2012 - 05:41 в Автоматизированное тестирование


Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)
1) PreCommitTests - маленький набор, поддерживаемый в "зеленом" состоянии программистами и ими же используемый перед комитом.


Жутко интересно, как вы ограничили размер набора. Выбрали самое важное что укладывается в n минут? GUI тесты имеют свойство идти долго. Если не секрет, сколько идет этот зеленый набор?

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



#100165 Уровень абстракции тестов

Отправлено автор: LeshaL 29 января 2012 - 20:30 в Автоматизированное тестирование

Скорость написания в третьем случае иллюзорна - быстро будет написан первый тест(пока вилларибо пишет фреймворк, виллабаджо наклепала 3 теста), потом копипаст утянет в пучину.
Первый вариант кстати лично меня отталкивает лишь наличием приведения - из-за снижения читабельности и рассеивания внимания +)
Второй вариант конечно заманчив - но решительность при выборе в его пользу зависит от сложности системы в целом.
Я бы начал со второго варианта, но не слишком бы убивался пытаясь придерживаться его - написал бы некоторое кол-во разноплановых тестов, а потом бы уж точно определился со стилем. Да и вообще бы на первых порах написания фреймворка не советовал наращивать "критическую массу" тестов.

В первом варианте приведения вроде можно избежать, как сделать я придумал только вот сейчас отвечая на вопрос. Завтра попробую. Да и возникают они только после метода open общего для всех страниц. А метод используется редко сам по себе.
Ну и конечно его можно избежать, разбив на две строки. Такова уж неповоротливая джава.
И так и есть, пока есть представители всех 3х вариантов тестов. 3й я стараюсь переводить в первый. Второй экспериментальный, сделал на выходных и пока не советовался с программистами, насколько он им будет удобен. В том-то и дело, что он заманчивый (с точки зрения тестировщика), но есть некоторые моменты, которые меня смущают.



#100549 Уровень абстракции тестов

Отправлено автор: LeshaL 06 февраля 2012 - 12:53 в Автоматизированное тестирование

Походу можно новую тему открывать :) про уровни автоматизации тестирования :)

Только что обсуждали эти уровни с коллегами. Сошлись для начала на 3х (это для GUI тестирования только)
1) PreCommitTests - маленький набор, поддерживаемый в "зеленом" состоянии программистами и ими же используемый перед комитом.
2) ReqTests - набор тестов написанных по спеке, покрывающий как отдельные функциональные требования, так и описанные сценарии. Второе в будущем может трансформироваться в отдельный Acceptance Tests
3) OtherTests - тесты с разными наборами данных, негативные тесты (неописанные в спеке) и прочие тесты (например необходимые для воспроизведения дефекта и его верификации).

Если решим запускать в CI после каждого комита какие-то тесты, то вероятно появится еще поднабор, состоящий из 1 и части 2.
Понятно, что один тест может входить в несколько тестовых наборов.



#100502 Уровень абстракции тестов

Отправлено автор: LeshaL 06 февраля 2012 - 06:14 в Автоматизированное тестирование

№2 еще бы допилить, чтобы ассерты были только в одном тесте, ну и в идеале - один ассерт = один тест.

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

В моих тестах будет столько проверок, сколько требуется. Я буду проверять прекондишены перед запуском основного действия, например для уменьшении времени при неуспешном выполнении подготовительного действия. Более того, далее стоит задача покрывать сценарии, описанные в спеке, т.е. там сделал действие, проверил, сделал, проверил итд в одном тесте.
Или вот например:
.doLogout()
      .checkLoggedIn(false)
      .checkLoggedOut(true);
имеет две проверки после действия. Можно сделать одну, так чтобы второй метод вызывал первый и в данном случае это прокатит, но в другом случае будет сложнее не запутаться, чем вызвать несколько проверок.

Честно говоря я большой непоклонник слепого следования сомнительным "бест практисам".



#100491 Уровень абстракции тестов

Отправлено автор: LeshaL 05 февраля 2012 - 18:06 в Автоматизированное тестирование

По результатам общения и размышлений пришел к выводу, что надо реализовывать вариант №2.
Объясню почему.
1) Он дает возможность более просто писать тесты, оперирующие с разными наборами данных, но с примерно одинаковым алгоритмом действий.
2) Оперирует объектами бизнес логики приложения отдаляясь от конкретной реализации страниц. Страницы же отвечают за предоставление информации об элементах и их содержимом.
3) При реализации этого подхода, вариант №1 остается доступным.
4) Более просто проследить сценарии, описанные в спецификациях.
5) Позволяет более "чисто" писать именно сценарные тесты с несколькими проверками по ходу дела и оперирующими несколькими объектами (а не только пользователем, как в примере).
6) Даёт простую возможность переиспользовать методы объектов как предварительные акции и без всяких изменений. Надо только убрать методы "checkXXX".
7) Очень важно то, что он даёт возможность следить за тем, чтобы в методах был бы вызван хоть раз хоть один check, в отличие от стандартного unit теста, который будет пройден, даже если в нём нет ни одной проверки.
8) Позволяет использовать проверки неоднократно (не в рамках одного теста, а "шарить" их между разными тестовыми классами).
9) Позволяет проверить результат всех проверок (asserts) в тесте, в отличие от junit, где падение происходит на первой же проверке. Очень удобно при отладке тестов.
10) Позволяет делать негативные проверки без перехвата AssertError (или что там используется) в каждом тесте, где есть такая необходимость.

Что касается возможности вешать дополнительные asserts, то она ровно такая же как и в первом варианте.
Что касается сложности отладки или поиска неисправности во втором варианте - зависит от того как выдаётся информация при ошибке.
Что касается того, что все перевести на вариант №2 не получится, ну и ладно. Вариант №1 меня тоже устраивает, а вариант №3 при появлении будет переводиться в вариант №1 или №2. Вообще оптимальным при написании нового теста кажется такая последовательность: пишется тест в варианте №3 (можно опустить) и потом переделывается в №1, при появлении большего количества тестов на данную функциональность всё рефакторится к виду №2.



#105228 Тюнинг firefox

Отправлено автор: LeshaL 05 мая 2012 - 20:48 в Selenium - Functional Testing

1) Уменьшить кол-во тестов, чтобы они проходили за час. Сделать разбивку на тестовые наборы. Остальные тесты, которые не успевают пройти за час запускать отдельно. Например ночью.
2) Использовать Хром. По моим ощущениям он самый быстрый.
3) Уменьшить количество перестартовок браузера, если таковые есть.
4) Уменьшить размер базы, гонять "часовые" тесты на эталонных данных. Тесты на расширенном наборе данных запускать ночью.
5) Избавиться от дублирующихся тестов, если таковые есть. Убрать большинство негативных проверок в другой тестовый набор.
6) Переиспользовать данные, созданные другими тестами, если они удовлетворяют условиям, но не полагаться на то, что они там уже есть.
7) Отказаться в большинстве тестов от селениума и тестировать не через UI.



#95162 Тестировщик реальности

Отправлено автор: LeshaL 05 октября 2011 - 08:24 в Свободное общение

Страницы не существует..

Вас не смущает, что прошло 8 лет?



#107091 Тестировщик и фриланс (или удаленная работа)

Отправлено автор: LeshaL 25 июня 2012 - 21:19 в Личный рост, карьера, развитие

Когда-то сам копал в эту сторону и пришел к выводу, что оно того не стоит. Почти везде, где нужно серьёзное тестирование (и как следствие приличные зп) невозможно впринципе тестировать из дома.

Неправда ваша. У меня среди знакомых есть обратные примеры.



#96410 Тестирование файловой системы

Отправлено автор: LeshaL 31 октября 2011 - 12:37 в Тест-дизайн и ручное тестирование

Если у кого-то есть опыт тестирования файловой системы, поделитесь пожалуйста.
Интересует подход к тестированию (что именно вы тестировали, как тестировали, какие tools использовали).
Может есть чек-лист того, что проверяли?
Какие были трудности, нюансы? В общем, инетересует любая информация ))
Спасибо!

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

Вообще, файловую систему никто с чеклистами тестировать не будет. Пишут много-много-много автотестов.



#100493 Тестирование использования пропускной способности канала

Отправлено автор: LeshaL 05 февраля 2012 - 18:24 в QA: обеспечение качества

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

А по простому не получится? Если взять определённый набор данных и послать его через канал с известной пропускной способностью, то зная время начала передачи данных и время конца передачи, можно вычислить и реальную скорость передачи, которую можно сравнить с пропускной способностью.



#95997 Статья про Кодировки

Отправлено автор: LeshaL 23 октября 2011 - 16:26 в Про тестирование обо всём подряд


Вопрос в том есть ли нужда у других тестировщиков знать что-то о кодировках?
Если есть то может что-то конкретное можете сказать?

Артем, отличная идея! Конечно, интересно знать про кодировки, чем больше, тем лучше.
Мне все интересно, особенно, если упорядочено, логично, можно хоть от истоков начинать. ASCI, Unicode, разница кириллическх кодировок. нструменты по преобразованию, как тестировать. Редкие и специальне кодировки, про которые стоит знать тестировщикам.
В общем, пишите, будет полезно!

Поддерживаю, будет интересно. Мы кодировки тестируем, точнее тестируем с использованием различных кодировок.



#95538 Создание вебинара

Отправлено автор: LeshaL 14 октября 2011 - 21:31 в Свободное общение

1. Если вам нравится визио или в нем хорошо выходит рисуйте в Visio! Но нужен инструмент для создания презентаций. Т.к. PowerPoint стоит денег (правда кого это в России волнует) я советую бесплатный libre office impress (http://www.libreoffice.org/download). Копируете картинку из визио, вставляете в слайд.
Учтите, на слайдах все должно быть крупным. Мелкие, детализированные диаграммы из визио могут стать абсолютно неразборчивыми и скучными.

2. Если вы выступаете первый раз - не надо никакого интерактива. Просто расскажите и ответьте на вопросы.

3. Я свои выступления на конференциях всегда и репетирую и "тестирую" на коллегах. Они дают дополнительную пищу для размышлений, находят опечатки итд. Очень полезно.

4. Если хотите сделать слайдкаст, то slideshare.net вам поможет. Регистрируетесь, загружаете слайды, загружаете звуковую дорожку доклада и синхронизируете слайды со звуком. Все очень просто. Потом можно поделиться с кем угодно.
Можно выложить отдельно звук и слайды, но это хуже. А еще хуже делают люди, неуважающие слушателей - они выкладывают на slideshare слайды и звук и не синхронизируют. Не делайте никогда так.

5. Если хотите провести вебинар, то подумайте ... и не делайте. Судя по всему опыта в этом деле у вас нет. Шансы на то, что получится сделать "живой" вебинар малы. Люди злые и если у вас будут накладки, то сделаете себе антирекламу. Запишите лучше для начала "оффлайн" презентацию со звуком. Разошлите знакомым. Анонсируйте тут на форуме.

И еще, а из какого вы города? Уже много где есть сообщества тестировщиков, можно договориться с организаторами и выступить на одной из встреч (если у вас в городе оно есть, а если нет - то кто мешает создать? Опытом создания готовы делиться). Лучше начинать с "живых" презентаций, когда видны глаза слушателей и есть обратная связь.



#93466 С чего начинать изучать тестирование с нуля! Помогите ПЛИЗ!

Отправлено автор: LeshaL 30 августа 2011 - 21:19 в Личный рост, карьера, развитие

Еще хотел спросить, входит ли в обязанности тестировщика исправление ошибки, на уровне исходников программы, в моем случае или это зависит от организации и предъявляемым требованиям?

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

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

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



#104872 Процесс найма сотрудника со стороны работодателя

Отправлено автор: LeshaL 25 апреля 2012 - 21:22 в Про тестирование обо всём подряд

Добрый день!
Во-первых, хочу поддержать ребят, которые говорят о том, что тестовое задание надо давать хотя бы после интервью, а не до него. Причин несколько, думаю они будут понятны из написанного ниже. Я бы предложил такую схему:
Изучение резюме и телефонный скрининг (для определения того, что человек хочет выполнять предлагаемую работу в принципе) -> техническое собеседование (лучше когда несколько человек, всей командой не обязательно, не все любят) -> тестовое задание (опционально, в них есть несомненные плюсы) -> второе интервью для определения условий итд (желательно с руководством) -> офер (для победителя).

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

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



#93461 Проверка поля ввода email.

Отправлено автор: LeshaL 30 августа 2011 - 20:43 в Тест-дизайн и ручное тестирование

Только я вот не пойму, почему на всех емейл сервисах, которые я нашел, нет подчинения этим стандартам. По-че-му? Может плохо искал? Могу предположить, что уменьшение количества символов в логине сделано для оптимизации размеров баз данных. А символы причем? Может следует изменить эти стандарты? Как же тогда производить тестирование или даже как кодировать? Выбрать самый требовательный к адресам сервис и по нему ориентироваться? И я так понимаю, что если какая-то форма не пропускает некоторые валидные емейлы из-за недопустимости адреса, то это не баг?

Интересно, сколько раз надо написать одно и тоже...
RFC - стандарт. Если вы пишете почтовый сервер - будьте добры, соблюдать все это.
Если ваша веб-програмулька не понимает всех возможных вариантов почтовых адресов - то это ХОРОШО!
В этом случае ваша программа не протеворечит этому стандарту. Но в ней будет меньше кода, и меньше ошибок, от исправления которых не станет лучше ни одному живому существу на планете.

Да и это нафиг никому не нужно, поддерживать все эти возможные адреса. И если найдется идиот с ненормальным адресом в 64 символа (или сколько их там) на домене второго уровня - то пусть он идет лесом мимо вашей программы со своим адресом.

Если вы не тестируете почтовый сервер (ну и возможно клиент тоже) - то использование всяких экзотических емэйлов - (а) трата времени и (б) создание ненужных записей в трэкере. Если бы я был программистом и ко мне бы пришли и сказали "first.(")middle.last(")@[IPv6:::12.34.56.78]" - не работает, согласно RFC, давай чинить. Я бы послал куда подальше.

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

PS: кстати [IPv6:::12.34.56.78] - нихрена невалидный Ipv6 адрес - очередной булшит



#103693 Приблизительная оценка времени, отведенного на тестирование

Отправлено автор: LeshaL 07 апреля 2012 - 05:07 в Начинающему тестировщику

...
На ручное тестирование времени примерно надо в два раза меньше чем на реализацию этой фичи.

Леша, интересный подход. Надо бы посмотреть реально ли так. Хотя мне почему-то кажется, что реализация все-таки больше в % соотношении должна занимать (даже без учета багфиксов).

Автору топика.
На абстрактную фичу на тестирование затратится абстрактное время. Никакого более конкретного ответа дать нельзя. Могу дать совет, когда оцениваете время, прибавляйте время на написание багов, отчетов и верификацию быстро починенных дефектов. Это отнимает значительное время. Если не написана тестовая документация - то время на планирование тестирования тоже прибавляйте.
Если у вас есть готовый чеклист или набор тесткейзов, то оценить время будет проще.

А вообще прав Майкл Болтон. Он говорит, что суммарное время на тестирование оценить очень просто. Например, если сегодня 7 апреля, а релиз назначен на 21 апреля, то у вас есть ровно 2 недели на тестирование. Все.
И вы не должны приходить и говорить начальству, что я за 2 недели не успею, мне нужно 4 по моим подсчетам. А вы должны сказать, по моим подсчетам нужно 4 недели, за 2 недели мы протестируем это и это, а то и се только поверхностно. При этом есть такие-то риски. Устраивает? И пусть начальство дальше думает.



#107086 Помогите сделать красиво

Отправлено автор: LeshaL 25 июня 2012 - 20:13 в Selenium - Functional Testing

Здравствуйте.
Решил использовать "по науке" pageobject и столкнулся с проблемой. Есть у меня отдельно класс какой-либо страницы и класс проверок. Отдельно конечно же существует класс с тест-кейсами и вот тут-то у меня загвоздка, наверное, от плохого знания Явы. Так вот проблема в следующем.
MainWindow mainwndw = new MainWindow(driveк)
mainwndw.buttonclick(mainwndw.submit);

В константах у класса страниц хранятся xpath к элементам на этих страницах, а как же тогда к ним обращаться из тест-кейсов и проверок, неужели только через mainwndw.submit? Нельзя ли это сделать красивей как-то? Спасибо.

Не очень понятно в чем вопрос. Напишите, что вы хотите сделать. Что такое MainWindow?
Почитайте про PageFactory - на мой взгляд использование PageObject без PageFactory - это полумера.
PS: и еще, хоть к делу не относится, почитайте про java code style и название локальных переменных. mainwndw это не по джавовски.



#93464 Помогите пож.определиться с тест-кейсами

Отправлено автор: LeshaL 30 августа 2011 - 21:04 в Тест-дизайн и ручное тестирование

если вводишь верно имя, фамилию и дату рожд. НЕуникального пользователя (Петров Петр 03.03.1993) программа выдает ERROR

По мне так это ошибка в программе - должно логинить