jUst QA blog

Hello Migration

Sun, 05 Feb 2023 11:29:14 +0100

Лінощі - двигун прогресу. Визначення, з яким познайомився дуже багато років тому і досі 100% погоджуюсь.

Але зараз маю й друге. Конкуренція - теж двигун прогресу. Це очевидно для бізнесу, для ринку. Але це теж працює на низьких рівнях. Пішли ми до басейну. Коли пливеш на доріжці сам - пливеш аби як. Коли з тобою на доріжці “парочка черепах” - то теж пливеш “аби як”. Але коли тебе починають обганяти “торпеди” (для яких ти є “черепахою”) - то це стимулює покращити себе, свою техніку та намагатись пливти краще.

І те саме стосується роботи. Можу сказати про себе: поки я працював у команді із іншими QA - то мав “мотивацію” показати, що “я щось знаю і щось знаю раніше за інших - тому в мене можна навчитись”. Коли ж останні 4 роки працюю “як єдиний QA у всьому офісі” - де й конкурувати немає з ким - то відчуваю, що “деградація мене проїла, як корозія метал”. Останні три дні на співбесідах допускаюсь таких помилок, про які б 5 років тому й не подумав, що можу допустити.

Testing is a process (минулому дню тестувальника присвячується)

Sun, 10 Sep 2017 13:08:01 +0300

https://www.dailymotion.com/embed/video/x2isb2v?pubtool=oembed What Is Software Testing? Hilarious Hyderabad Trainer.. must watch

Якось давно додав це відео про індійські процеси “війтівайті” і як тренер вчить тому, що testing is a process, в чернетки блогу і все ніяк не доходили руки до публікації. Тож, можливо, кілька років тому Ви його вже бачили. Ну а якщо ні – то приємного перегляду і з минулим професійним святом!

А якщо трохи серйозніше, нехай формат лекції і є “на межі фантастики”, testing is a process – це точно. І навчання, і розвиток у тестуванні – це теж process, причому нескінченний. Ось і побажаю отримувати задоволення від процесів:)

До речі, на відміну від поширеної думки, слово “баг” було винайдено не 9 вересня 1947 (до речі, 70 років тому – ювілей, однак), а набагато раніше.

Перше занурення у тестування – з чого почати?

Wed, 31 May 2017 23:32:58 +0300

Тестування програмного забезпечення – дивовижна сфера. На перший погляд, тут все просто – є “щось”, яке має бути “хорошим”, і є людина, яка бажає “все перевірити”. Але потім ця людина починає ходити на співбесіди, відправляти резюме – і якось “не беруть”. Так, насправді тестування далеко не така проста і банальна наука, як може здатися з реклами курсів “входу в айті”. Та й курси не завжди дешеві для тих, хто хоче “пірнути”. Як зрозуміти, чи варто Вам особисто пробувати?

Перше занурення у тестування

Почнемо з найпростішого: почитаємо Вікіпедію. Хоч довіряти їй варто на свій страх і ризик, але у визначеннях базових понять покластися можна. Але відразу обмовлюся – посилання хороше, але якщо подужаєте цю (а то і весь розділ) – відразу +50 в карму. Нехай не все буде зрозуміло, нехай важко, нехай зі словничком (благо гугл-транслейт можна в хромі налаштувати; а якщо зрозуміли, що написано до крапки з комою – то ще +50 в карму), але все найактуальніше і найсвіжіше вже років 10 (за більше не скажу – тому що 10 років тому не стежив) як з’являється спочатку англійською.

Отже, завантажили Ви себе термінами, які нічого не говорять, не хочу. Пора б і спробувати щось робити. Візьміть улюблену програму/сайт/олівець/кішку – і спробуйте подумати, поміркувати – а як би ви ЦЕ перевіряли? Спробуйте “накидати” прості перші тест-кейси. Що це за звір? Ви вже знаєте з минулого кроку. Якщо ні – повторюємо. Знайти “баги” – це не головне у тестуванні. Головне зрозуміти, що це таке, яким його хочуть бачити. Хто хоче? Ті, хто ЦИМ користується. А оскільки Ви взяли Вашу улюблену програму / кішку / кофтинку – то “тестуйте на собі”.

Вийшло накидати 20 тест-кейсів? Не набридло? Не нудно? Здорово! А 50? А як написати 50 КОРИСНИХ тест-кейсів? Ось тут пораджу цей блог. Олексій – ще той оповідач (шукаємо відео і дивимося), “ріже” по небажаю – але змушує думати. Особисто спілкуватися не доводилося, але в “нашомовній” “ком’юніті” один із тих людей, до критики кого варто дослухатися.

Далі

А далі що? Далі залежить від того, що Ви зараз відчуваєте. Тому що це перше занурення і навіть якщо весь контент (Ви ж знаєте, що це слово означає?) Вікіпедії вивчили напам’ять – поспішаю засмутити. Ви ще нічого не знаєте. Питання лише у тому, чи готові йти далі. Тому що далі книги, ютюб, океан технічних знань (те, що Ви не збираєтеся бути в майбутньому в програмуванні ще не означає, що “ручний кьюей” уникне скриптів), спроби продати себе на співбесіді, видавши за “синьйора з трирічним досвідом” ( у деяких виходило), курси (опціонально; ІМХО, на курси варто йти якщо у Вас вже є питання, а відповісти нікому, а не якщо є останні зайві тисячі і хочете загребати мільйони) і практика-практика-практика… І глибокого осягнути ВСІ сфери тестування одна людина ніколи не зможе, не спокушайтеся.

Ну звичайно ж, як я міг забути: http://software-testing.ru/ та стрічка блогів. Та й спробуйте вирішити завдання. Прості, банальні, але для розминки підійде.

Вести блог про тестування. Складно?

Tue, 27 Sep 2016 10:05:58 +0300

Доброго часу доби. Колись зустрічалася публікація, що вести блог про тестування складно. Складніше, ніж блог про програмування. І наводилися причини, чому так:

Багато вже сказано
Немає якихось нових “відкриттів”, “досягнень”
Не таке велике ком’юніті
“Текучка” (багато хто йде з тестування в “суміжні” області)

Воно хіба що так… Але хочу поділитися наступною думкою. Людина – істота розумна. А, як казав Олексій Лупан на нещодавньому мітапі у Львові, тестувальник – він ще й “істота аналітична”, тобто. повинен починати свою роботу не хаотично натискаючи на кнопки, а з аналізу.

Проблема

Так ось яка мета ведення блогу взагалі? Яка мета тестування? Правильно: самовираження. Зокрема. І заробляння папірців, що шарудять. Зокрема. Хоча б для того, щоб забезпечувати собі можливість для більш широкого та успішного самовираження. Тобто. блог – це в будь-якому випадку – інструмент та інструмент фінансовий.

Але ж на зміст цього інструменту теж потрібно виділяти фінансування: хостинг, сертифікати, програмування чогось свого, теми, зображення… Ні, можна звичайно робити все самостійно – але особистий час – це така цінність, яку купити та наздогнати втрачене неможливо.

Ось і виходить, що цей інструмент, який має приносити фінанси, витрачає як фінанси, так і час. Як же зробити його “рентабельним” і “приносить прибуток”? І тут виникає чудове слово, яке “ніхто не любить” – реклама.

Проблема реклами у тому, що її люблять. Вона настільки “мозолить” очі (особливо тоді, коли після пошуку на китайському сайті шпильок – ці шпильки показуються у тебе скрізь), що найменша згадка про неї викликає негатив (якщо Ви, звичайно, не продаєте ці шпильки). Тому “стандартні” методи (банери з рекламних мереж) – не завжди гарне рішення. Особливо коли у Вас блог про тестування, а “посеред тексту” красується реклама прального порошку чи дитячих іграшок.

Висновок: треба рекламувати тематичні “фішки”.

Розв’язання

Найочевидніше – рекламувати “інструменти” тестування. Колись давно, коли автотестування тільки “зароджувалося”, інструментів було мало, і всі вони були платні. Або кривуваті. Або платні та кривуваті одночасно. Зараз швидше можна знайти платні системи моніторингу, з виробниками (розповсюджувачами) яких Ви можете домовлятися про “невеликий гонорар” за “хвалебну статтю”. Мінус такої статті – у Вас можуть почати запитувати про Ваш досвід використання, але є і плюс: щоб уникнути цього мінуса, Ви скористаєтеся продуктом і у Вас у резюме з’явиться на один рядок більше:)

Крім “софту”, є такий інструмент тестування, як конференції та заходи. Про які теж можна писати (особливо якщо Ви збираєтеся на них виступати чи бути присутніми). І якщо звертати увагу на події, що відбуваються довкола, то вести блог про тестування складно буде – але вже буде цікавіше.

Також можна не лише стежити за подіями навколо, але й створювати події. Організуйте зустрічі, курси – і розповідаючи про них ви теж рекламуєте. Тільки в цьому випадку рекламуєте себе. А якщо зустрічі та курси будуть організовані добре – то ті, хто побував на них, почнуть писати вже про Вас:)

І останнє, що б порадив. Пишіть про свої нові знання. Ви ж не сидите на місці, а розвиваєтесь. А значить, використовуючи принцип “хочеш чогось навчиться – навчи іншого”, можете розповісти у своєму блозі іншим (зміцнивши свої напрацювання). І цим Ви теж рекламуватимете. Себе. Як особистість, як фахівця – “піднімаючи свою цінність на ринку”. І, як наслідок – це також принесе дохід.

Висновки

Так що так… Вести блог про тестування складно, поки не розумієш – навіщо це робити. А якщо проаналізувати свої бажання та можливості (не всі живуть у великих містах, де відбуваються події зі світу тестування, і не всі виробники софту готові платити за статтю у маловідвідуваному блозі) – то ведення блогу може стати і цікавим, і корисним!

P.S. Якщо вважаю, що в блозі про тестування можна рекламувати себе – так і бути – порекламую себе:) Як людина, яка любить стежити за останніми досягненнями у сфері IT, часто зустрічаю цікаві новини, що стосуються тестування, програмування, ІІ, віртуальної реальності та різних “технологічних фішок”. І щоб “найцінніші” не пропадали – став публікувати їх у “фейсбуківській сторінці” KVIT News. Лайкайте, підписуйтесь, читайте:) І, за бажання – приєднуйтесь як автори.

Робота у розподіленій команді

Wed, 07 Sep 2016 18:31:05 +0300

Починаючи з 2010 року доводилося працювати з людьми, у тому числі й технічними фахівцями, які знаходились віддалено, хоча більша частина команди все ж таки була в одному місці. Проте хотілося б поділитися свіжим відео із зустрічі-мітапу в Binary studio про таку тему як робота у розподіленій команді. Деякі моменти знайшов корисними для себе, сподіваюся, що знадобиться і Вам.

Логіка у тестуванні

Wed, 17 Aug 2016 23:22:21 +0300

Існує безліч жартів, анекдотів, наукових праць, книг та іншого про те, що жіноча та чоловіча логіка різні. Найдивовижніше, що так воно і є насправді! І, по-хорошому, її необхідно враховувати при UX-тестуванні. Тому як леді та джентльмени приділятимуть увагу одному і тому ж елементу сторінки (діалогу, вікна, програми) по-різному. У цьому випадку можна сказати що робота тестувальника виявляється сильно межує з роботою психолога.

Логіка

Але… Мені доводилось також працювати з клієнтами з різних предметних областей, з різних країн. І результатом хотів би “налякати” тих, хто тільки вступає на тернистий шлях QA. Логіка професій, логіка людей різних національностей також відрізняється! І не варто завжди покладатись на інтуїцію, коли тестуєте не повністю задокументовані вимоги. Уточнюйте у бізнес-аналітиків (клієнта) нюанси та тонкощі, тому що для німця касира 1+1=2, а для шведа архітектора може виявитися 1+1=10.

