Я обещалась сделать тему по тестированию безопасности сайтов по прочтении гайда от QWASP'а, но я все еще в процессе. Что бы начать излагать хотя бы отдельные главы мне нужно дочитать хотя бы первый раз целиком до конца и это движется, но медленно. Тупо переводить дело гиблое, я застряну сразу, а вот начать вольный пересказ - вполне по силам имхо. Осилила уже половину и в скором времени надеюсь уже начать излагать по кусочкам. Не переключайтесь, у меня обширный дополнительный материал :)
четверг, 20 марта 2014 г.
вторник, 21 января 2014 г.
В идеальном мире: мифология тестирования
Чем хороший специалист отличается от плохого? Почему платные клиники по большей части бесполезны? Чем так смешит фраза: "Вы не даете нам тестировать!" - читайте в рубрике "монологи о профессионализме".
Итак, тут я делала акцент на том факте, что тестирование - это не столько поиск багов. Задача тестировщика в бОльшей степени состоит как раз в понимании этой простой истины, и только потом уже - в ее реализации. Хотя на практике все происходит наоборот, т.к. нельзя натянуть теорию на голое место. Теория - это концентрированный опыт, а концентрат в голом виде либо бесполезен, либо вообще опасен, его нужно добавлять во что-то, нужна основа. И этим "что-то" служит практика тестирования, опыт проверок, изучение процесса и анализ повторяющихся ситуаций. Нельзя просто так взять, почитать теорию и думать, что знаешь как это устроено. Сдача на сертификат, как и любой экзамен, часто дает ложноположительный результат: признаками положительного служит тот факт, что человек рассказывает теорию (повторяет слова), а отрицательным фактом является то, что он не понимает сути этих слов. И надежного и унифицированного способа выяснить это понимание не существует. Все мы помним зубрил, которым незаслуженно ставили "отлично", но последствия ложного оценивания на единичных экзаменах (не все преподаватели любят зубрил) не так губительны, как выдача сертификата специалисту, который на самом деле не является таковым. Хотя конечно несмертельно, тем более с учетом того факта, что работодатель может довольно быстро проверить насколько знания теории соответствуют умениям (зазубрены они или есть понимание применения).
Но вернемся к основной задаче и важности ее понимания. Во второй половине 70х подход к тестированию заключался именно в поиске как можно большего кол-ва багов и мне кажется, что многие тестировщики так и застряли на этом этапе развития. Поиск багов является побочным продуктом деятельности тестировщика, а его прямой задачей является - я прошу прощения за повторы - полный, развернутый отчет о состоянии проекта. Проверить работоспособность каждой части системы в разных условиях. Может быть так, что с основными "обязанностями" отдельная функция справляется, а в какой-то нестандартной ситуации ведет себя не очень хорошо - и тут опять могут быть градации - от простого неудобства для пользователя, до полного отказа, но в столь нестандартном случае, что он практически невозможен. И вот именно в таких случаях - когда тестировщик в одиночку не может оценить целесообразность починки подобных вещей - нужно не кричать: "Чини его!", а просто донести до команды проблему и принять решение. Кстати, оценка последствий починки или не-починки багов, тоже привилегия тестировщика - именно он, зная систему, с большей точностью способен предсказать как именно окончательное решение повлияет на проект. И так по каждому багу практически :) Разумеется, есть вещи, которые видно сразу - оно сломалось и надо чинить, но в этих случаях вопрос о починке даже не стоит - он и так ясен. При таком подходе конфликта с программистами и споров до хрипоты "Баг или фича?!" не возникает вообще.
Так чем же хороший специалист отличается от плохого? Гибкостью подхода. Умением оперировать не шаблонами, а разными, годными, пластичнымишаблонами подходами к проблемам. Не "есть симптом - лечить/чинить, нет - симптома - нет болезни/бага", а "что будет симптомом для данного человека/программы?", "давление в 90/60 может быть нормальным для человека? - да, если он себя при этом прекрасно чувствует" - "у программы ломается интерфейс, если пользователь издевался над ней вводом невалидных данных - баг или пользователь неумный?" и прочие гибкие методологии. Возвращаясь к вопросу о платных клиниках - плохие специалисты, которые получили диплом, просто вызубрив энцикплопедические связки, никогда не смогут подходить к проблеме гибко, а так и будут гонять пациента сдавать анализы и качать головой, вместо того, чтобы подойти к проблеме индивидуально, с анализом бОльшего количества параметров. А наткнуться на такого "специалиста" как в платной, так и в обычной поликлинике, вероятность примерно одинакова. Конечно, это не значит, что в платных клиниках сплошь зубрилы с красными дипломами, это просто замечание, что даже платная клиника не панацея. Найти хорошего врача также трудно, как и любого другого хорошего специалиста.
Ну и к последней части. "Вы не даете нам тестировать!" - почему это смешно. Можете вы представить себе ситуацию, когда, наняв по трезвому и взвешенному размышлению, тестировщиков в команду, им не дают делать свою работу? Да это как купить Porsche с бриллиантовыми стразиками и поставить в гараж потому что "бензин дорогой"! Можно сделать вывод, что если тестировщикам "не дают тестировать", т.е. времени, которое они требуют на проверку билда, то это плохие, негодные тестировщики. Они пытаются не дать оценку проекту, а именно "найти все баги" чтобы прикрыть попу от возможных претензий в последствии. Они живут в идеальном мире, считая себя людьми, которые выносят вердикт "выходить на прод или нет". Но, как я уже говорила, решают это не тестировщики. И ответственность не только на них, так что нет смысла пытаться сначала всю на себя ее перетянуть, а потом думать как бы съехать. Не нужно создавать себе дополнительных сложностей :) Мы живем не в идеальном мире, и это - хорошо!
Итак, тут я делала акцент на том факте, что тестирование - это не
Но вернемся к основной задаче и важности ее понимания. Во второй половине 70х подход к тестированию заключался именно в поиске как можно большего кол-ва багов и мне кажется, что многие тестировщики так и застряли на этом этапе развития. Поиск багов является побочным продуктом деятельности тестировщика, а его прямой задачей является - я прошу прощения за повторы - полный, развернутый отчет о состоянии проекта. Проверить работоспособность каждой части системы в разных условиях. Может быть так, что с основными "обязанностями" отдельная функция справляется, а в какой-то нестандартной ситуации ведет себя не очень хорошо - и тут опять могут быть градации - от простого неудобства для пользователя, до полного отказа, но в столь нестандартном случае, что он практически невозможен. И вот именно в таких случаях - когда тестировщик в одиночку не может оценить целесообразность починки подобных вещей - нужно не кричать: "Чини его!", а просто донести до команды проблему и принять решение. Кстати, оценка последствий починки или не-починки багов, тоже привилегия тестировщика - именно он, зная систему, с большей точностью способен предсказать как именно окончательное решение повлияет на проект. И так по каждому багу практически :) Разумеется, есть вещи, которые видно сразу - оно сломалось и надо чинить, но в этих случаях вопрос о починке даже не стоит - он и так ясен. При таком подходе конфликта с программистами и споров до хрипоты "Баг или фича?!" не возникает вообще.
Так чем же хороший специалист отличается от плохого? Гибкостью подхода. Умением оперировать не шаблонами, а разными, годными, пластичными
Ну и к последней части. "Вы не даете нам тестировать!" - почему это смешно. Можете вы представить себе ситуацию, когда, наняв по трезвому и взвешенному размышлению, тестировщиков в команду, им не дают делать свою работу? Да это как купить Porsche с бриллиантовыми стразиками и поставить в гараж потому что "бензин дорогой"! Можно сделать вывод, что если тестировщикам "не дают тестировать", т.е. времени, которое они требуют на проверку билда, то это плохие, негодные тестировщики. Они пытаются не дать оценку проекту, а именно "найти все баги" чтобы прикрыть попу от возможных претензий в последствии. Они живут в идеальном мире, считая себя людьми, которые выносят вердикт "выходить на прод или нет". Но, как я уже говорила, решают это не тестировщики. И ответственность не только на них, так что нет смысла пытаться сначала всю на себя ее перетянуть, а потом думать как бы съехать. Не нужно создавать себе дополнительных сложностей :) Мы живем не в идеальном мире, и это - хорошо!
понедельник, 30 декабря 2013 г.
тут будет тема по тестированию безопасности сайтов
а пока скидываю линки чтоб не забыть
версия сервера
вторник, 22 октября 2013 г.
Что же делает QA/QC?
Вдогонку к заблуждениям. QC - это не поиск только багов, как уже говорилось ранее, это - предоставление полной информации о состоянии проекта. Сколько раз я читала эту фразу, но только сейчас она выкристализовалась в моем мозгу со всей своей ясностью - протестировать проект - это сделать его полное вскрытие и донести этот разрез до PM'а и/или разработчиков. И QC делает это вскрытие, а QA - показывает где и как резать, чтобы было лучше видно все детали.
пятница, 30 августа 2013 г.
Заметки на полях
Просто интересно - две компании, разработчики игр. На главных страницах - ВНЕЗАПНО - указана одна и та же игра, только у первых на мейле, у вторых - на одкл. С теми же...гм...ляпами. Нет, это не функционал (хотя я глубоко не копала), но в нашей фирме локализация поставлена так, что даже на банке с краской в арте вы не найдете следов английского текста. Т.е. у товарищей либо в куске движка остались англицизмы, либо это было портирование, поделенное между компаниями на 2 сети. Вторая интересная весчь - прикалываются они что ли - у обоих компаний открыты вакансии на QA (на сайтах с работой), но на сайтах собственных в перечне доступных вакансий - ВНЕЗАПНО! - ни у одной компании нет вакансии для QA. Это типа мы так пытаемся сразу определить насколько кандидат пошарился по сайту и нашел "баг" или просто несколько неактуальное состояние вакансий на сайте? У одних есть форма обратной связи - спросила интереса ради почему так - ответа нет. У второй компании даже формы обратной связи нет, только мыло - спрашивать лень. Но все равно интересно.
Еще наблюдизм - по ходу никто не отличает QA от QC - на всех сайтах с работой пишут QA, хотя по факту часто нужен QC. Если говорить о разнице, то QA это больше менеджмент (направление, постановка процесса для QC), а QC - практическая часть (тест-кейсы, выполнение, фиксация ошибок, проверки фиксов, пр). Такие хи-хи. UPD: они реально издеваются - еще одна контора, имеющая вакансию на сайте с работой, но которой нет на сайте (есть все, кроме как на тестировщика).
Еще наблюдизм - по ходу никто не отличает QA от QC - на всех сайтах с работой пишут QA, хотя по факту часто нужен QC. Если говорить о разнице, то QA это больше менеджмент (направление, постановка процесса для QC), а QC - практическая часть (тест-кейсы, выполнение, фиксация ошибок, проверки фиксов, пр). Такие хи-хи. UPD: они реально издеваются - еще одна контора, имеющая вакансию на сайте с работой, но которой нет на сайте (есть все, кроме как на тестировщика).
четверг, 22 августа 2013 г.
Большое заблуждение тестировщиков
Вот кто мне cкажет - что должен делать тестировщик? У 9/10 в голове всплывает "искать баги". Увы, это именно то, что хоронит проекты. Если тестировщик заинтересован только в поиске багов - пиши пропало. Если у него - после туевой хучи уебанных треннингов аля "Как найти удовольствие в работе? - Радоваться найденным багам!" - мозг настроен исключительно на поиск багов - проект либо вообще не будет выпущен, либо будет выпущен поздно (упущенная выгода + потеря лидирующих позиций) и все равно хромой. Поясняю на пальцах
А радоваться надо не найденным багам, а починенным. Если вы радуетесь только найденным - получается, что вам совсем неважно? что ваш проект - хромой, убогий и болезный, да вы именно этому и рады. А если вы радуетесь починкам - значит, вы улучшаете качество вашего продукта, радуетесь его росту, улучшению.
вторник, 2 июля 2013 г.
Свой опыт с Genie
Итак, теперь, когда мы имеем немого представления об инструменте, я попытаюсь рассказать о своем опыте его использования. Что нужно, что бы записать простой скрипт с Geine? Запущенный сервер, Эклипс и зеленый треугольник UT на флешке (не забываем коннектиться к SWFке). Жмем на значок и запись скрипта пошла! При этом значок становится красным квадратом (ВНЕЗАПНО!), при нажатии на кортоый запись, соответственно, прекращается. Но об этом чуть позже.
Если перед записью скрипта мы выбрали в выпадающем меню пункт "Запись с тупняками" (Record Script At Application Pace), то все задержки между кликами будут учтены в скрипте. Запишем что-нибудь самое простецкое, закрытие входных pop-up'ов. Загружаем игру и когда появляется газета, запускаем запись. Покликали, закрыли и остановили. После остановки записи Джин любезно вываливает на окошко с телом скрипта и кнопками "скопировать" и "закрыть" - наше дело сохранить этот скрипт либо в файлик, либо пока прямо в панель Эклипса со скриптами. Получится примерно такое:
где выделенны маркером те самые Genie ID и после них команда click (). Если аргументы click оставлять пустыми, то нажатие будет выполнено без подведения курсора на элемент. Теперь для того, чтобы запустить наш скрипт, нам понадобится сбросить его в текстовый файлик, обозвать его xxx.java (где xxx должен быть такой же, как и Unnamed - не забыть задать имя в теле скрипта), открыть в эклипсе. Если есть ошибки, редактор эклипса их выделит (в готовом скрипте ошибок конечно нет, но при модификации мы вполне можем что-нибудь напортачить). Следующий этап запуска - выбрать пункт Run Configuration... и в открывшемся окне в пункте New configuration во вкладке Arguments вдоме, который построил Джек строке Program Arguments указать перед .class имя скрипта (оно же имя из public class Unnamed extends GenieScript и
{
public Unnamed() throws Exception:
Если перед записью скрипта мы выбрали в выпадающем меню пункт "Запись с тупняками" (Record Script At Application Pace), то все задержки между кликами будут учтены в скрипте. Запишем что-нибудь самое простецкое, закрытие входных pop-up'ов. Загружаем игру и когда появляется газета, запускаем запись. Покликали, закрыли и остановили. После остановки записи Джин любезно вываливает на окошко с телом скрипта и кнопками "скопировать" и "закрыть" - наше дело сохранить этот скрипт либо в файлик, либо пока прямо в панель Эклипса со скриптами. Получится примерно такое:
package scripts;
import com.adobe.genie.genieCom.SWFApp;
import com.adobe.genie.executor.GenieScript;
import com.adobe.genie.executor.components.*;
import com.adobe.genie.executor.uiEvents.*;
import static com.adobe.genie.executor.GenieAssertion.*;
import com.adobe.genie.executor.enums.GenieLogEnums;
/**
* This is a sample Genie script.
*
//Change name of the class
public class Unnamed extends GenieScript {
public Unnamed() throws Exception
{ super();
}
@Override
public void start() throws Exception {
//Turn this on if you want script to exit
//when a step fails
EXIT_ON_FAILURE = false;
//Turn this on if you want a screenshot
//to be captured on a step failure
CAPTURE_SCREENSHOT_ON_FAILURE = false;
SWFApp app1=connectToApp("[object Preloader]");
(new GenieDisplayObject("SP^NewspaperPopup:::FP^NEWSPAPER:::SE^closeBtn::PX^0::PTR^0::IX^9::ITR^0",app1)).click(7,11,704,60,0,0,3,false);
(new GenieMovieClip("SP^MessageWindow:::FP^CloseButton:::SE^htmc::PX^25::PTR^0::IX^1::ITR^0",app1)).click(27,18,740,22,0,0,3,true);
}
}где выделенны маркером те самые Genie ID и после них команда click (). Если аргументы click оставлять пустыми, то нажатие будет выполнено без подведения курсора на элемент. Теперь для того, чтобы запустить наш скрипт, нам понадобится сбросить его в текстовый файлик, обозвать его xxx.java (где xxx должен быть такой же, как и Unnamed - не забыть задать имя в теле скрипта), открыть в эклипсе. Если есть ошибки, редактор эклипса их выделит (в готовом скрипте ошибок конечно нет, но при модификации мы вполне можем что-нибудь напортачить). Следующий этап запуска - выбрать пункт Run Configuration... и в открывшемся окне в пункте New configuration во вкладке Arguments в
{
public Unnamed() throws Exception:
Т.е. если у меня скрипт называется MC, но и в теле скрипта тоже стоит MC и в классе тоже MC. Возможно, для программистов это очевидно, но я в этом объезьяна, как сказали, как написано в документе, так и описываю :) После этого кликаем Run и переходим к нашей флешке. Во время выполнения скрипта значок на SWFке вверху меняется на красный треугольник без фона.
Как видно, сам кусочек с кликами занимает всего ничего - закрыли пару окон, получили пару строчек. Но это если нам нужно сделать всего пару действий, при более сложных задачах конечно конструкции становятся сложнее. К примеру, скрипт на прохождение HOG-сцены включал в себя считывание текста с плашки, сопоставление текста с соответствующим ему объектом и клик уже непосредственно по идентифицированному объекту. Предметов в HOGe у нас от 60 до 75, для каждой сцены приходилось делать такие библиотеки со связками "текст-объект". И тем не менее, скрипт работает! Если бы получилось таки добить остальные куски и соединить их в комплект, у меня был тест, выполняющий максимальное покрытие вширь функционала за минимальное время. Подозреваю, что на этапе соединения тоже были бы свои проблемы, но увы, опыта в этом деле мне обрести пока не удалось.
Подписаться на:
Сообщения (Atom)