CI/CD – Full Stack QE https://fullstackqe.org Just another WordPress site Wed, 05 Oct 2022 19:27:05 +0000 en-US hourly 1 https://wordpress.org/?v=6.1.6 155680629 Practical Tips to Speed up the Software Delivery Performance https://fullstackqe.org/practical-tips-to-speed-up-the-software-delivery-performance/ Wed, 05 Oct 2022 19:22:48 +0000 https://fullstackqe.org/?p=790 Continue reading "Practical Tips to Speed up the Software Delivery Performance"

]]>
This post will give you enough ideas to improve software delivery performance (and Automation Plays a key role here) and how to measure software delivery performance using statistical methods. I would like to share industry proven and practical tips which helps you speed up the Software Delivery Performance.

Accelerate classified the capabilities into 4 categories:

Technology & Automation capabilities:

Product and Process Capabilities:

Lean Management and Monitoring Capabilities:

Cultural Capabilities:

In next couple of articles, we will go over these capabilities one by one.

]]>
790
How to Speed Up Software Development? https://fullstackqe.org/how-to-speed-up-software-development/ Tue, 24 Aug 2021 19:26:53 +0000 https://fullstackqe.org/?p=777 Continue reading "How to Speed Up Software Development?"

]]>
Why is Faster Software Development Important?

Faster software development is important because it saves time and money.

In a business world that is more competitive than ever before, it’s important to be able to develop software as quickly as possible. Today’s software developers need to be able to build out new features for the company’s product or service, and they need to do so quickly. The faster that this can happen, the less time is wasted, which means that companies will be more prepared and have a higher chance of success in this competitive market.

What Practices Will Help You Speed Up Your Software Development?

  1. Shift Left through Automation
  2. Implement CI/CD
  3. Automate as many tasks as possible – coding, data entry, testing, etc.
  4. Make defects visible so they can be fixed early and often – unit testing, nightly builds, etc.
  5. Know what you want before you build it – are requirements clear? does the design make sense? are there risks or side effects we should know about?
  6. Do things in parallel wherever possible – running multiple tests, running multiple code reviews at the same time, etc.
  7. Be responsive to changes in requirements and design from stakeholders and teammates
  8. Limit your work in progress
]]>
777
Why You Should Consider the Testing Pyramid Structure? https://fullstackqe.org/why-should-sdets-care-about-the-test-pyramid/ Fri, 02 Jul 2021 20:22:05 +0000 https://fullstackqe.org/?p=743 Continue reading "Why You Should Consider the Testing Pyramid Structure?"

]]>
The purpose of the test pyramid is to provide a structure for designing and executing tests. It is also the cornerstone of testing at Google.

The test pyramid has four layers – unit tests, service tests, integration tests, end-to-end or acceptance tests. By dividing up the different types of tests into these levels, it becomes easier to decide what type of testing needs to be done when building and maintaining software.

At the bottom are unit tests. Unit tests are “white box” tests because they interact directly with product code. They typically perform operations on functions, methods, and classes. Unit tests should be concise, to the point, and focused on a single object/variation. They should be devoid of external dependencies and should instead rely on mocks/monkey-patching. These tests took less time to execute.

Integration tests are located in the center. Integration tests examine the point at which two distinct entities come together. They should be “black box” in nature, interacting with actual instances of the product being tested, rather than with code. Integration tests include service call tests (REST, SOAP, and others).

End-to-end tests are at top level. End-to-end tests trace a system’s path. They could be argued to be a multi-step integration test, and they should also be “black box.” Typically, they interact with the product in the same way that a real user would. Web UI tests are an example of integration tests, as they require the entire stack to run.

And manual testing is the cherry on top. Certain types of tests, such as exploratory or usability testing, cannot be automated, but we should always strive to minimize the number of manual tests.

You should be aware that as we progress up the pyramid, three factors begin to increase:

  • Costs associated with the development and maintenance of tests
  • Time frame for execution
  • Possibility of erroneous negatives

Key aspects relating to the software testing pyramid include the following:

Avoid conducting duplicate tests at multiple levels. There is no reason to conduct the same tests at various levels. For instance, if boundary values were validated in unit tests, they should not be repeated in the GUI – you will not obtain any new data.

One should strive to reduce the difficulty of tests whenever possible. For example, you can verify interest calculation on a negative sum at a “medium level” or even at the unit test level. Therefore, why should you do it at the UI level? Lower-level test automation is more efficient; it enables you to identify defects earlier and saves you time and money.

]]>
743
Agile Without Dedicated QA [Video] https://fullstackqe.org/agile-without-dedicated-qa-video/ Mon, 21 Jun 2021 08:57:49 +0000 https://fullstackqe.org/agile-without-dedicated-qa-video/ Continue reading "Agile Without Dedicated QA [Video]"

]]>
In the early days of Agile, methods such as Extreme Programming advocated for shipping without a QA phase. In fact, they often didn’t have dedicated software testers or even bug-tracking systems. And yet there are stories of these teams producing an order of magnitude fewer defects than normal. What did these teams do, and why did it work? And what role does that leave for QA? In an age where Agile is interpreted to mean “sprints” and “story points,” the technical side of Agile is often forgotten. This presentation discusses the technical underpinnings of Agile and how they lead to true business agility.