Висновки

Завжди пам’ятайте, що людина, яка замовляє музику, може любити зовсім іншу, ніж Ви. І дорого буде оплачувати замовлений концерт симфонічного оркестру із власної кишені, якщо насправді клієнтом очікувалась група стилю кантрі. Ось така логіка

200 дисертацій з тестування у вільному доступі від редакторів qahelp.net

Fri, 15 Apr 2016 03:26:46 +0300

12 червня 2015 року на сайті qahelp.net було зроблено запис “200 дисертацій з тестування у вільному доступі”, повний перелік яких публікую нижче. Сторінку було додано в закладки та на якийсь час забуто. Роблячи ревізію по закладках виявив, що сайт, на жаль, недоступний став (якщо хтось знає – підкажіть, чому?). Але завдяки веб-архіву вдалося відновити вміст – чим і поділяюся, щоб кожному бажаючому не довелося повторно проходити “квест”.

Примітка: деякі посилання ведуть на 404 або “cannot find document in database”.

200 дисертацій із тестування

Технологічний інститут Флориди (той самий, у якому працює Сем Канер) веде бібліографію дисертацій із тестування. Ми відібрали для вас ті, які мають електронну копію у вільному доступі. Читати не перечитати – просто скарб!

On the feasibility of using FSM approaches to test large web applications
Generation of tests from labeled event structures
An algebraic axiom environment for software testing (axenvironment)
Quality measurement and the utilisation of measurement results in a software development process
Test suite development using a structured framework
Formal models and analysis for software component interaction testing
Proposal for a software metrics-based critiquing system
A test planning system for functional validation of VHDL DSP models
A testing metric for designs modelled as hierarchical finite-state machines
Software comprehension: Theory and metrics
Software Design Based on Operational Modes
An infrastructure to support usability problem data analysis
A usability study of the Tksee software exploration tool
The variations in the use of I-CASE toolsets: a grounded theory approach
Mutation testing of hierarchical finite state machines in the Rational Rose Real Time toolset
Adaptive mode transition control architecture with an application to unmanned aerial vehicles
System-level fault diagnosis in the distributed PVM environment
Utilizing the notion of removable blocks to enhance program slicing algorithms
Safety verification conditions for software-intensive critical systems
Requirements engineering with use cases: A basis for software development
Using program slicing in software maintenance
Towards a regression test selection technique for message-based software integration
Efficient dynamic detection of input related software faults
Automatic testing of software with structurally complex inputs
Probabilistic Program Analysis for Software Component Reliability
The cat in the reaper: Usability testing of software instruction manuals
Reachability analysis and testing of asynchronous message-passing programs
Robustness testing of a distributed simulation backplane
Test driven development of embedded systems
Extending the constructive cost model through empirical defect modeling
A unique examination of the buffer overflow condition
The effectiveness of category-partition testing of object-oriented software
Conflict identification and resolution for software attribute requirements
Detection of faulty components in object-oriented systems using design metrics and a machine learning algorithm
A comprehensive framework for testing graphical user interfaces
Slicing-based coupling measurements
Process enhancement and database support for vehicle operational readiness reporting
Documentation and validation of the requirements specifications. An XML approach
Automatic generation of software test cases from formal specifications
A knowledge-based tool for regression testing
A software test plan generation approach for pedagogical purposes
An investigation into the determinants of software product development time
High-yield (fault-directed) approach to test suite evaluation
Generating test templates via automated theorem proving
High level test generation using software testing metrics
Inference in nonhomogeneous Poisson process models, with applications to software reliability
Introducing «FireWorks»: A tool for regression testing within the Smalltalk environment
On proportional sampling strategies in software testing
Knowledge-Based Program Understanding and Testing Assistant (KBPUTA)
Input validation testing: A system-level, early lifecycle technique
OCL exception handling
Implementation of the digital communication system in the F/A-18 aircraft
Test methodology for SRAM based FPGAs
Traceability in object-oriented quality engineering: A basis for regression analysis of object-oriented software
A Software Testing and Reliability Early Warning (STREW) metric suite
Safe software components
A measure for module cohesion
The Validation by Measurement Theory of Proposed Object-Oriented Software Metrics
Compiling with proofs
Testing instances of design patterns
Program reliability estimation tool
Software system defect content prediction from development process and product characteristics
Metamodeling: Rapid design and evolution of domain-specific modeling environments
Cause-effect validation of requirements for distributed systems
Specification mutation for test generation and analysis
Using Discrete-Event Simulation to Address the Probe Effect in Software Testing of Real-Time Distributed Systems
Enhancing software reliability with speculative threads
QUIM map: A repository for usability/quality in use measurement
Domain testing: Divide and conquer
Expert systems and test-plan generation
Development of decision support system for reliability
Achieving usability via design architecture and patterns: The things we implement that affect usability
Performance assertion checking
Predicting open-source software quality using statistical and machine learning techniques
Requirements-based design evaluation methodology
The use of data flow information for the selection and evaluation of software test data
Type qualifiers: Lightweight specifications to improve software quality
Analysis and quantification of test driven development approach
Issues in automation of checkpoint encoding for anti-random testing
Towards plug-and-play services: Design and validation using roles
An analysis of the difference in software project management practices between organizations registered to ISO 9001 and non-registered organizations
Coverage-directed validation of hardware models
Measuring inheritance coupling in object-oriented systems
A formal method for modeling and analysis of requirements for software
Automated construction of software behavior models
Safety-critical software testing in airborne systems: The modified condition/decision coverage criterion
A demand-driven approach for efficient interprocedural data flow analysis
Towards an integrated model for specifying and measuring quality in use
Reusable strategies for testing safety-critical systems
On the complete testing of simple safety-related software
Strategies for testing Web applications from the client side
Constructing black-box test suites for systems specified in Larch/C++
Testing multimedia software using Hybrid Control Flowgraph-Petri Net approach
A virtual RSNS direction finding antenna system
Key Success Factors for Keyword Driven Testing — LogiGear
Test automation snake oil
Helping everyday users find anomalies in data feeds
An implementation of the Schick-Wolverton and the Jelinski-Moranda software reliability models
A discipline of specification-based test derivation
Constraint-based feature validation
Analyzing infinite-state programs with abstract interpretation
Profile analysis techniques for observation-based software testing
An integrated testing and fault localization methodology for spreadsheet languages
A methodology and software environment for testing process model’s sequential predictions with protocols
Things that find bugs in the night
Managing software requirements: Organizational and political challenges
Integration of the Navy Tactical Environmental Database Service with the Joint Effects Model
Automating test generation for discrete event oriented real-time embedded systems
Efficient, effective regression testing using safe test selection techniques
Transformational approach to software reliability assessment
Dataflow analysis of software fragments
Stimulus response requirements specification notation: an empirically evaluated requirements specification notation.
Automatic generation of test cases and anticipated test outcome based on a tabular design specification
On mutation and data flow
Using Simulation to Empirically Investigate Test Coverage Criteria Based on Statecharts
An Architecture-Based Software Reliability Model
Constructing Bayesian-network Models of Software Testing and Maintenance Uncertainties
Automated Regression Testing using DBT and Sleuth
Automatic Test Generation using Checkpoint Encoding and Antirandom Testing
Pythia: A regression test selection tool based on textual differencing
Using a Neural Network in the Software Testing Process
Testability in hardware/software codesign systems
Software testing and reliability growth models
Effectiveness testing of embedded user support for US army installation-level software
Factors influencing a personal software process
Reliability quantification of nuclear safety-related software
Testability-directed specification of communications software
Towards a proportional sampling strategy according to path complexity a simulation study
A study on test cases generation for object-oriented programs based on UML state diagram
Program-based, structural testing of shared memory parallel programs
Software test generation based on flow models
A formal specification-based approach to object-oriented software testing at the class level
An empirical study of the branch coverage of different fault classes
A generic timing test framework for multimedia software testing
Quality assurance of Web applications: A survey
Integration of model checking into software development processes
Operational profile specification, test case generation, and reliability estimation for modules
Software component interaction testing: Coverage measurement and generation of configurations
Formal metrics for quantitative assessment of the quality of expert systems
COM-tester [microform] : a script testing tool for MS COM
Specification-based regression testing measurement with risk analysis
Empirical studies of the effects of incorporating fault exposure potential estimates into a test data adequacy criterion
Test data generation for relational database applications
Enhancing traditional behavioral testing through program slicing
Extending white box testing to database applications
The impact of team software organizations on software quality and productivity
Role of Larch/C++ specifications in black-box testing of object-oriented software
A trace-driven simulator for palm OS devices
A study on reproducible testing for distributed multithreaded Java programs
Structured testing: Analysis and extensions
Pattern-based design and validation of communication protocols
A quantitative approach for analyzing the impact of tools on software productivity
Distributed sensor network software development testing through simulation
SafeJava: A unified type system for safe programming
Validating complex agent behavior
A use case driven validation framework and case study
Foundations for the run-time analysis of software systems
A Taxonomy of E-Commerce Risks and Failures
Culture and international usability testing the effects of culture in interviews
Tools to support a formal verification method for systems with concurrency and nondeterminism
Leveraging test measurements into proposing additional domain tests
Feature engineering of software systems
An open-source, extensible spacecraft simulation and modeling environment framework
A view-based system for eliciting software process models
The complex quality world: Developing quality management systems for software companies
Verification and validation in software product line engineering
Scenario-driven requirements engineering: Method and tool
An Automated Oracle for Verifying GUI Objects
Automated test system for ADSL equipment
Group branch coverage testing of multi-version software
Object-oriented program testing using formal requirements specification
QUIM editor: A tool for quality in use measurement
ADaPT: Adaptive development and prototyping technique
Applying formal methods to software testing
The effects of roles and personality characteristics on software development team effectiveness
Enhancing visibility of annotations of software artifacts
Advanced software engineering models for quality improvement
Managing multiple interdependencies in large scale software development projects
A load-dependency model for software reliability
Context-driven testing of object-oriented systems
Implementation of a three-group classification model using case-based reasoning
Early component-based reliability assessment using UML based software models
Assessing software metrics
Identifying the mechanisms driving code inspection costs and benefits
A distributed approach to passively gathering end-to-end network performance measurements
Generation of grey box use cases for personal communication systems using simple design machines
Web-CAT a Web-based center for automated testing
Detecting errors in software using a parameter checker: an analysis
Comparative study of synchronous remote and traditional in-lab usability evaluation methods
Axiomatic verification to enhance software reliability
Improved techniques for software testing based on Markov chain usage models
Automatic detection of software failures with hierarchical supervisors
Metrics-guided models and methods for cost and quality management of component-based software
Metria-Guided Quality Management for Component-Based Software Systems
Relational specification as a testing oracle
Automatic continuous testing to speed software development
The specification-based validation of Reliable Multicast Protocol: Problem report
A hierarchical approach to the formal verification of embedded systems using MDGs
Usability analysis of the channel application programming interface
A run-time environment for concurrent Ada software test analysis

Чому важко бути QA? (частина 2)

Thu, 14 Apr 2016 10:37:25 +0300

Чим більше можливостей, тим важче вибрати. Вадим Мозговий

[![Складно бути QA тому, що багато шляхів розвитку]Придивіться до шляху: в одній широкій дорозі сходяться багато стежок

Доброго часу доби. Минулого разу в замітці торкнувся теми, чому важко бути QA і в списку проблем дійшов до пункту “неочевидність розвитку”, про який хотілося б детальніше поговорити сьогодні.

Сам я потрапив у тестування з університетського курсу прикладної фізики за порадою мого близького друга, який уже тоді був успішним програмістом. Його думка тоді була “Піди, навчися пару місяців програмувати”. Минуло 8 років. Програмувати вчитися можна все життя. А ось професію свою я покидати поки не збираюся:)

