salvador4k: (Default)
Закон Конвея,
изложенный Мелом Конвеем в статье How Do Committees Invent, опубликованной некогда очень популярным изданием Datamation еще в далеком 1968-м году. Ничего не изменилось

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
Conway's law was not intended as a joke or a Zen koan, but as a valid sociological observation. It is a consequence of the fact that two software modules A and B cannot interface correctly with each other unless the designer and implementer of A communicates with the designer and implementer of B. Thus the interface structure of a software system necessarily will show a congruence with the social structure of the organization that produced it.

Организации, проектирующие системы,
неизбежно производят системы, являющиеся копиями их организационных структур.
"Закон Конвея" не подразумевался как шутка или изречение в стиле дзен-буддизма, а как вполне обоснованное социологическое наблюдение. Оно основывается на простых фактах того, что два программных модуля А и Б не смогут нормально взаимодействовать между собой, если дизайнер и разработчик модуля А не в состоянии нормально общаться с дизайнером и разработчиком модуля Б; в следствии чего структура интерфейсов разработанной системы будет отражать некое совпадение с социальной структурой предприятия-производителя

Расширение закона Конвея Фредериком Бруксом
в книге "Мифический Человекомесяц" (кстати, советую почитать)

Because the design that occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.

Организационная структура
первоначально отражает проект первой системы, который наверняка был
ошибочным. Если проект системы должен допускать внесение изменений, то и
организация должна быть готова к переменам.
salvador4k: (Default)
Очень умные замечания по этому поводу.
Порой люди забывают, что Quality Assurance - это не только давить на кнопки или запускать скрипты.

Советую почитать однозначно:

...В представлении абсолютного большинства, тестинг ПО и QA суть одно и то же, но ведь это совсем не так. Обеспечение качества, как самостоятельная дисциплина, существует уже лет эдак 60, и не завязана на конкретную индустрию. QA, как дисциплина, применительна ко всему.
Суб-дисциплины включают в себя и контроль качества, и quality engineering (не знаю, как оно точно называется по-русски, ивритский термин - הנדסת איכות), и управление качеством на уровне процессов. Проверки ПО - частный случай приложения суб-дисциплины контроля качества...

Benny Epstein - И снова о QA
salvador4k: (Default)

Добрый день всем интересующимся
В соответствии с многими вопросами и большой заинтересованностью, решил таки поделиться с вами намеченной программой намеченного курса, который таки да откроется в намеченное время

Курс будет проводитсья на русском или иврите, по желанию заказчиков.
Весь материал, ессно - только на инглише, но программка курса есть и на иврите, если кому-нибудь больше по душе.

Предлагаю все замечания в комментарии.
Готов буду прислушаться к мнению других, так что у вас реально есть еще последний шанс изменить программу некоим образом.

Objectives

The main objective of the course is training the attendee to become software quality assurance professional, in terms of:

  • Becoming familiar with software testing and quality assurance as integral part of software development process, methodologies, terms and abbreviations used in the field
  • Acquiring ability to analyze requirement specifications documentation and render it into high level testing planning and design (STP / STD) and afterwards into low level test scenario preparation (STD / ATP), while maintaining traceability between requirements and test outcome
  • Obtaining basic knowledge in popular process enforcement and bug tracking tools
  • Gathering practical experience in popular tools and software used during software testing activities
  • Practical experience in performing quality assurance of distributed client-server systems.

Course Prerequisites

  • User level experience in Microsoft Windows working environment
  • User level experience in Linux / Unix CLI working environment – recommended
  • Academic degree – recommended
  • Previous experience with software development – recommended
  • Кnowledge of TCP/IP networking – recommended
  • English Knowledge on a technical reading level

Subjects

Introduction to Software Testing and Quality Assurance

This section main purpose is to introduce the attendee to the world of software development as a process, with emphasis to be done on the quality assurance tasks, responsibilities and influence.

  • Basic terms and abbreviations
  • Software development models and life cycles (Waterfall, Sashimi, Spiral, V model, Agile) in conjunction with authorities responsible for each phase in the cycle
  • Quality Assurance as part of software life cycle
  • Quality assurance methods (black-box testing, white-box testing)
  • Software testing phases (unit, component, integration, system, acceptance testing)
  • Test types and objectives (Functional, Interface, Compatibility, Availability, Performance, Compliancy, Usability, Stress and Longevity etc.)
  • Software testing strategy, phases and transitions (requirement specifications, planning, design, implementation, testing, reporting, maintenance)
  • Final exercise

Software Test Planning

The section uncovers accepted methodologies for preparation of STP documentation.

  • Guidelines of successful test planning – how, when, and what to plan
  • Interaction with different authorities during planning phase
  • Review of main subjects to be considered during test planning
  • Functional breakdown of planned system
  • Known pitfalls from practical experience
  • Hands-on experience in software test planning (real life example)

Software Test Design – Getting Into Nuts’n’Bolts

The section covers the main aspects of transition from theory to implementation, describes the accepted methodologies used for preparation of (S)TD documentation.

  • Guidelines of successful test design – templates, considerations
  • Interaction with different authorities during design phase, testability evaluation
  • Definition of successful test scenario
  • Functional testing plan for Black Box testing – boundary values,  error guessing, decision tables, equivalence partitions
  • White box testing – Statement coverage, Code review
  • Handling Non-functional requirements
  • Known pitfalls from practical experience, requirement “reverse-engineering”
  • Hands-on experience in software test design (real life example)

Software Test Running and Reporting

