1. Video

    • 09:21

      Hướng dẫn lắp ráp xe robot 3 bánh

      Tự lắp ráp xe robot 3 bánh đơn giản, đây là bước đầu tiên để bạn có sườn xe cơ bản trước khi thêm các linh kiện điều khiển và modules. Mua linh kiện: http://linhkienrobotics.com/ Blog: http://www.hoclamrobot.com/ Xem thêm

      1,697 lượt xem -


    • 01:58

      Mạch điện tử của robot tránh vật cản

      Chào các bạn, mình là ANH ROBOT. Video này mình sẽ hướng dẫn các bạn lắp mạch điện tử cho robot tránh vật cản. Chúc các bạn chế tạo robot thật vui và có nhiều phát minh sáng chế trong tương lai. Xem thêm

      1,146 lượt xem -


    • 04:28

      NẠP BOARD, CÀI DRIVER cho ARDUINO - Arduino 3

      Chuỗi video nhập môn Arduino. Phần 3: nạp board và cài driver Link tải ở đây nhé: http://linhkien69.vn/cach-cai-dat-driver-arduino-r3_n57974_g723.aspx

      1,135 lượt xem -


    • 05:52

      Cài đặt ARDUINO và mô phỏng PROTEUS- Arduino 1

      Hướng dẫn cài đặt arduino và mô phỏng trên proteus để lập trình điều khiển thiết bị Thư viên arduino cho proteus down ở đây nhé: https://www.facebook.com/groups/770915966338402/870723016357696/ Địa chỉ mua thiết bị: http://linhkienrobotics.xim.vn/ Xem thêm

      829 lượt xem -


    • 09:51

      Sơ lược về Arduino IDE - Arduino 2

      Chuỗi video nhập môn Arduino. Phần 2: sơ lược về Arduino IDE Fanpage (English): https://www.facebook.com/groups/1426364030991469/?fref=ts Fanpage (tiếng Việt): https://www.facebook.com/groups/770915966338402/?fref=ts Xem thêm

      521 lượt xem -


    • 13:54

      Build KANBAN board and burndown chart

      Được thực hiện bởi Tạ Thị Thinh. Giảng viên của trung tâm QRS thường xuyên tổ chức đào tạo và luyện thi ISTQB, QA Tester chuẩn Nhật, Automation testing

      1,452 lượt xem -

      Tạ Thị Thinh Tạ Thị Thinh

    • 22:02

      Giới thiệu về Agile Scrum- phương pháp làm việc nhóm- bởi Tạ Thị Thinh

      Giảng viên Tạ Thị Thinh - Trưởng phòng đảm bảo chất lượng (PQA) của công ty 100% vốn của Nhật Bản ( Co-well) và là giảng viên chính thức cho các trung tâm đào tạo Tester và QA ở Hà Nội.- Chị đã có trên 10 năm kinh nghiệm thực tế về kiểm thử phần mềm ( testing) và đảm bảo chất lượng phần mềm ( QA), từng làm ở các công ty lớn như Fsoft, VNP group, Seta Internation Asia.- Đào tạo nhiều nhân viên mới cho các công ty, các bạn sinh viên mới ra trường, hướng dẫn luyện thi cho trên 500 người lấy được chứng chỉ ISTQB ( chứng chỉ quốc tế cho tester) Xem thêm

      544 lượt xem -

      Tạ Thị Thinh Tạ Thị Thinh

    • 11:21

      Tóm tắt kiến thức luyện thi ISTQB foundation chapter 1 part 1 by Tạ Thị Thinh

      Với kinh nghiệm giảng dạy ISTQB foundation suốt 3 năm, chị Tạ Thị Thinh đã tóm tắt lại các kiến thức cơ bản nhất cần phải nắm được cho từng chương bằng hình ảnh và các phương pháp dễ nhớ nhất. Sau là kiến thức tổng hợp ngắn gọn nhất của ISTQB foundation CHAPTER 1: Fundamentals of Testing 1.1 Why is Testing Necessary (K2) 1.1.1 Software Systems Context (K1) 1.1.2 Causes of Software Defects (K2) Why do faults occur in software? Software is written by human beings Who know something, but not everything Who have skills, but aren’t perfect Who do make mistakes (errors) Under increasing pressure to deliver to strict deadlines No time to check but assumptions may be wrong Systems may be incomplete Failures must be corrected in the software The cost of finding and fixing defects rises considerably across the life cycle 1.1.3 Role of Testing Rigorous testing of systems and documentation can help to reduce the risk of problems Contribute to the quality of the software system, if the defects found are corrected before the system is released Meet contractual or legal requirements, or industry-specific standards. 1.1.4 Testing and Quality (K2) –     Testing measures software quality –     Testing can find faults; when they are removed, software quality  is improved –     Testing is a part of quality assurance –     Measure the quality of software in terms of defects found for both functional and non-functional software requirements and characteristics –     Give confidence in the quality of a software if it finds few or no defects and we have good test designs –     Improve the quality of future system 1.1.5 How Much Testing is enough? (K2) It depends on RISK –     Risk of missing important faults –     Risk of incurring failure costs –     Risk of releasing untested or under-tested software –     Risk of losing credibility and market share Risk of missing a market window Risk of over-testing, ineffective testing Test time will always be limited – Using RISK to determine –     What to test first –     What to test most –     How thoroughly to test each item –     What not to test ( this time) –     Allocate the time available for testing by prioritizing testing 1.2 What is Testing? K2) –     Test activities exist before and after test execution: planning and control, choosing test conditions, designing and executing test cases, checking results, evaluating exit criteria, reporting on the testing process and system under test, and finalizing or completing closure activities –     Testing also includes reviewing documents (including source code) and conducting static analysis. Test Objectives: Finding defects Gaining confidence about the level of quality Providing information for decision-making Preventing defects Prevent defects –     Designing tests early in the life cycle can help to prevent defects from being introduced into code. –     Reviews of documents (e.g., requirements) and the identification and resolution of issues also help to prevent defects appearing in the code. Different objectives in different phase –     In development testing: find as many defect as possible –     In acceptance testing: confirm that the system works as expected, to gain confidence that it has met the requirements. –     In some cases: assess the quality of the software to give information to stakeholders of the risk of releasing the system at a given time. –     Maintenance testing often includes testing that no new defects have been introduced during development of the changes. –     During operational testing: assess system characteristics such as reliability or availability. Debugging and testing are different. –     Dynamic testing can show failures that are caused by defects. –     Debugging is the development activity that finds, analyzes and removes the cause of the failure.. –     Re-testing by a tester ensures that the fix does indeed resolve the failure –     Testers test and developers debug – 1.3 Seven Principles of Testing Testing shows presence of defects –     Testing can show that defects are present, but cannot prove that there are no defects. –     Testing reduces the probability of undiscovered defects remaining in a software but, even if no defects are found, it is not a proof of correctness Exhaustive testing is impossible –  Test everything ( all combination of inputs and preconditions) is not feasible –  Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts Early testing –  Testing activities should start as early as possible and focus on defined objectives – Perform the test design and review activities early can finds defects early on when they are cheap to find and fix Defect clustering – A small numbers of modules usually contains most of the defects discovered during pre-release testing, or is responsible for most of the operational failures – Rule 80/20: Module core often contains 80% defects Pesticide paradox – If the same tests are repeated over and over again, no new defects can be found – To overcome this pesticide paradox, test cases need to be regularly reviewed and revised; – New and different tests need to be written to exercise different parts of the software to find potentially more defects Testing is context dependent – Testing is done differently in different context – Ex: Safety-critical software is tested differently from an ecommerce site Absence of error fallacy – Finding and fixing defects does not help if the system built is unusable and does not fulfill the users’ needs and expectations 1.4 Fundamental test process 1.4.1 Test Planning and Control (K1) Test planning is the activity of defining the objectives of testing and the specification of test activities Test planning tasks: –           Determine the scope and risks and identify the objectives of testing –           Determine the test approach –           Implement test policy and/or test strategy –           Determine the required test resources –           Schedule –           Determine the exist criteria Concepts: –           Test policy: A high level document describing the principle, approach and major objectives of organization regarding testing –           Test strategy: A high level description of the test types to performed –           Test approach: The implementation of the test strategy for a specific project –           Test ware: includes test cases, test plan, test data Test control is the ongoing activity of : –           comparing actual progress against the plan –           reporting the status, including deviations from the plan. –           taking actions necessary Test control task: –           Measure and analysis the results of reviews and testing –           Monitor and document progress, test coverage and exit criteria –           Provide information of testing to make evaluation –           Initiation corrective actions 1.4.2  Test Analysis and Design is the activity during which general testing objectives are transformed into tangible test conditions and test cases. Test Analysis and Design tasks: –           Reviewing the test basis –           Evaluating testability of the test basis and test objects –           Identifying and prioritizing test conditions –           Designing and prioritizing high level test cases –           Identifying necessary test data to support the test conditions and test cases –           Designing the test environment setup and identifying any required infrastructure and tools –           Creating bi-directional traceability between test basis and test cases 1.4.3 Test Implementation and Execution (K1) is the activity where test procedures or scripts are specified, the environment is set up and the tests are run Test Implementation and Execution tasks: –           Finalizing, implementing and prioritizing test cases –           Developing and prioritizing test procedures, creating test data, writing test scripts. –           Creating test suites from the test procedures for efficient test execution –           Verifying that the test environment has been set up correctly –           Verifying and updating bi-directional traceability between the test basis and test cases –           Executing test procedures either manual or automate –           Logging the outcome of test execution –           Comparing actual results with expected results –           Reporting discrepancies as incidents –           Repeating test activities in order to confirm a fix 1.4.4 Evaluating Exit Criteria and Reporting (K1) Evaluating exit criteria is the activity where test execution is assessed against the defined objectives. This should be done for each test level –           Checking test logs against the exit criteria specified in test planning –           Assessing if more tests are needed or if the exit criteria specified should be changed –           Writing a test summary report for stakeholders 1.4.5 Test Closure Activities (K1) Test closure activities collect data from completed test activities to consolidate experience, testware, facts and numbers. –           Checking which planned deliverables have been delivered –           Closing incident reports or raising change records for any that remain open –           Documenting the acceptance of the system –           Finalizing and archiving testware, the test environment and the test infrastructure for later reuse –           Handing over the testware to the maintenance organization –           Analyzing lessons learned to determine changes needed for future releases and projects –           Using the information gathered to improve test maturity 1.5 Psychology of testing Level of independence –           None: tests designed by the person who wrote the software –           Tests designed by a different person –           Tests designed by someone from a different department or team ( e.g test team) –           Tests designed by someone from a different organisation ( e.g agency) Communication about defects –           Testing is very constructive in the management of product risks. –           Looking for failures in a system requires curiosity, professional pessimism, a critical eye, attention to detail, good communication –           Need good interpersonal skills to communicate factual information about defects –           Communicate findings on the product in a neutral, fact-focused way without criticizing the person who created it. –           Explain that by knowing about this now we can work round it or fix it so the delivered system is better for the customer. –           Start with collaboration rather than battles.   Ngoài ra bạn có thể download nhiều tài liệu hay khác về testing theo link sau: http://bit.ly/2r3szBD Xem thêm

      1,006 lượt xem -

      Tạ Thị Thinh Tạ Thị Thinh

    • 05:59

      Tóm tắt kiến thức luyện thi ISTQB foundation Chapter 3 part 1 bởi Tạ Thị Thinh

      CHAPTER 3: Static Techniques (K2)3.1 Reviews and the test process- Defects detected during reviews early in the life cycle- Much cheaper to remove than those detected by running tests- Improve development productivity- Reduce timescales, cost and time- Fewer defects- Improve communication- Typical defects that are easier to find in reviews than in dynamic testing include: deviations from standards, requirement defects, design defects, insufficient maintainability and incorrect interface specifications.3.2.1 Activities of a Formal Review (K1)A typical formal review has the following main activities:3.2.2 Roles and Responsibilities (K1)ManagerModeratorReviewerAuthorScriber3.2.3 Types of Reviews (K2)StageInformalWalkthroughTechnical reviewInspectionPlanningNoYesYesOptional managementYesKick-offNoYesYesYesIndividual preparationNoOptionYesOption checklistYesReview meetingNoYesYesYesRe-workNoYesYesYesFollow upNoOption review report with list of findingsYesYesMetrics gatheringReport with list of findingEvaluate exit criteria3.2.4 Success Factors for Reviews (K2)- Specific objectives- Right people- Tester is a valuable reviewer- Welcome defects- Trust atmosphere- No people issue- Suitable review technique- Checklist- Training- Management support- Learning, improve3.3 Static Analysis by Tools (K2)The value of static analysis is:–              Early detection of defects prior to test execution–              Early warning about suspicious aspects of the code or design by the calculation of metrics, such as a high complexity measure–              Identification of defects not easily found by dynamic testing–              Detecting dependencies and inconsistencies in software models such as links–              Improved maintainability of code and design–              Prevention of defects, if lessons are learned in developmentTypical defects discovered by static analysis tools include–              Referencing a variable with an undefined value–              Inconsistent interfaces between modules and components–              Variables that are not used or are improperly declared–              Unreachable (dead) code–              Potentially infinite loops–              Overly complicated constructs–              Programming standards violations–              Security vulnerabilities–              Syntax violations of code and software modelsCompilers may offer some support for static analysis, including the calculation of metricsNgoài ra bạn có thể download nhiều tài liệu hay khác về testing theo link sau: http://bit.ly/2r3szBD Xem thêm

      720 lượt xem -

      Tạ Thị Thinh Tạ Thị Thinh

    • 09:27

      Tóm tắt kiến thức luyện thi ISTQB Chapter 6 part 1

      Chúng tôi tiếp tục gửi đến các bạn bản tóm tắt ISTQB foundation của chị Tạ Thị Thinh giảng viên 3 năm kinh nghiệm đào tạo ISTQB CHAPTER 6: Tools support for testing 6.1 Types of Test Tools (K2) data-driven scripting technique keyword-driven scripting technique Data files store test input and expected results in    table or spreadsheet data files store test input, expected results and keywords in table or spreadsheet   support capture/playback tools Writing script manually   6.2 Effective Use of Tools: Potential Benefits and Risks (K2) Risks of using tools Unrealistic expectations Underestimating Over-reliance Neglecting Vendor Open-source Unforeseen 6.3 Introducing a Tool into an Organization Ngoài ra bạn có thể download nhiều tài liệu hay khác về testing theo link sau: http://bit.ly/2r3szBD Xem thêm

      876 lượt xem -

      Tạ Thị Thinh Tạ Thị Thinh