Але є дві небезпечні крайнощі, які зустрічаєш через деякий час після початку:

Все здається зрозумілим, людина потрапляє в зону комфорту – і залишається “на все життя” “клікером”: кави, новини, подивитися котиків, переглянути зафіксовані баги, подивитися робочу пошту та нові хотівки замовника, пообідати – а там і додому пора, розслабитися компанії улюблених серіалів.
Все здається зрозумілим і хочеться бігти далі: вирости в QA ліда, тимліда, директора, автоматизатора, свій бізнес і політ фантазії.

QA на роздоріжжі

Проблема в тому, що QA – це набагато комплексніша, ніж здається на перший погляд. Тест-кейси вигадувати – потрібно як розуміння продукту, і певний, хоча б інтуїтивний, математичний апарат. Потрібна певна дисципліна підтримки документації в актуальному стані. Для того, щоб розуміти, яка документація ефективна і потрібна, а яка буде тільки дарма витраченим часом. Розуміння “тайм-менеджменту”, “ризик-менеджменту”. Розуміння того, як працює “залізо”, на якому крутиться продукт, що створюється, як працює операційна система. Тому, залишаючись “в своїй професії” для того, щоб робити свої завдання ефективно, QA поступово освоює наступні:

Програмування; причому, далеко не завжди однією мовою
Програмування лише на рівні ОС: bash, powershell; потрібно як для автоматизації завдань наступного пункту, так і для нетривіального тестування безпеки
Базові знання в DevOps: щоб не чекати поки до тебе дійде сис.адмін , щоб підправити налаштування тестового оточення або просто розгорнути пару додаткових віртуалок
Проектний менеджмент
Бізнес-аналіз
Залежно від продукту – може бути додатковий розвиток у “не-айтішній” галузі економіки, медицини, фінансів, продажів
Дизайн і прикордонні області: як для тестування юзабіліті так і для того, щоб робити няшні скріншоти в джиру.
SEO, SMM та інші мережеві та маркетингові технології – для розуміння, які елементи потрібні будуть бізнесу
Психологія, уміння вирішувати конфлікти, вести переговори, мотивувати
І ще 100 500 пунктів, з якими ви зустрічаєтеся так чи інакше

Що ж робити?

Найважливіше і найскладніше – вибрати собі мету. Або цілі. Перестати обманювати себе і – що найголовніше – не давати тобі заснути у “зоні комфорту”. Світ IT розвивається дуже швидко 24 години на добу: якщо це не зробили ми зараз, то ввечері, вночі чи вранці це зроблять замість нас в Америці, Китаї чи Індії (як би не любили у нас жартувати з приводу коду “індусів” – на десять) тисяч пару геніїв можна зустріти, які обіймуть керівні посади в Google, Microsoft та інших гігантах). Вибрати та розвивати себе у певній сфері тестування: досі професіоналів у тестуванні безпеки, продуктивності не так багато. А з розвитком операційних систем і збільшенням BigData продуктів потреби в них тільки зростатимуть.

Це складно, але важливо. Challenge, який потрібно пройти. І навіть залишаючись “просто тестувальником” – потрібно відточувати мистецтво тест-дизайну (бо вчорашні тест-кейси можуть стати завтра неактуальними).

Так що, як би не говорилося в “рекламі” різноманітних курсів, що за пару місяців з домогосподарки можна стати супер-оплачуваним QA – це не так легко. Це найскладніший шлях розвитку QA. Більше того, написане вище – це більше розвиток QA як “технічного фахівця”, а саме про QA – наступного разу.

Чому важко бути QA? (частина 1)

Tue, 12 Apr 2016 09:16:07 +0300

Перед вами злітна смуга та проблема лише в тому, що не вистачає пального.
Дональд Трамп

Злітна смуга

У будь-якій професії можна досягти величезних висот, якщо займатися справою із задоволенням. Коли ти отримуєш “кайф” від результатів (а також матеріальну винагороду, яка дозволяє не переживати за те, чим харчуватимуться і у що одягатиметься твоя сім’я та сама людина) – напевно, це вже майже можна назвати щастям. А чи складно бути QA?

Останні роки стає “айтішником” стало модно. Так само модно, як якийсь час тому були модними професії юристів, адвокатів, стоматологів – і просто “народних бізнесменів”. І, здавалося б, найпростіше стати “тестувальником” – нічого ж робити не треба, просто сиди та шукай помилки. Як на мене, найбільша проблема в тому, що на курсах (які, власне, рекламують професію) дають набір молотків, але не кажуть, як потім стати щасливим з ними. А проблеми можуть розпочатися вже одразу.

Потрібне інше мислення

Не дарма поламано тисячі копій та написано мільйони книг з приводу того, що жіноча та чоловіча логіки – різні. Що жінки з Венери, а чоловіки – з Марса. Так само і QA – це люди з іншої планети, ніж, наприклад, журналісти, шахтарі, програмісти, бухгалтери, математики. Потрібно хотіти відчувати якість. Насамперед – якість своєї роботи. Не потрібно ламати продукт – потрібно робити його зручним та корисним. Це перша причина, чому складно бути QA, що отримує кайф від роботи – “важко влізти в чужу шкуру”.

Це модно

Так уже склалося, що більшість людей все життя прагнуть багатства. Бажано швидко та легко. І зараз. А, як говорилося – тестувальник – це модно. А отже, на ЕН вакансій буде 100*ЕН охочих. Особливо – щойно вийшли з курсів з очима, що горять, і готовими працювати за пару десятків тисяч доларів. А конкуренція робить дві речі: підвищує вимоги та знижує ціну тих, кому відповідності вимогам не вистачає. Це друга причина.

Неочевидність у розвитку

Колись у дитинстві мені розповідали історію успіху: одна людина знайшла яблуко і продав його. Потім на ці гроші він купив 2 яблука і продав дорожче зміг купити вже 5. І так далі – поки не став мільйонером. Отримавши спадщину від бабусі. А куди зростати QA? Про це – далі.

Проблеми міграції

Tue, 07 Apr 2015 02:40:36 +0300

Є непоганий сайт про новини мого рідного міста – “новини Сєвєродонецька”. І є непогана звичка – читати новини в RSS стрічці: якщо відкрити стрічку “того ж” УНІАН та сайт УНІАН (просто для прикладу), то на сайті “одразу впадає в око” те, що новинна агенція хоче виділити. А у стрічці – всі новини рівні, і можна помітити важливе саме для себе. Так само, як і в 230 інших джерелах, які збираються до мене в агрегатор:) Так ось, якийсь час тому у стрічці з’явилося повідомлення, що сайт переходитиме на інший майданчик… І тиша.

Проблеми міграції бувають різні

Довгий час я про нього не згадував, поки “стуляком долі” не замислився перекласти http://slavaqa.pp.ua з друпала на вордпрес. Не те що б у друпала мені щось не подобалося… Але для мене особисто в останні кілька місяців вордпрес став зрозумілішим, ніж друпав за останні 2 роки використання: зручніше “колупати і виколупувати”. Прощаються з друпалом остаточно не збираюся – тестовий демо-майданчик як “крутився” так і буде, але рішення було приємно – і змігрувався. Зокрема (з іншого ресурсу) розпочав міграцію RSS новин… Хм… А де ж “новини Сєвєродонецька”? І тут (дуже вчасно:)) зрозумів, що урл RSS-ки змінився і в мене, і в улюбленого сайту! Що ж… Буває)

Пункти, важливі під час міграції

Отже, якщо Ви колись задумаєтеся над “кардинальною міграцією” Вашого сайту з однієї платформи на іншу, зверніть увагу на те, що збереглися б незмінними:

Адреса RSS (інакше можна втратити всіх передплатників)
SItemaps, “скормлені” пошуковим системам (або “годуйте” нові)
Permalinks (вони ж – “постійні посилання”) – формат адрес сторінок добре залишати без змін. Або налаштувати “правильні редиректи”. Інакше вся пошукова індексація, закладки в браузерах всіх численних передплатників і фанатів виявляться марними 404 помилками (вкрай розчарувавши СЕО-інженера)
Google/Yandex analitics та метрикс коди. Залежно від цього, як було реалізовано зв’язка з аналітикою, код може й загубитися, що було погано.

Ось, власне, стисло ті проблеми світграції, з якими зіткнувся. На жаль, вже постфактум. Сподіваюся, комусь ця коротка замітка допоможе подібним “граблям” запобігти.

З.Ю. Звичайно згоден, що краще використовувати не друпали та вордпреси, а своєписне своє. І дірок менше, і знаєш, десь лежить. Але це “зовсім інша історія”:)

Drupal 7.35 – оновлення безпеки

Thu, 19 Mar 2015 14:25:37 +0200

Вийшло оновлення Drupal 7.35, яке включає фікси безпеки.

Опис з офіційного сайту:

Description
Access bypass (Password reset URLs – Drupal 6 and 7)

Password reset URLs can be forged under certain circumstances, allowing an attacker to gain access to another user’s account without knowing the account’s password.

In Drupal 7, this vulnerability is mitigated by the fact that it can only be exploited on sites where accounts have been imported or programmatically edited in a way that results in the password hash in the database being the same for multiple user accounts. In Drupal 6, it can additionally be exploited on sites where administrators have created multiple new user accounts with the same password via the administrative interface, or where accounts have been imported or programmatically edited in a way that results in the password hash in the database being empty for at least one user account.

Drupal 6 sites that have empty password hashes, or a password field with a guessable string in the database, are especially prone to this vulnerability. This could apply to sites that use external authentication so that the password field is set to a fixed, invalid value.

Drupal

Open redirect (Several vectors including the “destination” URL parameter – Drupal 6 and 7)

Drupal core and contributed modules frequently use a “destination” query string parameter in URLs to redirect users to a new destination after completing an action on the current page. Under certain circumstances, malicious users can use this parameter to construct a URL that will trick users into being redirected to a 3rd party website, thereby exposing the users to potential social engineering attacks.

In addition, several URL-related API functions in Drupal 6 and 7 can be tricked into passing through external URLs when not intending to, potentially leading to additional open redirect vulnerabilities.

This vulnerability is mitigated by the fact that many common uses of the “destination” parameter are not susceptible to the attack. However, all confirmation forms built using Drupal 7’s form API are vulnerable via the Cancel action that appears at the bottom of the form, and some Drupal 6 confirmation forms are vulnerable too.

Джентльменський набір плагінів у WordPress

Thu, 12 Mar 2015 02:27:19 +0200

З’явилася необхідність “на коліні” спорудити простий і няшний сайт з мінімальними фінансовими та тимчасовими витратами. Спочатку думав зібрати з уже знайомих Drupal-а та плагінів, але “на слуху” частенько траплялося слово WordPress…

Останній раз з WordPress зіштовхувався багато років тому і тоді він здався набагато менш зручним, ніж Drupal. Але тепер, коли задум був “блого-подібний сайт” (без форумів і проблем) вирішив поекспериментувати. І хочу сказати, що сподобалося:)

Які плагіни були використані:

“Просувальні”

WordPress SEO – чудова штука, яка перевіряє “якість сіошності” + додає різні опції (зв’язки з пошуковими системами, редактор метаданих)
Google Analytics by Yoast – зв’язка з Google.
Google+ Plugin – зв’язка з Google+ сторінкою і додавання +1 кнопки
Yandex Metrica – зв’язка з Яндекс.Метрикою. Виведення на внутрішній дашборд графік (нема потреби відкривати Яндекс)

“Комьюнітібудівельні”