The section describes the common methods used for execution, collection of test results and analysis, actual quality metrics and key performance indicators

  • Test lab preparation and environment freezing
  • Compilation of test cycles, planning and management of version transitions
  • Test Suites - efficient execution of test scenarios
  • Defect submit, life cycle, management and follow up
  • Efficient interaction with different authorities during test execution
  • Evaluation of Exit criteria and reporting
  • Test closing activities
  • Known pitfalls from practical experience, prioritization and show stoppers

Availability and Recovery testing

The section describes the main purpose of those tests as a crisis-preventive measure

  • Terms and Abbreviations (MTBF, MTTR, MDT, availability levels)
  • Outcomes of recovery-untested system failures
  • Main subjects to be suspect for testing and assuring recovery success (hardware, backups, DB)
  • Recovery on different architectures

Interface & Conformance testing

Each software application has at least 1 interface towards other authority, be it human or another application. The section concentrates on main interface types

  • Human ó Machine interface – usability, design, functionality
  • Machine ó Machine interface – conformance and compliancy, security, error handling
  • Client-Server communication models (Thick Client / Thin Client)
  • Pitfalls
  • Hands-on Experience

Testing of Non-Explicit requirements

Requirement specifications will never be 100% complete; this section describes guidelines for common system aspects and behavior to be tested

  • Logging
  • Usability
  • Supportability and upgradeability
  • Free (exploratory) testing

Risk Management – QA as Part of Project

Software development is considered very interdependent industry. The section handles main aspects in risk management, in terms of identification, assessment, and mitigation

  • Risk identification and assessment and avoidance planning
  • Risk assessment calculations
  • Risk management planning – documentation, control and tracking, flag raising
  • Outcomes of unsuccessful risk management, examples from practical experience
  • Brooks Law

Advanced Approaches in SQA

The section describes advanced approaches towards software quality assurance, as well as several practical recommendations

  • Cost-effectiveness of QA – when is it worth to find a bug
  • Transition gates – Entry / Exit criteria
  • Adaptations of QA processes to software development model – Agile, XP vs. conservative development models
  • QA group as part of organization, impact of maturity on processes.
  • Pitfalls from practical experience

Test Automation

The section comes to describe the main benefits and disadvantages of automated software testing, as well as common practices for integration of automated testing into organization. Examples given on freeware web testing automation suites

  • Pros and Cons of automated testing
  • Functional testing automation
  • Performance and Stress testing automation
  • Regression vs. Progression - Could a robot replace a man?

Process and Tracking Tools

  • HP Quality Center – Brief Introduction
  • IBM Rational ClearQuest – Brief Introduction

Popular Tools and Important Software

  • SQL – understanding the language, basic queries
  • XML – understanding the basics
  • Debugging principles – symbols, stripped/unstripped code
  • Linux/Unix OS environment – basic commands and system architecture.
  • Sniffers
  • Hardware virtualization environments (VMWare server)
  • Functional Testing suites
Открыта запись на курс. Подробнее здесь: http://www.nexus-it.co.il/ru/training/software-quality-assurance/practical-sqa-i.html
salvador4k: (Default)
Внимание,
Открывается запись на курс Practical Software Quality Assurance I.
Курс проводится в Хайфе и Тель-Авиве
Дата открытия курса: 26/04/2009, воскресение

Ссылка на программу курса на сайте компании: www.nexus-it.co.il/ru/training/software-quality-assurance/practical-sqa-i.html

Контактная информация:
Телефон: 1800-10-20-74 (воскресенье - четверг, 9:00-18:00)
Факс: 072-2-740-740
E-Mail: info@nexus-it.co.il

Дополнительную информацию можно получить по телефону, факсу, электронной или обыкновенной почте
Свяжитесь с нами для того, чтобы мы могли внести вас в рассылку 
salvador4k: (Default)
Если кто-нибудь еще не видел, присоединяйтесь к нашей группе на одноклассниках.ру

Советы, вакансии, обсуждения и много чего еще.

http://www.odnoklassniki.ru/group/43853546717355

salvador4k: (Default)

В следствие вопроса в коммюнити rabota_il, давайте проставим точки над i
 
salvador4k: (Default)
Недавно прочитал книгу, от корешка до корешка (к сожалению, дабы не испортить чистоту восприятия, читал перевод)
Много думал

Что же это получается, грабли не исчезают, а всего навсего превращаются в более тяжелую и больную газонокосилку


Решил поделиться несколькими цитатами (увы, на русише). Будет время и желание - кореллирую с оригиналом. Но это уже потом, половину, может быть




salvador4k: (Default)
Меня часто спрашивают, в чем заключается разница между QA (quality assurance) и QC (quality check)
Ну, первое обьяснение довольно тривиально. QC заключается в рутинном исполнении одних и тех же тестов на каждую деталь, сошедшую с конвейера (или же на подгруппу деталей, типа 1 на 1000 итд)
Задача тестов - удостовериться в исправности тестируемого компонента и его соответствии принятым нормам. Нормы в этом случае являются сводом законов, посланных свыше главным технологом или кем еще, но явно напоминают десять заповедей, с которыми надо соглашаться вне зависимости от собственного мнения.
То есть, при изготовлении партии лампочек, очень хотелось бы, чтобы хотя бы часть из них работала, и выяснить ее работоспособность довольно просто

Profile

salvador4k: (Default)
salvador4k

May 2011

S M T W T F S
12 34567
891011121314
15161718192021
22232425262728
293031    

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 23rd, 2017 12:09 am
Powered by Dreamwidth Studios