Click here to download the slides.

Author: James Shore, The Art of Agile | First published at: PNSQC 2019

]]>
712
8 Habits of Highly Successful Continuous Testing Teams https://fullstackqe.org/8-habits-of-highly-successful-continuous-testing-teams/ Sun, 06 Jun 2021 13:22:22 +0000 https://fullstackqe.org/?p=706

https://faun.pub/8-habits-of-highly-successful-continuous-testing-teams-e9aabc861708

]]>
706
Understanding Continuous Integration – Part 2 https://fullstackqe.org/understanding-continuous-integration-part-2/ https://fullstackqe.org/understanding-continuous-integration-part-2/#comments Fri, 30 Oct 2020 20:46:18 +0000 https://fullstackqe.org/?p=569 Continue reading "Understanding Continuous Integration – Part 2"

]]>
[Must Read Part 1]

In addition to automated tests, organizations using continuous integration typically use build tools to implement continuous quality control. In addition to running unit and integration tests, such tools can run additional static and dynamic tests, measure and profile performance, extract and format documentation from the source code, and facilitate manual quality assurance processes. This continuous application of quality control aims to improve the quality of the product as well as reduce the time taken to deliver it by replacing the traditional practice of applying quality control after completing all development.

Build tools can be linked to automatic deployment tools, which can fetch the appropriate build from the continuous integration or build server and deploy it into one or more development, test, staging, or even production environments. This reduces the errors and delays associated with relying on specialized staff or programmers to install releases in these environments.

Continuous integration can provide the following benefits:

  • Allows earlier detection and easier root cause analysis of integration problems and conflicting changes
  • Gives the development team regular feedback on whether the code is working
  • Keeps the version of the software being tested within a day of the version being developed
  • Reduces regression risk associated with developer code refactoring due to rapid re-testing of the code base after each small set of changes
  • Provides confidence that each day’s development work is based on a solid foundation
  • Makes progress toward the completion of the product increment visible, encouraging
  • developers and testers
  • Eliminates the schedule risks associated with big-bang integration
  • Provides constant availability of executable software throughout the sprint for testing,
  • demonstration, or education purposes
  • Reduces repetitive manual testing activities
  • Provides quick feedback on decisions made to improve quality and tests

However, continuous integration is not without its risks and challenges:

  • Continuous integration tools have to be introduced and maintained
  • The continuous integration process must be defined and established
  • Test automation requires additional resources and can be complex to establish
  • Thorough test coverage is essential to achieve automated testing advantages
  • Teams sometimes over-rely on unit tests and perform too little system and acceptance testing

Continuous integration requires the use of tools, including tools for testing, tools for automating the build process, and tools for version control.

]]>
https://fullstackqe.org/understanding-continuous-integration-part-2/feed/ 1 569
Understanding Continuous Integration – Part 1 https://fullstackqe.org/understanding-continuous-integration-part-1/ Fri, 30 Oct 2020 20:40:07 +0000 https://fullstackqe.org/?p=567 Continue reading "Understanding Continuous Integration – Part 1"

]]>
Delivery of a product increment requires reliable, working, integrated software at the end of every sprint. Continuous integration addresses this challenge by merging all changes made to the software and integrating all changed components regularly, at least once a day. Configuration management, compilation, software build, deployment, and testing are wrapped into a single, automated, repeatable process. Since developers integrate their work constantly, build constantly, and test constantly, defects in code are detected more quickly.

Following the developers’ coding, debugging, and check-in of code into a shared source code repository, a continuous integration process consists of the following automated activities:

  • Static code analysis: executing static code analysis and reporting results
  • Compile: compiling and linking the code, generating the executable files
  • Unit test: executing the unit tests, checking code coverage and reporting test results
  • Deploy: installing the build into a test environment
  • Integration test: executing the integration tests and reporting results
  • Report (dashboard): posting the status of all these activities to a publicly visible location or emailing status to the team

An automated build and test process takes place on a daily basis and detects integration errors early and quickly. Continuous integration allows Agile testers to run automated tests regularly, in some cases as part of the continuous integration process itself, and send quick feedback to the team on the quality of the code. These test results are visible to all team members, especially when automated reports are integrated into the process. Automated regression testing can be continuous throughout the iteration. Good automated regression tests cover as much functionality as possible, including user stories delivered in the previous iterations. Good coverage in the automated regression tests helps support building (and testing) large integrated systems. When the regression testing is automated, the Agile testers are freed to concentrate their manual testing on new features, implemented changes, and confirmation testing of defect fixes.

[Click here to Read Part 2]

]]>
567