User Role Editor – редактор ролей, щоб зробити спілкування більш ясним і зрозумілим
Page Links To власне, даний плагін всього лише конвертує посилання на сторінки в посилання. Для чого потрібно? Для налаштування переходу з російської на англійську версію та назад

“Плюшки”

Video.js – HTML5 Video Player для WordPress – вставка легкого і зручного плеєра. Перебрав із десяток плагінів, цей сподобався найбільше.
Insert PHP вставка виконуваного коду.

Так що, практично “за все нічого” вдалося зварганити дуже пристойного вигляду штуку використовуючи набір плагінів до WordPress і сам двигун. Залишилося тільки тій людині, яка “замовляла”, регулярно наповнювати контентом:)

Задати конкретну країну для перегляду через Tor Browser

Thu, 12 Mar 2015 01:34:57 +0200

У житті тестувальника бувають моменти, коли пріоритетом для тестування є не так “крос-браузерне тестування”, як “географічно-залежне”. Можна, звичайно, заходити віддалено на сервери, які знаходяться в потрібних країнах, і тестувати звідти. Але є дуже легко і швидко настроюється спосіб: задати конкретну країну для перегляду через Tor Browser

Про нього відомо “всім і вся” завдяки анонімності веб-серфінгу, яку він надає (хоча є і ті, хто сумнівається). Але це, власне, “трохи інша історія”.

Отже, інструкція:

Завантажуємо Тор
Встановлюємо “розумним інсталятором”.
Заходимо в папку … Tor BrowserBrowserTorBrowserDataTor де знаходимо файл TORRC і відкриваємо його на редагування в блокноті
Пропустивши один рядок після коментаря, пишемо на наступному ExitNodes {ХХ}, де ХХ – код країни (наприклад, UA для України, RU для Росії, US – США). Приклад:

This file was generated by Tor; if you edit it, comments will not be preserved

The old torrc file був renamed to torrc.orig.1 or similar, and Tor will ignore it

ExitNodes {UA}
5. Перевантажуємо Тор (просто закриваємо та запускаємо заново) та перевіряємо, відкривши http://geoiptool.com, куди нас занесло:)

Навчання тестувальників. Презентація компанії Mail.ru

Wed, 24 Dec 2014 17:37:05 +0200

Знайшов і захотілося поділитися: сподобалися поради з презентації про навчання тестувальників від компанії Mail.ru. Презентація була показана під час конференції SQA Days 16

https://www.slideshare.net/slideshow/embed_code/key/6Anp22qe0pjAv6 Обучение тестировщиков. Практический опыт и советы

Обучение тестировщиков. Практический опыт и советы from SQALab

Криза у світовій економіці?

Tue, 09 Dec 2014 10:05:03 +0200

Криза!!!

Світова криза!!!!! А-а-а-а! Все пропало! Потрібно терміново міняти рублі та гривні на долари. Закуповувати гречку, сіль, сірники та буржуйку. Не час, не час зараз думати про щось ще, коли у світі панують геополітичні війни, лихоманка Ебола та ІГІЛ! При цьому якось завжди стороною обходиться така проста думка, що:

Моделювана криза світової економіки – не означає автоматично кризу кожної конкретної людини

Проте зараз нам намагаються спустити зверху “кризову ситуацію” – засмічуючи мізки інформаційними потоками. Єдина інвестиція, яка не знецінюється – інвестиція в себе. Єдиний актив, який дуже складно відібрати і одночасно ваш робочий інструмент, який потрібно оновлювати і відточувати – це ваш мозок і ваші здібності ним керувати.

Взято зі “спаму” (найкориснішого, який колись отримував:)) від Слави Панкратова (Школа менеджерів Стартоплан)

.Net + FitNesse

Mon, 01 Dec 2014 10:29:08 +0200

На нещодавній конференції SQA-Days 16 було багато корисних та цікавих доповідей. Бути присутнім не довелося, але Дякую організаторам за те, що виклали записи в загальний доступ. І один із доповідей (.Net + FitNesse) зацікавив і сподобався настільки (вже хоча б тому, що до .Net “особлива особиста прихильність”), що навіть захотілося “перепостити”.

https://vimeo.com/113139985

Математика для тестувальників

Fri, 28 Nov 2014 00:48:09 +0200

Відео однієї з доповідей SQADAYS#13

Повторення, як кажуть, мати вчення. А такі речі варто повторювати.

Ким будуть Ваші діти, Пані та Панове тестувальники?

Mon, 24 Nov 2014 08:38:48 +0200

Знайдено в Інтернетах.

![Колискова тестувальника](https://i0.wp.com/pp.vk.me/c621629/v621629859/800/vdSpFbug4Uo.jpg?resize=656%2C337&ssl=1)Колискова тестувальника

[Оригінал](http://martialtester.wordpress.com/2014/08/19/so-you-want-your-kid-to-be-a-tester/testers-jingle/)

Спочатку була стратегія…

Mon, 24 Nov 2014 01:17:19 +0200

Що спільне між тестувальником і… припустімо, Наполеоном? Наполеон хотів підкорити світ, досягнувши абсолютної влади. Тестувальник теж хоче “підкорити” продукт, досягнувши абсолютної якості. Як полководцю Наполеону, так і тестувальнику необхідно “чуття” у своїй роботі: мають бути розвинені тактика та стратегія. Тактика допомагає керувати часом прямо зараз, виконуючи поставлені (або більше) на день завдання. Стратегія – бачення майбутнього – допомагає вибудувати процес тестування від початку до успішної здачі та супроводу.

Стратегія – це загальний опис методів та підходів, які будуть використані у тестуванні та є вступною частиною та основою для тест-плану. Як назвали стратегію тестування в одній розумній статті, це огляд з висоти десяти тисяч футів. Власне далі буде про стратегію.

Стратегії тестування

![Стратегії тестування](https://i0.wp.com/cs621629.vk.me/v621629859/7f8/CalKiyBYTio.jpg?resize=800%2C600)Стратегії тестування

Якби була успішна стратегія щодо завоювання світу – вже він був би підкорений. З тестуванням простіше та складніше одночасно: успішних стратегій, які дозволяють випускати no-bugs релізи – безліч. І часто вони залежать від команди, проекту, замовника, цілей, наявних коштів тощо. І все-таки можна виділити кілька основних.

Орієнтоване на ризики. Тестування, в якому управління, вибір, пріоритети, використання підходів, завдань та ресурсів підбирається на підставі конкретних ризиків, називається орієнтованим на ризики.
Орієнтоване на моделі тестування використовує так звані формальні моделі (не ментальні) для управління активностями, такими як управління, дизайн, реалізація, виконання та звіти про тестування.
Стратегії, основу яких лежить процес, природно переважно поділяються на “традиційні” і “ітераційні” (гнучкі).
3.1. Agile стратегія: методи розробки ПЗ, в яких методи розробки та реалізації виконуються змішаними спільними командами, що самоорганізуються. Проте, у разі тестування ведеться практично всією командою весь цикл виробництва.
3.2. “Традиційний процес”, в якому стадії слідують одна за одною через пропозицію, ініціацію, аналіз вимог, дизайн, реалізацію, тестування, вихід у продакшн та підтримку. У традиційних процесах тестування проводиться окремо взятою групою вже ближче до кінця процесу після проведення всіх інтеграційних маніпуляцій.
Тестування, засноване на досвіді: тестування, в якому знання, навички, набутий досвід закладаються при плануванні, дизайні, реалізації та отриманні звітів про тестування. Багато тестувальників закладають різні аспекти такого підходу до тестування, хоча й буває, що хтось може використовувати їх “надзвичайно широко”. Концепції тестування, заснованого на досвіді, включають такі елементи як передбачання помилок, дослідне і ad hoc тестування.
Тестування перевірки вимог: такий підхід до стратегії тестування, у якому вимоги та інші артефакти ПЗ використовуються для перевірки відповідності коду вимогам та артефактам. Основним завданням є показати, що всі вимоги дотримані та показати відповідність стандартам та регулюючим специфікаціям. Перевіряючі тести закріплюються у письмовій документованій (“скриптованій”) формі тестових процедур та звітів.
Стратегія на підставі атак: тестувальники намагаються знайти помилки, ґрунтуючись на патернах, які повинні б “зламати” програмне забезпечення (застосовуючи атаки). Така стратегія є гібридом тестування, заснованого на досвіді та тестування, заснованого на ризиках. По суті, це є “максимально практичним” тестуванням.
Математично обґрунтована стратегія: у цьому випадку тести плануються, проектуються, реалізуються та аналізуються на підставі математичних концепцій та технік. Ці тести включають статистику, проектування експериментів, методику формальних доказів, комбінаторику, методики випадкових чисел, математичний аналіз (теорії про класи еквівалентності і граничні числа).
Валідація користувачами: дана стратегія містить мету показати те, що розробка створила той самий продукт, який відповідає бажанням користувачів та замовників. Продукт перевіряється на підставі “оперативних концепцій”, вимог, дизайну, моделей, реалізацій, оскільки будь-який із цих елементів може містити помилки. Оцінка якості відповідності може бути в такому разі складною і досить суб’єктивною (“добре-погано вийшло”, “подобається-не подобається”), тому багато таких стратегій намагаються уникати.

Насправді рідко бувають “чисті” стратегії. Зазвичай, залежно від контексту, стратегії поєднуються для отримання максимального ефекту та відповідності очікуванням власника бізнесу. Але в будь-якому випадку, добре продумана стратегія є ключовим пунктом для отримання якісного продукту і набагато важливіше мати чітку стратегію і слідувати їй до того, як буде складено основний детальний план і піде “занурення в глибокий тест-дизайн”. Важливо вміти складати та застосовувати різні стратегії. Тоді продукт, над яким працюєте, досягне того, чого не зміг досягти Наполеон.

Джерело

А ще можу порекомендувати наступне відео 🙂

Про тестовий фреймворк замовте слово…

Mon, 10 Nov 2014 12:13:16 +0200

«Для тих, хто хоче, але боїться автоматизації»

Не знаю, як для кого звучить згадка про тестовий фреймворк, але для мене, перш ніж став «тісно» працювати над автоматизацією слова когось на конференції/у відео-уроці «Я написав свій тестовий фрейморк» викликали шанобливу повагу та «тремтіння у колінах». Що цілком легко зрозуміло було, оскільки знань з програмування та розуміння того, з чим доведеться працювати було замало і по суті фраза сприймалася як «я написав свій ще крутіший варіант Selenium».

Гугління і вікіпедіння не дуже допомагало, тому що скрізь також зустрічалися визначення типу «програмний продукт», «набір бібліотек» тощо. Асоціативний ряд відразу виводив до деяких .dll файлів, які виникають якимось складним і фантастичним чином.

Насправді все не так. Точніше, не так «складно та фантастично». У всіх (які мені зустрічалися) курси автоматизації тестування з використанням Selenium перші уроки починаються з навчання роботі з Selenium IDE. Можливо, зі зростанням популярності Selenium Builder курси починатимуть навчати працювати з ним – але це так, ліричний відступ. Так ось, перший скрипт з IDE є набором команд, які є реалізацією фреймворку Selenium/Webdriver. Якщо його зберегти, підпиляти – то, в принципі, можна з ним і надалі працювати. Але проблема полягає в тому, що доведеться далі в тестах використовувати одні й ті ж повторення команд, одні й ті самі переходи, одні й самі алгоритми, елементи на сторінці/у вікні тощо, і т.д. Це незручно, довго та нудно. Набагато швидше вирішити квадратне рівняння за формулою (згадуємо шкільний курс:)), ніж будувати на мілімітровці графіки щоразу.
Тобто. насправді, “тестовий фрейморк” – це “конструктор, зроблений з конструктора”.
Один простий приклад: натиснути кнопку «Зберегти».
Можна завжди у тестах писати так:

<pre data-wpae="lang:csharp;theme:github;" style="background-color: #ddd;">driver.FindElement(By.Id("ctl00_A_btnSave")).Click();

Але що робити, якщо таких записів «багато-багато», а треба щось змінити? Або змінилося (в самому Selenium) назва методу натискання на елемент (став не Click(), а ClickElement()), або змінився ID, або ще якесь або? Для цього локатор зберігається окремо (в описі сторінки для PageObject/елемента сторінки HtmlObject), метод описується окремо, а всередині знаходиться той самий

<pre data-wpae="lang:csharp;theme:github;" style="background-color: #ddd;">driver.FindElement(By.Id(locator)).Click();

І так, малими «цеглинами», вибудовується оперування сторінками/вікнами/діалогами, а потім з цих «найбільших цеглинок» збираються тести. Що буде найважливішими моментами при початку роботи над «своїм дітищем» (що дозволить потім вийти на сцену на конференції з тестування і гордо випнувши груди сказати «я написав свій тестовий фреймворк»:))?

Розуміння плюсів/особливостей мови, якою писатиметься. Зі своїх граблів: перші спроби «автоматизувати» довелося викинути/переписувати через те, що тести об’єкто-орієнтованою мовою писалися «по-старому». І змусити працювати «того монстра Франкенштейна» вдалося, але через тоді «незрозумілі милиці».
Знання патернів (шаблонів, прийомів) проектування для тестових фреймворків. В інтернатах інформації багато, можливо, трохи пізніше «напишу і своє велосипедне пояснення». Зараз просто напишу так: якщо не знаєш, що має вийти – то може взагалі щось нікому незрозуміле.
Планування. Не можна автоматизувати відразу і все. Почніть із простих сценаріїв.

Кому як, а для мене добрим підходом здається наступний:
а) написати тест-кейси «на папірці»
б) перенести в тестовий проект у «командному» вигляді, тобто. не

