System Testing in Software Development Life Cycle

System testing of software is the black box testing conducted on a complete and fully integrated software product based on the software requirements specification. In main focus of this testing is to evaluate Business, Functional and End-user requirements implementation.

In Software Development Life Cycle the System Testing performs as the first level of testing where the application is tested as a whole in environment that particularly resembles the effective production environment in order to check if developed software meets functional requirements and to test, validate and verify both the Application Architecture and Business requirements. Basically this is the full end to end testing on the software on the similar to production environment.

System Testing preparation procedure:
  • Write/Update System Test Plan based on project plan, test strategy & main test plan
  • Create/Update test cases covering all functional, non-functional, technical & UI requirements and issues found during passed test cycles
  • Define and create test data based on main test design techniques, experience of QA engineers and specific requirements of customers.
  • Develop/Update automation test scripts using advanced automation test tools, e.g. Selenium WebDriver for web UI testing, TestComplete for Windows GUI testing, HP LoadRunner or JMeter for load, performance and stress testing
  • Ensure that functional smoke and the most important regression tests are automated, configured and free of defects
  • Ensure that required load, performance and stress scripts and scenarios are configured for running in different environments

System testing execution procedure:
  • Automatic execution of smoke, regression and functional tests
  • Manual testing of areas not covered by automated tests
  • Execution of load, performance and stress tests only after fixing of all critical and blocker issues
  • Report issues to the bug tracking system
  • Generate and send final system test report

In case if iterative development model is implemented the system testing is repeated on each iteration until quality of application meets the test exit criteria defined in the system test plan.

Comments

Post a Comment

Popular posts from this blog

QA Chapter

There are different point of view on organising a QA chapter. As a QA manager, I see it in the following way. If you ask me ` How  should  QA Chapter look like?` , I would suggest the following structure: Chapter Lead: Person taking final responsibility for decisions Mandatory: 3 QA engineers, 1 BE engineer, 1 FE engineer Optional: Product Owner, Architect, DevOps engineers NOTE: It is very important for me to have representatives of different roles in the chapter, since everyone sees how to improve quality and where to apply improvements differently.  If you ask me ` What  are  QA Chapter  areas of responsibility ?`, I will answer that the agenda of QA Chapter meetings should be based on the following areas: Product quality: Quality of Development Quality of Testing Quality Control Quality of Delivery Visibility of QA work If you ask me ` How are you going to make your QA Chapter performing well?` , I will answer that we will need to define a set of rules and constantly monitor tha
Read more

Organizing UI automation testing

In recent years it is becoming less and less companies where you can meet dedicated test teams working with different development teams under the same product. This is most likely due to financial reasons because there are not so many companies who can afford to keep a team dedicated exclusively to testing and everything related to it. Nowadays a majority of software development companies work using Agile & Scrum, where all team members (software engineers, architects, programmers, analysts, QA experts, testers and etc.) are sitting together and doing their best to meet the goals of the sprint. In such projects testers, in principle, may know nothing about work of their colleagues from other teams because their areas of responsibilities intersect not very often or do not intersect at all. It can work fine until we are not starting talking about organizing automation testing and everything related to it: planning, design, implementation of frameworks and tests, support. I
Read more

Leader is not an individual contributor

On many interviews for the leader's role you can hear questions like:  - Who pushed for this change? Who proposed this improvement? Who implemented this approach?  For me personally, leaders should answer in the following direction: - My team! It was a team effort! It was proposed by an individual, but implemented by the team!  Unfortunately, in many cases interviewers want to hear:  - It was me! I did this! It was my initiative!  They want to see an individual contributor pushing for changes and doing mostly a hands on work as a leader. Most likely, in their environment they need such a person.  My point of view, is that leader is a buddy, who can organise, motivate, inspire people. Sometimes he should lead by example, sometimes he should explain your fault one on one, sometimes he should motive a whole team. From day one in his role, real leader should start thinking about finding another leader in his team, to be able to delegate and share work with team mates. Only then you wil
Read more