Робоче...
Коли приходить усвідомлення, що твоя робота, то суцільне навчання, причому весь час, бо на роботі ти вивчаєш нові вимоги, нові рішення, а поза роботою ти вчишся працювати, вчишся як швидше, якісніше, грунтовніше все то робити...
Весь чась щось читаєш, дивишся, вивчаєш і в тому суцільному потоці легко загубитися...
Мені порадили зберігати цікаві статті та віде в одному місці, але як виявилось, це місце явно не закладки в браузері,бо їх рідко переглядаєш і стає багато, що не зручно, тоже сьогодні вирішила зробити щось типу огляду для себе, що з відео дуже сподобалось і на чому акцентувала свою увагу...
1.Сергей Мартыненко. Написание тестов, как вид тестирования требований
http://vimeo.com/13803733
Презентувалось це відео ніби-то для аналітиків, але в силу суміщення ролей тестувальник часто буває аналітиком, а ще чомусь майже всі забувають, що всі метри тестування кажуть, що цей процес требо починати якумого раніше, на етапі збору та аналізу вимог замовника, ТЕСТУВАННЯ ВИМОГ...
Отже основне, що я винисла і що часто забувається нами це що кожний елемент який має свій цикл життя і якщо щось з'являетьтся в системі, то вона має якось туди потрапляти, має щось з ним відбуватись і має кудись зникати чи має переходити в якийсь стан і десь зберігатись. ЦЕ ДУЖЕ ГАРНИЙ СПОСІБ АНАЛІЗУВАТИ ТЗ, ми часто забуваємо про цей для дрібних елементів, але в цілому вони значно навантажують систему своєю присутністю... більш детально і багато всього іншого,цікавого девіться у відео...
2.Коли вже заговорили про навантаження, то хочеться згадати Марина Широчкина, «Нагрузочное тестирование с точки зрения тестирования»
http://www.slideshare.net/spbsqagroup/ss-8254881
Говорячи про навантаження, особливо з замовником, найчастіше йде мова чомусь про кількість користувачів і досить рідко про навантаження данними, на мою думку в цьому відео досить різнопланово розглянуте навантажувальне тестування, йде мова й про метрики. В усіх проектах, яких я працювала, їх щобравда було не так багато, десь біля 5, тестування використовувалось досить однобоко, ми ніколи не аналізували кількість ітерацій, кількість знайдених багів і взагалі якість роботи, говорячи про процес створення продукту і покращення його якості, чомусь найчастіще говоримо про артефакти, про недоліки планування, недосконалість багтрекінгових систем, недостатність кадрій, вимог і все інше й ніби то геть не доходимо, до якості самої роботи, якості написання багів, швидкості реакції, складається враження, що ми знаходимось ще на дуже і дуже низькому рівні розвитку процессів створення. Цікаво, що таку систему,як bebugging говорили ще в 1970 роках, та ми ще й досі не звикнемо її використовувати...http://en.wikipedia.org/wiki/Bebugging
3. Тож про якість роботи почну з відео, коротенького 20 хв, але на мій погляд цікавого з точки розу питання оцінювання якості роботи тестувальників.
ConfeT&QA: Способы оценки эффективности тестирования, Наталья Руколь
http://software-testing.ru/library/around-testing/management/1494-confetqa-rukol
тут йде мова про оцінювання саме роботи тестувальників. Для мене критерієм оцінки є лише приймальне тистування, останнім часом помітна тенденція приймання тестувальником з боку замовника і лише після цього фінальне приймання користувачем, що дуже корисне, також виступає оцінкою якость роботи тестувальника. Хоча треба зазначити, що всі ми люди і трактуємо багато чого по своєму, сприймаємо одні й те ж по різному.
Чесно на нове місце, трошки огидно дивитись на ті тест плани,які доводиться узгоджувати, але ламати встановлені традиції дуже важко і не мені вчити Менеджера тестувальників, як писати тест плани, хоча дуже хочеться, або просто нагадати, що існує купа стандартів і всього іншого, що нам не треба вигадувати велосипед,просто треба докласти трохи зусиль і скласти пристойний документ,як шаблон,який надалі, кочуватиме і доповнюватиметься.
4.Нажаль я не склала іспит з ISTQB, але в одній з статей в процессі навчання і після нього побачила цікаву фразу - "навіть якщо не складати іспит...завдячуючи цьому іспиту,я принайні маю словничок в якомі можу подивитися терміни"...
http://istqb.org/display/ISTQB/Glossary
Мені теж дуже хочеться, щоб бага хто подивився в цей словник і усвідомив, що
re-testing: Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions. тоді як
regression testing: Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.
Ітак, маємо 2 різні поняття, які не треба плутати і коли вас просять зробити ретест, кейсу, що явно був не пройдений або у зв'язку зі зміною вимо і не зміною кейсів, зара явно помилковий, то не треба тестувати все заново, а треба просто пройти саме цей кейс, що явно менше за часом. Можливо в моїй голові живе сунмівне розуміння, але коли ми говоримо про перевірку пофіксених багів, ми не завжди робимо регресійне тестування, найчастіше ми робимо ретест,а тоді вже вирішуємо чи варто продовжити до регресу, якщо перевіряючи баг в нас відтворюється, то ми далі не копаємо,а навіщо, в нас зачасту є ще недотестований функціонал або ще якась купка роботи і ми повернемось до цього функціоналу, коли дефект буде усунено. Можливо моя думка є хибною, але вона має право на існування... на закуску, щось приэмне для прочитання http://alexeybulat.blogspot.com/2011/10/blog-post.html
Отож, це ті основні речі, які не займуть багато часу,але є потрібними і цікавими для роботи. Сподіваюсь, хоча б для себе продовжу складати в одне місце корисні посилання...
Весь чась щось читаєш, дивишся, вивчаєш і в тому суцільному потоці легко загубитися...
Мені порадили зберігати цікаві статті та віде в одному місці, але як виявилось, це місце явно не закладки в браузері,бо їх рідко переглядаєш і стає багато, що не зручно, тоже сьогодні вирішила зробити щось типу огляду для себе, що з відео дуже сподобалось і на чому акцентувала свою увагу...
1.Сергей Мартыненко. Написание тестов, как вид тестирования требований
http://vimeo.com/13803733
Презентувалось це відео ніби-то для аналітиків, але в силу суміщення ролей тестувальник часто буває аналітиком, а ще чомусь майже всі забувають, що всі метри тестування кажуть, що цей процес требо починати якумого раніше, на етапі збору та аналізу вимог замовника, ТЕСТУВАННЯ ВИМОГ...
Отже основне, що я винисла і що часто забувається нами це що кожний елемент який має свій цикл життя і якщо щось з'являетьтся в системі, то вона має якось туди потрапляти, має щось з ним відбуватись і має кудись зникати чи має переходити в якийсь стан і десь зберігатись. ЦЕ ДУЖЕ ГАРНИЙ СПОСІБ АНАЛІЗУВАТИ ТЗ, ми часто забуваємо про цей для дрібних елементів, але в цілому вони значно навантажують систему своєю присутністю... більш детально і багато всього іншого,цікавого девіться у відео...
2.Коли вже заговорили про навантаження, то хочеться згадати Марина Широчкина, «Нагрузочное тестирование с точки зрения тестирования»
http://www.slideshare.net/spbsqagroup/ss-8254881
Говорячи про навантаження, особливо з замовником, найчастіше йде мова чомусь про кількість користувачів і досить рідко про навантаження данними, на мою думку в цьому відео досить різнопланово розглянуте навантажувальне тестування, йде мова й про метрики. В усіх проектах, яких я працювала, їх щобравда було не так багато, десь біля 5, тестування використовувалось досить однобоко, ми ніколи не аналізували кількість ітерацій, кількість знайдених багів і взагалі якість роботи, говорячи про процес створення продукту і покращення його якості, чомусь найчастіще говоримо про артефакти, про недоліки планування, недосконалість багтрекінгових систем, недостатність кадрій, вимог і все інше й ніби то геть не доходимо, до якості самої роботи, якості написання багів, швидкості реакції, складається враження, що ми знаходимось ще на дуже і дуже низькому рівні розвитку процессів створення. Цікаво, що таку систему,як bebugging говорили ще в 1970 роках, та ми ще й досі не звикнемо її використовувати...http://en.wikipedia.org/wiki/Bebugging
3. Тож про якість роботи почну з відео, коротенького 20 хв, але на мій погляд цікавого з точки розу питання оцінювання якості роботи тестувальників.
ConfeT&QA: Способы оценки эффективности тестирования, Наталья Руколь
http://software-testing.ru/library/around-testing/management/1494-confetqa-rukol
тут йде мова про оцінювання саме роботи тестувальників. Для мене критерієм оцінки є лише приймальне тистування, останнім часом помітна тенденція приймання тестувальником з боку замовника і лише після цього фінальне приймання користувачем, що дуже корисне, також виступає оцінкою якость роботи тестувальника. Хоча треба зазначити, що всі ми люди і трактуємо багато чого по своєму, сприймаємо одні й те ж по різному.
Чесно на нове місце, трошки огидно дивитись на ті тест плани,які доводиться узгоджувати, але ламати встановлені традиції дуже важко і не мені вчити Менеджера тестувальників, як писати тест плани, хоча дуже хочеться, або просто нагадати, що існує купа стандартів і всього іншого, що нам не треба вигадувати велосипед,просто треба докласти трохи зусиль і скласти пристойний документ,як шаблон,який надалі, кочуватиме і доповнюватиметься.
4.Нажаль я не склала іспит з ISTQB, але в одній з статей в процессі навчання і після нього побачила цікаву фразу - "навіть якщо не складати іспит...завдячуючи цьому іспиту,я принайні маю словничок в якомі можу подивитися терміни"...
http://istqb.org/display/ISTQB/Glossary
Мені теж дуже хочеться, щоб бага хто подивився в цей словник і усвідомив, що
re-testing: Testing that runs test cases that failed the last time they were run, in order to verify the success of corrective actions. тоді як
regression testing: Testing of a previously tested program following modification to ensure that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made. It is performed when the software or its environment is changed.
Ітак, маємо 2 різні поняття, які не треба плутати і коли вас просять зробити ретест, кейсу, що явно був не пройдений або у зв'язку зі зміною вимо і не зміною кейсів, зара явно помилковий, то не треба тестувати все заново, а треба просто пройти саме цей кейс, що явно менше за часом. Можливо в моїй голові живе сунмівне розуміння, але коли ми говоримо про перевірку пофіксених багів, ми не завжди робимо регресійне тестування, найчастіше ми робимо ретест,а тоді вже вирішуємо чи варто продовжити до регресу, якщо перевіряючи баг в нас відтворюється, то ми далі не копаємо,а навіщо, в нас зачасту є ще недотестований функціонал або ще якась купка роботи і ми повернемось до цього функціоналу, коли дефект буде усунено. Можливо моя думка є хибною, але вона має право на існування... на закуску, щось приэмне для прочитання http://alexeybulat.blogspot.com/2011/10/blog-post.html
Отож, це ті основні речі, які не займуть багато часу,але є потрібними і цікавими для роботи. Сподіваюсь, хоча б для себе продовжу складати в одне місце корисні посилання...