<pre data-wpae="lang:csharp;theme:github;" style="background-color: #ddd;">driver.FindElement(By.Id(locator)).Click();

а

Site.OpenPage(page1);
Site.Page1.ButtonSavePresent();
Site.Page1.ButtonSaveClick();

який природно не проходитиме, оскільки всі (або частина) ці методи ще реалізовані.
в) реалізувати методи, виходячи з того, що OpenPage «глобальніший», а

<pre data-wpae="lang:csharp;theme:github;" style="background-color: #ddd;">Page1.ButtonSaveClick();

стосується лише Page1. І ось якраз цей самий момент реалізацій пункту і буде «тестовим фреймворком автоматизації».
г) підготувати “code convention”. Навіть якщо автоматизацією на проекті займатиметься одна людина – варто заздалегідь продумати певні правила, як саме писати як код тестів, так і код «конструктора». Бажано обговорити з програмістами, бо якщо знадобиться їхня порада, щоб не виявилося, що код «написаний на абсолютно різних діалектах однієї мови». (Елементарне: як ставити фігурні дужки? На цьому ж рядку відкривати – чи з наступного? Якщо можна «і так, і так».)

Природно, у фреймоврк варто заздалегідь закладати репортинг/логування результатів/звітність. Якщо це нове для вас – то не варто одразу чекати побудови гарних графіків. Відразу варто пам’ятати, що кількість тестів буде не 10 і тестових оточень буде більше ніж одна, а значить Grid і паралельне виконання тестів наближається. Звичайно не варто «відразу писати тести по всьому»: покрийте базову функціональність, основні сценарії, а потім приступайте до детальніших перевірок «всього». Природно, що тестових даних буде багато, а значить один і той же сценарій працюватиме на багатьох наборах даних (які читатимуться їх файли, бази даних, генеруватимуться «на льоту» залежно від контексту). Роботи багато, часу на реалізацію займе багато, особливо якщо з мовою програмування «на Ви» (про те, яку мову вибрати – теж треба подумати заздалегідь: якщо не буде «під рукою» людини, з якою можна порадитись щодо реалізації, то робота може “встати”, ще не розпочавшись).

Але недаремно є приказка «терпіння і працю все перетруть».

“Testing” what is it? (by Michael Bolton)

Wed, 29 Oct 2014 15:24:24 +0200

Testing can means different

Testing is — among other things — reviewing the product and ideas and descriptions of it, looking for significant and relevant inconsistencies.
Testing is — among other things — experimenting with the product to find out how it may be having problems—which is not “breaking the product”.
Testing is — among other things — something that informs quality assurance, but is not in and of itself quality assurance.
Testing is — among other things — helping our clients to make empirically informed decisions about the product, project, or business.
Testing is — among other things — a process by which we systematically examine any aspect of the product with the goal of preventing surprises.
Testing is — among other things — a process of interacting with the product and its systems in many ways that challenge unwarranted optimism.
Testing is — among other things — observing and evaluating the product, to see where all those defect prevention ideas might have failed.
Testing is — among other things — a special part of the development process focused on discovering what could go badly (or what is going badly).
Testing is — among other things — exploring, discovering, investigating, learning, and reporting about the product to reveal new information.
Testing is — among other things — gathering information about the product, its users, and conditions of its use, to help defend value.
Testing is — among other things — raising questions to help teams to develop products that more quickly and easily reveal their own problems.
Testing is — among other things — helping programmers and the team to learn about unanticipated aspects of the product we’re developing.
Testing is — among other things — helping our clients to understand the product they’ve got so they can decide if it’s the product they want.
Testing is — among other things — using both tools and direct interaction with the product to question and evaluate its behaviours and states.
Testing is — among other things — exploring products deeply, imaginatively, and suspiciously, to help find problems that threaten the value.
Testing is — among other things — performing actual and thought experiments on products and ideas to identify problems and risks.
Testing is — among other things — thinking critically and skeptically about products and ideas around them, with the goal of not being fooled.
Testing is — among other things — evaluating a product by learning about it through exploration, experimentation, observation and inference.

Author

Michael Bolton (http://www.developsense.com/)

Алгоритм Успіху: Як Стати Найкращим

Mon, 29 Sep 2014 16:33:43 +0300

Дуже часто людина відчуває потребу змінюватись та змінити сферу своєї діяльності. Бувають такі стани, коли Ви розумієте, що займаєтеся не тим, чого бажаєте або не тим, до чого маєте здібності. На жаль, найчастіше Ви змушені знаходити собі виправдання та відмовки для того, щоб не міняти цю звичну Вам сферу діяльності.

Оскільки за свою роботу, нехай і неприємну, отримуєте гроші, на які купуєте такі потрібні хліб та ковбасу, а може і з маслом. Більше того більшість людей навколо працюють на таких же нудних роботах і кажуть Вам такі приємні вашій душі виправдання “будь як усі”, “все що не робиться – робиться на краще”, “кожен цвіркун знай свою жердину”, “у тебе немає потрібної освіти”, “це ризиковано” і так далі, і таке інше. Переважна більшість людей навколо навіть не намагається щось змінити у своєму житті та роботі. Вони вважають за краще плисти з усіма за течією. Якщо Ви в такий стан речей не вірите або не розумієте, тоді ця стаття не для Вас, Дорогий Друже. Ви на жаль давно мертві і що-небудь змінювати мені буде не під силу. Цей матеріал для тих, хто відчуває бажання змінити своє життя та сферу своєї діяльності. Для тих, хто не задоволений і розуміє, що потрібно щось робити, але не знає як… Саме про те як це зробити і буде ця стаття.

Багато місяців тому у себе на стіні ВК я розмістив статтю дуже відомого на заході блогера Джеймса Альтушера з приводу того, як радикально поміняти сферу своєї життєдіяльності. Після тієї статті до мене надійшло безліч листів від глядачів та читачів зробити більш розгорнутий матеріал на цю тему. Джеймс Альтушер – дуже цікавий, бо є практиком, а не голим філософом. Він досягнув великого успіху в різних сферах: від програмування до інвестування. Причому багато разів розорявся повністю (не тільки у фінансовому плані) і починав усе з нуля. Його погляди на речі мені дуже подобається, тому вирішив зробити для вас своєрідний огляд його рекомендацій.

Я “НУЛЬ” І Я РУХАЮСЬ УПЕРЕД

Чим би Ви не займалися у минулому – забудьте це, якщо починаєте освоювати нову для себе сферу. Це дуже важливо зробити, щоб не гальмувати свій прогрес. Вам буде дуже хотітися тішити своє марнославство думками про те, що Ви чогось варті (адже в чомусь іншому таки досягли успіху). Це погано! Тому що відволікатиме від розвитку в новій сфері. Це погано! Тому що притуплятиме почуття голоду! Ви є мільйонером? У Вас було багато жінок? Круті батьки? Дорога тачка? Добра сім’я? До біса! Всесвіту немає до цього діла. Вважайте, що втратили ВСЕ. Не відволікайтеся і намагайтеся підняти свою самооцінку через інші сфери. Тільки ЗРОСТАННЯ у новій вибраній сфері можна сприймати як спосіб підняття своєї самооцінки. Розумієте? Чим більше отриманий мінус, тим більше хочеться розвинутись у плюс. Людина коли лише починає гойдатися, в неї прогрес йде слабко. Людина починає себе заспокоювати “це фігня”, “зате у мене три коханки та два мерседеси”. Чи розгойдається? Ще чого! Таким чином людина притуплює своє почуття голоду, і втрачає мотивацію.

Боротьба йтиме щодня. Що б Ви не обрали як свою нову сферу (програмування, малювання, акторство, мовознавство або пікап дівчаток), щодня належитиме вирішувати: ІТИ ВЕРЕД або котитися назад. Уявіть, що ви йдете на гору під пологим ухилом: щоб рухатися вперед потрібно докладати зусиль, а щоб котитися назад досить просто зупинитися. Тут немає зупинок чи вихідних. Якщо хочете чогось досягти в обраній сфері, то потрібно зрозуміти що Ви – “НУЛЬ” і що КОЖНИЙ ДЕНЬ ПОТРІБНО РУХАТИСЬ ВПЕРЕД.

БАЖАННЯ РУХАТИСЬ І ВЧИТЕЛЬ

Вам не обов’язково мати велику ПРИСТРІСТЬ для того щоб розвиватися в потрібному напрямку. Хоча, безперечно, справжня жагуча пристрість багаторазово прискорює досягнення результату. Вам достатньо мати БАЖАННЯ рухатись до мети РЕГУЛЯРНО. Не настільки важливо з якою саме швидкістю Ви рухаєтеся дорогою, скільки саме просування вперед. Якщо буде навіть мінімальний прогрес, то за рік він стане суттєво помітним, як і отриманий професіоналізм у обраній сфері.

У спорті, так само як і в інших сферах, зустрічаються такі собі “швидкоплинні вогники”. Тобто такі люди, які короткостроково палають пристрастю. Досягають дуже багато чого за пару кроків, а потім “тухнуть”, так і не досягнувши вершини. Ваше завдання не в супердосягненнях. Ваше завдання – сталість. Нехай маленькими кроками, але ж постійно рухатись далі!

І що вам насправді потрібно, так це ВЧИТЕЛЬ, який буде показувати вам як рухатися і що робити. Без такого ментора ви скоріше за все потонете. Це має бути не обов’язково якась жива людина. Навколо вас безліч супер наставників. Багато хто з них давно мертвий, але унікальність нашої цивілізації в тому, що ми навчилися користуватися навіть з думок і життів давно померлих людей. Читайте книги майстрів у тій сфері, яку обрали!

П’ЯТЬ РОКІВ ЩОБ СТАТИ КРАЩИМ

На все потрібен час. Щоб досягти результату одному може знадобитися більше зусиль, іншому менше. АЛЕ орієнтуєтесь на термін – П’ЯТЬ РОКІВ! Саме стільки потрібно для того, щоб ЗМІНИТИ СЕБЕ. Ось як проходитиме ваша трансформація:

ПЕРШИЙ РІК: нічого не знаєте, читаєте та дивитесь все поспіль, починаєте щось робити
ДРУГИЙ РІК: вже знаєте з ким треба поговорити і що зробити. Ви зростаєте щодня.
ТРЕТІЙ РІК: тут вже можете почати заробляти на цьому, але на життя цих грошей ще не вистачає
ЧЕТВЕРТИЙ РІК: Ви добре заробляєте
П’ЯТИЙ РІК: Ви стаєте заможною людиною

Перші пару років у всіх можливі розлади та сумніви в стилі “чому все йде не за планом?”, “Де мої результати?”, “Хочу більшого”. Часто турбують сумніви “чи ж ту сферу обрано взагалі?” Це нормально. Просто продовжуйте “довбати” те, що обрали.

ЯК І КОЛИ ЗРОЗУМІТИ ЩО ЦЕ МОЄ

КОЛИ? ЗАРАЗ! Хочеш хитатися? Прям зараз йди до тренажерного залу і намагайся рухати залізо. Хочеш стати художником? Дістань зошит, олівець, гумку і вперед. Прочитай 500 книжок у обраній сфері та застосовуй отримані знання НА ПРАКТИЦІ!!! Хочеш добре писати книги чи статті? Без проблем. Роби три речі: ЧИТАЙ, ПИШИ, ОРІЄНТУЙСЯ на улюблених авторів. Замислюйся чому вони так написали, а не інакше. Вивчай чужий досвід. Ставай краще. Хочеш розпочати бізнес? Візьми аркуш паперу та починай опрацьовувати ідею. Створи проект бізнес плану прямо зараз. НІКОЛИ НЕ ЧЕКАЙ ЗАВТРА! РОБИ СЬОГОДНІ! ЗАРАЗ!

ЯК ЗРОЗУМІТИ ЩО ЦЕ ВАШЕ? Потрібно прислухатися до своїх відчуттів і витратити три місяці свого життя. Прислухайтеся до себе: це може бути будь-яка сфера діяльності в якій ви відчуєте сили прочитати 500 книг? Якщо за ТРИ МІСЯЦІ стане нудно – ЗУПИНІТЬСЯ і виберіть іншу сферу, до якої у Вас більше бажання розвиватися. РОЗЧАРУВАННЯ – це нормально. Невдачі потрібні, тому що від них отримуємо більше досвіду, ніж від успіху. Запам’ятайте НЕВДАЛА СПРОБА ЧИ ДІЯ краще ніж 1000 вдалих СЛОВ! Навіть якщо щось у пішло не так, як планувалось, ви отримали більше ніж той, хто взагалі нічого не робив, а тільки базікав.

ГРОШІ – ЦЕ ВАЖЛИВО

Часто можна почути фразу “не в грошах щастя”. Це справді так, бо гроші – один із елементів комфорту. Тільки і всього. Якщо Ви незаможна людина, то не будете щасливим, саме через брак комфорту. З іншого боку не факт, що можна бути щасливим автоматично, якщо стати заможнім, тому що комфорт – це тільки ОДИН із елементів задоволення.

Чому ж я кажу, що гроші є важливими? Тому що ГРОШІ – ПОКАЗНИК прогресу. Ви можете займатися улюбленою справою з “любові до мистецтва”, але якщо немає чіткого матеріального критерію прогресу, то рух вперед може зайняти істотно більше часу ніж 5 років. Інакше кажучи, Ви можете просто хитатися “для себе”, а можете виступати на змаганнях, отримувати ступені майстра спорту, оплачувану роботу, великі контракти і т.п. У другому випадку Ваш рух уперед буде більш спритним, ніж у першому, тому що додався матеріальний критерій. Хочеш грати на гітарі? Давайте платні концерти чи грайте у переходах метро. Бажаєте вивчити програмування? Зареєструйся на фріланс сайті та пропонуйте свої платні послуги у цій сфері.

З кожним РОКОМ заробітки у вибраній сфері зростатимуть тому що зростатиме ДОСВІД! До третього року Ви можете витратити на вивчення нової сфери близько 5.000 – 7.000 годин! Цього вам вистачить для того, щоб потрапити до ТОП-300 найкращих фахівців світу, яку б сферу ви не вибрали. Такого рівня більш ніж достатньо щоб заробляти на гарну їжу. До ЧЕТВЕРТОГО РОКУ Ви опинитесь у ТОП-100 і Ваш заробіток зробить стрибок до гори! До П’ЯТОГО РОКУ увійдете в ТОП-30 або ТОП-50 (залежить від обраної сфери та особистої старанності). На цьому рівні Ви зможете отримувати вже великі статки. Якщо знайдете в собі сили рухатись РЕГУЛЯРНО вперед.

А ЯКЩО…

Давайте зараз попрацюємо з можливими “відмазками” та сумнівами. У кожної людини вони виникають автоматично через закладені з дитинства програми. Колись вони були корисні, поки людина була дитиною (“не роби те”, “не ходи туди”, “слухайся дорослих” і таке інше), але ж тепер Ви виросли і вони вам тільки заважають. Розглянемо основні.

А ЯКЩО… МЕНІ ПОДОБАЄТЬСЯ ЩО ЕКЗОТИЧНЕ? Чудово! Прочитайте ті самі 500 книг з цієї теми і витратьте на розвиток ті самі 5 РОКІВ. Матимете успіх, як би сумнівно зараз це не здавалось. Не потрібно намагатися розглянути кінець шляху, доки робляться лише перші кроки. Горизонт поки що закриває те, що буде попереду. Але це не означає, що там порожньо. Так не буває.

А ЯКЩО… МОЇ БАТЬКИ ХОЧУТЬ ЩОБ Я СТАВ ЮРИСТОМ? Обирайте СВОБОДУ завжди. Свободу, а не упередження. Свободу, а не задоволення чужих запитів. Тільки тоді зможете задовольнити свої. Батьки часто намагаються запхнути нас у ті самі вузенькі штанці, які носили все своє життя. Їм здається, що це вірно і безпечно, тому що добре знайоме. Але щоб досягти чогось незвичайного, потрібно робити щось незвичне. Іншого шляху немає. Обирайте свободу.

А ЯКЩО… МІЙ ВЧИТЕЛЬ ХОЧЕ ЩОБ Я ЙШОВ ЙОГО ШЛЯХОМ? Це нормально. Якщо вчитель є компетентним, то опануйте його шлях. А потім спробуйте власний варіант. Так ви перевершите свого вчителя, тому що дізнаєтесь більше.

А ЯКЩО МОЇ ДРУЗІ ПРОТИ? До біса таких друзів! Це не друзі. Справжні друзі підтримують. Вони зацікавлені у Вашому розвитку, як і Ви самі. Якщо ж люди гальмують – то вони не друзі. Намагайтесь завжди наближати себе до тих, хто несе позитив, і відсуватись від тих, хто несе негатив. Родичі, близькі, друзі… Не робіть ні для кого вийнятків. Це Ваше життя!

А ЯКЩО Я ХОЧУ СТАТИ СТРИПТИЗЕРОМ? Це не зміна себе. Це конкретна професія. Якщо подобаються танці чи шоу програми, то ідей у цій сфері величезна кількість. Обирайте те, що хочете освоїти досконало.

А ЯКЩО Я “ЗАНЯТИЙ” ЧИ ЛЮБЛЮ БУХАТИ І ТУСИТИ? Прочитате цю статтю через рік, коли все буде “хріново”.

А ЯКЩО Я ЗАГАЛЬНО НІФІГА НЕ ЗНАЮ І НЕ ВМІЮ? Почни все з самого початку.

А ЯКЩО Я НЕ МОЖУ КИНУТИ РОБОТУ ІЗ-ЗА ОБОВ’ЯЗКІВ? У цьому немає жодної проблеми. Людина, яка змінює себе та своє життя, завжди знаходить вільний час. Воно є. Просто треба переписати по хвилинах свій типовий день і точно можливо знайти купу вільного часу, який можна присвятити розвитку в потрібній сфері.

А ЯКЩО МЕНЕ КИНУЛА ДІВЧИНА ЧИ ДРУГ? Перестаньте витрачати на них свій час і більше ніколи не думайте про них. Як мінімум половина проблеми була від вас, але ви розумніші тому більше цінуєте свій час і сили, ніж вони.

А ЯКЩО… Я СОРОМ’ЯЗЛИВА ЛЮДИНА? Знайдіть силу у своїй слабкості. Так, якщо не дуже легко іде спілквання з людьми, але краще слухаєте, зосереджуєтесь і простіше вселити любов до себе. Це характерно для інтровертів. Знайдіть свої сильні сторони.

А ЯКЩО… МЕНЕ ПОСАДИЛИ ДО В’ЯЗНИЦІ? Що ж… У в’язниці матимете змогу прочитати багато книг. Не гальмуйте свого розвитку.

А ЯКЩО… МОЕ ЕГО ЗАВАЖАЄ РУХУ ВПЕРЕД? Марнославство має допомагати, а не заважати. Марнославство має заряджати прагненням перемоги. І не потрібно це показувати, інакше рух буде гальмуватись. Це має бути всередині, не випускайте назовні.

А ЯКЩО… НЕ ВДАЄТЬСЯ ЗНАХОДИТИ ІДЕЇ? Намагайтеся! Якщо не виходить підтягнутися на турніку навіть раз, це не означає, що потрібно кинути тренування. Це означає, що потрібно продовжувати робити спроби (тренуватися) до тих пір, поки не вийде. Не чекайте, що з першого дня з’являться класні ідеї. Все тренується.

А ЯКЩО… Я НЕ ВІРЮ В УСПІХ? Щодня дякуйте собі за те, що у вас вже є. Страх чи гнів, не надихає. ВДЯЧНІСТЬ – надихає. Не бійтеся часто говорити собі та іншим людям “ДЯКУЮ”. Це міст між Вашим світом і паралельним, в якому живе мільйон творчих ідей, що призводять до успіху.

А ЯКЩО… МЕНІ ПОСТОЯННО ЗАВАЖАЮТЬ? Людина, яка змінює себе та сферу своєї діяльності завжди стикатиметься людьми, які намагаються її придушити. Тому важливо навчитися говорити “НІ” і далі гнути свою лінію.

А ЯКЩО… Я РАДІЮ РОБОТІ В ОФІСІ? Радий за Вас.

А ЯКЩО… Я НЕ ЗНАЙДУ ВЧИТЕЛЯ? Хм…Ну Ви ж ВЖЕ пророкували цю статтю:-)

Денис Борисов

Оригінальний допис

Якість часу

Fri, 26 Sep 2014 12:38:32 +0300

The idea that ‘we don’t have time’. Human beings feel trapped by a world that focuses on the quantity of time, not the quality of time
— Maria Acle answers the question ‘what is the biggest problem we face in contemporary society?’

New Philosopher Magazine, Aug-Oct 2014

Власний переклад: “Існує ідея, що “у нас немає часу”. Людство відчуває себе таким, що потрапила до пастки, оскільки весь світ сфокусований на кількості часу, але не на якості.” – так відповіла Марія Екл на питання “з якою найбільшою проблемою стикнулось сучасне суспільство”

Журнал New Philosopher, Серпень-Жовтень 2014 року.

Як стати менеджером

Sun, 21 Sep 2014 08:09:24 +0300

Коротко та зрозуміло:) Посилання на першоджерело до можна дізнатись більше подробиць

Білль о Правах Тестувальника

Thu, 18 Sep 2014 10:15:16 +0300

Білль о Правах Тестувальника. Автор Том Гілб (Gilb 2003)

Тестувальники мають право відбирати вхідні дані для процесу тестування та відкидати працю низької якості.
Тестувальники мають право на несуперечливі та чіткі вимоги.
Тестувальники мають право тестувати якомога раніше з розвитком системи.
Тестувальники мають право включати свої тестові сценарії до інших технічних специфікацій.
Тестувальники мають право бути стороною, яка встановлює рівень якості, відповідно до якої вони тестуватимуть.
Тестувальники мають право на відповідні ресурси для професійного виконання своєї роботи.
Тестувальники мають право на рівномірне навантаження, а також на власне життя.
Тестувальники мають право вказувати на ризиковані наслідки використання продуктів, які їм не дозволили протестувати належним чином.
Тестувальники мають право на розгляд будь-яких специфікацій, які можуть торкнутися їхньої роботи.
Тестувальники мають право зосереджуватися на тестуванні продуктів та встановленні їх якості та надсилати погану роботу назад.

Посилання на джерело

Duolingvo: “шість рукостискань” лингвистики

Fri, 29 Aug 2014 11:10:34 +0300

Окрім “професійного та кар’єрного” розвитку та зростання іноді хочеться побайдикувати. Особливо зараз, коли у розпалі трохи меланхолійний кінець літа.
А кращого виду “байдикування” за пірнання у світ чогось несправжнього мені ще не доводилось зустріти. Занурюватися можна і до атмосфери гри (не обов’язково “комп’ютерної мозко-тупилки”, “Ерудит” та шахи — це теж ігри!), можна перенестись у вигаданий (або не дуже) світ цікавої книги, повністю перейнятись новими відчуттями.

Так от, виділити собі в день пів години на те, щоб поринути в нову мову (“людську”, не програмування) – мотивує знайдений нещодавно ресурс Duolingvo (не на правах реклами, просто особисто дуже сподобалося:))
Зареєструвавшись з російської мови ми отримуємо доступ до вивчення англійської та німецької, однак який “айтішник” не знає (хоча б більш-менш) англійської? Вказавши на сторінці вибору курсу іншу мову (англійська) ми отримуємо доступ до курсів французької, іспанської, португальської, голландської, ірландської, датської з вже підготовлених. А в майбутньому можна очікувати на шведську, угорську та інших.

І ось, маленька перша перемога!

З Новим 2014 Роком!

Thu, 26 Dec 2013 17:20:28 +0200

Відчуваю, що це буде останній запис… цього року;)

А тому хочу заздалегідь привітати всіх зі святами що настають (а для когось вони вже настали;)), побажавши Миру, Щастя, Спокою, Упевненості, Любові, Мудрості — і будьте здорові.

З повагою, Слава

Попрошу розповісти те, чого у Вас немає в резюме

Mon, 16 Dec 2013 18:13:22 +0200

Сподобалось це відео, де одна “досить відома людина” дає підказки з теми. Закортілось поділитися (та й просто – замітка на згадку).

Як навчити писати гарні тестові сценарії?

Sat, 07 Dec 2013 13:59:17 +0200

Іноді ми виростаємо. Це просто факт. Рух – це життя, навчання – це теж різновид руху. Отже, все життя ми вчимося. Але у кожної людини може настати той момент, коли не тільки вчишся самостійно, але намагаєшся водночас навчити іншу людину. Це може бути дитина, а може бути новий співробітник. А якщо цей співробітник працює у сфері контролю якості (тестування), то вміти писати відмінні тестові кейси – це МЕГА ВАЖЛИВО та мега потрібно.

…Потрапило до мене чергове чудове відео від Олексія Лупана. Людини, яку дуже поважаю як професіонала. І цитата звідти “прямо зачепила”: “Коли я вважав, що потрібно з самого початку все пояснювати як правильно робити, потім прийшов до висновку що не дуже і треба. Краще з самого початку дати написати як завгодно, передбачувано отримати нісенітницю у документі, а потім пояснити на основі його як треба зробити по-хорошому. Це приходить з досвідом.”

Ну а відео повністю ви, власне, можете подивитись далі. Дуже раджу, особисто сподобалось.

Скільки часу варто витратити на ефективне навчання?

Thu, 05 Dec 2013 12:08:02 +0200

Скільки часу потрібно, аби навчитися чогось?
Якщо правильно поставити мету, якщо позбавиться відволікань — достатньо 20 годин. 45 хвилин упродовж місяця. 45 хвилин ефективної практики. І можна досягти чудового результату. І не варто “зубрити” 20+ джерел. Достатньо 3-5.
Докладніше — у наступному відео.

Чи складно навчитися тестуванню?

Wed, 30 Oct 2013 13:49:46 +0200

Вчора в книзі Testing ASP.NET Web Applications “потрапила” на очі одна коротка, але водночас містка фраза. “Testing is easy; good testing is hard” (“Тестування є простим; добре тестування є важким” – переклад особистий)
Власне – це все.

За бажання придбати книгу Testing ASP.NET Web Applications можна тут

Тестування ASP.NET веб-додатків

Помилки та Хмарки

Tue, 29 Oct 2013 11:41:23 +0200

Переглядаючи нещодавно електронну пошту, звернув увагу на один “несподіваний” лист. Який закінчувався так:

“Перепрошуємо, якщо наша програма створила для Вас хоч якісь проблеми.
Нам дуже важливо зберегти Вашу довіру, тому ми повністю переглянули
процес розробки та тестування наших продуктів, щоб унеможливити подібні помилки.

Щоб згладити неприємне враження від помилки, ми збільшили
доступний для Вас простір на Яндекс.Диску на 200 ГБ. Залишайтеся з нами.”

Так уже вийшло, що причину таких глибоких вибачень від Яндекса я не відчув (не довелося), але отримати відчутний додатковий шматочок хмарки було дуже приємно. І тут виникла ідея, а чи не порахувати користі, які вже отримую від різноманітних безплатних хмарних сервісів? (Можна сперечатися або не сперечатися з приводу безпеки зберігання даних, але те, що вже “звик” і “капець як зручно” – факт).

OneDrive 15 (+”unlimited” якщо підписатись на Офис365) Gb
Mail.Ru Cloud 1024 Gb
Yandex.Drive 215 (+10 за запрошення) Gb
Google Drive 17 Gb
Dropbox 2 (+14 за запрошення) Gb
~~Ubuntu One 5 (+20 за приглашенных людей) Gb~~ (сервис зачинено)
iCloud 5 Gb
Baidu 0 (+2048) Gb

Отже, разом у вже 1278 (і можна збільшити ще на 2072 + “unlimited”) Gb

Update (квітень 2020 року):
Випадково в одному з чатів проскочив наступний список можливих “безплатних” “хмар”. Протестувати список поки не сталося, але “і для себе, щоб не забути”, і може комусь допоможе.

https://yunpan.360.cn – 360GB of free storage. (can be extended up to 36TB by downloading the PC and Android/iOS clients)
https://ozibox.com – 100GB of free storage.
https://surdoc.com – 100GB of free storage.
https://shared.com – 100GB of free storage.
https://adrive.com – 50GB of free storage
https://mega.co.nz – 50GB of free storage.
https://hubic.com – 25GB of free storage.
https://firedrive.com – 20GB of free storage.
https://copy.com – 15GB of free storage.
https://mediafire.com – 10GB of free storage. (40GB more available with other activities)
https://pcloud.com – 10GB of free storage (10GB more available with other activities)
https://box.com – 10GB of free storage.

![Облака](https://i0.wp.com/pp.vk.me/c624331/v624331859/26795/ZRNujhg7TNI.jpg?resize=564%2C376&ssl=1)Хмари – це не тільки айКлауд та ГуглДрайв:)

Якщо додати можливість зберігати документи на файлах безплатних хостингів, хмарних svn, git і т.д. – то накопичиться кругленька цифра. І вона постійно зростає.

І якщо припустити ситуацію, що доступ до Інтернету буде завжди, що можна довіряти цим сховищам власну інформацію — то виникає якесь почуття ейфорії: якщо раніше перед перевстановленням операційної системи (на домашньому ноутбуку) доводилося довго і старанно створювати бекапи, перевіряти “а чи не загубиться що-небудь?” то важливе”, то тепер можливо зберігати в одній хмарі всі важливі документи, в іншому – програми. І після швидкого перевстановлення тільки встигаєш почитуючи книгу “клікати” на файли установок, які “з’являються з нізвідки”. Зручно.

5 do’s and 5 don’ts автоматизації тестування

Fri, 04 Oct 2013 10:27:23 +0300

Зустрівся запис виступу Геннадія Алпаєва на онлайн-конференції Auto ConfeT&QA, який був зроблений навесні 2013 року про різні “переваги” та “недоліки” від автоматизації тестування. І собі на згадку, і поділитися з Вами.

Користь SQL або “де його взяти?”

Wed, 02 Oct 2013 14:22:11 +0300

Так уже вийшло, що без знання SQL в сучасному світі не те що АйТішником (програмістом, тестувальником) стати, але навіть влаштуватися на більш-менш добру посаду в банку чи до бухгалтерії важко (якщо немає деяких інших якостей, які не входять до тематики цього блогу :)). Що ж робити молодій і зеленій (“що подає великі надії”) людині, яка планує почати свою кар’єру в тестуванні, але в кожній вакансії леді з рекрутингового департаменту пишуть, що “необхідне знання SQL”?

[![Microsoft SQL Server](https://i0.wp.com/slavaqa.pp.ua/wp-content/uploads/2013/10/Microsoft-SQL-Server1-300x246.jpg?resize=300%2C246)](https://i0.wp.com/slavaqa.pp.ua/wp-content/uploads/2013/10/Microsoft-SQL-Server1.jpg)SQL важливий як для стартапів, так і для великих компаній

Як завжди, є два шляхи: вчити самостійно або “податись на курси” (є ще варіант “вчити або не вчити”, але він також не входить до тематики цього блогу:)).

Для тих хто обирає другий варіант знову ж таки є два шляхи: курси онлайн (найкращі, як мені здається, будуть тут) або очні “десь на просторах вашого міста” (якщо Ви живете у великому місті — то хтось та й заробляє на навчанні “молодих та перспективних”).

Книги +++–

Якщо ж Ви вирішите освоювати цю ношу самостійно, то тут настільки широке та неоране поле різноманітних ресурсів – що було б бажання.
Особисто я починав своє знайомство з цієї книги та саме їй віддаю перше місце з корисних посилань.
Непоганий підручник написали тут, і, як я розумію, автори “приклали руку” і до створення цього сайту із вправами. Обов’язково їх виконайте (хоча б що порадувати себе відмінними результатами та закріпити знання)!
Ще з російськомовних сайтів хотів би поділитися цим і ось цим
Перевірити знання можна (і потрібно) тут

Онлайн курси ++++++++++++

Нещодавно вийшов курс з SQL і на сайті Академії Майкрософт, але… не такі прості там тести, як очікував. Якщо бачиш SQL перший раз і хочеш вивчити, то без додаткових матеріалів здати їх з першого разу допоможе лише успіх.
Для кого англійська не є проблемою (або, навпаки, більш привабливою для навчання) також є безліч джерел.
Наприклад, ця дуже відома школа, або цей курс.
Посилання на курси зібрані тут, і для різноманітності можна переглянути цей старенький сайт (давно не оновлювався, але актуальності не втратив, чим особисто мене порадував і здивував).
Досить багато матеріалів можна знайти на найбільшому (з відомих мені) сайті презентацій, наприклад, цю.

Купа посилань? 🙂 Вдалого навчання!

З Днем Програміста!

Fri, 13 Sep 2013 15:07:23 +0300

Зі Святом Вас, Дорогі Программери:)

З Днем Тестувальника!

Mon, 09 Sep 2013 11:27:28 +0300

Ось він і настав, Цьогорічний День Тестувальника. Зі святом усіх причетних:)

Сум і смуток відхабреності

Tue, 03 Sep 2013 11:21:33 +0300

Був той час, що дуже активно читав Habrahabr, ділився думкою в коментарях… і в якийсь момент отримав мінус у карму. За що про що – як тоді не розібрався, і на час “затих” (ну а що, без карми – і ні плюсик поставити, ні профілем не похвалитися).

Час минав… І схотілося виправити ситуацію. Хабр пропонує це зробити цілком законним шляхом: написати статтю та сподіватись на краще. Але якось все не вистачало ідей/знань/умінь/відкриттів… І тут потрапила на очі стаття з Офіційного блогу Селеніуму про плани на третю версію. Зважився ризикнути, перекласти (адже можна розміщувати переклади на Хабре) і опублікувати.
Вирішено – зроблено. “Дрижачими руками” перед кліком на кнопку перевіряв “А раптом хтось уже, а що як виявиться дублікат”. Але… наче перший. І, несподівано для себе, потрапив одразу ж у блого-стрічку Software-testing.ru і їхнє дзеркало

Дрібниця, здавалося б, а все ж приємно.

Завдання для тестувальника початківця

Thu, 29 Aug 2013 09:42:31 +0300

Доволі часто в мене запитують “Як навчитись тестуванню?” Звичайно, є курси та їх цінність ніхто не збирається скасовувати! Але деякі люди просто не мають того “стартового капіталу”, з яким йти на курси, але є час і бажання себе спробувати до першої співбесіди.

Напевно, багатьом потрапляла до рук програма ListBoxer (потрапила вона і мені як тестове-вступне завдання на першому місці роботи). Але попросила мене якось “поділитися знаннями” одна добра знайома, у якої “під рукою” не було на той момент жодного апарату, куди можна було б встановити ListBoxer. Ось і з’явилася ідея накрапати простеньке (і водночас творче:)) завдання пошуку явних помилок і тренування написання тестових сценаріїв. А потім цим завданням поділився далі. І далі. І далі… 🙂
То чому б її не викласти тут? 🙂 Zadachka

А хто має бажання погратись із ListBoxer – посилання в студії ListBoxerFull
та невеликий бонус dumb (файли ListBoxer та Dumb взяті з http://iqa.com.ua/)

Довершений тестовий фреймворк

Thu, 29 Aug 2013 09:42:18 +0300

Протягом “програми самонавчання” знайшов цікаве відео про тестові фреймворки – Довершений тестовий фреймворк

Запрацювало!

Wed, 28 Aug 2013 11:05:20 +0300

Ура! Нарешті запрацювало!
… або Переходимо до Page Object Pattern

… Вирішив переробити структуру проекту автотестів із “банального” (але працюючого!:)) варіанта
Constants <- Helper <- Test <-Runners
в
Helper <- Modules; Tests (Helper, Modules)
де Modules – окремі класи (файли) для різних сторінок програми, Tests (Helper, Modules) – окремі класи (файли) для тест-сьютів для кожного окремого модуля (сторінки), що використовують методи з базового класу Helper та спадкоємців Modules. Та ось невдача: знань з основ програмування на C# не вистачало. Після кількаденного танцю із бубнем та переписування всього, консультацій з хлопцями-програмістами з проекту вийшло ось що у файлі тестів

{
    public TestsFirefox(): base(new FirefoxDriver())
    { }
}

public class TestsIE : TestsCases2TS
{
    public TestsIE(): base(new InternetExplorerDriver())
    { }
}

public TestsCases2TS(IWebDriver browser): this()
{
    Helper.driver = browser;
}

public TestsCases2TS()
{
    myHelper = new Helper();
    myModule = new Module();
    myHelper.baseURL = Helper.testServerBaseUrl;
    myHelper.verificationErrors = new StringBuilder();
}
public Helper myHelper { get; set; }
public Module myModule { get; set; }

І ось ЦЕ запрацювало!:) (власне, описи тестів та методів у самих файлах залишилися майже без змін)

Але більш докладно розібратися з конструкторами, інкапсуляцією та іншими радощами реалізації ООП в C# мені ще належить…

Lead SDET/QA Automation Engineer

Mon, 26 Aug 2013 17:11:37 +0300

VIACHESLAV KLEVCHENIA

Lead SDET/QA Automation Engineer

CONTACT INFORMATION

Address: Warsaw, Poland
Cell phone: +48518797940
E-mail: contacts@slavaqa.pp.ua
LinkedIn page link

SUMMARY

More than 14 years in Software Quality Assurance
Around of 10 years as SDET/QA Automation Engineer
Leading and mentoring QA teams members as well motivating team in general
Leading and prioritizing test automation instrumentation efforts and planned work
Using smart test-design techniques to intelligently cover AUT functionality
The highly-motivated person with goals of improvements in a variety of areas of technical and soft skills and solving problems
Well organized and social team player, capable to work either with a team or alone.

WORKING EXPERIENCE

2021 (October) – Present time

Employer: Sportradar Polska (https://sportradar.com/)
City, country: Warsaw, Poland
Department, position: Lead QA Engineer for Backbone Tribe

Project description: Sports technology company, at the intersection between sports, media and betting.

Responsibilities and Tasks: Work on creation of testing strategy withing department without QA-s and creation of test results dashboards solution for multi-components multi-repositories products.

2019 (September) – 2021 (September)

Employer: Paradox Interactive (via Vilmate) (https://www.paradoxinteractive.com/)
City, country: Kyiv, Ukraine Department, position: Lead QA Automation Engineer

Project description: DevOps department of lead gaming industry producer.

Responsibilities and Tasks: Created an easy-supportable and stable test framework over API (Python + pytest) also creation and maintain status monitoring tools.

Achievements: Deployed and evangelized modern regression test automation approach in multiple departments, helped to organize communication and information shared between separate project teams

2018 (January) – 2019 (September)

Employer: GlobalLogic (https://www.globallogic.com)
City, country: Kyiv, Ukraine Department, position: Sr. Test Automation Engineer in Networking project

Project description: Network device firmware development for international semiconductor producing client.

Responsibilities and Tasks: Write and support automated tests on different network levels (Python + .Net)

Achievements: Successfully support collaboration in multilingual international and intercontinental development team.

2017 (April) – 2018 (January)

Employer: Certent Inc. (http://certent.com/)
City, country: Kyiv, Ukraine Department, position: QA Automation Engineer in Equity Management team

Project description: Portal for administration and support equity management for public and private companies and portal for participants, based on Angular framework, with Oracle DB in the back-end.

Responsibilities and Tasks: Write and support automated tests on UI level (Selenium Webdriver + C# + xUnit.net), support CI processes (TFS and TeamCity), with DB-level based supporting tests (Oracle DB connection)

Achievements: Change test automation framework status from 300 flaky tests to 1600 stable functional regression tests with nice coverage of important portal functions in a short time (in the first five months)

2015 (November) – 2017 (April)

Employer: Diebold Nixdorf (http://www.dieboldnixdorf.com/, recently Wincor Nixdorf http://www.wincor-nixdorf.com/) City, country: Kyiv, Ukraine Department, position: QA Automation Engineer in NAMOS Cloud team

Project description: Cloud-oriented secured retail web-application for fuelling stations, based on microservices’ architecture, with Angular framework + Kendo-UI as frontend and RabbitMQ, MSSQL and RedisDB in bthe ack-end (intended to replace desktop “old” application).

Responsibilities and Tasks: Sprint planning for QA team, Test planning, Test-design, write and support automated tests on UI level (Webdriver + C# + JavaScript injections + NUnit2 and HP LeanFT + C# + NUnit3 + HP ALM), DB-level automated tests (.Net Entity Framework + NUnit), and REST API testing

Achievements: Build test automation framework with nice coverage of functional regression tests.

2010 (July) – 2015 (November)

Employer: Ciklum, Webforum AD (http://webforum.com/) City, country: Kyiv, Ukraine
Department, Position: QA Engineer

Description of Project: SaaS application with project management and document management functions with elements of internal CMS, using KendoUI for web-client and MSSQL and .Net framework in a back-end Teams size: 7 developers, 1 production database administrator, 2 BA, and 1 QA
Clients: Webforum/Aducera services

Responsibilities and Tasks: Manual testing and test-design as the main task; create automation regression (WebDriver + C# + MSUnit) tests from scratch as the additional task from the 2012.

Achievements: Support of development high-quality level web application and that helps to win tenders with big customers

2009 (September) – 2010 (July)

Employer: Rabota International (http://rabota.ua/)http://rabota.ua/ City, country: Kyiv, Ukraine Department, Position: Product Development/QA Engineer

Description of Project: Head-recruiting web portal Teams size: 4 developers, 1 interface designer, 1 SEO analyst, 1 product manager, 1 QA Clients: Marketing Department of Rabota International

Responsibilities and Tasks: Manual testing

Achievements: Support of development in time of big strategic changes, increase level of customers support and reduce feedback time

2008 (March) – 2009 (June)

Employer: Finport Technologies City, country: Kyiv, Ukraine Department, Position: QA Department/QA Engineer

Description of Project: Mainly framework-based document workflow systems (as desktop projects) and some internal web-portals. Teams size: From 3 to 7 (1-2 QAs, depends on the project). Clients: Main clients: Bayer Crop Science, Raiffeisen Bank Aval, General Procurator of Ukraine and Ukrainian Department of Bankruptcy.

Responsibilities and Tasks: Manual desktop and web testing

Achievements: Prepare detailed documentation and test artifacts, support in acceptance testing from the customer side.

SKILLS and KNOWLEDGE

“Human” Languages

English (~C1), Ukrainian (native), Russian (native), Polish (~B1), German (~A1)

Technical

C#, Python, Java, C++, git, Jenkins, GitLab, TeamCity, AWS, Azure, DevOps, SQL, nUnit3, xUnit, pytest, Selenium, Docker, Jira, Linux, algorithms, OOP, test automation, networking

Testing

test automation, security testing, test design, test planning, test strategy, test analysis, integration testing, regression testing, acceptance testing, functional and non-functional testing (load, performance), API testing, unit testing, embedded systems testing

Management

QA team leading and management, mentoring, applied Agile/Scrum practices

Soft skills

quick learning, responsible, commitment, consistency, is attentive to detail, high-speed decision-making, team player, public speaking

Courses and Certificates

VOLUNTEER EXPERIENCE

Role: Reviewer Organization: Packt Publishing September 2014 – February 2015 (6 months) Preproduction review of “Learning Selenium Testing Tools, Third Edition”

EDUCATION

Dates: 2018 – 2022, BS in Computer Science, “Systems, Technologies and Mathematical Methods of Cybersecurity”, National Technical University of Ukraine “KPI”
Dates: 2002 – 2008 (not graduated BS) “Applied physics and nanomaterials”, National Technical University of Ukraine “KPI”

ADDITIONAL PERSONAL INFO

Date of Birth: 1984-04-28
Place of Birth: Sievierodonetsk city, Lugansk region, Ukraine
Marital status: Married
Children: Daughter (born in 2006)

Маленький старт

Sun, 25 Aug 2013 21:59:57 +0300

Усі сайти починаються з чогось. Якісь з великих, об’ємних, важливих та потрібних статей. Якісь — із жарту, рисунків, коміксів. А тут — просте вітання-повідомлення. Вітаю! Якщо коротко описати те, на що потрібно очікувати — особисті думки та нотатки. Щось про тестування, щось — про життя, щось — по простому “про щось”.

Але, сподіваюсь, що ці думки зможуть бути для когось корисними, а чи просто цікавими.